From nobody Sat Mar 18 19:34:37 2023 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PfB621WTbz3ywX4 for ; Sat, 18 Mar 2023 19:34:50 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PfB615MJfz3kms for ; Sat, 18 Mar 2023 19:34:49 +0000 (UTC) (envelope-from nagy.attila@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-17997ccf711so9289663fac.0 for ; Sat, 18 Mar 2023 12:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679168088; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=umR7rs7rqKQouVLgo7F9NUvj+vj8BkZ/Zi/O8lxxjM4=; b=BGoIjrszM71sDL3Ay0Z+inDNPVi4m92nraYHftt/XWyhJodftvVAP+x1tmRK3HduPG WJi+0r3aqEkyt6Iz2TbuPB+sof0Stfp1rdMyh+utUqaigHqzldgigv/h9lnUnIt3FxKy 6KzqzcmpC6Lkbg/00fuqKyiruApPfGsqMmSwYc3k6rzKudh9vsNkaGsmYNPnFSUTeZMF ORNz4EjT9M2WFq0sjJogai9IhkdYpCoeM17dgIU/WQta0zPN4OCbra+xCZ27CPWFCP6I pqerLYFJwZ7cGIFfoyHl1xh3tI5OuNcVpNV3DoA9NZmlepplKe+xJeJi69Cv+Xoy/CQi Z+Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679168088; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=umR7rs7rqKQouVLgo7F9NUvj+vj8BkZ/Zi/O8lxxjM4=; b=Hdup4F0kD0Rk+tgKHB4HNiNOL5iEQFWflwdftNI3e+2PFn+LTahZPeVNjECC65vj1W bzUIxmBmgfK+gRTP/BlocWCkefnBc8uvhodjp0fjobAqtg47AbZe0fOP19mUfl7HjcvJ Q7mbw8eo0N1ksFwwsUZCmxwTzf0CN1ekEiVd/oTFlyiVvu84xtz7d5FIeWFtDnurHMDS wPCZqGybDBYcwIPdVckE/qmsV+S7e35gJwGutqRYlIwBc/5+DXf+6sbIOw+Us02dKf2p mZWpva+IZ4hATDGEpKFwfp43j7XwhzhwSlfr6BmAAFTCGBpZGoYV27qI6gSjNrHg3c71 avgg== X-Gm-Message-State: AO0yUKWoL0RxjkMh1irBvgba3X7sanlq2T/m/yDoO1D6ku4/oFXbkjsw 7cRG6fd79mAfNfvIyC2lIoqkSOnJoTsojVbQe/A= X-Google-Smtp-Source: AK7set+LcpraY3+T1/RDe5MKXTiH4NVDjfVz35zuG1aEDskgMhFEg/fIXM0oUN6Erqtcs9PbhP1UGLVI7Puj6e57kJw= X-Received: by 2002:a05:6871:8689:b0:17b:1895:a637 with SMTP id ta9-20020a056871868900b0017b1895a637mr838943oab.11.1679168088211; Sat, 18 Mar 2023 12:34:48 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: <0b95a502-eea0-46cc-5d0d-ec6e861ad51f@marco.de> In-Reply-To: From: Attila Nagy Date: Sat, 18 Mar 2023 20:34:37 +0100 Message-ID: Subject: Re: Kernel DHCP unpredictable/fails (PXE boot), userspace DHCP works just fine To: Daniel Braniss Cc: stable@freebsd.org Content-Type: multipart/alternative; boundary="0000000000006a845605f731c9f3" X-Rspamd-Queue-Id: 4PfB615MJfz3kms X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2001:4860:4864::/48, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000006a845605f731c9f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Daniel Braniss ezt =C3=ADrta (id=C5=91pont: 2023. m= =C3=A1rc. 18., Szo, 10:56): > take look at src/stand/libsa/bootp.c, there is a compile option that > allows many > more options to be transferred via dhcp =E2=80=A6 > Without the kernel BOOTP/DHCP, this (doing the DHCP from userspace, from /etc/rc.d/dhclient) is somewhat late for rc.initdiskless to pick them up, no? I mean how would you use that to have the same support for classes in rc.initdiskless? > > BTW, where possible I=E2=80=99m moving to uefi, since pxeboot is failing= with > file to large =E2=80=A6 > Does that make any changes here? rc.initdiskless is called very early in the boot process and kern.bootp_cookie won't exist (there wouldn't be a hostname either I think, which I also rely on with the in-kernel DHCP). --0000000000006a845605f731c9f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Daniel Braniss <danny@cs.huji.ac.il> ezt =C3=ADrta (id=C5=91pon= t: 2023. m=C3=A1rc. 18., Szo, 10:56):
take look at src/stand/libsa/bootp.c, there is a= compile option that allows many
more options to be transferred via dhc= p =E2=80=A6=C2=A0
Without the kernel BOOTP/DHC= P, this (doing the DHCP from userspace, from /etc/rc.d/dhclient) is somewha= t late for rc.initdiskless to pick them up, no?
I mean how would = you use that to have the same support for classes in rc.initdiskless?
=C2=A0
=

BTW, where possible I=E2=80=99m moving =C2=A0to ue= fi, since pxeboot is failing with file to large =E2=80=A6
Does that make any changes here? rc.initdiskless is called very= early in the boot process and kern.bootp_cookie won't exist (there wou= ldn't be a hostname either I think, which I also rely on with the in-ke= rnel DHCP).
--0000000000006a845605f731c9f3--