ChrisO

@laibsch, the answer to your question is in my last post. All those bad/"half-broken" adapters don't have problems with sequential writing/reading. And if you consider helpful pointing me to some obscure GUI writing tools as helpful, sorry, it's was not. I trust "dd" more then any of them. Very helpful was, however, @eselarm's post and I expressed my gratitude for it. To be honest, I don't really understand the intention of your last post. Could be my English is not good enough... Anyway, if my tone was was too harsh, I apologize for it.

Hi Installed Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img and one of the USB-3 port, the top one, doesn't work. No reaction when inserting something, nothing in /var/log/syslog. The same with Armbian_25.11.1_Rock-5c_noble_current_6.12.58_minimal.img The Armbian_25.11.1_Rock-5c_trixie_vendor_6.1.115_minimal.img however is OK. What could be the cause of this problem? Thanks and regards, Chris

Hi I have a Rock5c with a Penta SATA hat and it works OK. It is the only (?) way of having several disk connected to Rock5c. Note, it cannot boot of the disks on the hat. Have two SSDs and mirrored ZFS pool. No problems at all. Setting it up to act as Frigate server. The fifth SATA, in fact e-SATA connector comes very handy to connect a large disc for constant recording. You may also consider Odroid HC4. I think it's the cheapest solution and it's fan is negligible 🙂 Have three of them, acting as mail/backup/HomeAssistant servers. Had in the past some problems with USB but recent kernels are OK. Hope it helps.

Brillant, eselarm! I followed your suggestion to avoid USB-adapter issues and took my quite old laptop with a MCC/SD slot. Run fsck -fn /dev/mmcblk0p1 - no errors! As you suspected, the USB-adapter is at fault! I grabbed all SD-USB adapters I collected over the years and tried them. Different results, fsck without errors using few of them. My lesson lerned is: NEVER TRUST A USB-SD ADAPTER! The strange thing however is, that using this faulty adapter (14cd:1212 Super Top microSD card reader (SY-T18)) some images like Armbian_25.8.1_Rockpi-e_noble_current_6.12.41.img fsck'ed OK. I think all my adapters can cope w/o problems with simple, more or less sequntiell, reads/writes. It's what they do most of the time. I guess, when it comes to more complex I/O operations requested by fsck, some of them give out. What eselarm also suggested. Just for reference, the bad ones: 2 x 14cd:1212 Super Top microSD card reader (SY-T18) 5136:4678 Generic USB2.0 Device aaaa:8816 MXT microSD CardReader The OK ones: two with this inside: 090c:6200 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) microSD card reader and 14cd:127b Super Top SDXC Reader (very old, labeled hama) Thanks and regards, Chris

I should have mentioned, I tried fsck on loop device and it was fine. It's what I cannot understand. In my script after writing the image I read it back and compare with the source: dd status=progress if=Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img of=/dev/sdc bs=1M conv=fsync 2032140288 bytes (2.0 GB, 1.9 GiB) copied, 79 s, 25.7 MB/s2034237440 bytes (2.0 GB, 1.9 GiB) copied, 79.2902 s, 25.7 MB/s Reading image from disk ... dd status=progress if=/dev/sdc of=Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.from-disk bs=1M count=1941 2032140288 bytes (2.0 GB, 1.9 GiB) copied, 127 s, 16.0 MB/s They are equal in size. Produce same SHA hash: $ sha256sum Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img* ab74fc6f34f4f235ca224bc8d282feb1acf94cfe56bdf0b93c21894838ea0c71 Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img ab74fc6f34f4f235ca224bc8d282feb1acf94cfe56bdf0b93c21894838ea0c71 Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.from-disk Tried also simple cmp on image file and SD card: $ sudo cmp Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img /dev/sdc cmp: EOF on Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img after byte 2034237440, in line 14175730 See, after byte 2034237440, so the 2034237440 bytes are equal on disk and on the SD card, .img is 2034237440 bytes of size: $ stat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img File: Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img Size: 2034237440 Blocks: 1643993 IO Block: 131072 regular file $ sudo -fn /dev/sdc1 gives FS errors, hundreds of "Unattached inode" and such. Pass 5: Checking group summary information armbi_root: ********** WARNING: Filesystem still has errors ********** armbi_root: 64131/123136 files (0.1% non-contiguous), 441689/492539 blocks Voodoo? 😉 A spare SD card anyone to try it: 🙂

This is really a strange question, Werner. fsck for filesystems like ext2/3/4 is for a purpose, no? But here you go. Normally when I install a new system, configure it to my needs and liking I make a backup image of it. To let say quickly restore after breaking the system with some "experiments" or such. Is much easier then install from scratch. As first step in this procedure i shrink the filesystem on the 1st partition which requires a fsck -f on it. Theodore's telling us to do so, he must know why 🙂 So I discovered those two images I mentioned give me filesystem errors. As there is nobody in my neighborhood messing up with Armbian, I asked here for help. If somebody could try to see if he/she reproduced my problem. Instead I was instructed what tools are recommended (by whom?) and "scolded" for using fsck. 🙂 BTW, after fsck lost+found contains several hundreds of files, most of them .c/.h from kernel source/headers. Thanks.

