no usb3 after apt upgrade / Rock64

Troubleshooting
21

Yes, but they are missing the last bit:

javi@rock64:~$ cat /boot/armbianEnv.txt
verbosity=1
overlay_prefix=rockchip
rootdev=UUID=1639309a-8d38-46b5-b9bc-ac91ff373f78
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x1058:0x07a8:u
javi@rock64:~$ sudo sed -i '/usbstoragequirks/d' /boot/armbianEnv.txt
javi@rock64:~$ cat /boot/armbianEnv.txt
verbosity=1
overlay_prefix=rockchip
rootdev=UUID=1639309a-8d38-46b5-b9bc-ac91ff373f78
rootfstype=ext4
javi@rock64:~$ sudo reboot
...
javi@rock64:~$ cat /boot/armbianEnv.txt
verbosity=1
overlay_prefix=rockchip
rootdev=UUID=1639309a-8d38-46b5-b9bc-ac91ff373f78
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u



The only two packages I’ve been holding back were linux-dtb-current-rockchip64 and linux-image-current-rockchip64. You can see the result here:

javi@rock64:~$ apt list --upgradable
Listing... Done
linux-dtb-current-rockchip64/bionic 22.02.1 arm64 [upgradable from: 21.08.2]
linux-image-current-rockchip64/bionic 22.02.1 arm64 [upgradable from: 21.08.2]
javi@rock64:~$ sudo apt install linux-u-boot-rock64-current
Reading package lists... Done
Building dependency tree
Reading state information... Done
linux-u-boot-rock64-current is already the newest version (21.08.1).
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

Can that be the problem? The linux-dtb-current-rockchip64 and linux-image-current-rockchip64 packages have a 22.02.1 version available but the U-boot stays on 21.08.1:

javi@rock64:~$ sudo apt list -a linux-u-boot-rock64-current
Listing... Done
linux-u-boot-rock64-current/bionic,now 21.08.1 arm64 [installed]
linux-u-boot-rock64-current/bionic 21.05.1 arm64
linux-u-boot-rock64-current/bionic 21.02.3 arm64

javi@rock64:~$ sudo apt list -a linux-dtb-current-rockchip64
Listing... Done
linux-dtb-current-rockchip64/bionic 22.02.1 arm64 [upgradable from: 21.08.2]
linux-dtb-current-rockchip64/bionic,now 21.08.2 arm64 [installed,upgradable to: 22.02.1]
linux-dtb-current-rockchip64/bionic 21.08.1 arm64
linux-dtb-current-rockchip64/bionic 21.08 arm64
linux-dtb-current-rockchip64/bionic 21.05.9 arm64
linux-dtb-current-rockchip64/bionic 21.05.4 arm64
linux-dtb-current-rockchip64/bionic 21.05.1 arm64
linux-dtb-current-rockchip64/bionic 21.02.3 arm64
linux-dtb-current-rockchip64/bionic 21.02.2 arm64

javi@rock64:~$ sudo apt list -a linux-image-current-rockchip64
Listing... Done
linux-image-current-rockchip64/bionic 22.02.1 arm64 [upgradable from: 21.08.2]
linux-image-current-rockchip64/bionic,now 21.08.2 arm64 [installed,upgradable to: 22.02.1]
linux-image-current-rockchip64/bionic 21.08.1 arm64
linux-image-current-rockchip64/bionic 21.08 arm64
linux-image-current-rockchip64/bionic 21.05.9 arm64
linux-image-current-rockchip64/bionic 21.05.4 arm64
linux-image-current-rockchip64/bionic 21.05.1 arm64
linux-image-current-rockchip64/bionic 21.02.3 arm64
linux-image-current-rockchip64/bionic 21.02.2 arm64



I tried that but again, it didn’t work:

javi@rock64:~$ sudo bash -c '. /usr/lib/u-boot/platform_install.sh; write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$(findmnt -Ufnro SOURCE -M /)")"'
javi@rock64:~$ apt list --upgradable
Listing... Done
linux-dtb-current-rockchip64/bionic 22.02.1 arm64 [upgradable from: 21.08.2]
linux-image-current-rockchip64/bionic 22.02.1 arm64 [upgradable from: 21.08.2]
javi@rock64:~$ sudo apt install linux-dtb-current-rockchip64=22.02.1 linux-image-current-rockchip64=22.02.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following held packages will be changed:
  linux-image-current-rockchip64
