PXE Boot doesn't ask for bootcode.bin #862
Comments
|
I've done a wireshare here https://pastebin.com/ju4hrEa6 that should show whats going on. It's limited to the packets participating in the conversion. Can upload full version if helpful. All help would be greatly appreciated. Without SD card I'm unable to get the PI to boot from network. |
|
ping @ghollingworth might this be something you could help with? |
|
With help from the dnsmasq mailing list I've finally managed to boot the raspi without SD card/ the help of With this setup the raspi is finally net-booting. |
|
Looking at your previous wireshark response there is no IP address served to the device. You are using a proxy DHCP reply to provide the pxe-service but there is no standard DHCP reply from your router. Previously you had "dhcp-range=192.168.0.255,proxy" which means the dnsmasq will not give the device an IP address (it is assuming a separate DHCP server is going to do this for you). It only serves a DHCP offer that contains the Option 43 with the client IP address of 0.0.0.0 What you've now done is to get your fritzbox to actually serve IP addresses as well so your DHCP response should now have both the Option 43 and the client IP address in there. Why do you think the DHCP request is malformed, we've never found a problem with getting a DHCP server to actually serve it addresses. |
Right.
Correct. This setup is working fine if the SD with bootcode is in place. Combined with the fact that not a single other device has had problems with the router that makes me think that the router reply is per se fine, potentially the raspi request is different with or without bootcode.
Imho no. I've set my server raspi to serve the IP instead of the fritzbox router?
I'm only guessing. But if the client raspi receives an IP from the router with bootcode but not without then this should not depend on the router DHCP reply (which should not change), unless bootcode is already doing things for working with "malformed" replies or similar? |
|
Looking at your dump again, I can't see the reply from the router. I assume this is because you've got a switch between the router and the client and you are tcpdump'ing from the server... Would you have a managed switch that you can use between the two to enable all traffic get routed to the server, then I can understand what it is that is causing it to fail. It's clearly been fixed in bootcode.bin but I'm not sure what it is that is fixed! Gordon |
Both client and server are directly attached to the router.
Theoretically the router should support packet capture but apparently mine doesn't. Since I'm aiming for replacement anyway I'll try to get the replacement and provide packet capture. From the wireshark sessions I still have the DHCP request around that didn't get an answer: |
|
Is a permanent resolution for the "diskless PXE" issue possible at all on the RPi3 or this root-cause is within the boot ROM itself and will remain as is? A recent |
|
@hlev The solution presented above does work reliably without SD now. The key to success is to make sure that the raspi actually receives the IP which it didn't- for not entirely clear reasons- from my FritzBox. |
|
@andig thanks, good to know it works, it seems the trick is the TL;DR I originally experimented with My first "diskless" plan was, despite my router supports BOOTP/TFTP, that I'd simply use it to relay BOOTP DHCPREQUEST packets to my laptop running Then I simplified this setup by putting the Pi and the laptop running |
JamesH65
added
the
Bootcode/Netboot/PXE
|
Can any participents comment on the status of this issue? This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested. |
JamesH65
added
the
Close within 30 days
|
is there a workaround for isc dhcp 4.1.1? |
|
Are you running the very latest raspbian and bootcode, there have been changes. |
JamesH65
removed
the
Close within 30 days
|
I will check momentarily |
|
Hello, I was able to boot, I suppose it successfully completed the dhcp handshake, retrieved the kernel and netbooted, then got stuck there: https://www.eskimo.com/~jibanes/pi/IMG-0852.JPG |
|
I found the issue, cmdline.txt doesn't need to be at the root of the tftpboot path, it needs to be (in my case) in a directory called b4c1710b, does anyone know what this represent? (it works though, I found out about this path with tcpdump) |
|
@jibanes The bootloader will attempt to fetch the files from |
|
thanks, works great! |
|
After many tries, I still get a significant number of failures, sometimes it boots, sometimes not, often not; a reboot command, would halt linux, but fail to reboot; it seems to be indifferent whereas I have hdmi/usb connectors plugged in; it's random. It could be that my PI3 is defective, has anyone else seen this behavior? I'm running the latest firmware according to rpi-update. |
|
@jibanes If the devices fails at the TFTP stage by not even accepting the IP from the DHCP/TFTP server, I recommend you read this thread #894 which explores and explains why the Pi sometimes ignores the DHCPOFFER from the TFTP server. Also why it will likely not be fixed by further firmware releases, because it is a bug in the first stage of the bootloader in ROM. It can be circumvented by creating random packages that will "nudge" the Pi to proceed with booting. If boot fails at an arbitrary place while downloading assets over TFTP, I would suggest trying a different switch between the Pi and the server (if you use one) If the device fails when booting into Linux, you can debug that further on the serial port. If the device fails after a successful boot into Linux then it could be a lot of things. Let me know if you need pointers in debugging either scenario. |
|
@jibanes If you want to test quickly and you are on a Linux host: When you suspect the Pi is failing to boot, just send a broadcast or multicast packet from a host on the same physical LAN. The IP/port/content does not matter as long as it is a broadcast or a multicast packet. For example: If you see that this reliably nudges the Pi into booting, then just send this packet periodically and you're done. |
|
very useful hlev, thank you, I'll explore this; it seems to be somewhat nondeterministic but from my tcpdumps it's not even making the dhcp request. I will also send the multicast packet from cronjob, I'll post results here, many thanks. |
|
Sure, welcome. I suggest higher recurrence rate than cron though, a simple loop with a 3 second sleep for example. One reason for this being nondeterministic is that on busy networks there is a good chance that at any point in time an ARP broadcast, or DHCP traffic or other unrelated traffic will be present and those packets nudge the Pi out of the buggy loop mentioned in that other thread and it just works. On less busy networks, according to my experience, this self-generated traffic reliably fixes the issue and if you have only a few other hosts on the network you can very clearly see in the traffic dump that the Pi makes the initial bootp request, fails to act on the DHCPOFFER but continues as soon as your packet reaches its interface. |
Similar to #764, originally reported in forums before I found my way here. I've followed tutorial, main difference that a fritzbox is running as router in the local network and serving dhcp.
rpi-updatehas been run, didn't tryBRANCH=nextyet.tcpdump:
daemon log:
dnsmasq.conf:
The
" "and appended pxe server IP were added after looking for potential solutions.Is there any way to get this working without need for as SD card?
UPDATE Playing with
dhcp-reply-delayfrom 1 to 5 seconds didn't help any.UPDATE I've also tried with an SD card containing but a single
FAT32partition with justBOOTCODE.BIN. This does go into TFTP but fails withUnable to mount root fs on unknown-block(2,0), but that's a separate topic.The text was updated successfully, but these errors were encountered: