Upgrade from 8.5.1 not working on RockPro64

I updated our ROCKPro64 image btw :slightly_smiling_face:.

1 Like

The upgrade failed as before says it needs to reboot

I copied a directory to /usr/lib/modules/5.15.72-rockchip64
the reboot message went away but
it seems to be looking for this directory in error

root@Bwana:~# uname -a
Linux Bwana 5.15.72-rockchip64 #22.08.4 SMP PREEMPT Fri Oct 7 16:46:30 UTC 2022 aarch64 GNU/Linux

It looks for /usr/lib/modules/5.15.72-rockchip64, but which directory is present instead? And does it match the version installed in /boot?

There was a bug in recent Armbian rockchip64 kernel, which has been taken down in the meantime and fix is on the way. Not sure whether it’s related, but it caused a complete boot failure on other SBCs, like ROCK Pi 4.

The upgrade installs /usr/lib/modules/5.15.74-rockchip64 but requests reboot until I install /usr/lib/modules/5.15.72-rockchip64 .

can you share content of /boot as requested by @MichaIng above.

I don’t understand what you are asking for, a directory listing?

total 59296
drwxr-xr-x  4 root root     4096 Oct 31 16:31 .
drwxr-xr-x 18 root root     4096 Oct 13 14:41 ..
-rw-r--r--  1 root root        0 Oct 14 12:19 .next
lrwxrwxrwx  1 root root       26 Oct 14 12:19 Image -> vmlinuz-5.15.72-rockchip64
-rw-r--r--  1 root root  6391168 Oct  7 11:46 System.map-5.15.72-rockchip64
-rw-r--r--  1 root root      215 Jun 29 02:55 armbianEnv.txt
-rw-r--r--  1 root root   307322 Dec 17  2021 boot.bmp
-rw-r--r--  1 root root     3113 Aug 26  2021 boot.cmd
-rw-rw-r--  1 root root     3185 Aug 26  2021 boot.scr
-rw-r--r--  1 root root        0 Oct 31 16:31 boot.txt
-rw-r--r--  1 root root   231723 Oct  7 11:46 config-5.15.72-rockchip64
drwxr-xr-x  4 root root     4096 Oct 14 12:48 dietpi
-rw-rw-r--  1 root root    18092 Dec 17  2021 dietpi-LICENSE.txt
-rw-rw-r--  1 root root    14517 Dec 17  2021 dietpi-README.md
-rw-rw-r--  1 root root    15141 Oct 28 12:06 dietpi.txt
lrwxrwxrwx  1 root root       22 Oct 14 12:19 dtb -> dtb-5.15.72-rockchip64
drwxr-xr-x  6 root root     4096 Oct 14 12:17 dtb-5.15.72-rockchip64
-rw-r--r--  1 root root 11573436 Oct 14 12:20 initrd.img-5.15.72-rockchip64
lrwxrwxrwx  1 root root       26 Oct 14 12:20 uInitrd -> uInitrd-5.15.72-rockchip64
-rw-r--r--  1 root root 11573500 Oct 14 12:20 uInitrd-5.15.72-rockchip64
-rw-r--r--  1 root root 30540288 Oct  7 11:46 vmlinuz-5.15.72-rockchip64

Can you show:

dpkg -S /lib/modules/5.15.74-rockchip64
dpkg -S /boot/vmlinuz-5.15.72-rockchip64

Probably this was the issue with the Armbian package, mixing different kernel and modules versions.

I took an old 8.3.1 image from my archives, upgraded it to 8.10.2 and the update went smoothly. with the emmc jumper applied.
Then I updated my sd boot card 8.9.2 to 8.10.2 and that upgrade went smoothly with the emmc jumper applied then
I updated my 8.9.2 EMMC card to 8.10.2 and that upgrade went smoothly . with the emmc jumper off
the problem seemed to occur when the update was attempted with the sd card in and the emmc jumper off. this seemed to confuse the system as to where certain files were stored during the update.

the system module directory is now /lib/modules/5.15.76-rockchip64.

any comments?

I’ll post this here just for your information. Upgraded from 8.8.x, cant remember the exact version and dietpi didn’t even boot. No video signal after the some seconds of normal boot log.
I ended up creating an emmc’s image and migrating the data to a new installation.
I still have the old emmc image, I can provide some informations if needed.

The DietPi version btw ia irrelevant. It’s the kernel upgrade which you can do isolated via:

apt update
apt upgrade

There was a faulty kernel v5.15.75 which broke boot on all rockchip64 boards, but v5.15.76 (or later) doesn’t have the issue anymore.

If you have bootable DietPi images on SD card as well as eMMC then indeed this may be the issue (regardless how you set the eMMC switch) since the UUIDs of the contained filesystems may match so that the board may boot with kernel from SD card but mount the eMMC filesystem or the other way round. After upgrading the kernel on how, however, it should work, but still might mount sometimes the one or the other filesystem by chance. Mounting is done based on UUID. To workaround this you could replace the UUID=... part in /etc/fstab to match the currently mounted device path: echo $G_ROOTFS_DEV. Ah and same in /boot/boot.cmd and compiling /boot/boot.scr.

just to avoid a misunderstanding, we as DietPi team don’t do own kernel development. On rockchip64 boards we use Armbian as base image, and the Armbian kernel was a faulty one for a couple of hours or a day. Thy to Armbian guys for removing the faulty kernel quickly and provide a new one on short time.

1 Like

I never had that faulty kernel. i went from 72 to 74 now 76.and all is well. The problem arose from there being an sd card and an emmc card both containing operating systems and the jumper off, even if they had different UUID’s the upgrade process would update one kernel and try to use the other. With that jumper off it gets confused as to which kernel to update. My solution was to install a switch to close the jumper when the emmc is not being used to boot the machine. Rockpro64.