Restoring the backup into a fresh image on an SD card makes it unbootable because it can’t find “serverip” during boot. I also can not move the rootfs anymore with this new version. I have no longer access to my old installation.
You put the firmware at the wrong location. If the microSD card to be written is listed as /dev/sda1, you must use the disk as a target. The correct command in this case is:
dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/sda
If the microSD card was properly erased, an lsblk output would have looked like this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 29,8G 0 disk
As opposed to one with an existing partition table, e.g.:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 29,8G 0 disk
├─sda1 8:1 1 512M 0 part
└─sda2 8:2 1 28,9G 0 part
I dd’ the card again for a few seconds to erase the incorrectly placed firmware and copied it to sdb this time. It is now booting from SSD.
Attempting to restore the backup into the SSD still results in an unbootable state. Partition table is incorrect and no “serverip” found. Is there a way to restore it without breaking anything?
I know that restoring the backup will overwrite the boot folder with the 4.9.241-arm64 version of the firmware. Maybe I need to avoid that?
If i only really want to restore the software and its configurations could i just restore the backup, copy the relevant folders someplace else, reflash and setup the SSD again and copy the folders back into the new SSD image?
Ah right, your using the old image with Meveric’s vendor kernel/bootloader builds. Hmm, those around work with petitboot actually, but not 100% sure.
Generally the new bootloader should be able to boot with old kernel. But drive path/UUID in /boot/boot.ini and /etc/fstab need to match the ones of the new system. dietpi-backup tries to automate this, but no guaratee in all cases. Also you’re restoring a legacy Debian Buster system.
I personally would only manually copy /mnt/dietpi_userdata and other custom data and configs individually onto a fresh system and install software freshly. So you run new Debian Bullseye with Linux 5.10.
@usual-user
Btw, if it’s the U-Boot from here, this is already included in our image. 2022-07 currently, next image with 2022-10. Those are working very well on all SD cards and eMMC modules I can test. Many thanks for providing them 
.
With USB I’m still fiddling with petitboot, currently stuck on an old version which denies to self-update, and probably a too slow USB stick: Odroid N2 | Add support for petitboot>USB boot · Issue #5634 · MichaIng/DietPi · GitHub
1 Like
Okay, I specifically want to save the configurations I made for plexmediaserver, deluge and ubooquity. I also made a few symlinks to let plex save media on an external HDD instead. Which folder would I need to copy for this?
And I understand that the copied firmware on the SD card is probably not a long term solution. Can I keep it like this for now until an appropriate update comes out?
Damn, you caught me, guess I’ll have to hide it better next time 
Try the same method as I suggested in this thread. If all systems boot from USB as intended, consider loading the firmware into the SPI flash and forget Petitboot.
Btw, it’s not Armbian, Manjaro, fedora, … do not support Petitboot, it’s the other way around Petitboot primarily supports only Hardkernel systems and newer, other boot methods are not supported by the u-boot emulation.
My firmware compose also works for systems that were not explicitly developed for the n2. For example, if you want to try an upcoming release of fedora, download an Image, put it onto a storage device (microSD, eMMC, USB storage device) and let the firmware boot it. The mainline software support for the n2 is sufficient enough to let it work out-of-the-box. Unfortunately, fedora can’t offer the firmware out-of-the-box because of its binary blobs. But I know how I can compose it for me and know others who appreciate the result also
I’m actually trying to find out about the exact reason it does not work: Petitboot, yet another bootloader based on KEXEC - Page 35 - ODROID
It seems to be the specific syntax env import -t <addr> <size> to load an external environment file, which does not work in petitboot, or works differently. Otherwise, when settings the mandatory variables in /boot/boot.scr directly, it works. So that I’ve started investigating this, the “petitboot does not support it” (or the other way round), it too simple, but the exact command/syntax failing needs to be identified, checked whether @tobetter can fix it, otherwise an alternative found. E.g. in reference boot.ini, ini <section> <addr> is used, but it requires an ini section, like [section] in the file, which breaks env import again I guess, so I’d like to avoid that.
@asiaclonk
All data of these should be stored in /mnt/dietpi_userdata and /var/lib/plexmediaserver:
ls -l /mnt/dietpi_userdata/{deluge,ubooquity} /var/lib/plexmediaserver
Copy/merge those two directories into the new system, before installing any software. When you install the software titles with these copied, all data and configs will be migrated.
It’s a good thing I made a note of how to do the symlinks years ago. The backups were also accessible without having to restore them, too. Most of the settings have been preserved and it’s up and running again. Hopefully there won’t be any substantial OS reorganizations anytime soon. Thanks for all the work.
Though it’s a bit annoying that I have to unplug all storage when rebooting since those devices get picked over the SSD for booting.
Petitboot works in the following way. The legacy u-boot boots the Petitboot kernel and the Petitboot userspace analyzes the u-boot boot configuration in the system to be booted. When all necessary information has been evaluated, KEXEC switches to the kernel of the system to be booted. It should be clear that not all u-boot boot configuration subtleties are supported one to one. The fact that no sources for Petitboot are available is also not exactly helpful and you are dependent on @tobetter’s goodwill if you want information or bugs fixed. And I’m also pretty sure that he will never include full support for distro-boot or uefi where legacy boot is not even fully usable.
I therefore prefer to build on mainline u-boot that has the functions out-of-the-box that @tobetter tries to emulate with Petitboot because the legacy u-boot does not support them. There is also a vivid development taking place, the findings of which will most likely never be ported into the u-boot that Petitboot uses. I can live with the fact that there are no sources available for the TF-A components, but of course it prevents the integration into distributions that require open sources for all components. @tobetter is sitting here in the same boat because Armlogic does not seem to provide them.
Of course, you can workaround the shortcomings of Petitboot, but for my taste it is far too fragile and not really sustainable. Especially since there seem to be functioning alternatives. Why my build works better than the Armbian build I can’t really say. I build from the same sources but I use a fedora toolchain because I build on-target. Maybe it’s a Heisenbug.
The order in which the USB devices are probed should always be the same, possibly it may be a workaround which USB storage is connected to which USB port. Alternatively, you can temporarily disable the boot configuration file of a drive that should not be used and skip it.
Out of curiosity, you can post the serial log of a boot process, I would be interested to know how it looks in your use case.
1 Like
Thanks for clarification. The petitboot boot procedure is actually quite transparent, watching the output. So this means that the underlying U-Boot is not involved in parsing the boot.scr, but it is a custom integration on top of kexec? That makes sense and explains it well, indeed.
Our images will always ship with mainline U-Boot, of course. What I want to achieve is that Odroid N2 and especially Odroid C4 users do not need to change anything on their freshly shipped hardware but can boot DietPi OOTB with and without SPI bootloader and petitboot. The ability to boot from USB is another bonus, but this should work with mainline U-Boot flashed to SPI as well. If petitboot support comes with too many sacrifices, I’ll instead provide a script to flash mainline U-Boot to SPI to enable USB boot, but preferring a solution which does not involve additional end user steps.
Strange indeed. You include all Armbian patches as well? There were quite some cases where old patches became conflicting with new U-Boot, and not all combinations of SBC and boot drive can be covered by smoke tests, of course.
@asiaclonk
Is it intentional that there are multiple functional boot partitions? Generally I’d otherwise format all other USB drives with a single fresh partition and as well erase the content or even partitions of the SD card (but not via drive manager, since it would erase U-Boot as well). So there is only a single valid boot partition which U-Boot from SD card or eMMC can pick.
The only devices with boot partitions were the ones which have been flashed with the old dietpi images.
Now there is not a single boot partition in the system, if you exclude the firmware in the main SD card slot.
I have an external HDD for media connected via a usb docking station (which doesn’t spin up fully before the odroid tries to access it during boot). During the first reboot there also was a USB stick connected (which I used to move folders around).
How do I get the failed boot logs, if it is possible to get them after a successful boot?
Not at all, pure mainline with few configuration changes like zero bootdelay and USB keyboard support for my personal preferences. I do this because the firmware should behave the same for all my devices and each manufacturer has a different idea of what the default should be. Because I have to build the uboot-tools package myself anyway because the firmware for some devices is not included for one reason or another, this is a one-time setup effort. And then it is only a rebuild for any new release.
And once you have experienced the disto-boot possibilities that allow you to easily use the same image for different devices, you only look for devices that allow you to store the firmware outside the system image. I don’t know of any x86 architecture device that stores its BIOS within the system image.
Uefi works too, but I find it more complex to maintain.
Just to clarify, is it the blank microSD card with only the firmware in place?
You can only record them entirely via the serial console because there is no storage available where they can be preserved at the time the problem occurs. You can also try to pick them up on the HDMI display, but there are only the logs available since the u-boot launch. TF-A messages are missing.
Yeah, it’s the blank SD card with the firmware on it.
Then it is not the boot partition because there are no paritions configurred at all. The boot partition is the partition in which the u-boot boot configuration is found, it can be the system root partition because the firmware does not rely on any special partitions. It is always the partition where a u-boot boot configuration is found first in the device scan order.
@usual-user
Your U-Boot should work on Odroid C4 as well, isn’t it? It’s only one case, but failing to boot from SD card: odroid c4 installation issue · Issue #5782 · MichaIng/DietPi · GitHub
And based on many reports on Armbian forum, several meson64 boards are affected by warm reboot issues, which I cannot replicate on my Odroid N2+ with your U-Boot, at least.
Not at all, the firmware code is the only truly device-dependent code. My offered firmware uses TF-A for the S922X SoC and expects a hardware that is mapped by the devicetrees meson-g12b-odroid-n2.dtb and meson-g12b-odroid-n2-plus.dtb. The Odroid C4 uses a S905X3 SoC and the hardwaredesign ist quite diffent. To have a firmware for the Odroid C4 you have to build u-boot with a different setup und use different TF-A.
All other code in a system is not explicitly device-specific. For example, a fedora image works the same way for all devices of the aach64 architecture. To run on a specific device, only a device-specific firmware, that can boot the system, is required and a board devicetree file so that the kernel knows which driver components to use. Driver support for a specific SoC is of course mandatory. But if support is available for a board with a particular SoC, support is available for all other boards with that SoC. This is also the reason why the fedora image on my Odroid M1 already runs the same today. OK, I’m using my self-built kernel because the necessary out-of-the-box support is only available with 6.2.0-rc1, but the media support is already better than with the N2 where many out-of-tree patches are still necessary.
Out of curiosity I have meanwhile played around with the spec file for the uboot-tools, now I have a u-boot-meson.bin which is built with C4 configuration, but I can’t do much with it because I don’t have appropriate hardware.
1 Like
This is what I last see before it restarts when the HDD is connected
If a USB stick is connected, a lot more happens, but I have no way of capturing it aside from the last bits.
You said before:
Is the drive already fully spun up in this situation?
This looks like no u-boot boot configuration was found and after a few more iterations u-boot should fall back to its interactive console (=>) where you can execute u-boot commands. Here it would be necessary to see the beginning of the log to really say what happens. But if the USB stick does not contain a u-boot boot configuration, this is an expected behavior.