Upgrade from 8.5.1 not working on RockPro64

Why are the images for Rock64 and Rockpro64 not updated? and dietpi-upgrade not working?

Not sure what you mean but all our updates are independent from SOC type. What is the output of

dietpi-update

The image for RockPro64 is 10 months old, 8.5.1 other platforms are 8.9.2. is there a problem with the pine boards?

Did you tried to simply run dietpi-update?

A reboot is required to finalise a recent kernel upgrade, even after reboot . doesn’t go away

Cant install software :
Kernel modules for the loaded kernel at /lib/modules/5.15.48-rockchip64 are missing. This is most likely the │
│ case as of a recently applied kernel upgrade where a reboot is required to load the new kernel.

rebooting does no good

it appears that the kernel files were copied to /lib/modules/5.15.72-rockchip64 but the kernel didn’t upgrade
root@Bwana:/# uname -a
Linux Bwana 5.15.48-rockchip64 #22.05.3 SMP PREEMPT Wed Jun 22 07:27:54 UTC 2022 aarch64 GNU/Linux

system will not map an NFS share
[FAILED] NFS mount failed with the following error output: │
│ │
│ mount.nfs: mount(2): No such device │
│ mount.nfs: No such device │
│ mount.nfs: timeout set for Tue Oct 11 06:53:10 2022 │
│ mount.nfs: trying text-based options │
│ ‘port=2049,vers=4.2,addr=192.168.0.27,clientaddr=192.168.0.29’

what is not going away? What exactly is not working? What is the output of dietpi-update? What exactly you are trying to do?

Install dietpi .on a RockPro64
when it first boots it attempts to upgrade and gives the aforementioned “reboot” message. which I do but the message stays until I create the directory </lib/modules/5.15.48-rockchip64>
then i try to install NFS and NFS server wont start with a dependency error
NFS client won’t map a share with a no such device error

oot@Bwana:/# uname -a
Linux Bwana 5.15.48-rockchip64 #22.05.3 SMP PREEMPT Wed Jun 22 07:27:54 UTC 2022 aarch64 GNU/Linux

does this mean the kernel didn’t upgrade?

so your issue is the kernel upgrade now and not the DietPi update? Both are completely independent thinks as DietPi is not creating, developing, or managing kernel version. We always use the stock kernel provided from underlying base image.

@MichaIng could you have a look pls.

Sorry I’m New at this,
Dietpiwont dietpi-ugrade or install. When I dietpi-upgrade it leaves me with that aforementioned reboot message and I can no longer install software. Thanks

you mean dietpi-update I guess? Because we don’t have a tool dietpi-ugrade :wink:

The main problem seems to be the incomplete kernel update.

Try following

/boot/dietpi/func/dietpi-set_software apt-cache clean
apt update
apt upgrade
apt full-upgrade
reboot

Does this have any effect on kernel version?

did not change the diet pi version and uname output is same as above

If i go to dietpi-software it asks me to reboot did it 5 times same result

Thanks

ok we are in some kind of loop :wink:

an apt upgrade will not change any dietpi version. This is done by dietpi-update only.

dietpi-software is not working due to the incorrect kernel update. This is just a symptom. Before doing anything else, the kernel needs to be corrected.

yes my master. show me the way. Pardon the Vader impression, It’s very late and I must take my mask off.

Can you show the output of these commands:

dpkg -l | grep '^linux-'
ls -l /boot

It seems /boot/Image was not updated as expected, respectively the symlink to the new kernel image not set.

dpkg -l | grep '^linux-'

no ouput returns to prompt

dpkg -l | grep 'linux-'    ---modified removed carat
root@BWANA:~# dpkg -l | grep 'linux-'
ii  binutils-aarch64-linux-gnu     2.35.2-2                       arm64        GNU binary utilities, for aarch64-linux-gnu target
ii  linux-base                     4.6                            all          Linux image base package
ii  linux-dtb-current-rockchip64   22.08.4                        arm64        Armbian Linux DTB, version 5.15.72-rockchip64 current
ii  linux-image-current-rockchip64 22.08.4                        arm64        Linux kernel, armbian version 5.15.72-rockchip64 current
ii  linux-libc-dev:arm64           22.08.4                        arm64        Armbian Linux support headers for userspace development
ii  linux-u-boot-rockpro64-current 22.08.4                        arm64        Uboot loader 2022.04
root@BWANA:~#


ls -l /boot

root@BWANA:~# ls -l /boot
total 94912
lrwxrwxrwx 1 root root       26 Oct 12 02:51 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      228 Apr 16 00:40 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   231723 Oct  7 11:46 config-5.15.72-rockchip64
drwxr-xr-x 4 root root     4096 Apr 16 14:33 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    15105 Apr 17 21:06 dietpi.txt
lrwxrwxrwx 1 root root       22 Oct 12 02:51 dtb -> dtb-5.15.72-rockchip64
drwxr-xr-x 6 root root     4096 Oct 12 02:49 dtb-5.15.72-rockchip64
-rw-r--r-- 1 root root 12443797 Oct 19  2021 initrd.img-5.10.60-rockchip64
-rw-r--r-- 1 root root 12442464 Oct 19  2021 initrd.img-5.10.63-rockchip64
-rw-r--r-- 1 root root 11587191 Apr 16 01:03 initrd.img-5.15.25-rockchip64
-rw-r--r-- 1 root root 11573939 Oct 12 02:54 initrd.img-5.15.72-rockchip64
lrwxrwxrwx 1 root root       26 Oct 12 02:54 uInitrd -> uInitrd-5.15.72-rockchip64
-rw-r--r-- 1 root root 11574003 Oct 12 02:54 uInitrd-5.15.72-rockchip64
-rw-r--r-- 1 root root 30540288 Oct  7 11:46 vmlinuz-5.15.72-rockchip64

This is all correct, there is no other kernel than v5.15.72 which is also correctly linked. If you did a reboot and it still loads v5.15.48, then the only possibility is that it loads from a different boot partition than the one which is mounted. Are there other drives attached to this ROCKPro64?

fdisk -l
df

The obsolete initramfs images will be cleaned up on next kernel upgrade btw, a rated postinst script was installed/updated during the DietPi update.

There’s a Emmc with dietpi on in. I renamed the /boot to /holdboot and booted to sdcard
reran dietpi-update and Viola. It worked!

there was early man, then neanderthal man, but today udaman.

Thanks

1 Like

Okay great that it worked. Probably the UUIDs of the filesystems on eMMC and SD card match so that the bootloader from eMMC (loaded with priority) and kernel mounted the root filesystem from SD card.

we could check available drives

lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
1 Like

exactly correct! SD card and EMMC module have same UUID.

solved using fdisk to change device id and tune2fs to randomize UUID

Thanks very much