Problems booting Linux via PXE

Problems booting Linux via PXE

[Turner, Ian]

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

I'm having some trouble using GRUB to boot Linux via PXE. It seems that for some reason the call to the PXE BIOS fails when retrieving the third packet of the Linux kernel. I don't have this problem loading multiboot kernels or GRUB modules. This is using GRUB 1.98.

I've seen the problem on all three servers where I've tested, which are as follows:
- A Sun Fire X4100
  - with four Dual Core AMD Opteron(tm) Processor 285 SE
  - Running Intel Boot Agent GE 1.2.50
            Intel Boot Agent PXE Base Code (PXE-2.1 build 086)
- A Sun Fire X4150
  - with two Intel X5440 processors
  - Running Intel Boot Agent GE 1.2.42
            Intel Boot Agent PXE Base Code (PXE-2.1 build 085)
- A Dell PowerEdge R610
  - With two Intel X5570 processors
  - Running Broadcom NetXtreme II Ethernet Boot Agent v5.0.5
            Broadcom UNDI PXE-2.1 v5.0.5
            Broadcom Base Code PXE-2.1 v1.1.1

On the Sun servers, the relevant call to grub_pxe_call(GRUB_PXENV_TFTP_READ) at fs/i386/pc/pxe.c:300 simply does not return. On the Dell server, some dots (2-200) are printed to the console at the time this call is placed, and sometimes the call does return, but with a (invalid) status code of 65536. Other times the call hangs after printing the dots.

Looking at loader/i386/linux.c, the grub_file_read() at line 638 works, as does the one at line 698. It's the third read, at line 891, which creates the failure.

I should emphasize that the PXE code seems to work fine for everything else. I am able to load dozens of GRUB modules, multiple configuration files, and multiboot and linux16 kernels with no problem. It's only the bzImage that seems to create trouble, and only the third packet of that image. It doesn't seem to matter what kernel I use; at least, I see this problem with RHEL kernels from 5.2 up to 5.5.

I hypothesize that something between linux.c line 698 and linux.c line 891 writes to a region of memory reserved by the PXE bios. Is there a way to test this theory?

Has anyone else been able to make this work? Is there something simple that I am missing? I would love to hear your thoughts. Also, if I should take this over to grub-help or grub-bugs, let me know.

Cheers,

--Ian Turner


[-- Attachment #2: Type: text/html, Size: 4421 bytes --]

Re: Problems booting Linux via PXE

[Omni Flux]

I am able to reproduce this with GRUB2 1.97~beta3-1~bpo50+1 from Debian 
backports attempting to boot the current Debian Lenny net installer 
kernels (32-bit and 64-bit) on several machines.

A packet capture shows the tftp server sending block 3 of the kernel 
several times with no response from the client.

This did work with some version of grub2 and the D-I linux kernel in the 
past.

If I can make time, I will try to test with the current version in the 
repository later tonight.

-- 
Omni Flux

On 2010-08-25 13:02, Turner, Ian wrote:
> I’m having some trouble using GRUB to boot Linux via PXE. It seems that
> for some reason the call to the PXE BIOS fails when retrieving the third
> packet of the Linux kernel. I don’t have this problem loading multiboot
> kernels or GRUB modules. This is using GRUB 1.98.
> I’ve seen the problem on all three servers where I’ve tested, which are
> as follows:
> - A Sun Fire X4100
> - with four Dual Core AMD Opteron(tm) Processor 285 SE
> - Running Intel Boot Agent GE 1.2.50
> Intel Boot Agent PXE Base Code (PXE-2.1 build 086)
> - A Sun Fire X4150
> - with two Intel X5440 processors
> - Running Intel Boot Agent GE 1.2.42
> Intel Boot Agent PXE Base Code (PXE-2.1 build 085)
> - A Dell PowerEdge R610
> - With two Intel X5570 processors
> - Running Broadcom NetXtreme II Ethernet Boot Agent v5.0.5
> Broadcom UNDI PXE-2.1 v5.0.5
> Broadcom Base Code PXE-2.1 v1.1.1
> On the Sun servers, the relevant call to
> grub_pxe_call(GRUB_PXENV_TFTP_READ) at fs/i386/pc/pxe.c:300 simply does
> not return. On the Dell server, some dots (2-200) are printed to the
> console at the time this call is placed, and sometimes the call does
> return, but with a (invalid) status code of 65536. Other times the call
> hangs after printing the dots.
> Looking at loader/i386/linux.c, the grub_file_read() at line 638 works,
> as does the one at line 698. It’s the third read, at line 891, which
> creates the failure.
> I should emphasize that the PXE code seems to work fine for everything
> else. I am able to load dozens of GRUB modules, multiple configuration
> files, and multiboot and linux16 kernels with no problem. It’s only the
> bzImage that seems to create trouble, and only the third packet of that
> image. It doesn’t seem to matter what kernel I use; at least, I see this
> problem with RHEL kernels from 5.2 up to 5.5.
> I hypothesize that something between linux.c line 698 and linux.c line
> 891 writes to a region of memory reserved by the PXE bios. Is there a
> way to test this theory?
> Has anyone else been able to make this work? Is there something simple
> that I am missing? I would love to hear your thoughts. Also, if I should
> take this over to grub-help or grub-bugs, let me know.
> Cheers,
> --Ian Turner
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Problems booting Linux via PXE

[Omni Flux]

I am able to reproduce this with GRUB2 1.97~beta3-1~bpo50+1 from Debian 
backports attempting to boot the current Debian Lenny net installer 
kernels (32-bit and 64-bit) on several machines.

A packet capture shows the tftp server sending block 3 of the kernel 
several times with no response from the client.

This did work with some version of grub2 and the D-I linux kernel in the 
past.

If I can make time, I will try to test with the current version in the 
repository later tonight.

-- 
Omni Flux

On 2010-08-25 13:02, Turner, Ian wrote:
> I’m having some trouble using GRUB to boot Linux via PXE. It seems that
> for some reason the call to the PXE BIOS fails when retrieving the third
> packet of the Linux kernel. I don’t have this problem loading multiboot
> kernels or GRUB modules. This is using GRUB 1.98.
> I’ve seen the problem on all three servers where I’ve tested, which are
> as follows:
> - A Sun Fire X4100
> - with four Dual Core AMD Opteron(tm) Processor 285 SE
> - Running Intel Boot Agent GE 1.2.50
> Intel Boot Agent PXE Base Code (PXE-2.1 build 086)
> - A Sun Fire X4150
> - with two Intel X5440 processors
> - Running Intel Boot Agent GE 1.2.42
> Intel Boot Agent PXE Base Code (PXE-2.1 build 085)
> - A Dell PowerEdge R610
> - With two Intel X5570 processors
> - Running Broadcom NetXtreme II Ethernet Boot Agent v5.0.5
> Broadcom UNDI PXE-2.1 v5.0.5
> Broadcom Base Code PXE-2.1 v1.1.1
> On the Sun servers, the relevant call to
> grub_pxe_call(GRUB_PXENV_TFTP_READ) at fs/i386/pc/pxe.c:300 simply does
> not return. On the Dell server, some dots (2-200) are printed to the
> console at the time this call is placed, and sometimes the call does
> return, but with a (invalid) status code of 65536. Other times the call
> hangs after printing the dots.
> Looking at loader/i386/linux.c, the grub_file_read() at line 638 works,
> as does the one at line 698. It’s the third read, at line 891, which
> creates the failure.
> I should emphasize that the PXE code seems to work fine for everything
> else. I am able to load dozens of GRUB modules, multiple configuration
> files, and multiboot and linux16 kernels with no problem. It’s only the
> bzImage that seems to create trouble, and only the third packet of that
> image. It doesn’t seem to matter what kernel I use; at least, I see this
> problem with RHEL kernels from 5.2 up to 5.5.
> I hypothesize that something between linux.c line 698 and linux.c line
> 891 writes to a region of memory reserved by the PXE bios. Is there a
> way to test this theory?
> Has anyone else been able to make this work? Is there something simple
> that I am missing? I would love to hear your thoughts. Also, if I should
> take this over to grub-help or grub-bugs, let me know.
> Cheers,
> --Ian Turner
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Problems booting Linux via PXE

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 08/25/2010 09:02 PM, Turner, Ian wrote:
> I’m having some trouble using GRUB to boot Linux via PXE. It seems
> that for some reason the call to the PXE BIOS fails when retrieving
> the third packet of the Linux kernel. I don’t have this problem
> loading multiboot kernels or GRUB modules. This is using GRUB 1.98.
>  
Please avoid using HTML mail. Changing color of your text only makes it
annoying to read. This is plain-text mailing list even if no filters are
configured to strictly enforce that.
Could you try newreloc branch which is about to be merged?
> I’ve seen the problem on all three servers where I’ve tested, which
> are as follows:
> - A Sun Fire X4100
>   - with four Dual Core AMD Opteron(tm) Processor 285 SE
>   - Running Intel Boot Agent GE 1.2.50
>             Intel Boot Agent PXE Base Code (PXE-2.1 build 086)
> - A Sun Fire X4150
>   - with two Intel X5440 processors
>   - Running Intel Boot Agent GE 1.2.42
>             Intel Boot Agent PXE Base Code (PXE-2.1 build 085)
> - A Dell PowerEdge R610
>   - With two Intel X5570 processors
>   - Running Broadcom NetXtreme II Ethernet Boot Agent v5.0.5
>             Broadcom UNDI PXE-2.1 v5.0.5
>             Broadcom Base Code PXE-2.1 v1.1.1
>  
> On the Sun servers, the relevant call to
> grub_pxe_call(GRUB_PXENV_TFTP_READ) at fs/i386/pc/pxe.c:300 simply
> does not return. On the Dell server, some dots (2-200) are printed to
> the console at the time this call is placed, and sometimes the call
> does return, but with a (invalid) status code of 65536. Other times
> the call hangs after printing the dots.
>  
> Looking at loader/i386/linux.c, the grub_file_read() at line 638
> works, as does the one at line 698. It’s the third read, at line 891,
> which creates the failure.
>  
> I should emphasize that the PXE code seems to work fine for everything
> else. I am able to load dozens of GRUB modules, multiple configuration
> files, and multiboot and linux16 kernels with no problem. It’s only
> the bzImage that seems to create trouble, and only the third packet of
> that image. It doesn’t seem to matter what kernel I use; at least, I
> see this problem with RHEL kernels from 5.2 up to 5.5.
>  
> I hypothesize that something between linux.c line 698 and linux.c line
> 891 writes to a region of memory reserved by the PXE bios. Is there a
> way to test this theory?
>  
> Has anyone else been able to make this work? Is there something simple
> that I am missing? I would love to hear your thoughts. Also, if I
> should take this over to grub-help or grub-bugs, let me know.
>  
> Cheers,
>  
> --Ian Turner
>  
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Problems booting Linux via PXE

[Omni Flux]

Issue also exists in r2629 (current HEAD), 1.97.2, and 1.97. I jumped 
back to r1090 (1.96+2009-01-27) and it worked fine.

This leaves r1090-r1796 to bisect...10 revisions to try, I think, 
assuming each one otherwise works.

-- 
Omni Flux

On 2010-08-25 19:14, Omni Flux wrote:
> I am able to reproduce this with GRUB2 1.97~beta3-1~bpo50+1 from Debian
> backports attempting to boot the current Debian Lenny net installer
> kernels (32-bit and 64-bit) on several machines.
>
> A packet capture shows the tftp server sending block 3 of the kernel
> several times with no response from the client.
>
> This did work with some version of grub2 and the D-I linux kernel in the
> past.
>
> If I can make time, I will try to test with the current version in the
> repository later tonight.
>

Re: Problems booting Linux via PXE

[Omni Flux]

The newreloc branch resolves this issue for me; hopefully it does for 
Ian as well.

Thanks for pointing it out.

-- 
Omni Flux

On 2010-08-26 01:52, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 08/25/2010 09:02 PM, Turner, Ian wrote:
>> I’m having some trouble using GRUB to boot Linux via PXE. It seems
>> that for some reason the call to the PXE BIOS fails when retrieving
>> the third packet of the Linux kernel. I don’t have this problem
>> loading multiboot kernels or GRUB modules. This is using GRUB 1.98.
>>
> Please avoid using HTML mail. Changing color of your text only makes it
> annoying to read. This is plain-text mailing list even if no filters are
> configured to strictly enforce that.
> Could you try newreloc branch which is about to be merged?

Re: Problems booting Linux via PXE

[Bruce Edge]

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

On Thu, Aug 26, 2010 at 1:48 AM, Omni Flux
<omniflux+lists@omniflux.com<omniflux%2Blists@omniflux.com>
> wrote:

> The newreloc branch resolves this issue for me; hopefully it does for Ian
> as well.
>
> Thanks for pointing it out.
>
> --
> Omni Flux
>
>
I have also seen this issue but chalked it up to user error. (version
1.98-1ubuntu7) I watched wireshark traces show 3 pkts and stop. This was
from a Xen domU so I suspected a Xen problem at the time and gave up and
went to Xen's pv-grub instead that has a built-in tftp client.

Where can I retrieve a Grub2 branch that resolves this issue? An Ubuntu
package would be nice, but I'll take anything that builds.

Thanks

-Bruce



>
> On 2010-08-26 01:52, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>
>> On 08/25/2010 09:02 PM, Turner, Ian wrote:
>>
>>> I’m having some trouble using GRUB to boot Linux via PXE. It seems
>>> that for some reason the call to the PXE BIOS fails when retrieving
>>> the third packet of the Linux kernel. I don’t have this problem
>>> loading multiboot kernels or GRUB modules. This is using GRUB 1.98.
>>>
>>>  Please avoid using HTML mail. Changing color of your text only makes it
>> annoying to read. This is plain-text mailing list even if no filters are
>> configured to strictly enforce that.
>> Could you try newreloc branch which is about to be merged?
>>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 2512 bytes --]

Re: Problems booting Linux via PXE

[Omni Flux]

On 2010-08-26 09:06, Bruce Edge wrote:
> I have also seen this issue but chalked it up to user error. (version
> 1.98-1ubuntu7) I watched wireshark traces show 3 pkts and stop. This was
> from a Xen domU so I suspected a Xen problem at the time and gave up and
> went to Xen's pv-grub instead that has a built-in tftp client.
>
> Where can I retrieve a Grub2 branch that resolves this issue? An Ubuntu
> package would be nice, but I'll take anything that builds.
>
> Thanks
>
> -Bruce

I assumed user error on my part as well, until I saw someone else 
complain here...

You can checkout the newreloc branch from bazaar with the following command:

bzr branch http://bzr.savannah.gnu.org/r/grub/branches/newreloc/

I did the following to build and test it last night:

./autogen.sh
./configure
make
./grub-mkimage --directory=grub-core -O i386-pc --output=core.img 
--prefix="(pxe)/boot/grub" pxe pxecmd
cat grub-core/pxeboot.img grub-core/core.img > grub-core/grub2pxe
cp grub-core/*.mod /var/lib/tftpboot/boot/grub/
cp grub-core/*.lst /var/lib/tftpboot/boot/grub/
cp grub-core/grub2pxe /var/lib/tftpboot/boot/grub/

Your target directories will surely vary :)

-- 
Omni Flux

RE: Problems booting Linux via PXE

[Turner, Ian]

> On 08/25/2010 09:02 PM, Turner, Ian wrote:
> > I’m having some trouble using GRUB to boot Linux via PXE.

> Could you try newreloc branch which is about to be merged?

The newreloc branch solved the problem and allowed me to successfully boot Linux, but I noticed a few other problems getting the branch to compile:

1. 'make dist' is totally broken; I think this is because some files were moved around or just removed (e.g., kern/i386/loader.S) and the build scripts were never updated.

2. grub-core/kern/emu/misc.c seems to assume that libdevmapper will define dm_log_with_errno_init, which it does not on my system (RHEL 5.2). Configuring with --disable-device-mapper made this go away for me, since I don't need DM functionality.

3. It looks like grub does not compile properly if CFLAGS or LDFLAGS contains -m64 (standard in our environment); it's probably a good idea to consider checking for these at configure time.

Thanks for your help,

--Ian

Re: Problems booting Linux via PXE

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

On 08/27/2010 12:55 AM, Turner, Ian wrote:
>> On 08/25/2010 09:02 PM, Turner, Ian wrote:
>>     
>>> I’m having some trouble using GRUB to boot Linux via PXE.
>>>       
>   
>> Could you try newreloc branch which is about to be merged?
>>     
> The newreloc branch solved the problem and allowed me to successfully boot Linux, but I noticed a few other problems getting the branch to compile:
>
> 1. 'make dist' is totally broken; I think this is because some files were moved around or just removed (e.g., kern/i386/loader.S) and the build scripts were never updated.
>
>   
I corrected the failure of make dist but it's still broken (some files
not included)
> 2. grub-core/kern/emu/misc.c seems to assume that libdevmapper will define dm_log_with_errno_init, which it does not on my system (RHEL 5.2). Configuring with --disable-device-mapper made this go away for me, since I don't need DM functionality.
>   
Fixed.
> 3. It looks like grub does not compile properly if CFLAGS or LDFLAGS contains -m64 (standard in our environment); it's probably a good idea to consider checking for these at configure time.
>
>   
CFLAGS and LDFLAGS should have no such effect. Perhaps you set TARGET_*
variables as well? Those are meant for cross-compiling (and we actualy
cross-compile). Setting them to anything other than the options for
target architecture (in this case i386) would have an unpredictable
effect. And there is no way our build system can check for every
possible annoying parameter. My recomendation is GRUB to be excluded
from any default compile flags at packaging level.
> Thanks for your help,
>
> --Ian
>   
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]