Using network informations from PXE as grub2 enviroment variables

Using network informations from PXE as grub2 enviroment variables

[Aleš Kapica]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

Dear friends,

You have missunderstood my previous post from Thu, 15 Oct 2009 08:52:01 +0200 when I post patch, which fixies problem with identification of the booting machine in network by IP address.
The following discussion have nothing to do with my post. I want to clarify porpose of my patch.

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.

In current state these informations is possible only to list, that means that they aren't a part of the grubs environment.
My patch solve this. Now is this possible to set PXE informations as grubs environment variables, and use in them in grub.cfg for identification of the booting machine.

Is there any problem with adding of my patch?

Aleš Kapica

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[-- Attachment #2: set_pxeinfo_into_enviroment_variables.diff --]
[-- Type: application/octet-stream, Size: 1657 bytes --]

diff --git a/grub2/commands/i386/pc/pxecmd.c b/grub2/commands/i386/pc/pxecmd.c
index df53870..066d9a0 100644
--- a/grub2/commands/i386/pc/pxecmd.c
+++ b/grub2/commands/i386/pc/pxecmd.c
@@ -22,12 +22,14 @@
 #include <grub/misc.h>
 #include <grub/machine/pxe.h>
 #include <grub/extcmd.h>
+#include <grub/env.h>
 
 static const struct grub_arg_option options[] =
 {
     {"info", 'i', 0, "show PXE information.", 0, 0},
     {"bsize", 'b', 0, "set PXE block size", 0, ARG_TYPE_INT},
     {"unload", 'u', 0, "unload PXE stack.", 0, 0},
+    {"set", 's', 0, "set network variables PXE_IP etc.", 0, 0},
     {0, 0, 0, 0, 0, 0}
   };
 
@@ -43,6 +45,15 @@ print_ip (grub_uint32_t ip)
     }
   grub_printf ("%d", ip);
 }
+static void
+set_ip2env_var(char *var_name, grub_uint32_t ip)
+{
+	char s[20];
+	grub_sprintf (s,"%d.%d.%d.%d", (ip>>0)&0xFF,
+		(ip>>8)&0xFF, (ip>>16)&0xFF, (ip>>24)&0xFF);
+	grub_env_set (var_name, s);
+}
+
 
 static grub_err_t
 grub_cmd_pxe (grub_extcmd_t cmd, int argc __attribute__ ((unused)),
@@ -78,6 +89,13 @@ grub_cmd_pxe (grub_extcmd_t cmd, int argc __attribute__ ((unused)),
       grub_printf ("\n");
     }
 
+  if (state[3].set)
+    {
+		set_ip2env_var ("pxe_your_ip", grub_pxe_your_ip);
+		set_ip2env_var ("pxe_server_ip", grub_pxe_server_ip);
+		set_ip2env_var ("pxe_gateway_ip", grub_pxe_gateway_ip);
+	}
+
   if (state[2].set)
     grub_pxe_unload ();
 
@@ -89,7 +107,7 @@ static grub_extcmd_t cmd;
 GRUB_MOD_INIT(pxecmd)
 {
   cmd = grub_register_extcmd ("pxe", grub_cmd_pxe, GRUB_COMMAND_FLAG_BOTH,
-			      "pxe [-i|-b|-u]",
+			      "pxe [-i|-b|-u|-s']",
 			      "Command to control the PXE device.", options);
 }
 

Re: Using network informations from PXE as grub2 enviroment variables

[Vladimir 'phcoder' Serbinenko]

Aleš Kapica wrote:
> Dear friends,
>
> You have missunderstood my previous post from Thu, 15 Oct 2009
> 08:52:01 +0200 when I post patch, which fixies problem with
> identification of the booting machine in network by IP address.
> The following discussion have nothing to do with my post. I want to
> clarify porpose of my patch.
>
> 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.
>
I let someone more familiar with PXE than me to answer this.
> In current state these informations is possible only to list, that
> means that they aren't a part of the grubs environment.
> My patch solve this. Now is this possible to set PXE informations as
> grubs environment variables, and use in them in grub.cfg for
> identification of the booting machine.
>
> Is there any problem with adding of my patch?
>
I've looked into your first patch. The idea is good however patch has
some problems:
1) Don't hardcode array sizes. Use sizeof ("XXX.XXX.XXX.XXX") instead
2) Exporting variables shouldn't require user to run a command. Just
export them as soon as possible (e.g. on module load)
3) "your_ip" is problematic name. I would prefer "local_ip" and "remote_ip"
> Aleš Kapica
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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 

Re: Using network informations from PXE as grub2 enviroment variables

[Pavel Pisa]

Forwarding Pavel Pisa's e-mail to the subscribers only list.

