svn commit: r314948 - in head: lib/libstand sys/boot/i386/libi386

[Andriy Gapon]

On 27/05/2017 15:56, Baptiste Daroussin wrote:
> 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
>>>
>>> Log:
>>>   Try to extract the RFC1048 data from PXE. If we get enough info we can skip
>>>   the bootp(). It removes unnecessary DHCP request from pxeloader.
>>>   
>>>   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
>>
>> Sorry for being late to the party, but this being head hopefully not too late.
>>
>> I am not sure that I agree with the spirit of this change.
>>
>> There are network boot setups that do depend on the "unnecessary" DHCP request
>> from pxeboot.  For example, a DHCP server could be configured to return a
>> different set of parameters depending on a particular PXE client.  I personally
>> use a configuration where the DCHP server sends a boot menu[*] to a PXE client
>> that's built into network cards.  If a FreeBSD boot is selected and pxeboot 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.
>>
>> 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-mode/
>> Using a separate PXE server is not uncommon in corporate environments too.
>>
>> In general, I think that the change was not thought through to cover scenarios
>> beyond the basic unattended, FreeBSD-only, single DHCP server network boots.
>> That scenario is, of course, very common, but it is not the only one.
>>
>> 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 cached
>> 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.
>>
>> And my apologies again for missing the original discussion.
>> My focus was somewhere else at the time.
>>
>> [*] It uses PXE_BOOT_MENU and PXE_MENU_PROMPT vendor options for that.
>>
>> References:
>> http://www.pix.net/software/pxeboot/archive/pxespec.pdf
> 
> I should have been all fixed in head (including some sugar added)
> 
> Can you confirm?

Yes, I can.  Thank you!
My setup works again.
I have some further local changes for which I will open a differential review
(or a few of them) soon.


-- 
Andriy Gapon