The following packages will be upgraded:
  linux-dtb-current-rockchip64 linux-image-current-rockchip64
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 51.6 MB of archives.
After this operation, 122 MB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 http://mirrors.dotsrc.org/armbian-apt bionic/main arm64 linux-dtb-current-rockchip64 arm64 22.02.1 [365 kB]
Get:2 http://es.armbian.mirrors.bret.dk/apt bionic/main arm64 linux-image-current-rockchip64 arm64 22.02.1 [51.2 MB]
Fetched 51.6 MB in 5s (9,547 kB/s)
(Reading database ... 109681 files and directories currently installed.)
Preparing to unpack .../linux-dtb-current-rockchip64_22.02.1_arm64.deb ...
Unpacking linux-dtb-current-rockchip64 (22.02.1) over (21.08.2) ...
Preparing to unpack .../linux-image-current-rockchip64_22.02.1_arm64.deb ...
update-initramfs: Deleting /boot/initrd.img-5.10.63-rockchip64
Removing obsolete file uInitrd-5.10.63-rockchip64
Unpacking linux-image-current-rockchip64 (22.02.1) over (21.08.2) ...
Setting up linux-image-current-rockchip64 (22.02.1) ...
update-initramfs: Generating /boot/initrd.img-5.15.25-rockchip64
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/drivers/cdrom/cdrom.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/isofs/isofs.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/jfs/jfs.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/reiserfs/reiserfs.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/udf/udf.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/xfs/xfs.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/netfs/netfs.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/fscache/fscache.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/net/sunrpc/sunrpc.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs_common/grace.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/lockd/lockd.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfs.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfsv2.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs_common/nfs_acl.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfsv3.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nfs/nfsv4.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/fs/nls/nls_iso8859-1.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/lib/842/842_decompress.ko.xz not found.
modinfo: ERROR: Module /lib/modules/5.15.25-rockchip64/kernel/drivers/md/dm-mod.ko.xz not found.
update-initramfs: Converting to u-boot format
Setting up linux-dtb-current-rockchip64 (22.02.1) ...

Could it be that those problems come from the u-boot package not having the same version as the linux-image-current-rockchip64 and linux-dtb-current-rockchip64?

22

This worked to get me back on track. I had a network share drive that was disconnected, and the system was hanging after the upgrade.

I still see I have 2 apt upgrades waiting for me after the rollback, I’m guessing these are due to the rollback and I shouldn’t touch them?

In any case, chiming in here to follow this thread, as any news will be welcome to keep up to date with.

23

probably better to follow this GitHub issue https://github.com/MichaIng/DietPi/issues/5378

It’s a problem we might not be able to fix from DietPi side as we don’t do any kernel development.

To check the 2 apt packages pending, you could do foollowing

apt update
apt list --upgradable
24

Yeah, I see that this board is no longer maintained/supported by Armbian, and the maintainer seems to have fallen off. Really sad, this board is still quite capable compared to boards that are still maintained.

I was able to check the packages and indeed they seem to be the kernel packages. I will simply hold off on updating and ride this board out into legacy land, and will be looking for more supported hardware.

Very sad day.

25

sorry to hear but not really something we could influence :frowning:

26

The older U-Boot package usually isn’t an issue. The included actual U-Boot version is changed rarely by Armbian, so the version increment is often just a formal thing without any actual change. Also even in case of a U-Boot bump, it should be rare that the older U-Boot is incompatible with the newer kernel, breaking changes regarding support for different kernel image/initramfs/dtb format or boot config syntax is rare. We just have that topic on Armbian as 2015 U-Boot cannot boot the common Linux image format, but a specific U-Boot format with added headers only. But even that doesn’t break anything since both formats are created: /boot/Image and /boot/uImage. How to drop legacy uImage generation without breaking boot on old images is the open question :slight_smile:.

Okay, so it’s neither the (two present) USB quirks, nor U-Boot. I’m puzzled then what can have changed between an older but upgraded Armbian image compared to the current Armbian image, so that this USB 3.0 issue is present on the first but not on the second :thinking:.

Interesting that USB quirks re-appear. Looks like one of the many Armbian boot scripts re-adds them. There is even an additional one added. On the other hand, the new image does not ship with these USB quirks. I just checked it offline, are they probably added as well on actual boot?

Now I’m wondering whether the additional quirk may be even the solution. Did you reboot now that it is there and check back? Probably it is only added when no usbstoragequirks line exists, during boot, hence effective from next reboot on. So the older image, where usbstoragequirks exists already, the additional one is missing? It should only affect one specific USB drive or chip, but worth to test it. With:

lsusb

You can check the IDs of attached USB devices and compare them with the quirks.

I’ll regenerate our ROCK64 and NanoPi NEO3 images based on current Armbian image, let’s see whether this solves the issue for our users as well.

27

I’ll regenerate our ROCK64 and NanoPi NEO3 images based on current Armbian image, let’s see whether this solves the issue for our users as well.

Curious to see if this solves it.

28

I did a fresh install yesterday (Rock64, SSD on USB3). The image boots, does its autoupgrade and attempts an autoreboot. After that the board is unreachable\dead. Powering off the device and switching the ssd to USB2 enables normal operation. So I can confirm that USB3 is still broken on 8.3.1.

29

Just to avoid a misunderstanding. This is nothing a DietPi update will fix as it is an issue of the Armbian kernel for your board.

Did you tried to downgrade the kernel and mark them as on hold to avoid further updates?

apt install linux-dtb-current-rockchip64=21.08.2 linux-image-current-rockchip64=21.08.2
apt-mark hold linux-dtb-current-rockchip64 linux-image-current-rockchip64
30

Thanks, that worked.

31

Hi pals, hope it’s alright that I’m bumping this one from a while back.

Recently installed DietPi on my Rock64 after being disappointed with OMV and Manjaro. Really like DietPi so far! I’m having the same issue as folks, and the suggested kernel downgrade did make a difference, but I still can’t get it working. I have 2 external HDDs (one 2.5", one 3.5" w/ power) hooked up to a powered USB3 hub. The issue is that the drives are disappearing and reappearing every 5-10 seconds, making them unusable. I had this same issue on Manjaro, but not on OMV (using the Ayufan 0.8.3 build from here). Using OMV on my Rock64, the USB3 drives worked perfectly. Additionally, they work perfectly when I plug it into my Windows laptop.

A couple other stray observations that might help: First, CPU usage varies wildly when I have USB3 hub plugged in to the USB3 port, CPU usage drops and remains steady when it’s not plugged in or plugged into the USB2 port. Second, one of the errors that pops up when using the “refresh” function of the dietpi-drive_manager is “the following drive seems to have no UUID, skipping fstab entry: /dev/sbd5 /mnt/drive2 fuseblk”

So TL;DR -

Newest kernel: no USB3 at all.
Kernel 21.08.2: USB3 exists, unusable with USB3 hub.
OMV Ayufan 0.8.3 build (OMV 4 - Arrakis): works perfectly
USB3 hub plugged into USB2 port with newest kernel: works perfectly

Anyone have any ideas that might help? My thought would be that, since it works on that older build of OMV, maybe a further downgrade would get the job done? But I don’t know the kernels well enough to guess what might work.

32

Kernel 21.08.2

This is not the kernel version, this is the distro release version. To find the kernel version, try:

uname -a



USB3 hub

Don’t use a USB 3 hub with the Rock64, it’s just not reliable. There was some discussion about this on the Pine64 forums but I can’t seem to find it right now. Basically, the controller just doesn’t work well with hubs. Direct connect all storage to the device, avoid hubs.

The Rock64 is a dead-end piece of hardware in my honest opinion. Armbian, the largest reliable kernel developer for the board, has completely abandoned it. I sold mine and moved to a Dell Optiplex 3050 micro and installed the PC DietPI image on it, works FLAWLESSLY. Faster, more stable, current kernel, more I/O. It draws more power (35w vs 5w), but that’s negligible in my opinion.

33

Ahhh yeah, my bad. Current kernel is: 5.10.63-rockchip64

Sadly, no budget to change from the rock64 at this point in time so I’ll make it work with what I’ve got and leave the USB hub out. I appreciate the advice, though!

34

@kmkm
Does the USB3 port otherwise work well with the older kernel, when attaching a USB3 drive directly instead of the hub?