Re: PXE-compliant boot server request?

Hi Marty!

On 2 Mar 2006, at 17:21, Marty Connor wrote:

> On Feb 28, 2006, at 3:24 PM, Roland Kuhn wrote:
>> Here's my first try: it works for me (TM), I've successfully  
>> booted several machines with this patch. The PXE boot menu is  
>> printed, but I've not implemented a selection, it uses always the  
>> first entry. I trust that someone knowing etherboot better than me  
>> can easily add a small question prompt with a timeout.
>>
>> The function principle is the following: If the DHCP reply  
>> contained vendor encapsulated options with a boot menu, we parse  
>> it and store it for later. In case of proxyDHCP only the packet  
>> from the proxy server is relevant. After that the server address  
>> given for the first boot menu item is queried on port 4011 using  
>> another DHCPREQUEST-type packet, including the selected boot item.  
>> The server sends back a DHCP reply with a filename and new  
>> options, which are copied to the KERNEL_BUFFER and BOOTP_DATA_ADDR  
>> respectively. From there on everything is as usual.
>>
>> This is used to implement a three phase booting: after the  
>> procedure outlined above an image like pxelinux is loaded, which  
>> in turn loads the kernel and initrd as configured on the boot  
>> server. The initrd contains boot scripts which configure the  
>> network using normal DHCP (without PXE extensions) and receive in  
>> the filename field e.g. the name of a kickstart installation  
>> config file. PXE extensions are necessary to facilitate this  
>> distinction between booting and installation and enable the usage  
>> of the filename field with two different values in different  
>> phases of the boot procedure.
>> Ciao,
>> Roland
>> <pxe.patch>
>
> Hi Roland,
>
> Thank you very much for the patch!
>
> The code looks good.  It's nicely structured, and clean.
> I'd like to have Michael Brown take a look at it, since he  
> implemented the PXE support, and knows the most about it.
>
> It would also be very nice to have a test case.  Can you think of  
> something relatively simple that will exercise the code?
> I'd like to try it here, but am not sure how to set it up.  It  
> looks like I need to run a proxyDHCP server as well as DHCP server.
>
No, a proxyDHCP is not needed, and in fact I also don't have one for  
testing. The setup is in principle not complicated: The DHCP server  
needs to send different replies based on who is asking: if the vendor  
ID is "PXEClient" (and so on), then provide the boot menu, else  
provide only IP. After having obtained the boot menu, the client is  
supposed to formulate another query, this time containing a selected  
boot menu item, upon which the final boot information is sent back  
(real boot file name). I have not tried to produce such a server  
behaviour myself, since the installation at CERN (where I use this  
stuff) works for me.

But there is a caveat: Reading the PXE spec I came to the conclusion  
that the unicast menu selection query to port 4011 must always be  
supported by the server, so I didn't implement the other two  
(broadcast and multicast to port 67). I don't know which DHCP servers  
besides the one used at CERN (with special patches) supports this...

> Also, when you say:
>
>> PXE extensions are necessary to facilitate this distinction  
>> between booting and installation and enable the usage of the  
>> filename field with two different values in different phases of  
>> the boot procedure.
>
> Did you mean that you had to create and implement extensions to  
> PXE, or that there were existing parts to PXE that were not  
> implemented in Etherboot, and you implemented them?
>
It was not my intention to create extensions to PXE, and I hope that  
I stayed within the PXE spec :-) But I did not implement the full  
specification.

> This is neat stuff.  Now we just have to document the capabilities  
> so people actually know what is possible.
>
Yes, you're right. As soon as I have a bit more time I'll do some  
more testing and document what I've been doing. But it might be a few  
weeks before I get around to it (our computers can be nicely  
installed, so now I have to _use_ them ;-) ).

Ciao,
                     Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
	-Doug Gwyn
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M 
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------