My drive fails to automount and randomly goes missing

1. offizieller Beitrag

    Hello all,


    I am pretty new to network lingo and am excited to learn a new environment and get a better understanding of how things work.


    I setup a system on my boat here in Tahiti to stream all of my media to any of my devices aboard. My goal was also to share files with neighboring boats by letting them on my network.


    My setup -
    I am running OMV 4.1.13-1 on an Odroid HC2 with a 8TB Seagate Ironwolf drive. I have the HC2 connected directly to an old dlink router, which at the moment doesn’t have a reliable power supply. (I am waiting for a DC-DC step down converter to arrive to feed it a reliable 5V) It works fine for a day, then randomly stops supplying voltage to the router intermittently.


    I am trying to use PLEX to try to stream to all of my devices. The NAS is on a local network not connected to the internet, we can only get internet when we paddle to shore and head to the local dive shop.


    NAS Issues-
    My Seagate Ironwolf drive does not mount automatically. Each time I boot up the NAS I have to login to the GUI and mount the drive. I am not sure what is causing this, but it has happened since I originally fired everything up.


    The drive goes missing every once in a while. When it goes missing, I have to reboot the NAS and it usually finds the drive and I have to remount it and I’m off to the races.


    Sometimes my router loses power and “blips” when it starts back up OMV sometimes loses the drive and thus I have to reboot the server for it to see it again.


    If I happened to be accessing the SMB filesystem on one of my computers when this happens, the NAS can’t find the drive and tries to find a drive at a new directory that doesn’t exist. (my drive is /srv/dev-sda1 and it will try to mount a drive named /srv/dev-sdb1) which doesn’t exist.


    The only solution I have found to make the drive accessible again is to close the connection on the computer and reboot the server. If the connection fails because a computer dies, I am SOL and must wait until the morning when the sun is shining and our solar panels are making lots of power to try again. It is very frustrating.


    I have attached a log file from this morning. If anyone has any advice on what I should do differently, I am open ears.


    PLEX issues -
    These may belong on a different forum, but I figured I would include it here in the off chance someone an help.


    I have been able to access PLEX on both my iPad and my iPhone without any trouble. My MacBook cannot see the server, and my firewalls are disabled. I also have an android phone which can access plex via the app just fine as long as the mobile network is turned off. (I don't like having to turn off the mobile network)


    Some files won’t play. They say a required codec cannot be found. I tried to Analyze the libraries after downloading the metadata, but It still comes back with the same issues.


    Thanks for any help

    • Offizieller Beitrag
    Zitat von p.gazibara

    My Seagate Ironwolf drive does not mount automatically. Each time I boot up the NAS I have to login to the GUI and mount the drive.

    Same here. I have not found a solution. As work around I added a scheduled job which does mount -a at reboot.



    Zitat von p.gazibara

    The drive goes missing every once in a while.

    Maybe your power supply is not stable enough for the HC-2 as well.

    • Offizieller Beitrag
    Zitat von p.gazibara

    the NAS can’t find the drive and tries to find a drive at a new directory that doesn’t exist. (my drive is /srv/dev-sda1 and it will try to mount a drive named /srv/dev-sdb1) which doesn’t exist.

    @macom , what did you think of this? I looked through his syslog and was under the impression that he might have old partition flags, from something in the past.


    @p.gazibara have you used this drive with something else before? What's the output of fdisk -l
    ____________________________________________________________________


    On a side note, do you have a UHF/VHF rig on your boat? HAM operators were running x.25 packet switching networks back in the day. (Apparently they still do.) It might be worth looking into, for the possibility of text only Internet and E-mail when you're close to a port.

    • Offizieller Beitrag

    I had a very similar experience. I solved it and now my HC2s and my 12TB Ironwolf HDDs are working perfectly with OMV.


    It seems that some HDDs, possibly in connection with a USB-SATA bridge, are incompatible with hdparm. And OMV use hdparm to set physical disk properties. You get there by selecting edit on the disk.


    I did a complete reinstall and simply made sure not to use or change any of the physical disk properties. And then everything was perfectly fine. And has been since then. I reflashed the SATA firmware to set the spindown timer.


    I have written about this many times here. For example:


    Odroid HC2, HDD and questions

    Zitat von p.gazibara

    I have attached a log file from this morning. If anyone has any advice on what I should do differently, I am open ears

    Code
    May 30 01:02:32 CinderellaCloud kernel: [104040.451666] usb 4-1: USB disconnect, device number 2
...
May 30 01:02:49 CinderellaCloud kernel: [104056.999786] usb 4-1: new SuperSpeed USB device number 3 using xhci-hcd

    The USB-to-SATA bridge on your device disappears and reappears again. There is no way for cable/contact problems to occur so you suffer from unstable powering.

    • Offizieller Beitrag

    I could get the Ironwolf, HC2 and OMV working fine again with a restore of the SD card from a backup image. A backup image where I had never touched the physical disk properties. Or with a fresh reinstall where I never touched any of the physical disk properties. My HC2s are humming along perfectly fine now, without any of the physical disk properties activated.


    I also reflashed the SATA firmware, but that was only needed to increase the spindown time. Not to fix the problem with the hdd unmounting or refusing to mount on boot. Otherwise the spindown time was only 2-3 minutes. I set it to 30 minutes.


    I never figured out how or if it was possible to get an OMV install working properly again after touching the physical disk properties. It should be possible, but for me it was much easier to restore a backup image to the SD card or reinstall from scratch.

    Zitat von crashtest

    @macom , what did you think of this? I looked through his syslog and was under the impression that he might have old partition flags, from something in the past.
    @p.gazibara have you used this drive with something else before? What's the output of fdisk -l
    ____________________________________________________________________


    On a side note, do you have a UHF/VHF rig on your boat? HAM operators were running x.25 packet switching networks back in the day. (Apparently they still do.) It might be worth looking into, for the possibility of text only Internet and E-mail when you're close to a port.


    Here is the result of fdisk-I


    root@CinderellaCloud:~# fdisk -l
    Disk /dev/ram0: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram1: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram2: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram3: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram4: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram5: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram6: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram7: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram8: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram9: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram10: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram11: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram12: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram13: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram14: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/ram15: 8 MiB, 8388608 bytes, 16384 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/mmcblk1: 14.9 GiB, 15931539456 bytes, 31116288 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x01bb5fb4


    Device Boot Start End Sectors Size Id Type
    /dev/mmcblk1p18192 139263 131072 64M 83 Linux
    /dev/mmcblk1p2139264 15500000 153607377.3G 83 Linux
    /dev/mmcblk1p315500001 30805119 153051197.3G 83 Linux



    Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
    Disklabel type: gpt
    Disk identifier: 9673CEE8-86DE-444A-84A3-5980844DE2B6


    Device Start End Sectors Size Type
    /dev/sda1 2048 15628053134 156280510877.3T Linux filesystem



    Disk /dev/zram0: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/zram1: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/zram2: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/zram3: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/zram4: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/zram5: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/zram6: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes



    Disk /dev/zram7: 124.8 MiB, 130871296 bytes, 31951 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes

    • Offizieller Beitrag

    @p.gazibara


    The key seems to be "never touching physical disk properties", but getting there (an OS rebuild) might be a bit painful.

    Zitat von Adoby

    A backup image where I had never touched the physical disk properties. Or with a fresh reinstall where I never touched any of the physical disk properties.

    Zitat von growweedeasy101

    I did a complete reinstall and simply made sure not to use or change any of the physical disk properties. And then everything was perfectly fine

    Zitat von macom

    Same here. I have not found a solution

    Can you please provide output from armbianmonitor -u after a reboot? I mean this thread talks about an HC2 with a connected disk in a horrible state:

    • tons of monit[1415]: Device /srv/dev-sdb1 not found in /etc/mtab messages in the log (so there's something misconfigured in OMV anyway)
    • The JMS578 disappearing and reappearing from the USB bus (the JMS578 is soldered on the PCB so how should this happen if it's not a powering problem or some obscure incompatibility?)
    • As a result of this problems tons of errors talking about a corrupted ext4 filesystem
    • The journaling functionality being stopped: May 30 01:23:58 CinderellaCloud kernel: [105326.140097] Aborting journal on device sda1-8. (so now a lengthy fsck has to happen the next time the filesystem will be mounted)
    • At reboot time May 31 18:18:38 CinderellaCloud systemd[1]: Starting File System Check on /dev/disk/by-uuid/5bab0a55-56f1-4443-8cac-297e1181425c...
    • And OMV's mount job timing out: May 31 18:18:38 CinderellaCloud systemd[1]: dev-sda1.device: Job dev-sda1.device/start timed out. and systemd-fsck@dev-sda1.service: Job systemd-fsck@dev-sda1.service/start failed with result 'dependency'
    • While the fsck is still running it's already game over again: May 31 18:20:57 CinderellaCloud kernel: [ 257.198255] print_req_error: I/O error, dev sda, sector 15628052992


    Everything as expected here. Why should a corrupted filesystem been mounted automagically? This is a problem that needs to be fixed. And how should this work in general when the disk simply disappears when being used.

    I will run armbianmonitor -u next time I boot the server. It is still having issues, so I am assuming I will have to wipe the OS and start over.


    It seems to be having lots of errors, and like I said, I'm pretty new to this.


    I did create a job to mount -a and it seems to be mounting a couple minutes after booting, but I am still seeing it try and fail to mount a drive that doesn't exist, it must be referenced somewhere in the OS that I cant find.


    You seem to be sure it's the disk that is in a horrible state, why? Could it be some strange communication error due to this hdparm that Adoby is talking about?


    I am going to try to reinstall the updated version of OMV and see where that gets me, though it will probably be painful to go through and set everything up gain.

    • Offizieller Beitrag
    Zitat von p.gazibara

    I am going to try to reinstall the updated version of OMV and see where that gets me, though it will probably be painful to go through and set everything up gain.

    (If you rebuild:)
    This time around, when all is configured the way you want it, clone your SD-Card and you'll never have to do a full rebuild again. (Or at least until you want to.) Considering the time investment involved in rebuilding and reconfiguring, the cost of a 2nd SD-card is cheap insurance. Even if a mistake is made, with a known working clone, you'll be able to gracefully back out.

    Zitat von p.gazibara

    You seem to be sure it's the disk that is in a horrible state, why?

    That's what the logs are telling. The filesystem is already heavily corrupted and your whole disk disappears from the USB bus while repairing.


    I don't believe in miracles and voodoo so unless @Adoby and @macom provide logs to study the behavior on their installs with and without hdparm 'active' I can only talk about your install and there strange stuff happens like the USB-to-SATA bridge disappearing from the USB bus (that bridge is soldered to the PCB -- so either there's some really strange stuff going on related to hdparm or you're suffering from underpowering which based on my experiences after many years of dealing with SBC is responsible for almost half of the problems users run into).


    BTW: It won't help if you ignore the facts. The filesystem on your disk is corrupted (not the SD card) so you need to fix THIS problem anyway regardless whether you reinstall OMV or not. The try to mount a corrupted filesystem will fail fortunately since otherwise more corruption will occur.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden