/srv/dev-disk....is not a mountpoint

  • Posting in here because I'm experiencing a similar frustrating issue where my drives are all randomly disconnecting or being flipped to read-only for no good reason. My disks are not RAID (just singles), are SSDs, and have been fully reliable but OMV seems to be just dropping them in an all-or-nothing fashion if it gets flustered.


    Sample errors (All I was literally doing was using Zune to scan a music share for new mp3 files, a task that should require literally no effort):

  • Hi All,

    I'm also having this weird issue. as you can see below that the device has missing status but not sure which one it is...any help would be much appreciated.

    and the 2nd screenshot is when I tried to click on edit.

    • Offizieller Beitrag

    I just realised that my 500GB SSD is not being detected, so I'm guessing that that is it. but how do I sort this out?

  • Two years later the same problem. Fresh install, a few weeks of work. After the power loss got this and a Loading... page in a browser.


    Code
    Jul 23 09:54:50 homehub monit[1262]: 'mountpoint_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' status failed (1) -- /srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a is not a mountpoint
    Jul 23 09:55:20 homehub monit[1262]: Filesystem '/srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' not mounted
    Jul 23 09:55:20 homehub monit[1262]: 'filesystem_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' unable to read filesystem '/srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' state
    Jul 23 09:55:20 homehub monit[1262]: 'filesystem_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' trying to restart
    Jul 23 09:55:20 homehub monit[1262]: 'mountpoint_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' status failed (1) -- /srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a is not a mountpoint
    Jul 23 09:55:20 homehub monit[1262]: 'mountpoint_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' status failed (1) -- /srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a is not a mountpoint
    • Offizieller Beitrag

    Two years later the same problem.


    After the power loss got this


    unable to read filesystem '/srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' state

    Yep, power loss is still bad and so is a filesystem that cannot be read which is most likely a consequence from the power loss.


    Check the filesystem from CLI.

  • Yep, power loss is still bad and so is a filesystem that cannot be read which is most likely a consequence from the power loss.


    Check the filesystem from CLI.

    Unfortunatelly, didn't help. The filesystem is OK. I have restarted the server into the recovery mode and the boot process inclded the fsck, which has checked the FS and optionaly repaired it. The next reboot gave me the same message. It seems, I have lost my entire Server and have to re-install everything with the data loss.


    P.S. Why can't we run fsck on each boot? I've had to connect keayboard and monitor to a headless station, which is not so comfortable....

    • Offizieller Beitrag

    P.S. Why can't we run fsck on each boot? I've had to connect keayboard and monitor to a headless station, which is not so comfortable....

    For OS drive, all you need to do is just create empty file called /forcefsck


    Data drive you can unmount and check from CLI anytime.

    Did you check the filesystem with the UUID 96f03791-cc11-48cd-9a59-1833f659322a?

  • For OS drive, all you need to do is just create empty file called /forcefsck


    Data drive you can unmount and check from CLI anytime.

    Did you check the filesystem with the UUID 96f03791-cc11-48cd-9a59-1833f659322a?

    Yes. The FS is good. I've tried few other tools and gave up. Fresh reinstall and once the server will be ready, I will do an image with Clonezilla. Too bad, debian and other distros have self-recovery but not the headless OMV. And even if the snapshots are done, I could not use them, until the system could be mounted. Kinda recovery, which works from the working OS and software running in the OS...

    • Offizieller Beitrag

    Too bad, debian and other distros have self-recovery but not the headless OMV.

    OMV is just a package installed on top of Debian. What kind of self-recovery are you referring to?

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.6 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    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!

  • OMV is just a package installed on top of Debian. What kind of self-recovery are you referring to?

    I mean, we have multiple plugins which state they do a backup and none of them (or built-in features) can truly automatically recover the OS and configuration after the disaster.


    Let's say, the FS has crashed and I have a backup. There could be an option on the OMV live USB stick "Recover from a snapshot" which asks You to provide the snapshot and do a recovery.

    The Debian OS has been booted. I can log in to a console and see a working OS. But the software could not be started due to a wrong UUID in the configuration file. It could be nice to have a liveusb restore system instead of snapshots, which cannot be used until the messed/broken OMV is replaced by the fresh one.


    How can I restore a corrupted DB? Corrupted configuration?

    P.S. For now the way to quickly restore the service - Clonezilla and hands

    • Offizieller Beitrag

    I mean, we have multiple plugins which state they do a backup and none of them (or built-in features) can truly automatically recover the OS and configuration after the disaster.

    Please feel free to contribute the restore functionality. If it was possible from a plugin, I would've added it many years ago. And realize that you are comparing a project that two people work on to commercial products with hundreds if not thousands of people work on.

    Let's say, the FS has crashed and I have a backup. There could be an option on the OMV live USB stick "Recover from a snapshot" which asks You to provide the snapshot and do a recovery.

    This only works on systems that can do this. So i386 and amd64 only. OMV has a huge number of armhf and arm64 users that this wouldn't work with.

    The Debian OS has been booted. I can log in to a console and see a working OS. But the software could not be started due to a wrong UUID in the configuration file. It could be nice to have a liveusb restore system instead of snapshots, which cannot be used until the messed/broken OMV is replaced by the fresh one.

    Only works on i386 and amd64 as well. And no idea what uuid you are referring to.

    How can I restore a corrupted DB? Corrupted configuration?

    corrupted db? it is single file. If you have regular backups, you would just copy it back into place. Corrupted configuration? Not sure what that means but OMV uses configuration management - saltstack. You should just be able to run omv-salt deploy run MODULE_NAME to rewrite the configuration.

    For now the way to quickly restore the service - Clonezilla and hands

    What you are asking for could take hundreds of hours of my time (and not work on arm boards) to save you a couple of minutes.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.6 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


    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!

    • Offizieller Beitrag

    I mean, we have multiple plugins which state they do a backup and none of them (or built-in features) can truly automatically recover the OS and configuration after the disaster.

    I guess something like this is what you're looking for. https://github.com/xhente/omv-regen



    A simple bash script like this made by someone like me (computer science is not my profession) can restore an entire OMV system. It's been working for a long time.

    If the database you want to restore from is in good condition you can regenerate any system. The only limitation is the version of the available OMV packages and plugins. If there has been an update since you make the backup until you regenerate the system, you will not be able to do it, since the database could change its format. This does not depend on me, it depends on the version of packages available for download.

    Someone more capable than me could develop this and improve it to do it automatically, also removing that package version limitation. A lot of things can be done. For example, create a partition with the original OMV installation and the versions of the installed packages matching the current OMV database, so that they are available for a new installation. This would allow the restoration to be done automatically regardless of the package versions available on the internet. They are just ideas in case someone wants to spend time on this.

    It can be done, it would just be necessary to dedicate enough time to it. I am convinced that anyone with more computer knowledge than me can do much better.

  • Two years later the same problem. Fresh install, a few weeks of work. After the power loss got this and a Loading... page in a browser.


    Code
    Jul 23 09:54:50 homehub monit[1262]: 'mountpoint_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' status failed (1) -- /srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a is not a mountpoint
    Jul 23 09:55:20 homehub monit[1262]: Filesystem '/srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' not mounted
    Jul 23 09:55:20 homehub monit[1262]: 'filesystem_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' unable to read filesystem '/srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' state
    Jul 23 09:55:20 homehub monit[1262]: 'filesystem_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' trying to restart
    Jul 23 09:55:20 homehub monit[1262]: 'mountpoint_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' status failed (1) -- /srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a is not a mountpoint
    Jul 23 09:55:20 homehub monit[1262]: 'mountpoint_srv_dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a' status failed (1) -- /srv/dev-disk-by-uuid-96f03791-cc11-48cd-9a59-1833f659322a is not a mountpoint

    I experienced same issue after power loss. Rebooting the system a few times with all network cables disconnected helped fixed the issue for me. From what I can remember (and I could be wrong here) the issue had something to do with drivers booting in wrong sequence.


    After experience that problem, I've gotten myself an external usb storage for full NAS backup.

    • Offizieller Beitrag

    I'm late to this party.. but how I do this


    Wrote a simple dd script that images my OS drive and schedule it to run once a week (because of this, you want your OS drive to be on the smallish size... or the images will be huge.. Mine is 64gig, and typically my images are around 2-3gigs).


    If my OS drive croaks, I buy a new OS drive, hook it up, boot any linux live Disk on my server. Mount the filesystem that has the folder where my images are kept... download belena etcher and use etcher to write the most recent image to the new disk.


    Reboot.


    Done


    Only thing I've not automated.. is if I'm not careful, I'll have a bunch of images in my backup folder.. so I usually go into it every couple months and delete all but the 2 most recent images.

    • Offizieller Beitrag

    Only thing I've not automated.. is if I'm not careful, I'll have a bunch of images in my backup folder.. so I usually go into it every couple months and delete all but the 2 most recent images.

    Why don't you use the backup plugin with dd full backup?

    • Offizieller Beitrag

    Why don't you use the backup plugin with dd full backup?

    Honestly... I tried it one time, and something happened on the restore (it's been several years ago). I'm sure it was something I did wrong, but I couldn't get the image to boot. So I just made a simple dd script and did it on my own... and that's how I've done it ever since.

    • Offizieller Beitrag

    Honestly... I tried it one time, and something happened on the restore (it's been several years ago). I'm sure it was something I did wrong, but I couldn't get the image to boot. So I just made a simple dd script and did it on my own... and that's how I've done it ever since.

    It was probably the regular dd option that doesn't always backup grub correctly. ddfull would avoid that issue.

Jetzt mitmachen!

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