Kernel not updating after upgrade to bullseye, docker issues

Hi all, I am running dietpi on a pine64.

I have recently upgraded to bullseye from scratch (doing buster first) and then upgraded it to latest version (v8.4.2)

Still I can see that my kernel is still running 4.19. I tried to install linux-image but after rebooting it doesn’t change kernel version

 uname -a
Linux pine64 4.19.63-sunxi64 #5.92 SMP Fri Aug 2 00:18:27 CEST 2019 aarch64 GNU/Linux
dietpi@gal /boot $ ls -lrt
total 189488
-rw-r--r-- 1 root root     2970 Jan  9  2019 boot.cmd
-rw-r--r-- 1 root root     4882 Jan  9  2019 boot-desktop.png
-rw-rw-r-- 1 root root     3042 Jan  9  2019 boot.scr
-rw-r--r-- 1 root root     8196 Jan 29  2019 dietpi-README.md
lrwxrwxrwx 1 root root       19 Feb  2  2019 dtb.old -> dtb-4.19.17-sunxi64
-rw-r--r-- 1 root root   307322 Feb  2  2019 boot.bmp
-rwx------ 1 root root     2790 Feb  2  2019 dietpi-wifi.txt
-rwxr-xr-x 1 root root 14311432 Aug  1  2019 vmlinuz-4.19.63-sunxi64
-rw-r--r-- 1 root root  3049764 Aug  1  2019 System.map-4.19.63-sunxi64
-rw-r--r-- 1 root root   153113 Aug  1  2019 config-4.19.63-sunxi64
drwxr-xr-x 3 root root     4096 Sep 22  2019 dtb-4.19.63-sunxi64
lrwxrwxrwx 1 root root       23 Sep 22  2019 Image -> vmlinuz-4.19.63-sunxi64
lrwxrwxrwx 1 root root       19 Sep 22  2019 dtb -> dtb-4.19.63-sunxi64
-rw-r--r-- 1 root root      166 Sep 22  2019 armbianEnv.txt
-rw-r--r-- 1 root root 27533184 Dec  8 16:21 vmlinuz-5.10.0-10-arm64
-rw-r--r-- 1 root root       83 Dec  8 16:21 System.map-5.10.0-10-arm64
-rw-r--r-- 1 root root   254044 Dec  8 16:21 config-5.10.0-10-arm64
-rw-r--r-- 1 root root 27533184 Apr 29 10:36 vmlinuz-5.10.0-14-arm64
-rw-r--r-- 1 root root       83 Apr 29 10:36 System.map-5.10.0-14-arm64
-rw-r--r-- 1 root root   254124 Apr 29 10:36 config-5.10.0-14-arm64
-rw-r--r-- 1 root root    11605 May 22 09:41 dietpi.txt
drwxr-xr-x 4 root root     4096 May 22 09:41 dietpi
-rw-r--r-- 1 root root  6574100 May 22 12:00 initrd.img-4.19.63-sunxi64
-rw-r--r-- 1 root root  6574164 May 22 12:00 uInitrd-4.19.63-sunxi64
-rw-r--r-- 1 root root 26869640 May 26 11:16 initrd.img-5.10.0-14-arm64
-rw-r--r-- 1 root root 26869704 May 26 11:16 uInitrd-5.10.0-14-arm64
-rw-r--r-- 1 root root 26826911 May 27 18:26 initrd.img-5.10.0-10-arm64
-rw-r--r-- 1 root root 26826975 May 27 18:27 uInitrd-5.10.0-10-arm64
lrwxrwxrwx 1 root root       23 May 27 18:27 uInitrd -> uInitrd-5.10.0-10-arm64

I believe this is causing my docker to not start

May 27 18:28:45 pine64 dockerd[552]: time="2022-05-27T18:28:45.780011512+01:00" level=error msg="4852e2a05e99ebfdb728739e412af8eac5cbf5eb9234124f88b15dc9e2085da5 cleanup: failed to delete container from containerd: no such container"
May 27 18:28:45 pine64 dockerd[552]: time="2022-05-27T18:28:45.780150470+01:00" level=error msg="failed to start container" container=4852e2a05e99ebfdb728739e412af8eac5cbf5eb9234124f88b15dc9e2085da5 error="failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown"

Is it probably using the legacy kernel packages for some reason?

dpkg -l | grep linux
 dpkg -l | grep linux
