How do Kernel upgrades work in DietPi


I have an issue with the kernel Linux DietPi 4.9.241-arm64 on my Odroid HC4 with Dietpi. This relatively old kernel seems to have problems with btrfs, where the btrfs driver in the kernel causes some exceptions. The syslog reads
Unable to handle kernel NULL pointer dereference at virtual address 00000044

Anyway, according to some sources on the internet this is resolved in newer kernel versions, there I thought I could just upgrade the kernel on my machine an pish pash posh all fine. I thought.

So I did a apt install linux-image-arm64-odroid-c4 and apt install linux-headers-arm64-odroid-c4 real quick. This caused the system to refuse to boot.
After having a look at the SD cards boot partition and not understanding a thing, I made a new SD card (but kept the old), deleted all the contents of the boot partition of the old SD card an copied everything from the new SD cards boot partition to the old SD card.
Now the system boots again. Fine. But I still have no new kernel.

So instead I thought maybe I should upgrade to bulleye (C4/ HC4 image still has buster) and this will give me the new kernel. Turns out it doesnt. After doing everything from here, rebooting, uname -a is:
Linux DietPi 4.9.241-arm64 #1 SMP PREEMPT Tue Jan 5 23:38:40 CET 2021 aarch64 GNU/Linux

So I wonder, how do you upgrade kernels?

Basically DietPi is not doing any own kernel development. We use the kernel give by the underlying base image. In case of Odroid we use image from Maveric. I guess there is no newer version available for this image. MichaIng I guess you are more close to Maveric. Maybe you know.

Oh. Now I understand what some people meant with “underlying base image”. I thought that is the debian basis you use for dietpi, but rather it is the image from another developer.
So you cant use that kernel even though it says arm64-odroid-c4 in the name? I just thought apt is doing something wrong with that weird bootloader of yours.

Anyway. Just for the folks googling that error “Unable to handle kernel NULL pointer dereference at virtual address 00000044” and that error pops up when they mount their btrfs partition and use it a bit: I did a btrfs check --repair /dev/md0 (or whatever your device is called, BE CAREFUL WITH BTRFS, THIS IS A COMMAND OF LAST RESORT!) and this resulted in the error only coming when I use the disk under heavy load for a while.
Still not good, but maybe better it helps someone.

For all SBCs in general the kernel version is not tied to the Debian version. This is only true for x86_64 where Debian’s own kernel is used. So you say the latest kernel upgrade on Odroid C4 makes your system unbootable? The bootloader is not upgraded with it, so it needs to be either the kernel image itself or the device tree (included). You btw do not need to install the kernel headers, as long as you do not install WireGuard or build other kernel modules.

What do you mean by this? APT is doing everything right as this is the intended correct kernel package. Also you are the first who reports boot issues with it and this version is available since half a year, so it could be simply a filesystem error caused by the file writes or so.

I checked the image, and the device trees have not changed and also the kernel version did not change. It was a rebuild/repack only, but I don’t remember the exact reason anymore. This however makes me think that you boot issues are indeed not directly related by the kernel upgrade but indirectly due to some some filesystem corruption or so.

Alright, so this means the Kernel linux-image-arm64-odroid-c4 should just work fine and the problem is in /boot or the bootloader i guess.

When I have some spare time I will make an image of that sd card, then play around with it.
What is the name of this bootloader, so I can find and read some documentation? When apt installs that kernel, it does everything for me, or how do I choose which kernel is bootet?

It’s U-Boot:

dpkg -l u-boot

But that generally works, it did before the kernel upgrade, didn’t it?

Do you have a screen or serial cable to see related error messages at boot?

I tried my monitor with hdmi, but the screen staid blank.

Anyway, I will first make an image of the card, then upgrade the kernel and then I could post the contents of /boot here. I think there is something going on with the kernel image, initrd or something.
We’ll see.

A serial cable? In 2021? Do you think I am a nerd? Well. Then you’re right. But I still don’t have that cable.

Ok, I think I fucked up.

So, the kernel image thats originally installed is linux-image-arm64-odroid-c4, while the package I tried to install was linux-image-5.13.7-arm64.
I just wrote the wrong name in my initial post, and this led to your confusion. I should write forum posts when tired.