I do verify what is written to the SD card. It's a homegrown script I have used for at least ten years. It's not the cause of my problem. And as for all those shiny clicky-clickity tools, no thanks! I prefer to know what is going on on my computer. Any comments on my question, anyone? If anybody could write one of the images using his his preferred/recommended imaging tool and run fsck on the resulting partition it would help me much. Thank you.

Hi I dd the Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img to a SD card (/dev/sdc) and then run a fsck -f /dev/sdc1 and got errors: sudo fsck -f /dev/sdc1 fsck from util-linux 2.39.3 e2fsck 1.47.0 (5-Feb-2023) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Entry '.' in ??? (1065) is duplicate '.' entry. Fix<y>? .... Tried few SD cards, same result. Tried those SD cards with other images, i.e. Armbian_24.8.4_Rock-5c_bookworm_vendor_6.1.75_minimal.img no problems. Could anybody verify this behavior? Thanks Chris Armbian_25.11.1_Rock-5c_trixie_vendor_6.1.115_minimal.img image generates the same problem.

I started from scratch. Installed Armbian_25.2.2_Rpi4b_bookworm_current_6.12.15_minimal.img Having in mind what @eselarm suggested as culprit, I put raspi-firmware on hold root@rpi5b:~# apt-mark hold raspi-firmware then dpkg --remove --force-all libraspberrypi0 armbian-bsp-cli-rpi4b-current apt --fix-broken install apt install armbian-bsp-cli-rpi4b-current everything OK apt upgrade everything OK Reboot root@rpi5b:~# uname -a Linux rpi5b 6.12.31-current-bcm2711 #1 SMP PREEMPT Wed Jun 4 14:00:53 UTC 2025 aarch64 GNU/Linux Tried the same with raspi-firmware unhold and got this . . Setting up raspi-firmware (1:1.20250430-1) ... ERROR: Unsupported kernel version (6.12.15-current-bcm2711) Setting up libraspberrypi0:arm64 (1:2+git20231018~131943+3c97f76-1) ... Setting up libraspberrypi-bin (1:2+git20231018~131943+3c97f76-1) ... Processing triggers for libc-bin (2.36-9+deb12u9) ... Processing triggers for man-db (2.11.2-2) ... Processing triggers for initramfs-tools (0.142+deb12u1) ... update-initramfs: Generating /boot/initrd.img-6.12.15-current-bcm2711 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for built-in driver r8152 ERROR: Unsupported initramfs version (6.12.15-current-bcm2711) I then did apt-mark hold raspi-firmware apt purge raspi-firmware and apt upgrade went through but the system is not in a good shape. root@rpi5b:~# uname -a Linux rpi5b 6.12.15-current-bcm2711 #1 SMP PREEMPT Wed Feb 19 13:49:50 UTC 2025 aarch64 GNU/Linux The /boot/firmware/initrd.img was not updated. Then I installed Armbian_25.2.4_Rpi4b_bookworm_current_6.12.22_minimal.img First thing after boot: root@rpi4b:~# update-initramfs -u update-initramfs: Generating /boot/initrd.img-6.12.22-current-bcm2711 ERROR: Unsupported initramfs version (6.12.22-current-bcm2711) The same with Armbian_25.5.1_Rpi4b_bookworm_current_6.12.28_minimal.img I don't have anymore a clean 25.2.3 but the homeassistant_minimal.img one has the same problem. No idea how to fix it. raspi-firmware has status optional and the 25.2.2 works OK without it, I think I will go this way hoping somebody with better skills then me will fix it one day. Regards, Chris

Hi Installed Armbian_25.2.3_Rpi4b_bookworm_current_6.12.17-homeassistant_minimal.img To work around broken packages dependency run: apt update dpkg --remove --force-all libraspberrypi0 armbian-bsp-cli-rpi4b-current apt --fix-broken install At the end I got this: update-initramfs: Generating /boot/initrd.img-6.12.17-current-bcm2711 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for built-in driver r8152 ERROR: Unsupported initramfs version (6.12.17-current-bcm2711) Armbian_25.2.4_Rpi4b_bookworm_current_6.12.22_minimal.img the same. Any idea anyone what is wrong here? Thanks Chris

Hi I installed https://dl.armbian.com/rock-5c/Bookworm_current_minimal-homeassistant, configured it to my liking (OS on a mirrored ZFS pool) to discover there is no WiFi, no Bluetooth. It's now kernel 6.12.17-current-rockchip64. Anybody managed to get WiFi and BT working with this kernel? Thanks, Chris

I also downgraded to 6.6.63 and everything is working OK.

Hi Installed Armbian_25.2.3_Odroidhc4_bookworm_current_6.12.17-homeassistant_minimal.img an a HC4 and noticed that USB doesn't work. lshw shows: *-usbhost:0 product: xHCI Host Controller vendor: Linux 6.12.17-current-meson64 xhci-hcd physical id: 1 bus info: usb@1 logical name: usb1 version: 6.12 capabilities: usb-2.00 configuration: driver=hub slots=2 speed=480Mbit/s *-usbhost:1 product: xHCI Host Controller vendor: Linux 6.12.17-current-meson64 xhci-hcd physical id: 2 bus info: usb@2 logical name: usb2 version: 6.12 capabilities: usb-3.00 configuration: driver=hub slots=1 speed=5000Mbit/s Nothing in syslog when I connect anything to USB port, just once I saw this: kernel: [ 2113.840333] usb usb1-port2: connect-debounce failed Any idea what could be wrong? Thanks Chris

I wanted to try Armbian on a Raspberry Pi-5 with a Radxa penta SATA hat. Installed: Armbian_community_25.2.0-trunk.86_Rpi5b_bookworm_current_6.6.63_minimal.img The SATA hat is not detected: root@rpi5b:~# lspci 00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21) 01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge I would expect this: root@raspi:~# lspci 0000:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21) 0000:01:00.0 SATA controller: JMicron Technology Corp. JMB58x AHCI SATA controller 0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 21) 0001:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge What am I missing. Thanks for your time. ChrisO Silly me. Just found it. Add those two lines dtparam=pciex1 dtparam=pciex1_gen=3 to /boot/firmware/config.txt and reboot.

I've just tried Armbian_24.11.1_Rock-5c_bookworm_edge_6.11.7_minimal.img wlan works. No ZFS, however. Building zfs-dkms fails, from /var/lib/dkms/zfs/2.2.5/build/make.log: 93 | #error "Unsupported kernel" According to https://github.com/openzfs/zfs/releases: zfs-2.2.5 is compatible with 4.18 - 6.9 kernels zfs-2.2.6 is compatible with 4.18 - 6.10 kernels zfs-2.3.0 would be compatible with Linux kernels 4.18 - 6.11 Armbian_24.8.4_Rock-5c_bookworm_vendor_6.1.75_minimal.img - ZFS OK, wlan after 'apt upgrade' not anymore. But $ /sudo dkms install aic8800-usb/3.0+git20240327.3561b08f-2 does the trick. ------- Sign command: /lib/modules/6.1.75-vendor-rk35xx/build/scripts/sign-file Binary /lib/modules/6.1.75-vendor-rk35xx/build/scripts/sign-file not found, modules won't be signed Creating symlink /var/lib/dkms/aic8800-usb/3.0+git20240327.3561b08f-2/source -> /usr/src/aic8800-usb-3.0+git20240327.3561b08f-2 Building module: Cleaning build area...(bad exit status: 2) make -j8 KERNELRELEASE=6.1.75-vendor-rk35xx -C /lib/modules/6.1.75-vendor-rk35xx/build M=/var/lib/dkms/aic8800-usb/3.0+git20240327.3561b08f-2/build/USB/driver_fw/drivers/aic8800 && make -C /lib/modules/6.1.75-vendor-rk35xx/build M=/var/lib/dkms/aic8800-usb/3.0+git20240327.3561b08f-2/build/USB/driver_fw/drivers/aic_btusb....... .... depmod... -------- root@rock-5c:~# iw phy0 info Wiphy phy0 wiphy index: 0 max # scan SSIDs: 3 max scan IEs length: 200 bytes max # sched scan SSIDs: 0 max # match sets: 0 Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Device supports AP-side u-APSD. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) .... Regards, Chris

It looks like there is a linux-headers mismatch in those two images: Armbian_24.11.1_Odroidhc4_bookworm_current_6.6.60_minimal.img Armbian_24.11.1_Odroidhc4_noble_current_6.6.60-kisak.img Installed those linux-headers: apt install linux-headers-current-meson64 I tried then to install ZFS module, and it failed: Setting up zfs-dkms (2.2.5-1~bpo12+1) ... Loading new zfs-2.2.5 DKMS files... Building for 6.6.60-current-meson64 Module build for kernel 6.6.60-current-meson64 was skipped since the kernel headers for this kernel do not seem to be installed. root@odroidhc4:~# dpkg -l | grep linux-headers ii linux-headers-current-meson64 24.8.2 arm64 Armbian Linux current headers 6.6.47-current-meson64 The Armbian_24.8.1_Odroidhc4_bookworm_current_6.6.47_minimal.img is OK. Finally I see both SSDs and ZFS works! 🙂 Regards, Chris