ii  console-setup-linux            1.205                          all          Linux specific part of console-setup
ii  libselinux1:arm64              3.1-3                          arm64        SELinux runtime shared libraries
ii  linux-base                     4.6                            all          Linux image base package
ii  linux-dtb-next-sunxi64         5.92                           arm64        Linux DTB, version 4.19.63-sunxi64
ii  linux-image-5.10.0-10-arm64    5.10.84-1                      arm64        Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-5.10.0-14-arm64    5.10.113-1                     arm64        Linux 5.10 for 64-bit ARMv8 machines (signed)
ii  linux-image-arm64              5.10.113-1                     arm64        Linux for 64-bit ARMv8 machines (meta-package)
ii  linux-image-next-sunxi64       5.92                           arm64        Linux kernel, version 4.19.63-sunxi64
ii  linux-libc-dev:arm64           5.10.113-1                     arm64        Linux support headers for userspace development
ii  linux-stretch-root-next-pine64 5.73                           arm64        Armbian tweaks for stretch on pine64 (next branch)
ii  linux-u-boot-pine64-next       5.90                           arm64        Uboot loader 2019.04
ii  util-linux                     2.36.1-8+deb11u1               arm64        miscellaneous system utilities

I guess these are incorrect kernel packages. If I’m not mistaken, you require a linux-image-next-sunxi64 kernel package for the Pine64 for.

@MichaIng You are the master of our images, could this be an older image, like we had for the Ordroid, not being able to update for a newer version of the kernel? Or was this not an issue on the Pine64?

I may have tried to manually update them, but yeah they are not used

Jep, those are the Debian kernel packages while the bootloader looks for specific files provided by the Armbian kernel packages. I’ll give you instructions how to upgrade the kernel when I’m back home, the package names have changed (“current” instead of “next”).

2 Likes

Okay, before doing this, at best do an SD card backup, in case something goes wrong and the device becomes unbootable. Then install the new kernel/dtb/bootloader first + flash U-Boot:

apt install linux-image-current-sunxi64 linux-dtb-current-sunxi64 linux-u-boot-pine64-current
. /usr/lib/u-boot/platform_install.sh # the leading dot and space are intended here ;)
write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$(findmnt -Ufnro SOURCE -T /boot)")"

This may already remove the “next” packages in the same turn. Then remove the Debian kernel packages as well:

G_AGP linux-dtb-next-sunxi64 linux-image-5.10.0-10-arm64 linux-image-5.10.0-14-arm64 linux-image-arm64 linux-image-next-sunxi64 linux-stretch-root-next-pine64 linux-u-boot-pine64-next

Before you reboot, can you paste the output of:

cat /boot/boot.cmd

I want to compare it with the latest one, just in case there have been breaking changes.

1 Like
# cat /boot/boot.cmd
# DO NOT EDIT THIS FILE
#
# Please edit /boot/armbianEnv.txt to set supported parameters
#

# default values
setenv load_addr "0x44000000"
setenv rootdev "/dev/mmcblk0p1"
setenv verbosity "1"
setenv rootfstype "ext4"
setenv console "both"
setenv docker_optimizations "on"

# Print boot source
itest.b *0x10028 == 0x00 && echo "U-boot loaded from SD"
itest.b *0x10028 == 0x02 && echo "U-boot loaded from eMMC or secondary SD"
itest.b *0x10028 == 0x03 && echo "U-boot loaded from SPI"

echo "Boot script loaded from ${devtype}"

if test -e ${devtype} ${devnum} ${prefix}armbianEnv.txt; then
        load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt
        env import -t ${load_addr} ${filesize}
fi

if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=ttyS0,115200 console=tty1"; fi
if test "${console}" = "serial"; then setenv consoleargs "console=ttyS0,115200"; fi

# get PARTUUID of first partition on SD/eMMC it was loaded from
# mmc 0 is always mapped to device u-boot (2016.09+) was loaded from
if test "${devtype}" = "mmc"; then part uuid mmc 0:1 partuuid; fi

setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} panic=10 consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}"

if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi

load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
fdt addr ${fdt_addr_r}
fdt resize 65536
for overlay_file in ${overlays}; do
        if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then
                echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo"
                fdt apply ${load_addr} || setenv overlay_error "true"
        fi
done
for overlay_file in ${user_overlays}; do
        if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then
                echo "Applying user provided DT overlay ${overlay_file}.dtbo"
                fdt apply ${load_addr} || setenv overlay_error "true"
        fi
done
if test "${overlay_error}" = "true"; then
        echo "Error applying DT overlays, restoring original DT"
        load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
else
        if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then
                echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)"
                source ${load_addr}
        fi
        if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then
                load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr
                echo "Applying user provided fixup script (fixup.scr)"
                source ${load_addr}
        fi
fi

load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd
load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image

booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

looking good after reboot!

uname -a
Linux pine64 5.15.43-sunxi64 #22.05.1 SMP Sat May 28 08:25:20 UTC 2022 aarch64 GNU/Linux

and docker containers are up :grinning:

thanks @MichaIng your instructions worked fine

Okay great, luckily the boot.cmd is up-to-date already for this kernel and bootloader.