bugGNU GRUB - Bugs: bug #43396, TFTP boot: error: time out opening...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #43396: TFTP boot: error: time out opening '/grub/i386-pc/normal.mod'

Submitted by:  Daniel Dehennin <nebuchadnezzar>
Submitted on:  Fri 10 Oct 2014 07:54:05 AM UTC  
 
Category:  Network Severity:  Major
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Closed Release: 
Release:  Git master Reproducibility:  None
Planned Release:  None

( Jump to the original submission)

Tue 19 Jul 2016 06:36:01 AM UTC, comment #17: 

I do not know. Please ask Ubuntu and request to include this fix. Feel free to reopen this bug if you still observe this problem with current git master.

Andrei Borzenkov <arvidjaar>
Project Member
Mon 18 Jul 2016 05:25:00 PM UTC, comment #16: 

Thanks for getting back to me.

I am using GRUB version 2.02~beta2-9 (Ubuntu signed grub) do you know if this fix is implemented in it?

The reason why i can't build my own grub binary is because i am working on PXE boot that will be compatible with secure boot so i need a signed grub in order to be able to PXE boot when secure boot is enabled

Robster <rabih9780>
Mon 18 Jul 2016 04:59:15 PM UTC, comment #15: 

As you can see the fix is implemented. Make sure to use at least 2.02~beta3.

Andrei Borzenkov <arvidjaar>
Project Member
Mon 18 Jul 2016 03:48:35 PM UTC, comment #14: 

anyone willing to give an advice on what to do if i am still having this issue...

more info on this issue

1. DHCP and PXE server are NOT on the same subnet
2. Grub time out when it TFTP cause it is trying to TFTP to an invalid server (It tries to TFTP to the firewalll)

Robster <rabih9780>
Fri 15 Jul 2016 09:55:43 PM UTC, comment #13: 

I am still having the same problem, I am using a DHCP relay. Do you know when this fix will be implemented?

Thanks a lot :)

Robster <rabih9780>
Fri 17 Jul 2015 04:51:14 PM UTC, comment #12: 

Sorry for not replying sooner:

Yes, I used a DHCP releay which is the client default GATEWAY.

I'll give a try to the patch next week.

Thanks a lot.

Daniel Dehennin <nebuchadnezzar>
Sun 17 May 2015 07:40:41 PM UTC, comment #11: 

Fixed in a666c8bd18aee7bf1b202b6b8c0ffe953bd2c1b6. Thank you for finding root cause!

Andrei Borzenkov <arvidjaar>
Project Member
Sun 17 May 2015 07:23:49 PM UTC, comment #10: 

Patch works correctly; the code comments are spot-on as well. Consider this a +1 for committing it.

Rink Springer <rnk>
Sun 17 May 2015 07:15:46 PM UTC, comment #9: 

Please test attached patch. I left code ifdef'd out in case we hit regression.

(file #34034)

Andrei Borzenkov <arvidjaar>
Project Member
Sun 17 May 2015 07:10:04 PM UTC, comment #8: 

Andrei, yes 10.13.13.254 is the relay and 10.22.11.1 is the DHCP server itself. I've captured 'dhcp.pcap' on the DHCP server itself, the other capture was made using a host on a mirrored port.

The 'rogue address' is indeed the relay, and AFAICT GRUB shouldn't even try to talk to it - as I understand it, the gateway field giaddr (RFC 2131 describes it as 'Relay agent IP address') is used so that the DHCP server can know which network to use (which makes sense, how else can the server know which range to use?)

It seems to me that the confusion is that in BOOTP, giaddr indeed was a gateway IP address (at least, my quick scan of RFC 951 leads me to conclude that). For DHCP, it is used for relaying and options are used to provide the routers, as Vladimir also states.

I'd propose that a fix is to ignore giaddr in the DHCP case, as it is meaningless to the client - yet, in the BOOTP case, traffic still shouldn't go to the default gateway, but the client cannot know this because the network mask isn't known...

Rink Springer <rnk>
Sun 17 May 2015 06:58:58 PM UTC, comment #7: 

@Rink: is 10.13.13.254 address of DHCP relay? Did you capture this on LAN between relay and DHCP server?

Unfortunately original trace does not include DHCP replies as well, but it has final ARP for rogue address which is very similar to what you observe.

Andrei Borzenkov <arvidjaar>
Project Member
Sun 17 May 2015 06:47:30 PM UTC, comment #6: 

AFAIR the meaning of field gateway is specifically on how to reach boot server. This is in contrast with the option "default route" which is for communications with other subnets

Vladimir Serbinenko <phcoder>
Project Administrator
Sun 17 May 2015 06:35:47 PM UTC, comment #5: 

@Andrei, the DHCP server is on another subnet. DHCP relaying is provided by a Cisco 2960G, which cannot perform IPv4 routing (nor does it need to, in this case). The DHCP server is isc-dhcpd-server 4.2.4.

I've added a capture of what the DHCP server receives and responds (dhcp.pcap). However, in my opinion, GRUB shouldn't attempt to use the gateway for hosts which are on its own subnet.

As a workaround, I've tried to add 10.13.13.2 as default gateway, but this makes no difference. I've hacked net.c to dump the routing table (by just calling grub_cmd_listroutes() prior to grub_net_route_address()'s return) and this yields:

pxe:local 10.13.13.0/24 pxe
pxe 10.13.13.254/32 pxe
pxe:gw 10.13.13.2/32 gw 10.13.13.254

The final line is what worries me: why is it forcing to use the  gateway for something that it knows is on its local network?

@Daniel, are you using DHCP relay as well (it seems you are) - otherwise, I may have hijacked your bug report, apologies if this is the case.

(file #34033)

Rink Springer <rnk>
Sun 17 May 2015 12:00:50 PM UTC, comment #4: 

@Rink: Where is your DHCP server? Is it on different subnet? If yes, do you know what is your DHCP relay?

Full pcap including DHCP server replies would be extremely useful.

Andrei Borzenkov <arvidjaar>
Project Member
Sun 17 May 2015 10:05:32 AM UTC, comment #3: 

I'm hitting the exact same issue -and dug a little further: note how the pcap file ends with an ARP query for .254. I expect this to be the gateway IP address (the DHCP reply doesn't seem to be in the packet dump).

I've attached my own dump (rnk-dump.pcap) to this report, where:

- 10.13.13.2 = TFTP server
- 10.13.13.254 = gateway IP
- 10.13.13.34 = client

As can be seen, initially it all goes well. However, once core.0 has been loaded, an ARP is done for the gateway address - and traffic intended for 10.13.13.2 is instead sent to the gateway address.

This seems wrong to me - both the client and server are on the same subnet, so there is no need to contact the gateway. The code in grub-core/net/boot.pc, grub_net_configure_by_dhcp_ack() explicitely adds a route for the server host (this is the 'if(bp->gateway_ip) ...' block) - I'd say such a route only needs to be added if the server is on another subnet.

For what it's worth, commenting out the 'if(bp->gateway) { ... }' block lets my client boot correctly.

(file #34028)

Rink Springer <rnk>
Thu 20 Nov 2014 10:05:36 AM UTC, comment #2: 

Could you attach tcpdump capture?

Andrei Borzenkov <arvidjaar>
Project Member
Mon 13 Oct 2014 07:16:36 PM UTC, comment #1: 

Hello,

Chainloading iPXE[1] before running grub is working:

card ROM -> iPXE -> Grub

Regards.

[1] http://ipxe.org/howto/chainloading

Daniel Dehennin <nebuchadnezzar>
Fri 10 Oct 2014 07:54:05 AM UTC, original submission:  

Hello,

I tried to setup a DHCP/TFTP boot with Grub2 from Debian 2.02~beta2-14 and git master.

I used the following command to create the grub net directory:

    roo@tftp:~# grub-mknetdir -v --net-directory=/var/lib/tftpboot --subdir grub
    [...]
    grub-mknetdir: info: grub-mkimage --directory '/usr/lib/grub/i386-pc' --prefix '/grub' --output '/var/lib/tftpboot/grub/i386-pc/core.0' --format 'i386-pc-pxe' --compression 'auto'  'tftp' 'pxe'
    .
    grub-mknetdir: info: the total module size is 0xf5cc.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/kernel.img.
    grub-mknetdir: info: locating the section .text at 0x0.
    grub-mknetdir: info: locating the section .rodata at 0x54d4.
    grub-mknetdir: info: locating the section .data at 0x6480.
    grub-mknetdir: info: locating the section .bss at 0x6c08.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/bufio.mod.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/datetime.mod.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/boot.mod.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/priority_queue.mod.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/net.mod.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/tftp.mod.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/pxe.mod.
    grub-mknetdir: info: kernel_img=0x144cdb0, kernel_size=0x6c08.
    grub-mknetdir: info: the core size is 0x9b1b.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/lzma_decompress.img.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/pxeboot.img.
    grub-mknetdir: info: writing 0x400 bytes.
    grub-mknetdir: info: reading /usr/lib/grub/i386-pc/diskboot.img.
    grub-mknetdir: info: writing 0x200 bytes.
    grub-mknetdir: info: writing 0xa65b bytes.
    Netboot directory for i386-pc created. Configure your DHCP server to point to /var/lib/tftpboot/grub/i386-pc/core.0
    grub-mknetdir: info: Looking for `/usr/lib/grub/i386-efi'.
    grub-mknetdir: info: Looking for `/usr/lib/grub/i386-ieee1275'.
    grub-mknetdir: info: Looking for `/usr/lib/grub/x86_64-efi'.
    grub-mknetdir: info: Looking for `/usr/lib/grub/sparc64-ieee1275'.
    grub-mknetdir: info: Looking for `/usr/lib/grub/powerpc-ieee1275'.
    grub-mknetdir: info: Looking for `/usr/lib/grub/ia64-efi'.
    grub-mknetdir: info: Looking for `/usr/lib/grub/arm-efi'.

My DHCP server is configured to serve “/grub/i386-pc/core.0”.

I boot a little zotac box using:

    06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)

It get an IP address from the DHCP server, then it download core.0 from my tftp server:

    Oct 10 09:22:23 tftp in.tftpd[29516]: RRQ from ::ffff:192.168.230.199 filename /grub/i386-pc/core.0
    Oct 10 09:22:23 tftp in.tftpd[29516]: tftp: client does not accept options
    Oct 10 09:22:23 tftp in.tftpd[29517]: RRQ from ::ffff:192.168.230.199 filename /grub/i386-pc/core.0

The zotac hangs for several seconds and then it display:

    error: time out opening '/grub/i386-pc/normal.mod'.
    Entering rescue mode...
    grub rescue>

Running tcpdump on the TFTP server I see the download of core.0 but no packet to get normal.mod.

Grub environment has the following variables:

    grub rescue> set
    cmdpath=(tftp,192.168.230.2)/grub/i386-pc
    net_default_interface=pxe
    net_default_ip=192.168.230.199
    net_default_mac=00:01:2e:3a:XX:XX
    net_default_server=192.168.230.2
    net_pxe_boot_file=/grub/i386-pc/core.0
    net_pxe_domain=example.net
    net_pxe_ip=192.168.230.199
    net_pxe_mac=00:01:2e:3a:XX:XX
    prefix=(tftp,192.168.230.2)/grub
    pxe_default_server=192.168.230.2
    root=tftp,192.168.230.2

The ls command returns nothing:

    grub rescue> ls

    grub rescue>

The same apply with another machines using:

    01:00.1 Ethernet controller [0200]: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet [14e4:163b] (rev 20)

and

    04:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express [14e4:1659] (rev 11)

Daniel Dehennin <nebuchadnezzar>

 

Attached Files
file #34034:  43396.patch added by arvidjaar (3KiB - text/x-patch)
file #34033:  dhcp.pcap added by rnk (2KiB - application/vnd.tcpdump.pcap)
file #34028:  rnk-dump.pcap added by rnk (7KiB - application/vnd.tcpdump.pcap - Capture)
file #32490:  grub-pxe.pcap added by nebuchadnezzar (49KiB - application/vnd.tcpdump.pcap - TCPDUMP capture on the TFTP server)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rabih9780 (Posted a comment)
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by rnk (Updated the item)
  • -email is unavailable- added by arvidjaar (Posted a comment)
  • -email is unavailable- added by nebuchadnezzar (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-05-17 arvidjaar StatusNeed Info => Fixed
        Open/ClosedOpen => Closed
    2015-05-17 arvidjaar Attached File- => Added 43396.patch, #34034
    2015-05-17 rnk Attached File- => Added dhcp.pcap, #34033
    2015-05-17 rnk Attached File- => Added rnk-dump.pcap, #34028
    2014-11-20 nebuchadnezzar Attached File- => Added grub-pxe.pcap, #32490
    2014-11-20 arvidjaar StatusNone => Need Info

    Back to the top


    Powered by Savane 3.6