On Friday 16 October 2009 13:57:47 Vladimir 'phcoder' Serbinenko wrote:
> Aleš Kapica wrote:
> > Dear friends,

Hello Vladimir and other GRUB2 developers,

I am replying to your review as one of the patch authors.

> > 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.
>
> 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.

As for scalability, I agree, that use of single config file with checking
for each IP is horrible hack, but there is no problem to source
to another IP specific file (menu-xxx.xxx.xxx.xxx.lst) with separate
menu configuration when own IP is known and if file is not found
switch do default one.

The knowledge of own IP can be even win in other situations.
We use same diskless bootup setup provided by single server
 from multiple networks connected through more VLANs. The server
provids NFS root through direct connection to the more subnets
behind local firewall and server IP is different for these subnets.
The knowledge of pxe_sever_ip from DHCP provides a simple way
to use same conjfiguration with Linux commandline adjusted for right
server IP for each subnet direct connection.

So I strongly vote for a way to be able to use server IP provided
by DHCP/PXE.

The implementation details are other story. I have almost no Grub
programming experience and I am prepared to follow your suggestions.

> > In current state these informations is possible only to list, that
> > means that they aren't a part of the grubs environment.
> > My patch solve this. Now is this possible to set PXE informations as
> > grubs environment variables, and use in them in grub.cfg for
> > identification of the booting machine.
> >
> > Is there any problem with adding of my patch?
>
> I've looked into your first patch. The idea is good however patch has
> some problems:
> 1) Don't hardcode array sizes. Use sizeof ("XXX.XXX.XXX.XXX") instead
Yes, that a good idea, may it be add +1 or +2 for safety even that
not required.
> 2) Exporting variables shouldn't require user to run a command. Just
> export them as soon as possible (e.g. on module load)
I am not sure  about module initialization order, if the module is integrated
to the main grub image. Is it ensured, that internal PXE C variables are set
before any module is loaded? May it be, better solution would be to
ensure unconditional variables setting if PXE base is used. But is the
environment variables subsystem ready at that time? My knowledge
is not deep enough to reply to these without longer analysis so I would
take this safe approach.
> 3) "your_ip" is problematic name. I would prefer "local_ip" and "remote_ip"

I agree that name is strange but I tried to follow names already used in
the sources. My personal vote would be to have "station_ip" and "server_ip"
but I do not see this so much important. Feel free to modify or suggest
names according your preferences.

If you prefer to receive new patch version, we will prepare and test
it in university labs and VLANs infrastructure on Monday.

By the way we have experienced some troubles with actual kernel image
load over PXE with our motherboards. Short files reading and typing over
PXE has no problems. Has somebody this experience. Can that be PXE
mainboard firmware bug?

Thanks in advance,


                 Pavel Pisa
     e-mail:     pisa@cmp.felk.cvut.cz
     www:        http://cmp.felk.cvut.cz/~pisa
     university: http://dce.felk.cvut.cz/
     company:    http://www.pikron.com/

Re: Using network informations from PXE as grub2 enviroment variables

[Seth Goldberg]

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.  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

Re: Using network informations from PXE as grub2 enviroment variables

[Vladimir 'phcoder' Serbinenko]

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 

Re: Using network informations from PXE as grub2 enviroment variables

[Seth Goldberg]

Quoting Vladimir 'phcoder' Serbinenko, who wrote the following on Fri, 16...:

> 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

  We'll need a flag bit indicating the presence of network boot information. 
After that, define a field that's a pointer to a structure of the form:

struct netbootinfo {
 	int	type;	/* 0 = PXE; 1 = RARP/BOOTP */
 	void	*data;	/* Pointer to the boot-protocol-specific data */
 			/* In the PXE case, that's a DHCPACK frame; */
 			/* In the RARP/BOOTP case, it's a BOOTP reply */

 	struct netbootinfo *next;	/* Link to next netbootinfo structure */
};

   I know you don't like linked lists/pointers in the multiboot structure, so 
we can specify an array of these structures, but that's a bit inefficient (and 
embedding a union of types could waste even more space).

  --S

Re: Using network informations from PXE as grub2 enviroment variables

[Brendan Trotter]

Hi,

On Sat, Oct 17, 2009 at 4:42 AM, Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote:
> As for scalability, I agree, that use of single config file with checking
> for each IP is horrible hack, but there is no problem to source
> to another IP specific file (menu-xxx.xxx.xxx.xxx.lst) with separate
> menu configuration when own IP is known and if file is not found
> switch do default one.

> So I strongly vote for a way to be able to use server IP provided
> by DHCP/PXE.

I vote for using the ethernet card's MAC address (which never changes)
instead of whatever IP address the DHCP server felt like *dynamically*
assigning...

