Loaded kernel remains outdated after reboot

Creating a bug report/issue

Required Information

  • DietPi version | 8.10.2
  • Distro version | buster
  • Kernel version | Linux DietPi 4.9.241-arm64 #1 SMP PREEMPT Thu Feb 25 18:56:07 CET 2021 aarch64 GNU/Linux
  • SBC model | Odroid N2 (reported by dietpi, in reality N2+)
  • Power supply used | Stock charger that came with the SBC
  • SD card used | SanDisk High Endurance

Steps to reproduce

It started happening after updating via dietpi-update to 8.7.2 (recently to 8.10.2)

Expected behaviour

The new kernel 4.9.277-arm64 being loaded, as that is the name of the folder I found in /lib/modules/

Actual behaviour

The OS requires reboots all the time. When attempting to use dietpi-software I receive a warning that the folder “4.9.241-arm64” is not found in /lib/modules. I rebooted several times over multiple OS updates. Attempting to update the firmware via dietpi-config in the advanced settings does not update it.

Extra details

The OS is located on an SSD over USB-C. The boot partition is still on the SD card.

I took a look at /boot/ and a lot of the files do indeed still refer to 4.9.241-arm64.

While I’ve let dietpi run on this little device for a while already (1+ years), I’m still new to all this. Nice to meet you!

hmm maybe there are still parts used from the boot folder located on SD card? @MichaIng any ideas?

You need to unplug or format the SD card, otherwise it will always boot from SD card and, in case of UUID conflict, mount partition 2 of either the SD card or SSD randomly.

EDIT: Ah wait, does Odroid N2 actually support USB boot? If not, but you want the root partition on SSD, the SSD must contain a new (non-conflicting) single ext4 partition only, to be used in boot configuration and /etc/fstab.

Apparently it does support USB boot. But so far I have always let it boot from SD and redirected the root directory to the SSD via overriding the UUID with a command I don’t remember. I doubt the boot partition on the SSD is up to date.

Both the SSD and SD card have separate installations of dietpi.

I guess this is causing some issues during boot, Probably the system is loading stuff from SD card before it will mount the SSD?

That’s what I think, too. Wouldn’t it be easy to somehow manually update the boot partition on the SD card?

Or have only the firmware on an otherwise empty microSD card and let u-boot pick up the boot configuration from the bootable partition of the USB device.

What we usually do (which can be done also via dietpi-drive_manager) is moving only the rootfs to a newly formatted drive with 1 partition only, letting and mounting /boot from the SD card. With two valid boot partitions on different drives, I’m not sure after which logic U-Boot (the part stored at boot sector) picks either the one or the other to read config, kernel etc from. Obviously on your case it didn’t choose the one that was finally mounted to /boot.

1 Like

I downloaded the newest image for odroid n2+ and used balena etch to flash it onto the SSD again, when checking dietpi-drive_manager, I see only one partition of 750MB instead of the 250GB capacity of the SSD. Booting the device into petitboot makes it crash when trying to load the SSD initially. Not sure if I did something wrong here.

did you still have the SD card connected? Or did you complete an initial setup using the SSD only?

The SD card was removed at the time of boot into petitboot. The SD card was in when i was checking the drive details in dietpi-drive_manager.

Attempting to do the initial setup via petitboot is when I get the crash

in this case the system has been booted of the SD card and there it is logic that you don’t have the whole SSD available. Expanding the partition is part of the first initial boot process, but this did not happen until now.

Is my USB device faulty if petit boot fails to launch after “[sda1] Processing new USB device”?

For now I’m giving up on USB boot and copied the rootfs (which i previously copied back to the SD card) to the SSD. The format that was required for this has allocated 220GB to it, which seems correct. So now there is only one valid boot partition now. However the SD card boot partition is still on kernel firmware 4.9.241-arm64. How do I update that? Or do I need to do something completely different?

I did try dietpi-update -1 to force an update, but the boot partition is left untouched.

I also tried to update the entire thing when the rootfs was still on the SD card. No changes there either.

Missing petitboot support is a known limitation of the current Armbian image, the same way of our image: Odroid N2 | Add support for petitboot>USB boot · Issue #5634 · MichaIng/DietPi · GitHub

I’m currently busy with another board. If you find time in between, could you test:

sed -i '/^setenv overlay_prefix/a\if test "${variant}" = "n2_plus"; then setenv fdtfile "amlogic/meson-g12b-odroid-n2-plus.dtb"; fi' /boot/boot.cmd
sed -i '/^setenv overlay_prefix/a\if test "${variant}" = "n2-plus"; then setenv fdtfile "amlogic/meson-g12b-odroid-n2-plus.dtb"; fi' /boot/boot.cmd
sed -i '/^setenv overlay_prefix/a\if test "${variant}" = "n2"; then setenv fdtfile "amlogic/meson-g12b-odroid-n2.dtb"; fi' /boot/boot.cmd
sed -i '/^setenv overlay_prefix/a\setenv fdtfile_orig "${fdtfile}"' /boot/boot.cmd
sed -i '/^setenv bootargs/s/"$/ fdtfile_orig=${fdtfile_orig}"/' /boot/boot.cmd
mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scr

Then switch the slider from MMC to SPI. If it boots:

cat /proc/cmdline

Background is that the fdtfile variable is not set with petitboot, but used on Armbian’s/our U-Boot config. So it cannot find the device tree when using petitboot. The above sets it explicitly based on the variant variable, which is set by petitboot as well.

I can do that tonight. Where exactly am i supposed to set it? While in dietpi when it boots from SD card into the SSD root? In the shell after it crashes from petitboot?

Looks like my boot partition doesn’t have what you are looking for

Are you perchance referring to boot.ini?

Would you like to do another experiment?
If so,

  • use balena etch to flash newest image for odroid n2+ onto the SSD
  • prepare an empty microSD card
    dd if=/dev/zero of=/dev/${microSD-card-used}
  • extract this firmware
    tar -xzf u-boot-meson.tgz
  • put the firmware in place
    dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${microSD-card-used}
  • set the boot switch towards the microSD card
  • put the prepared microSD in the n2+ card slot
  • plug in the USB SSD into a n2+ USB port
  • boot the n2+

I tried to dd another SD card with an SD card adapter but it was only doing it at a rate of 8.8MB/s, so I cancelled and looked for an alternative on windows. However doing so and then rebooting the odroid made it not boot from SD card anymore. So I’m gonna take a while to get things back up and running

Flashed a fresh image into the SSD.
Fully zeroed an old 16GB sd card and copied the u-boot-meson.bin as instructed. The sd card appeared corrupted in the drive manager afterwards.

Booted the device in sdcard mode with the 16GB card and SSD plugged in. Nothing is happening.

The SD card was in /dev/sda1. That’s the destination I input.