ODROID XU4 USB 3.0 Disconnect only on OMV

    • ODROID XU4 USB 3.0 Disconnect only on OMV

      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

      Post by Reutemann ().

      This post was deleted by ryecoaaron: dupe ().
    • Reutemann wrote:

      I'd appreciate any feedback
      Read problem #4 here - Solutions to common problems
      omv 4.1.17 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • tkaiser wrote:

      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.
    • Reutemann wrote:

      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.

      Reutemann wrote:

      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 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: forum.odroid.com/viewtopic.php?f=99&t=28076#p200342
    • Reutemann wrote:

      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 4.1.17 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      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 :(
    • New

      Reutemann wrote:

      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.