OpenMediaVault Issues

So my OpenMediaVault (OMV) NAS did reboot today for some reason. It didn’t manage to boot up successfully again, however, but entered “emergency mode” instead.
After some digging around it seems this is related to the combination of LUKS drive encryption and MergerFS (same with UnionFS).
For normal operation, first the LUKS drives need to be decrypted. Then the decrypted drives can be pooled together with MergerFS.
Some changes in OMV 5 (as compared to OMV 4) cause the boot sequence to enter emergency mode if not all drives in /etc/fstab can be mounted while booting. Since the LUKS drives are still encrypted when booting, mounting those drives obviously fails. And consequently mounting the MergerFS filesystem also cannot succeed.

The issue can be patched by adding the nofail option to all LUKS drives in /etc/fstab and also adding the noauto option to the MergerFS entry in /etc/fstab. It may only be a matter of time until OMV decides to rewrite /etc/fstab, thus nullifying the changes described above.

But since I do not reboot my NAS that often, the above patch works fine for now.


References:

  1. https://forum.openmediavault.org/index.php?thread/30129-problem-booting-up-with-luks-and-unionfilesystem/&pageNo=2
  2. https://forum.openmediavault.org/index.php?thread/33186-omv-5-0-keeps-booting-into-emergency-mode-can-t-ssh-in/
  3. https://forum.openmediavault.org/index.php?thread/33213-omv-booting-to-emergency-mode/

Previous

Some Docker Best Practices

Next

Setting up Wireguard on Ubuntu

1 Comment

  1. jok

    Hi, this is a kind of late response 🙂
    Maybe it helps someone new to openmediavault
    But if you do not make the noauto option for the fuse.mergerfs disk you can instead have it automounted if you delete the “depends on” statements in /etc/fstab

    this is an example from my disks in /etc/fstab

    Gives emergency mode:
    x-systemd.requires=/srv/dev-disk-by-uuid-7d8c6807-d074-43c1-a030-9bcc2b95ee79,x-systemd.requires=/srv/dev-disk-by-uuid-f1cb2f07-1891-4c78-a827-f68a7580d3b2

    If you delete the “x-systemd.requires” entries the system will boot fine, until you mount a new disk from the web gui, then those entries will come back and you’ll have to edit /etc/fstab again.

    Thanks for the great root cause analysies

    /jok

Leave a Reply to jok Cancel reply

Your email address will not be published. Required fields are marked *

Powered by WordPress & Theme by Anders Norén

Close Bitnami banner
Bitnami