I updated our ROCKPro64 image btw 
.
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
root@Bwana:~#
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 .
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?
Hi,
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.