Re: Using network informations from PXE as grub2 enviroment variables

[Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>]

Seth Goldberg wrote:
> Hi,
>
> Quoting Pavel Pisa, who wrote the following on Fri, 16 Oct 2009:
>
>>>> Nobody can't use options 150 from DHCP, because GRUB2 don't have any
>>>> driver for network adapters. Network task are done only through
>>>> adapters PXE firmware. PXE passes informations only about IP
>>>> addresses, but no DHCP options.
>
>   Not true -- all DHCP options are available by inspecting the cached
> DHCPACK that is available from a call to PXE firmware.  This is a
> stable interface and works quite well.  In fact, we enhanced the
> Legacy GRUB we use in Solaris to pass the entire DHCPACK via the
> multiboot structure (albeit in a non-standard way -- and I'd like to
> rectify that by including the DHCPACK in the multiboot structure
> explicitly) so it can be used by the kernel.
Since you are familiar with networking and PXE could you make a
multiboot amendment proposal? It has to be
(a) expandable to new network interfaces (not only PXE), it includes the
necessity of passing info pertatining to multiple adapters and a way to
match this info to adapters (I think MAC is good for this)
(b) possibility to add custom information, not only what is specified by
DHCP standard. Vendor info encapsulation is perhaps a way. I'm not sure
we'll ever need this but I would like to have this possibility if we
ever need it
>   Note also that the EFI PXE wrapper also provides access to the
> cached DHCPACK.
>
>>>
>>> I let someone more familiar with PXE than me to answer this.
>>
>> The 150 option would be usesfull a lot, but I do not know PXE
>> good enough to support that. The PXE firmware seems to be
>> problematic (high probability of bugs and diversity) to me anyway
>> so we want to use as small subset as possible.
>
>   In our experience (booting Solaris using PXE firmware), for our
> uses, the firmware has been quite stable.  The trick it to ensure that
> you're using APIs that Microsoft uses -- that's the only way these
> APIs will be stable enough for general use.  This is the same story as
> with the multitude of BIOS calls -- as time has progressed, the only
> stable set of calls you can 100% rely on are that set that are used by
> Windows.
>
>  We've been using DHCP Option 150 extensively without a problem.  In
> fact, we made modification to Legacy GRUB to go a bit beyond Option
> 150, which includes a search order for finding the appropriate GRUB
> menu.  The search order is as follows (see the `solaris_config_file'
> in OpenSolaris's grub source base): (1) We look for DHCP option 150;
> (2) We look for menu.lst.01<MAC>  using the MAC address of the
> PXE-booted NIC; (3) We look for menu.lst.<BootFile> (but if BootFile
> is "pxelinux.{X}" we just use {X} for <BootFile>; (4) Finally, if
> those fail, we fall back on plain-old "menu.lst".
>
>  This allows a significant amount of customization, either at the DHCP
> server level, or based on the MAC of the requesting client.  Our
> install-server preparation scripts create the appropriate files
> automatically.
>
>   Since our customers have come to rely on this behavior, we will
> continue to offer these options (obviously, with different menu
> filenames, though).  It would be nice to include this functionality
> for all other GRUB2 users as well.
>
>   Thanks,
>  --S
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git