Alternative command to > mount | column -t <

Not sure either, but worth an attempt. Else we could report to RPi devs, as at least the documentation states it should work. We just need someone else with that device to replicate, to rule out that it’s a hardware issue.

am willing to test this, but need some help migrating to the Rpi5 compatible kernel/firmware package.

The right command would be ideal. :thinking:

root@adsb-feeder-pi:~# uname -a
#Linux adsb-feeder-pi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux
root@adsb-feeder-pi:~# sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
FW_REV:285539f763ef2d0612792935cf79bde07f3b7b38
BOOTLOADER_REV:14f05613b4795a9070d40b554dff84598d684bb2
rpi-eeprom firmware package appears to be too old. Skipping bootloader updates
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Backing up firmware
 *** Backing up modules 6.1.21-v8+
WANT_32BIT:0 WANT_64BIT:1 WANT_PI4:1 WANT_PI5:0
Partition size 128M may not be sufficient for all firmware files
This could result in a system that will not boot.
256M FAT partition is recommended. Ensure you have a backup if continuing.
Would you like to proceed? (y/N)

That makes me a little suspicious, so I stopped at first.

Follow this thread and migration script: Image | Raspberry Pi 5: Testing and firmware migration script · Issue #6676 · MichaIng/DietPi · GitHub
rpi-update does not do the migration, but instead restores legacy libraries if not excluded explicitly, so do not use it, unless you must for another reason.

Unfortunately, we will only be able to contribute to a solution to a limited extent. When the script was executed, it destroyed the system. The same thing happened with a copy of it. I then rebuilt the system and the script ran without errors. Now there is an option in dietpi-config to change the kernel, but the USB bootloader option still does not work.

Could you give any details about how it destroyed the system, error logs etc? We aim to roll this out automatically on all (Bookworm and above) RPi systems, hence this must work rock solid.

Okay, so then indeed USB boot is not supported on RPi Zero 2 W, in contradiction to what the documentation states. Would be still great if someone else with this SBC could verify, so we can check back with RPi devs.

Sorry, I’m not good at analyzing mistakes, I don’t understand enough about the internals.
I can only say this much, the script aborted with an error, multiple confirmations with Reply did not change this. A new boot process then no longer worked. The running system was completely set up and so was the copy. However, the script worked on a newly installed DietPi with the basic installation.

I’m still not sure whether it might have something to do with my exotic circuit board, which turns the Zero 2 into an RPi 4, with 1 network port, 4 USB 2.0 ports and a normal HDMI port. Not that anything is interfering. It would be better to test it again with a Zero 2 alone.

Thanks for your effort and help!

Collecting and sharing the error messages would have been enough.

I will try to reproduce the error again by next weekend and post the output here.

Possible, but I am also not sure how an extension board can affect it. If you are able to replicate it. A copy of the error message/prompt would be very helpful.

I’ll see what I can do. :wink:

Today I got around to testing and retracing the whole thing again.
I can no longer recreate the two system crashes.
This means that the above script works.
Since both system installations were a 1:1 copy at the time, it was possibly due to a corrupted system.

Nevertheless, the USB boot does not work.
No matter what I try, I cannot boot from USB, whether USB stick or USB SSD.

So far so good. And yes, then USB boot seems to be not supported on RPi Zero 2 W, or the required OTP programming is broken on it with current firmware.

I hope we can find someone else to verify, just to assure it is not somehow device or revision specific, before we check back with RPi devs.

As always, you will solve it, I’m sure of that.