trejan
Posts: 2591
Joined: Tue Jul 02, 2019 2:28 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Sep 25, 2019 4:23 pm

dickon wrote:
Wed Sep 25, 2019 4:10 pm
I realise that this doubtless isn't supported, but upgrading the eeprom using network booting doesn't work.
You probably need to use USE_FLASHROM=1 so it does the upgrade directly instead of getting the firmware to do it at next boot.
dickon wrote:
Wed Sep 25, 2019 4:10 pm
This seems to be for two reasons: ropi-update-eeprom drops the new firmware in /boot/recovery.bin, whereas the bootloader looks for recovery.elf, recovery8.img, recovery8-32.img, recovery7l.img, recovery7.img, and recovery.img.
AFAIK the bootloader in the SoC ROM always looks for recovery.bin before doing anything else.

timg236
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 646
Joined: Thu Jun 21, 2018 4:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Sep 25, 2019 4:38 pm

trejan wrote:
Wed Sep 25, 2019 4:23 pm
dickon wrote:
Wed Sep 25, 2019 4:10 pm
I realise that this doubtless isn't supported, but upgrading the eeprom using network booting doesn't work.
You probably need to use USE_FLASHROM=1 so it does the upgrade directly instead of getting the firmware to do it at next boot.
dickon wrote:
Wed Sep 25, 2019 4:10 pm
This seems to be for two reasons: ropi-update-eeprom drops the new firmware in /boot/recovery.bin, whereas the bootloader looks for recovery.elf, recovery8.img, recovery8-32.img, recovery7l.img, recovery7.img, and recovery.img.
AFAIK the bootloader in the SoC ROM always looks for recovery.bin before doing anything else.
The ROM is only able to load recovery.bin from the sd-card boot partition. The recovery.bin method was chosen because it's safe in the event of a power failure during flashrom and flashrom suffers from conflicts with the SPI pins / drivers so unfortunately dtoverlay / dtparam might hang if the analog audio is in use or a HAT is using the SPI pins.

If you have a spare sd-card then you could mount that somewhere else (e.g. /boot-sd) and change the BOOTFS path for rpi-eeprom-update via /etc/default/rpi-eeprom-update i.e. use a small / old sd-card solely for bootloader updates if flashrom is not useable.

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Sep 25, 2019 4:44 pm

trejan wrote:
Wed Sep 25, 2019 4:23 pm
dickon wrote:
Wed Sep 25, 2019 4:10 pm
I realise that this doubtless isn't supported, but upgrading the eeprom using network booting doesn't work.
You probably need to use USE_FLASHROM=1 so it does the upgrade directly instead of getting the firmware to do it at next boot.
Ah! Ta.
dickon wrote:
Wed Sep 25, 2019 4:10 pm
This seems to be for two reasons: ropi-update-eeprom drops the new firmware in /boot/recovery.bin, whereas the bootloader looks for recovery.elf, recovery8.img, recovery8-32.img, recovery7l.img, recovery7.img, and recovery.img.
AFAIK the bootloader in the SoC ROM always looks for recovery.bin before doing anything else.
Not over the network. There's no sign of recovery.bin in my server logs.

trejan
Posts: 2591
Joined: Tue Jul 02, 2019 2:28 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Sep 25, 2019 5:04 pm

dickon wrote:
Wed Sep 25, 2019 4:44 pm
Not over the network. There's no sign of recovery.bin in my server logs.
Yeah. I forgot to say SD card. timg236 explains it above.

recovery.elf is used by NOOBS/PINN. It is a renamed copy of start.elf which if found causes it to look for different files. This is why your kernel command line changed as it ignores cmdline.txt and looks for recovery.cmdline instead. recovery.bin doesn't have an ELF header so can't be loaded like that.

In theory it would be possible to make the regular firmware check for a newer version on the TFTP server and flash it. It would have already loaded itself from the EEPROM so you're not rewriting it whilst it is still using it. Maybe something in the future as it'd be a lot of extra work.

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Sep 25, 2019 5:10 pm

I wouldn't worry about it. It's a niche use-case. Might be worth adding a check to the update tool to immediately flash it (or at least warn) if it spots that /dev/mmcblk0p1 isn't mounted as /boot, though.

mullcom
Posts: 5
Joined: Fri Sep 19, 2014 8:06 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Oct 23, 2019 11:51 pm

Hello!

Can someone explaining this a bit more what this can do and what is good for. What is the difference between this and eagerly sdcard ?

I have to little information about eeprom to understand everything,


Thx. It is very grateful

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Sun Dec 15, 2019 6:20 pm

I'm having kind of a odd issue with network booting raspbian on a pi4 4GB from a Synology nas.

