Date: Fri, 26 May 2017 23:09:09 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Andriy Gapon <avg@FreeBSD.org> Cc: Mariusz Zaborski <oshogbo@FreeBSD.org>, Steven Hartland <smh@FreeBSD.org>, "George V. Neville-Neil" <gnn@FreeBSD.org>, Toomas Soome <tsoome@FreeBSD.org>, freebsd-net@FreeBSD.org, kczekirda@FreeBSD.org Subject: Re: svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386 Message-ID: <20170526210908.ykqalqbetxp4f27p@ivaldir.net> In-Reply-To: <c5f695ad-53f8-b5cd-2b20-d3eeefddf7bb@FreeBSD.org> References: <201703090601.v2961OJx077853@repo.freebsd.org> <c5f695ad-53f8-b5cd-2b20-d3eeefddf7bb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--mb35fwzxs6poyq4t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 26, 2017 at 12:27:45PM +0300, Andriy Gapon wrote: > On 09/03/2017 08:01, Mariusz Zaborski wrote: > > Author: oshogbo > > Date: Thu Mar 9 06:01:24 2017 > > New Revision: 314948 > > URL: https://svnweb.freebsd.org/changeset/base/314948 > >=20 > > Log: > > Try to extract the RFC1048 data from PXE. If we get enough info we ca= n skip > > the bootp(). It removes unnecessary DHCP request from pxeloader. > > =20 > > Submitted by: kczekirda > > Sponsored by: Oktawave > > Initiated by: Matthew Dillon > > Reviewed by: smh, gnn, bapt, oshogbo > > MFC after: 3 weeks > > Differential Revision: https://reviews.freebsd.org/D9847 >=20 > Sorry for being late to the party, but this being head hopefully not too = late. >=20 > I am not sure that I agree with the spirit of this change. I just figured out it also breaks chainloading with ipxe (like qemu does) a= nd it does not request the rootpath if not passed to the ipxe first. I'm now really thinking the our loader deserves its own DHCP value. We should also give it some tags so people can provide it the information t= hey want depending on the tags (like hey this is the fbsd loader give it that rootpath). >=20 > There are network boot setups that do depend on the "unnecessary" DHCP re= quest > from pxeboot. For example, a DHCP server could be configured to return a > different set of parameters depending on a particular PXE client. I pers= onally > use a configuration where the DCHP server sends a boot menu[*] to a PXE c= lient > that's built into network cards. If a FreeBSD boot is selected and pxebo= ot is > started, then the server sends parameters required for the FreeBSD boot > (root-path, etc) in response to the request from pxeboot. > I don't see how I can keep that working after this change. >=20 > Additionally, as far as I can tell, we only get cached > PXENV_PACKET_TYPE_BINL_REPLY. This might cause a problem in environments= where > a separate PXE server (Proxy DHCP) is used. In that case the reply might= not > have the network configuration information which would actually be in > PXENV_PACKET_TYPE_DHCP_ACK. > An example of such a setup is described here: > https://n0dy.com/blog/2014/09/14/network-booting-with-dnsmasq-in-proxy-mo= de/ > Using a separate PXE server is not uncommon in corporate environments too. >=20 > In general, I think that the change was not thought through to cover scen= arios > beyond the basic unattended, FreeBSD-only, single DHCP server network boo= ts. > That scenario is, of course, very common, but it is not the only one. >=20 > At minimum, I would like to have a compile time option to control whether > pxeboot should send a DHCP request of its own or rely entirely on the cac= hed > information. Or maybe pxeboot could be smart enough to do the former if = the > cached reply is missing some required information like the root-path. > Right now, there is no bootp(BOOTP_PXE) under any conditions. >=20 > And my apologies again for missing the original discussion. > My focus was somewhere else at the time. >=20 > [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that. >=20 --mb35fwzxs6poyq4t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkomWcACgkQY4mL3PG3 Plp1URAAjTMDuyo/Hiy5a/+bMMw808gM3RFVskFM6C4e+5f9Aji+2dUSHVLtIBSL SXeUN95FuQOMk920h9wzPOJg7sLM4fuoT2L2F8rwjeopd04y/S6FkZCE0ohjFBSP +ZwcCI3vaq+Ue40BbdVfZCr/+Ygs+7Kj9YLu2CAOlH2LvBchYeXxqzmxCcrNudE0 vJr5Gcp6wo2lN85SxkwV//bkGkiUAAnUO6hHpRX35yWxMgWuyBaiVSlP7BzfGMkr QtEl7j2coIgwwAW5dOTG0FQG+TDnyB3CFC/47NTPg0zRk+xp+Pj2xXP3H9RA+Lyp PeMGizc/vJ5gaPw/NsOKj0za91JXDS6Ki5QNiaIFciUj1IlGn2PlhjgXtgD2mYTV bw2UdFF0NWPWLT9ku66XfT6xQdWMF4GXsoeut+6WyjzebB0DJwRNujL5u6Ngs6uj itMMfatCqudZQHrLZMpZzpjq+/8o6QOafF64gWhB7VCXTLYIq2YgaGW2vX2R2zWW d4wKyx4YaaESjF4zriFhQ1QnZyZYj11EoDNyNRqQwqudoTd9Tv2EUpOdvlb/yljD XH5sERr6KwG83KIuQNqMAEj5z9Q+VxyfWEy1wKoAEVw4wJ/I5rM6jbNvYD9h08uI A5So7Mwcs9aVRvnDJWtDSRh1DBP36H5tRweuyAp5cDHMhFlZIEw= =VvHH -----END PGP SIGNATURE----- --mb35fwzxs6poyq4t--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170526210908.ykqalqbetxp4f27p>