Ah okay. If it adds the 60 seconds delay, then it should be just unnecessary: As said, the rootwait you should see in /boot/boot.scr means an infinite wait for the rootfs already, making rootdelay obsolete.
- If something with the download fails, the package would not extract in the first place, hence APT would throw errors and not even start replacing files. So the only thing where something could go wrong is when there are I/O errors when the files are replaced. I/O errors could also happen later, when the initramfs is generated, but similarly, it would result in an APT error, and the very last invoked script which replaces the
/boot/initrd symlink would not run, hence there would be still a valid initramfs. So as long as there are no kernel errors thrown during the package upgrades, it is unlikely that something went wrong with its installation.
- The bootloader definitely supports loading the rootfs (boot scripts/env, kernel, dtb, initramfs) from anywhere, including USB. But the bootloader is not flashed on package upgrade anyway, hence did not change. Do you have some exact examples of those errors you see? It could be the initramfs not detecting or failing to mount the rootfs, before the kernel is launched, or the kernel at some point. Best would be of course the whole output taken from a serial console.
And did you check whether all files/links are there as intended? Do you still have this /mnt/sdcard mount and /mnt/sdcard/boot symlink (or bind mount), or do you in the meantime mount /boot directly? Check whether in /boot, you see the symlinks Image, uInitrd and dtb all pointing to the same new kernel version, matching the the kernel modules below /lib/modules.
In theory, power usage could have changed, or a higher peak caused in boot stage. So what could be tested is using a more powerful PSU or powering the USB drive with a dedicated PSU (if not the case already).
What exactly is not working with our bootloader in this regards? It supports all boot media, directory structures, filesystems etc just fine as well. I am not aware of anything which would prevent the setup Ruud uses, or any other with smaller or larger parts on the SD card (like bootloader binary and script and/or env only). And again, the bootloader has not been updated, neither has the boot script or environment been touched, hence it has already proven to work.
Ruud’s setup has the whole /boot directory on the SD card, hence it must not be R/O, otherwise kernel upgrades and initramfs rebuilds would fail. But of course with a different setup this can be done. I never found the time to start with this, but a tiny image with only bootloader and a FAT partition with a boot script which does nothing else then searching for and running another boot script, is what I am aiming for: USB boot | Provide tiny SD card image as USB boot relay · Issue #6186 · MichaIng/DietPi · GitHub
So the SD card never needs to be mounted, but just serves as minimal relay to boot any other attached image.
Now that I think about it, if I am not mistaken, it could even work to really only flash the bootloader binary to the SD card, and no partition table or filesystem at all. If I am not mistaken, the default U-Boot environment loops through all attached drives by itself, not only the one it was loaded from. Will test when I find time.
.