I started with a fresh install of raspbian buster lite on a sd card, ran the updates and updated the eeprom.
I then shutdown the pi and used my laptop to copy the /boot and /rootfs partitions to the nfs shares using: sudo cp -a.

The pi will boot from the tftp/nfs (I am monitoring with uart) but when I try to log in as the pi user I recieve the message "Unable to cd to /home/pi" then returns to a login prompt.

It seems like a permissions issue, but I'm just not sure how to resolve it. cp -a should have retained the owner/group/permissions and the nfs exports do not have any user mappings, I am stumped... Any Ideas? :?

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Mon Dec 16, 2019 12:11 pm

Check on the server. ls -l /home, that sort of thing.

If /home or /home/pi is a separate filesystem, has that been exported and mounted correctly?

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Mon Dec 16, 2019 2:21 pm

The permissions for /home/pi in the nfs export appear to be correct (uid:gid=1000 mode=755). /home is not a separate mount, it is part of the rootfs mount. The cmdline.txt also includes the rw directive for the nfsroot.

cmdline.txt:

Code: Select all

root=/dev/nfs nfsroot=serverip:/volume1/rpi-rootfs,vers=3 rw
Edit: The root user doesn't seem to have any issues writing to the nfs export, I can verify the pi's logs are being written on the server in rpi-rootfs/var/log, but none of them seem to contain any clues.

incognitum
Posts: 528
Joined: Tue Oct 30, 2018 3:34 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Mon Dec 16, 2019 4:25 pm

uncarvedblock78 wrote:
Mon Dec 16, 2019 2:21 pm
The permissions for /home/pi in the nfs export appear to be correct (uid:gid=1000 mode=755).
Also double check the parent directories (/home and /) have "x" permission for other users.

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Mon Dec 16, 2019 4:42 pm

permissions on /home are uid:gid=root mode=755
permissions on /home/pi are uid:gid=1000 mode=755

digging into the /etc/exports file on the synology, the rootfs export has the following opts enabled:

Code: Select all

(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys)
I find it a bit odd that the mode of /home/pi is not 700, but i wouldn't think being more permissive would result in less access lol.

Edit: Also, I'm not entirely convinced it's a permission issue anyway, just that it looks like a permission issue. Normally, I would expect to see a reason after "Unable to cd to /home/pi" e.g. "Permission Denied", "No such file or directory", etc. However, no reason is given, it just returns to the login prompt.

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Mon Dec 16, 2019 9:39 pm

It may be attempting to map your UID to something the Synology should know about but doesn't, so it's being rejected on that basis -- are you running idmapd? I may be wrong but it has that feeling to me.

This is all actually off-topic for this thread -- which is about the firmware and your Pi has clearly successfully booted using it -- and I'd be tempted to start a new one before James growls.

incognitum
Posts: 528
Joined: Tue Oct 30, 2018 3:34 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Mon Dec 16, 2019 11:54 pm

uncarvedblock78 wrote:
Mon Dec 16, 2019 4:42 pm
permissions on /home are uid:gid=root mode=755
permissions on /home/pi are uid:gid=1000 mode=755
Don't forget to check / as well. ("stat /volume1/rpi-rootfs" on your Synology)

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Dec 17, 2019 1:06 am

dickon wrote:
Mon Dec 16, 2019 9:39 pm
are you running idmapd?
so checking ps aux, the synology is running idmapd... I was under the impression that that was only really used for nfsv4 though, I will need to research the subject a bit, unless you are able to point me in the right direction?

I'm reluctant to disable it completely so as to not break anything else it may be required for on the synology.
dickon wrote:
Mon Dec 16, 2019 9:39 pm
Don't forget to check / as well.
root:root mode=777

Again, permissions seem to be correct.... :?

Edit: I tried to connect with ssh instead of the uart:

Code: Select all

Unable to chdir to home directory /home/pi: Permission denied
/bin/bash: Permission denied
Connection to raspberrypi closed.

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Dec 17, 2019 10:59 am

My memory is clearly going. idmapd doesn't have anything to do with NFSv3, correct.

Your root permissions must be 0755, not 0777 -- I can imagine sshd complaining about that.

If you're on console, login as root, and

Code: Select all