So theres no chance the package linux-image-arm64-odroid (without the c4, but this is kernel 5.13.14) is going to run is there?

Thanks for looking into this. I really appreciate it.

No the bootloader as well as its configuration (boot.ini) require the linux-image-arm64-odroid-c4 kernel. If you use Debians kernel, you’d need to install Debian’s U-Boot package as well (and flash it) and create a matching boot.cmd => boot.scr.

Hi Schievel,
I’m in the same situation as you, I would like to use btrfs as base filesystem for my backup server on Odroid-HC4 and was wrongly thinking when I upgrade to Debian/Bullseye it would upgrade the kernel to 5.10. Upgrade went well as per the nice and clear DietPi instructions, but kernel remained 4.9.x and it broke docker.
So couple of questions:

  1. Did you find a solution to upgrade to a newer kernel ?
  2. Armbian has a Bullseye image with kernel 5.10y, could that be used as base image to DietPi ?
  3. If yes, how do you build DietPi on top of another base image ?

Maybe MichaIng can answer the 2 last question.

Thanks for your help and this instruct-full thread.

For Odroid we have updated all our images to Bullseye.

If I’m not mistaken they should ship a newer kernel version. You could give it a try.

Creating own images is described on our online docs

Docker should have been fixed by the update to DietPi v7.7. Here is the patch, does this show any output in your case?

grep -q 'systemd.unified_cgroup_hierarchy=0' /boot/boot.ini || G_EXEC sed -i '/^setenv bootargs "/s/"$/ systemd.unified_cgroup_hierarchy=0"/' /boot/boot.ini
  1. Yes we plan to create new Odroid N2 and C4/HC4 images based on Armbians mainline kernel. The Hardkernel Linux 4.9 implies more and more issues with recent userland utilities.

  2. You should be able to flash the Armbian image and then run our PREP script:

EDIT: Ah whoops, doubled a little with Joulinars post :wink:. Our new images ship with the Docker/cgroupv2 patch, but still with the old Hardkernel Linux version.

Thanks for the quick answer to both of you.

This parameter is not set in my boot.ini file.
Trace-back: I installed the Buster image October 16th, version 6.34.3, I saw in my bash history that I ran a dietpi-update quite at the begin which brought me probably to 7.7.3. Then, few days ago, updated to 7.9.3 just before upgrading to Bullseye.

Good news, I can test that (as in meantime I gave a try to Armbian), so I will try to add DietPi. But that, if I understood well will not run with petitboot which is the standard bootloader for the Odroid HC4 (so I would have to hold down the button to bypass it or remove).

I did not use the latest image. I ran the upgrade path…

I will post if I succeed with Armbian+DietPi.

Thanks again :wink:

Using worked well except one error when rebooting:

[FAILED] File does not exist or cannot be written to by current user
Please verify the existence of the file $3
Retry with proper permissions or apply the setting manually:

The fix is:

touch /boot/dietpi/.installed

Then the menu got displayed, so it was expecting this file to exists.

Now I’m able to use the 5.10 kernel, which I wanted to have to use recent and more stable btrfs v5.10.1.
I successfully installed the OLED driver suggested by Armbian found HERE.
Hopefully the new image can be integrated with petitboot avoiding to press the button to boot or removing petitboot.

did you tried using dev brach for the PREP script themselves? Usually the issue should have been fixed.

bash -c "$(curl -sSfL '')"

Yes, I used that command.

just to avoid a misunderstanding. My command is explicitly pointing to /DietPi/dev/ and not to master branch as the command on our online docs :wink:

The error can be ignored btw, it doesn’t affect anything on the result of the first run setup. And yes, it’s solved in the dev branch which will be released this Saturday.

While petitboot may work, generally also with our image it is intended to boot via U-Boot from SD card/eMMC, otherwise I’m not sure whether settings and overlays from boot.ini are applied as intended.

The MTD flash can be erased via flash_eraseall command from mtd-utils package.


I did not notice about the dev branch in your reply, my mistake.

Great to hear.

Thanks for your feedback.

all good :sunglasses: