ODROID XU4 USB 3.0 Disconnect only on OMV

1st Official Post

    Hello OMV experts,



    Having run Debian for a few years, I've never had any issues on XU3 and XU4. Switched recently to OMV, all was good, until I started to get USB disconnects as below. A USB3 2TB drive is connected on this port.
    I did the alcohol cotton connector clean, but unfortunately not working. I've seen threads with bitching on the quality of the Odroid HW, but as I said before did not have issues until this one with OMV. I also don't understand why at some point the device reconnects but instead of mounting as sda1, OMV mounts it as sdb1 !!!, which breaks up everything that's running fromt he disk (Containers).


    I'd appreciate any feedback or if anything that I could try to mitigate this, driver issue?, disk gone rogue?, kernel options?, PS?, why is it not remounted with its original sda1 ?


    Thanks in advance.



    Jan 7 17:39:11 odroid kernel: [ 354.519163] usb 4-1.2: USB disconnect, device number 4
    Jan 7 17:39:11 odroid kernel: [ 354.533515] print_req_error: I/O error, dev sda, sector 0
    Jan 7 17:39:11 odroid kernel: [ 354.533554] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
    Jan 7 17:39:11 odroid kernel: [ 354.533562] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 64 05 3a c0 00 00 08 00
    Jan 7 17:39:11 odroid kernel: [ 354.533568] print_req_error: I/O error, dev sda, sector 1678064320
    Jan 7 17:39:11 odroid kernel: [ 354.551561] sd 0:0:0:0: [sda] Synchronizing SCSI cache
    Jan 7 17:39:11 odroid kernel: [ 354.551737] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00
    Jan 7 17:39:12 odroid kernel: [ 354.693198] blk_partition_remap: fail for partition 1
    Jan 7 17:39:12 odroid kernel: [ 354.693219] EXT4-fs error (device sda1): ext4_find_entry:1437: inode #52428958: comm mono: reading directory lblock 0
    Jan 7 17:39:12 odroid kernel: [ 354.703132] blk_partition_remap: fail for partition 1
    Jan 7 17:39:12 odroid kernel: [ 354.703150] EXT4-fs error (device sda1): ext4_find_entry:1437: inode #52428958: comm mono: reading directory lblock 0
    Jan 7 17:39:12 odroid kernel: [ 354.714874] blk_partition_remap: fail for partition 1

    • Official Post
    Quote from Reutemann

    I'd appreciate any feedback

    Read problem #4 here - Solutions to common problems

    omv 7.5.0-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.3.2 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Quote from tkaiser

    Then it must be OMV's fault. As simple as that.

    Are you able to read till the end?. But yes, no issue before, that's correct. Will probably revert to not-so-tightly packed things, as recommended in other places, like dietpi, or plain Debian as I had.


    I'd appreciate any feedback or if anything that I could try to mitigate this, driver issue?, disk gone rogue?, kernel options?, PS?, why is it not remounted with its original sda1 ?


    Thankfully people are kinder elsewhere.

    Quote from Reutemann

    Are you able to read till the end?


    Sure. It's pretty obvious that you made up your opinion already ('bitching on the quality of the Odroid HW', 'everything worked flawlessly until I used OMV').


    All hardware will eventually die. So stuff that worked flawlessly for years will stop at some point in time. With the XU4 even touching the USB cable can result in disconnects.


    In case you're able to provide some information (e.g. is the disk powered by XU4, did you already try to replace the USB cable) maybe someone can give a hint.


    Quote from Reutemann

    OMV mounts it as sdb1 !!!

    OMV isn't mounting anything, that's the kernel (if you want to blame someone here visit Hardkernel's forum -- OMV uses their kernel from https://github.com/hardkernel/linux).


    The XU4 hardware is not really suited for a NAS since there's always an internal USB3 hub in between hosts and disks. How should the kernel realize that the device that has disappeared behind the USB hub due to some problem (cabling? connector? The usual undervoltage shit show especially with older PSUs?) and is now immediately coming back is the same?


    TL;DR: XU4 is not a great choice for a NAS as even Justin from Hardkernel explains himself: https://forum.odroid.com/viewtopic.php?f=99&t=28076#p200342

    • Official Post
    Quote from Reutemann

    plain Debian as I had

    OMV is plain Debian. It doesn't do anything magically. It is just a web interface that creates the fstab lines (for the most part). Maybe the OMV image is using a different kernel and this is causing it?? It would be interesting to see if installing your "plain debian" image and getting solid with no issues then install OMV and see if it causes any problems.

    omv 7.5.0-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.3.2 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Thank you both.


    @tkaiser, yes tried the cable already. Also UAS was already disabled (JIC)


    @ryecoaaron Right meant non UI, XML, Debian. Yes, can try again, but was working fine, unless something collapsed in the last weeks.


    Is it possible to revert to some older kernel?...backports....older OMV version...at least to test.


    Is the issue 100% consistent with HW (or HW kernel kombo)?, or could I have unintentionally (docker installs, vpn, fstab, smart, APM settings) screwed or triggered this issue?.


    PS: Could trying another drive perhaps behave differently?.


    Apologies if I'm asking some non sense. Only puzzled by the issue, as I said this OMV port looked all good so far :(

    Thanks, will do when it fails.


    I disabled APM yesterday, so far it's running. Could be coincidence or black magic with the cable or something. Knock on wood for now.

    Quote from Reutemann

    I disabled APM yesterday, so far it's running. Could be coincidence

    Very likely coincidence since APM doesn't affect this problem (disk controller disappearing from the USB bus). While it's good to hear that it works now providing the debug output would be nice too (just to check the timing of events and whether to recognize a pattern or not).

    Quote from Reutemann

    Did the armbian -u, says uploaded to ix.io/1yBU

    All that can be read from the log is 'filesystem already corrupted', nothing else in there (armbianmonitor -u only uploads last 250 lines from dmesg output). But even more dmesg output won't change reality: USB storage is unreliable by design, USB-3A receptacles are horrible for SuperSpeed data transmissions, an internal USB hub should always be avoided between host and disks.

    • Official Post
    Quote from Reutemann

    Libre with Rockchip?
    loverpi.com/collections/renega…-cc?variant=2817846607885


    Rock 64?

    I really like my renegade and lots of people are using the rock64 with good results.

    omv 7.5.0-1 sandworm | 64 bit | 6.11 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.15 | compose 7.3.2 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Guys I have the same problem on XU4 after upgrading to omv 4 from 3.x ... I read here that it might be a kernel bug:
    https://bugzilla.redhat.com/show_bug.cgi?id=1530093


    Though its from different distro's (fedora) bugtracker it still could be bug in kernel code
    They say it still appears on kernel 4.15.4, but seems to be fixed in latest kernel...


    Any opinions?


    Fun thing is it happens only with one of 2 usb drives...


    First I thought the drive is dying but SMART does not report any problem

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login