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 
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
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
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
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