strace -f su - pi
should show you where your problem lies (admittedly in amongst a lot of other guff). You may need to install strace first. You may need to set a root password first, but that should be easy enough to do on the fileserver (ie, chroot and passwd, but if that doesn't work, simply copy the hash in /etc/shadow from the pi to root user).

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Dec 17, 2019 3:26 pm

I logged into the pi a root and ran a strace, I still need to analyze the output, but while I was logged in, I checked a few other things:
  • dmesg errors. nothing of note.
  • systemctl --failed, a few units failed, notably systemd-timesyncd, journal was of little help, but I did see a Permission denied[200]
  • created a new user, has the same issues as the pi user
  • triple checked the perms on /, /home, and /home/pi, ownership looked okay from within the running nfsroot, modes were 777, 755, 755 respectively.
I apologize if this discussion is drifting off topic of the boot-loader, but as I haven't been able to rule anything out yet I can't say that it couldn't be an issue with how the bootloader is grabbing the nfsroot. I can say I am using a hard-coded address in the eeprom config rather than setting up dhcp options, so that appears to be finding the share properly.

I will report again when I've had a chance to look through the strace. Thanks again for the assist.

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Dec 17, 2019 5:24 pm

Edit: redacted, of no value.
Last edited by uncarvedblock78 on Tue Dec 17, 2019 7:32 pm, edited 1 time in total.

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Dec 17, 2019 7:31 pm

Update: I seem to have the login issues cleared up. Also, no more failed units or other random errors.
dickon wrote: Your root permissions must be 0755, not 0777 -- I can imagine sshd complaining about that.
I changed the mode of the rootfs export on the nfs server from 777 (which is apparently synology's default mask when creating dirs as the admin user in the gui).

Will verify by fresh installing in a new nfsroot with the proper mode (0755). Thanks dickon!

I wouldn't have guessed that having more open permissions on the root dir would cause permission issues in the running system.

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Dec 17, 2019 10:35 pm

0777 is, of course, a+rwx, which means that *anybody* can write to the root filesystem. What you may not have realised -- I don't know how much Unix you know -- is that that means you can rename minor, unimportant directories, like /etc, /usr, /home, and /bin and replace them with your own, if you have an otherwise-unprivileged login on the system.

This is generally considered a Bad Thing, for some bizarre reason...

uncarvedblock78
Posts: 17
Joined: Mon Oct 30, 2017 3:30 pm

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Dec 18, 2019 1:32 am

Yeah, I do understand why that would be a Bad Thing, I just figured nfsroot would be smart enough to mount / with the appropriate permissions, lol. :P

Didn't think the exact permissions mattered on the share itself so long as the the machine doing the actual mounting had at least read/write. Learn something new every day if you're not careful :oops:

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Sun Dec 22, 2019 9:27 pm

That would involve the kernel synthesising the entry for /, which would be a special case. As with any filesystem, the fact that / is NFS really doesn't matter: VFS has a structure which describes the filesystem as mounted, and the FS-specific calls to read directory entries and whatnot are function pointers embedded within that. The only things that makes NFS a bit special is the fact it's entirely plausible that the filesystem is mounted by multiple clients simultaneously (which has implications for caches), and that 'x' permission is generally considered the same as 'r' permission by the server, as it can't tell the difference.

vinntec
Posts: 148
Joined: Thu Aug 02, 2012 9:37 am
Location: Basingstoke, UK

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Dec 31, 2019 10:41 pm

I am setting up a cluster of RPi4s, and while I wait for all the bits to arrive I experimented with the single RPi4 I had to act as client, and an RPi3B to act as the server for the time being. I carefully followed the two sets of instructions and amazingly it all worked first time! It took a long time to boot the RPi4, probably because of slow ethernet on the RPi3B, but it does work.

I had a couple of minor snags:
1. The step # (Optional) Update rpi-eeprom-update to automatically get updates / bug fixes using the command

Code: Select all

sudo echo FIRMWARE_RELEASE_STATUS="beta" > /etc/default/rpi-eeprom-update
gave me not authorised.
2. The step to monitor daemon.log said I should see something like

Code: Select all

raspberrypi dnsmasq-tftp[1903]: file /tftpboot/bootcode.bin not found
, but my one did not.

Moving on, the snag is that I can't figure out how to expand this to handle multiple clients which may or may not have the same configuration? I would certainly want a way to make sure which NFS share each individual one is assigned to. The RPi4 instructions mention using the MAC address which makes sense, but it isn't mentioned in the netboot tutorial on how to do this.

I am also unclear how to customise each image once the client has booted up - is it as simple as doing maintenance on each client RPi exactly like it was on the SD card? e.g. I can startx and configure each RPi however I want it?

Sorry if I am being dozy but I think I am close, but just not close enough yet!

vinntec
Posts: 148
Joined: Thu Aug 02, 2012 9:37 am
Location: Basingstoke, UK

Re: Raspberry Pi4 bootloader - network boot support - BETA

Sun Jan 05, 2020 11:11 pm

An update on my experiments which is now using 1 x RPi4 master and 4 x RPi4 slaves...

I worked out how to separate the four slaves into their own NFS and TFTP folders on the master system, using the last 8 digits of their serial numbers so I could keep them completely apart for maximum flexibility. First snag was, of course, that the RPi4 master (which replaced the test RPi3) can't easily boot from USB [yet] so I had to work around that first - not helped by the UUID of all drives being the same and having to be overridden! So an SD card and some fiddling with PARTUUID was needed to get it to run off the HDD at all. However worth it in the end to use the HDD via USB3.0 and network via gigabit ethernet!

During my earlier experiments, I got my one and only RPi4 netbooted no problem from the initial RPi3B but couldn't get any RPi3B to netboot which should have been possible. When I came to setup RPi4-2, 3 and 4 in the same way as RPi4-1, they froze during boot up. It was the step of copying / from the master system to each /nfs/<serial number> folder which appears to have caused that - it was completely rebuilt from scratch with a new HDD when the extra RPi4s arrived just before Christmas.

However, #1 that was setup when I first starting experimenting was still working perfectly. So I recreated the /nfs/<serial number> folders of #2, 3, 4 by copying from #1's nfs folder, rather than the master / directory as in the original guide. Now all four and the master are working robustly.

Incidentally there is an error in the netbooting instructions in the last step (where client1 is the serial number in my case):

ORIGINAL: Finally, edit /nfs/client1/etc/fstab and remove the /dev/mmcblk0p1 and p2 lines (only proc should be left). Then, add the boot partition back in:
echo "10.42.0.211:/tftpboot /boot nfs defaults,vers=3 0 0" | sudo tee -a /etc/fstab

MY VERSION: Finally, edit /nfs/client1/etc/fstab and remove the /dev/mmcblk0p1 and p2 lines (only proc should be left). Then, add the boot partition back in:
echo "10.42.0.211:/tftpboot /boot nfs defaults,vers=3 0 0" | sudo tee -a /nfs/client1/etc/fstab

beldzhang
Posts: 10
Joined: Tue Jan 14, 2020 5:53 am

Re: Raspberry Pi4 bootloader - network boot support - BETA

Tue Jan 14, 2020 6:46 am

Hi, I'm a developer focused on network boot for about 20 years, mainly support x86 pc boot to Windows and Linux.
I got RPi4 just one week, already tested raspbian, ubuntu, debian and network boot.

some issues about network boot

0) testing environment
EEPROM version: pieeprom-2020-01-09.bin
DHCP/PXE/TFTP server: developed by myself.

1) in DHCP requests:
other than the MAC address, there is no any field to identify a RPi client,
option 93 is set to "0" means IA x86 PC
option 97 UUID just repeat serial no 4 times
the OUI(dc:a6:32) can be use, but it not reliable as my experience
why this needed?
because the PXE options need a special menu item to continue and need to identify x86(bios/uefi) and RPI
suggestion:
option 97, change to magic number + serial no, there is enough length
-or-
option 93, acquire a unique number for RPi (it's complex with IEEE/IANA/RFC...)
-or-
any other option not defined by RFC

2)in DHCP REQUEST packet, there is no PXEClient(60) option
this is not consistency whit DHCP DISCOVER packet.
in my server, I just skip the packets without PXEClient(60), many desktop/laptop/mobile will sent request, and some ones running like flood

3) in DHCP response option 0 (padding) is not handled properly
then this response ignored.
in some(many) not implemented very well DHCP/PXE bootrom, padding zero is required to let them got correct hostname / bootfile / etc...

4) TFTP download files
blocksize is 1024, could be larger?
is there any future plan to implement windowsize ? since start.elf / kernel / initrd are big, set windowsize > 1 to speed up downloading.

User avatar
dickon
Posts: 1718
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Raspberry Pi4 bootloader - network boot support - BETA

Wed Jan 15, 2020 11:41 pm

vinntec wrote:
Tue Dec 31, 2019 10:41 pm
I had a couple of minor snags:
1. The step # (Optional) Update rpi-eeprom-update to automatically get updates / bug fixes using the command

Code: Select all

sudo echo FIRMWARE_RELEASE_STATUS="beta" > /etc/default/rpi-eeprom-update
gave me not authorised.
That's a bug in the instructions: it'll never work. It's another irritating problem with instructing people to use sudo all the time.

The shell doing the redirection '> /etc/default/...' is your login shell, which is running as you, not root. The echo command is (rather uselessly) running as root (or would be, if the shell hadn't given up as it couldn't open the file). The usual idiom is 'echo foo | sudo tee -a $file'. Personally, I just do things that need doing as root as root.

Return to “Advanced users”