Partitions not visible after update to 26.2.1

[belegdol]

Hello,

 

I have updated my Odroid HC1 to 26.2.1 - just the kernel, u-boot and such. I have been running a self-built 6.6.128 prior so kernel version itself is unlikely the issue. After rebooting, my SATA drive seems dead - no partitions are detected, only the main sda device. This is what the journal said before:

Mar 05 15:51:31 kernel: usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd
Mar 05 15:51:31 kernel: usb 4-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=31.02
Mar 05 15:51:31 kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 05 15:51:31 kernel: usb 4-1: Product: USB to ATA/ATAPI Bridge
Mar 05 15:51:31 kernel: usb 4-1: Manufacturer: JMicron
Mar 05 15:51:31 kernel: usb 4-1: SerialNumber: 0123456789ABCDEF
Mar 05 15:51:31 kernel: SCSI subsystem initialized
Mar 05 15:51:31 kernel: usbcore: registered new interface driver usb-storage
Mar 05 15:51:31 kernel: scsi host0: uas
Mar 05 15:51:31 kernel: usbcore: registered new interface driver uas
Mar 05 15:51:31 kernel: scsi 0:0:0:0: Direct-Access     JMicron  Generic          3102 PQ: 0 ANSI: 6
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] Write Protect is off
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] Disabling FUA
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
Mar 05 15:51:31 kernel:  sda: sda1
Mar 05 15:51:31 kernel: sd 0:0:0:0: [sda] Attached SCSI disk

This is what it says now:

Mar 19 09:36:34 kernel: usb 4-1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=31.02
Mar 19 09:36:34 kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 19 09:36:34 kernel: usb 4-1: Product: USB to ATA/ATAPI Bridge
Mar 19 09:36:34 kernel: usb 4-1: Manufacturer: JMicron
Mar 19 09:36:34 kernel: usb 4-1: SerialNumber: 0123456789ABCDEF
Mar 19 09:36:34 kernel: SCSI subsystem initialized
Mar 19 09:36:34 kernel: usbcore: registered new interface driver usb-storage
Mar 19 09:36:34 kernel: scsi host0: uas
Mar 19 09:36:34 kernel: usbcore: registered new interface driver uas
Mar 19 09:36:34 kernel: scsi 0:0:0:0: Direct-Access     JMicron  Generic          3102 PQ: 0 ANSI: 6
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Unit Not Ready
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Sense Key : 0x4 [current] 
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 
Mar 19 09:36:34 kernel: r8152-cfgselector 6-1: reset SuperSpeed USB device number 2 using xhci-hcd
Mar 19 09:36:34 kernel: r8152 6-1:1.0: load rtl8153a-3 v2 02/07/20 successfully
Mar 19 09:36:34 kernel: r8152 6-1:1.0 eth0: v1.12.13
Mar 19 09:36:34 kernel: r8152-cfgselector 6-1: reset SuperSpeed USB device number 2 using xhci-hcd
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=0x07 driverbyte=DRIVER_OK
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Sense Key : 0x4 [current] 
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 
Mar 19 09:36:34 kernel: r8152 6-1:1.0: load rtl8153a-3 v2 02/07/20 successfully
Mar 19 09:36:34 kernel: r8152 6-1:1.0 eth0: v1.12.13
Mar 19 09:36:34 kernel: r8152 6-1:1.0 enx001e06326076: renamed from eth0
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0x07 driverbyte=DRIVER_OK
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Sense Key : 0x4 [current] 
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B)
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] 0-byte physical blocks
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Asking for cache data failed
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes not a multiple of physical block size (0 bytes)
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (0 bytes)
Mar 19 09:36:34 kernel: sd 0:0:0:0: [sda] Attached SCSI disk

I will try attaching the drive to another PC to exclude a poorly timed hardware failure.

Edited 1 hour ago by belegdol

[belegdol]

I was able to see the data on the drive just fine when connected to another machine via eSATA cable. Oddly enough, the partition showed back up again after reattaching it to the odroid and starting it again.

I have then rebooted the odroid again, and the partition went away once again. So it appears to be some sort of cold vs hot boot difference. 

 

[belegdol]

Rolling "back" linux-{dtb,image}-current to my self-built 6.6.128 did not help. 

[belegdol]

Other packages upgraded by unattended-upgrades:

Start-Date: 2026-03-15  10:51:39
Commandline: apt upgrade
Requested-By: julas (1000)
Upgrade: linux-base:armhf (4.12~bpo12+1, 4.12.1~bpo12+1)
End-Date: 2026-03-15  10:51:51

Start-Date: 2026-03-16  06:20:00
Commandline: /usr/bin/unattended-upgrade
Upgrade: linux-image-current-odroidxu4:armhf (25.11.2.3, 26.2.1)
End-Date: 2026-03-16  06:21:56

Start-Date: 2026-03-16  06:22:47
Commandline: /usr/bin/unattended-upgrade
Upgrade: base-files:armhf (25.11.2-12.4+deb12u12-bookworm, 26.2.1-12.4+deb12u13-bookworm), armbian-bsp-cli-odroidxu4-current:armhf (25.11.2, 26.2.1)
End-Date: 2026-03-16  06:23:48

Start-Date: 2026-03-16  06:24:54
Commandline: /usr/bin/unattended-upgrade
Upgrade: armbian-firmware:armhf (25.11.2, 26.2.1)
End-Date: 2026-03-16  06:26:03

Start-Date: 2026-03-16  06:26:48
Commandline: /usr/bin/unattended-upgrade
Upgrade: linux-dtb-current-odroidxu4:armhf (25.11.2.3, 26.2.1)
End-Date: 2026-03-16  06:26:52

Start-Date: 2026-03-16  06:27:35
Commandline: /usr/bin/unattended-upgrade
Upgrade: linux-u-boot-odroidxu4-current:armhf (25.11.2, 26.2.1)
End-Date: 2026-03-16  06:27:37

Unfortunately, the previous versions seem to be gone from the repos. Is there any way of getting these back?

[eselarm]

40 minutes ago, belegdol said:

idVendor=152d, idProduct=057

Is the much trouble USB-SATA chip, I have it as 'cable', but unused as it at least fails with RPI4 when SSD. It looks like a sequencing/timing issue. You can treat it like external maybe and/or reset the USB device node. That usually works for various USB connected HW that fails at boot but when Linux/platform fully up and running, a reset then somehow avoids timing issues.

[belegdol]

This could be, but something has changed and is now triggering this behaviour. Warm reboots have been working fine for years.

[eselarm]

24 minutes ago, belegdol said:

Warm reboots have been working fine for years.

I would not be surprised if there has always been a HW initialization issue. It is just that now with newer Linux (whole systemd stuff etc) you hit this problem. I always liked this HC1, but it is not even on Odroid WiKi anymore. You might need to focus on version/build of U-Boot in combination with kernel and DTB. I have some examples (Rockchip based SBC's) were it is make-or-break, e.g. if I just take latest U-Boot whole system / use-case is useless / gone. So I need to stick to legacy U-Boot or just buy other HW/platform.

[belegdol]

I will try downgrading u-boot next once I find the older package somewhere. Kernel does not seem to be the cause given that it has been working fine with both my own build 6.6.122 and 6.6.128 before and rolling back not helping.

New device is something I had on my mind for a while. But given the RAM and SSD prices these days, I do not really want to overspend. Not to mention that the SBC landscape has not been that great lately when it comes to compact NAS offerings. HC4 is five years old at this point. Many even recommend N100 but this is a whole different size category.