On 2021-12-29, Rainer Dorsch wrote: > The root cause of the new kernel not booting was that the memory addresses for > kernel and initrd.img in the u-boot environment have probably changed during > this or a previous Debian release. > > A new installed bullseye system uses > > kernel_addr_r=0x12000000 > ramdisk_addr_r=0x13000000 > fdt_addr_r=0x18000000 > > On the upgraded system > kernel_addr_r=0x10800000 > ramdisk_addr_r=0x11800000 > fdt_addr_r=0x18000000 > > was used. Changing these variable to the new values fixed the issue. Many > thanks for all the advice I got. Glad you figured it out! From your original report: U-Boot SPL 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43) U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43) Looks like you never upgraded u-boot. The u-boot packages do not upgrade u-boot on your boot media; you have to manually install u-boot when you want to upgrade it. There's a discussion about the challenges of automatically installing or upgrading u-boot: https://bugs.debian.org/812611 The short of it is, some boards are trickier than others and it is difficult to detect which environments are reasonable safe to do so automatically. > I assume this is because the u-boot environment variables are not changed > during an upgrade of u-boot or to a new Debian release. Yes, neither u-boot components nor the saved environment are (re)installed on upgrade. > Judging from the upgrade typescripts, the system was originally installed with > Jessie (Debian 8). > > The u-boot environment variables of the newly installed system are very > different from the ones in the upgraded system. > > Is there an easy way to copy all the u-boot environment variables from the old > system to the new system? If you've used "saveenv" to save the u-boot environment variables, even if you upgrade u-boot, the environment will remain frozen in the state when you ran "saveenv". I strongly discourage using "saveenv" as this makes upgrading u-boot more difficult as you end up with inconsistent values between the u-boot version you're running and the environment you've saved. This will often work fine, although as you've discovered, sometimes updates to the environment fixes bugs. You have to erase or overwrite the environment area on the microSD to get new defaults; not sure off the top of my head where exactly this is for the cubox-i. If there is no saved environment, u-boot uses built-in defaults from the version of u-boot you're running. > Does SPL get upgraded with the u-boot upgrade? Also a manual upgrade process. > I summarized my learnings in the Debian Wiki: > https://wiki.debian.org/InstallingDebianOn/SolidRun/CuBox-i#Boot_Process > and checked it on a second cubox-i device. Most of what you've written is not specific to cubox-i, but kind of how to navigate u-boot in general. I would not recommend the use of saveenv for the reasons described above. The mmc device enumeration may not be the same across u-boot and linux; e.g. mmc 0 in u-boot will not necessarily be /dev/mmcblk0 in linux. Sometimes it even varies by boot. live well, vagrant
Attachment:
signature.asc
Description: PGP signature