Today's Update for Rock64 Killed my System

I’m afraid I don’t know what version I am running but it is the version that was released today.

I have been running dietpi on a Rock64, booting from SD card but with the system on a USB disk drive.

I ended up in this situation because not matter how hard I tried (and I spent days on it) trying to get the system to boot from USB disk via SPI uboot booting from SD was my only option.

Today there were 5 updates which I blindly let apt fo its thing with. When I rebooted nothing…

I have connected the system which usually runs headless to a monitor and keyboard.

Something happens, the red LED flashes the heartbeat pulses but there is no disk activity and no output on the screen. though there are backups on a partition of my USB disk, I kind of need a running system to restore them which is a bit of a SNAFU.

Help and advice would be very welcome as my busy nextcloud is no longer running

To restore your backup you can flash a fresh system and then restore it via dietpi-backup.

Would be interesting to know what packages broke your system. If you are able to do, you can mount the disk on another system and check the apt history

cat /var/log/apt/history.log

Do you have any logs about from which to which kernel version the update happened? Indeed we pushed a new Rockchip kernel to the APT repo yesterday, but it was only a minor change from 6.18.13 to 6.18.16, which has a low risk of causing such issues. And I tested this kernel on a bunch of Rockchip SBCs, including the NanoPi NEO3 which has the same RK3328 SoC than the ROCK64.

The edge kernel branch however made a major jump from 6.19 to 7.0, so if you installed that one manually, possible that something broke for individual SBCs.

Hi, I am sorry but I lost everything in the end it was an update from .13 to .16 but I think I may have not helped things with my setup.

To be clear, I have a Rock64 that has an SD Card and a USB disk. I used the facility to move the rootfs to the USB disk and have been running on the SD Card and US Disk combo for some time.

I read somewhere though that running a system like that means that kernel updates will break the system so I have now recreated the system on the latest version but put an apt-mark hold on..

armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-u-boot-rock64-current

In the hope that this won’t happen again.

As per my original comment, it would be good to have an SPI U-Boot that worked. I spent many hours trying to get that to go without success eve though it is the same hardware that worked on the Ayufan stuff.

Which facility? If you show the exact steps you did, we might identify the issue. Probably you booted with the kernel from SD card but without matching modules on the USB drive after the kernel upgrade. It is essential that the SD card, or its /boot dir is mounted to /boot, else it is basically expected that any kernel upgrade breaks things.

Newer ROCK64 revisions do have an SPI storage which allows native USB boot, without the need for an SD card. But we can check that after the system has been restored. EDIT: Ah you did so already. Does /dev/mtd0 exist?

This time round, the exact steps are as follows:-

  1. Download latest version of dietpi for Rock64 to my chromebook
  2. unxz the file to a .img file and the zip it so that the ‘Recovery’ Utility’ on the Chromebook can burn it to a 8GB SD Card
  3. Let Dietpi go through its setup routine and install just a basic system
  4. Plugin USB drive. It has two 20GB partitions, sda1 for rootfs and sda2 for dietpi-backup
  5. Originally at this point I used drive_manager to copy the system to sda1 but this function no longer appears in the drive_manager menu so I did this…
  6. rsync -aAXv / --exclude={“/dev/“,”/proc/”,“/sys/“,”/tmp/”,“/run/“,”/mnt/”,“/media/*”,“/lost+found”} /mnt/sda1/
  7. Manually edit /boot/dietpiEnv.txt and /etc/fstab to point to the partition of /mnt/sda1 on both the SD Card and /mnt/sda1
  8. Reboot
  9. Do this to stop kernel upgrades ..apt-mark hold armbian-firmware linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-u-boot-rock64-current

I appreciate that I have put myself in the position where the system is locked out of upgrades but it seems to work for now..

I also see your comment about the SD Card /boot needing to be mounted as the real /boot but am unsure of how to do that because there is only one partition on the SD Card and only one sda1

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 ext4 1.0 2b5c0c55-fc74-4121-84c1-095ca9ec213a 15.9G 16% /
└─sda2 ext4 1.0 24e0ccd1-bb4e-4e4f-bef4-c32e5e78cf3a
mtdblock0
mmcblk0
└─mmcblk0p1 ext4 1.0 8de1413e-ec66-4185-baeb-21a5fc4a9813

I fell out with dietpi-backup as it did not restore I’m guessing because now I have a 6.18.16 system and the backup was done on a 6.8.13 one?

Advice to sort out the boot issue would be most welcome before I get too far down the route of setting up the nextcloud environment again.

Sadly, the Rock64 is now useless. I don’t know how but the SD Card holder is trashed. I cannot get the old card out and in trying have caused some damage.

For the sake of completeness though it would be good to know how to solve the /boot issue above.

I probably won’t get another Rock64 even though because of all of the USB boot issues

Thanks for helping me out