Sorry, it will be quite long 🙂 I have three HC4 devices: odroid1: Linux odroid1 5.10.57-meson64 #21.05.8 SMP PREEMPT Mon Aug 9 12:44:31 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux ata-Samsung_SSD_870_QVO_1TB ata-Samsung_SSD_870_QVO_1TB odroid2: Linux odroid2 5.19.17-meson64 #22.08.7 SMP PREEMPT Thu Oct 27 18:34:08 CEST 2022 aarch64 aarch64 aarch64 GNU/Linux ata-Samsung_SSD_870_QVO_1TB ata-Samsung_SSD_870_QVO_1TB They run the kernel which recognized both discs AND there was ZFS support when I installed them. odroid3, currently used for some experimenting: Linux odroid3 6.1.63-current-meson64 #1 SMP PREEMPT Mon Nov 20 10:52:19 UTC 2023 aarch64 GNU/Linux odroid3 recognises those disks: ata-Samsung_SSD_840_EVO_120GB_S1D5NEAD710633R ata-Samsung_SSD_750_EVO_250GB_S33SNWAH687472R I replaced the ata-Samsung_SSD_840_EVO_120GB_S1D5NEAD710633R by another Samsung SSD_860_EVO_250GB It is not recognized, and in the /var/log/kern.log I see this: odroid3 kernel: [ 2.692110] ata1: SATA max UDMA/133 abar m512@0xfc700000 port 0xfc700100 irq 27 odroid3 kernel: [ 2.692124] ata2: SATA max UDMA/133 abar m512@0xfc700000 port 0xfc700180 irq 27 odroid3 kernel: [ 3.005134] ata1: SATA link down (SStatus 0 SControl 300) odroid3 kernel: [ 3.478833] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Disconnected the ata-Samsung_SSD_750_EVO_250GB_S33SNWAH687472R and rebooted NO ssd! /var/log/kern.log: odroid3 kernel: [ 2.901128] ata1: SATA link down (SStatus 0 SControl 300) odroid3 kernel: [ 3.213129] ata2: SATA link down (SStatus 0 SControl 300) Tried both SATA slots, same results. Tried another Samsung SSD_860_EVO_250GB, same results, no SSD. The same "SATA link down" message. I bought a Crucial 1TB just to change manufacturer: ata-CT1000MX500SSD1_2249E68F3955 Works in both SATA slots. Rebooted again with ata-Samsung_SSD_750_EVO_250GB_S33SNWAH687472R and ata-CT1000MX500SSD1_2249E68F3955 The last one in not there, the same messages in /var/log/kern.log. Two days later I rebooted it to try libata.force=noncqtrim kernel parameter and both disks are there. Removed libata.force=noncqtrim from armbianEnv.txt rebooted again, both disks are there. Then shutdown, power off/on and boot, no CT1000MX500SSD1. I tried the SD-card from odroid3 in the odroid2 and there both Samsung_SSD_870_QVO_1TB are there. Rebooted few times, just in case 😉 they were always there. Then disconnecte those two disks and connected the CT1000MX500SSD one: no disk after reboot. Put the SD-card in odroid1, only one disk, Samsung_SSD_870_QVO_1TB, is there. Replaced one of Samsung_SSD_870_QVO_1TB by CT1000MX500SSD, both are not there: kern.log: odroid3 kernel: [ 2.940933] ata1: SATA link down (SStatus 0 SControl 300) odroid3 kernel: [ 3.252903] ata2: SATA link down (SStatus 0 SControl 300) I like the HC4 (when it works 😉 so I ordered another one hoping it will not have any problems. Got it today (I must be one of the best HK's custommers: H3, H3+, 4 x HC4 🙂 booted with a EVO 860 250GB SSD: uname -a Linux odroid4 6.1.63-current-meson64 #1 SMP PREEMPT Mon Nov 20 10:52:19 UTC 2023 aarch64 GNU/Linux No SSD there. Re-plug it (I know the riscs) and lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 232.9G 0 disk Rebooted. lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 232.9G 0 disk Rebooted again and the SSD is there. Aha, rebooted, not powered off/on. init 0 remove power 10 seconds connect power The SSD is there. init 0 Connected the CT1000MX500SSD, boot. lsblk -> no SSD. Somehow it doesn't make any sense, I don't see any regularity in all this. Did again hotplug ~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931.5G 0 disk Some time ago I already reported the problem with SSD's not being recognized. And the strange thing is, some of the events are quite random. The SSD is there, than not there. Now I would say: HC4 and kernels newer than 5.19.17-meson64 don't want to cooperate correctly. Who is the culprit? I don't know, don't have the necessary skills to debug it. However, I would love to provide all infos needed which HK needs to analyze the problem. Screenshots, etc. BTW, rebooted odroid4 again, no SSD. Regards, Chris