GRUB could (should?) download a configuration file from the TFTP
server that's called "123456789ABC.cfg" or "123456789ABC/grub.cfg"
(where "123456789ABC" is the ethernet card's MAC address) ; and if
that's not found it should try something like "default.cfg".

Putting the ethernet card's MAC address and the current IP address
into an environment variable (e.g. for use in command line parameters)
might be fun too.

Note 1: the easiest way to find the ethernet card's MAC address and
the computer's IP address is to use the "GET_CACHED_INFO" function
(opcode 7), with the Packet type field set to 2 (DHCP ACK from
server); because you need to use this function to find the IP address
of the TFTP server anyway.

Note 2: the name "your_ip" probably came from the PXE specification.


Cheers,

Brendan

Re: Using network informations from PXE as grub2 enviroment variables

[Seth Goldberg]

Hi,

   Solaris has adopted the following search path for configuration files:

  (1) DHCP Option 150
  (2) menu.lst.01<MACADDR> (i.e. menu.lst.01XXXXXXXXXXXX)
  (3) menu.lst.<BootFile> (where BootFile is the DHCP server-specified BootFile
      option)
  (4) menu.lst

  This has served use and our customers very well and it would be great if 
GRUB2 could adopt this scheme as well (I'm working on a patch).

  Thanks,
  --S

Quoting Brendan Trotter, who wrote the following on Tue, 20 Oct 2009:

> Hi,
>
> On Sat, Oct 17, 2009 at 4:42 AM, Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote:
>> As for scalability, I agree, that use of single config file with checking
>> for each IP is horrible hack, but there is no problem to source
>> to another IP specific file (menu-xxx.xxx.xxx.xxx.lst) with separate
>> menu configuration when own IP is known and if file is not found
>> switch do default one.
>
>> So I strongly vote for a way to be able to use server IP provided
>> by DHCP/PXE.
>
> I vote for using the ethernet card's MAC address (which never changes)
> instead of whatever IP address the DHCP server felt like *dynamically*
> assigning...
>
> GRUB could (should?) download a configuration file from the TFTP
> server that's called "123456789ABC.cfg" or "123456789ABC/grub.cfg"
> (where "123456789ABC" is the ethernet card's MAC address) ; and if
> that's not found it should try something like "default.cfg".
>
> Putting the ethernet card's MAC address and the current IP address
> into an environment variable (e.g. for use in command line parameters)
> might be fun too.
>
> Note 1: the easiest way to find the ethernet card's MAC address and
> the computer's IP address is to use the "GET_CACHED_INFO" function
> (opcode 7), with the Packet type field set to 2 (DHCP ACK from
> server); because you need to use this function to find the IP address
> of the TFTP server anyway.
>
> Note 2: the name "your_ip" probably came from the PXE specification.
>
>
> Cheers,
>
> Brendan
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: Using network informations from PXE as grub2 enviroment variables

[Vladimir 'phcoder' Serbinenko]

Brendan Trotter wrote:
> Hi,
>
> On Sat, Oct 17, 2009 at 4:42 AM, Pavel Pisa <pisa@cmp.felk.cvut.cz> wrote:
>   
>> As for scalability, I agree, that use of single config file with checking
>> for each IP is horrible hack, but there is no problem to source
>> to another IP specific file (menu-xxx.xxx.xxx.xxx.lst) with separate
>> menu configuration when own IP is known and if file is not found
>> switch do default one.
>>     
>
>   
>> So I strongly vote for a way to be able to use server IP provided
>> by DHCP/PXE.
>>     
>
> I vote for using the ethernet card's MAC address (which never changes)
> instead of whatever IP address the DHCP server felt like *dynamically*
> assigning...
>
> GRUB could (should?) download a configuration file from the TFTP
> server that's called "123456789ABC.cfg" or "123456789ABC/grub.cfg"
> (where "123456789ABC" is the ethernet card's MAC address) ; and if
> that's not found it should try something like "default.cfg".
>
>   
As a free software project we should avoid hardcoding configuration. Let
sysadmin decide how he wants to configure his boot
> Putting the ethernet card's MAC address and the current IP address
> into an environment variable (e.g. for use in command line parameters)
> might be fun too.
>   
Just exporting them and doing sth like
if [ test -f $prefix/grub.cfg.$pxe_mac ]; then
   configfile $prefix/grub.cfg.$pxe_mac
else
   configfile $prefix/grub.cfg.generic
fi
is enough
> Note 1: the easiest way to find the ethernet card's MAC address and
> the computer's IP address is to use the "GET_CACHED_INFO" function
> (opcode 7), with the Packet type field set to 2 (DHCP ACK from
> server); because you need to use this function to find the IP address
> of the TFTP server anyway.
>
> Note 2: the name "your_ip" probably came from the PXE specification.
>
>
> Cheers,
>
> Brendan
>
>
> _______________________________________________
> 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