search

raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.19k stars 1.68k forks source link

PXE RPi3 boots stops #937

Open jrburk opened 6 years ago

jrburk commented 6 years ago

I'm using isc-dhcp-server that responds to the PI:

TIME: 2018-02-04 18:44:04.141 IP: 192.168.1.80 (8:0:27:b1:5f:9b) > 192.168.1.12 (b8:27:eb:ac:1c:1) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 26f30339 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 192.168.1.12 SIADDR: 192.168.1.82 GIADDR: 0.0.0.0 CHADDR: b8:27:eb:ac:1c:01:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: pxelinux.0. OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER) OPTION: 54 ( 4) Server identifier 192.168.1.80 OPTION: 51 ( 4) IP address leasetime 86400 (24h) OPTION: 43 ( 20) Vendor specific info 5261737062657272 Raspberr 7920506920426f6f y Pi Boo 74202020 t
OPTION: 66 ( 12) TFTP server name 192.168.1.82 OPTION: 1 ( 4) Subnet mask 255.255.255.0

Then on the tftpd-hpa server I'm seeing this:

Feb 4 18:44:05 content in.tftpd[1421]: RRQ from 192.168.1.12 filename bootcode.bin Feb 4 18:44:05 content in.tftpd[1422]: RRQ from 192.168.1.12 filename bootsig.bin Feb 4 18:44:05 content in.tftpd[1422]: sending NAK (1, File not found) to 192.168.1.12

Booting doesn't continue from here and the green LED blinks four times.

The Raspi touch display is black during the whole operation.

ghollingworth commented 6 years ago

tcpdump would probably help here:

Do 'ifconfig' to find out the interface name, usually 'eth0' but can be something else, then add to:

sudo tcpdump -i eth0 ether host b8:27:eb:ac:1c:01

This should show what is happening... I believe that tftpd-hpa should work, I've used it before, but it's possible something has been broken...

jrburk commented 6 years ago

It looks like the raspi is requesting more files (like autoboot.txt, config.txt, ...) but they don't appear in the tftp server log (see first post). Maybe the tftp client or server cannot recover from the missing bootsig.bin request.

Is there a place to obtain or generate the bootcode.sig to try without missing files?

indoor.txt

ghollingworth commented 6 years ago

It looks like tftp-hpd is failing, it might be worth trying to see if there is some kind of failure message ... One thing that is different in the first failing request is the addition of the tsize parameter.

I'd suggest trying a different tftp daemon to see if that's the only problem

jrburk commented 6 years ago

I tried with atftpd with the same result as with in.tftpd

ghollingworth commented 6 years ago

Can you get more information from the command line? Otherwise just run dnsmasq as a proxy only server and remove the other details... It will then provide you with a known working good tftp

Gordon

jrburk commented 6 years ago

I used the tftp command line client which works normal:

root@content:/tmp# tftp 192.168.1.82
tftp> get bootcode.bin
tftp> get bootsig.txt
Error code 1: File not found
tftp> get cmdline.txt
tftp> get start_x.elf
tftp> quit
root@content:/tmp# ls
bootcode.bin  bootsig.txt  cmdline.txt  start_x.elf
ghollingworth commented 6 years ago

Great, doesn't help though

jrburk commented 6 years ago

What kind of information can I provide that would help?

6by9 commented 6 years ago

Sounds like exactly the issue I had with the boot stalling after getting bootcode.bin and checking for bootsig.bin. Stick jsut bootcode.bin on an SD card and check with that.

skspurling commented 6 years ago

People have said they see the TFTP server stall after the bootsig.bin file. Mine appears like the Pi won't proceed without the bootsig.bin. I am running a Pi 3B+. Would that make things work any differently?

weinholt commented 6 years ago

Here's tcpdump -e output showing what the problem is:

14:37:03.557737 b8:27:eb:6f:3d:3c (oui Unknown) > d4:3d:7e:6b:6d:74 (oui Unknown), ethertype IPv4 (0x0800), length 62: 192.168.1.124.49152 > upshot.tftp:  20 RRQ "bootsig.bin" octet
14:37:03.560759 d4:3d:7e:6b:6d:74 (oui Unknown) > b8:27:eb:6f:3d:3c (oui Unknown), ethertype IPv4 (0x0800), length 61: upshot.60968 > 192.168.1.124.49152: UDP, length 19
14:37:05.672278 b8:27:eb:6f:3d:3c (oui Unknown) > aa:aa:aa:aa:aa:aa (oui Unknown), ethertype IPv4 (0x0800), length 71: 192.168.1.124.49154 > upshot.tftp:  29 RRQ "autoboot.txt" octet tsize 0

After the request for bootsig.bin the following requests all have the Ethernet destination address set to aa:aa:aa:aa:aa:aa. A simple workaround is to add that address to your server (although I only tested it with br0, not eth0, and I can't promise that this will not mess anything else up for you):

ip link add link eth0 address aa:aa:aa:aa:aa:aa eth0.1 type macvlan
ip link set eth0.1 up

I checked that this works with Linux 4.17 and both dnsmasq and tftpd-hpa.

Flole998 commented 6 years ago

What does wireshark show on the Pi's NIC? The Server is on the same subnet, is that correct?