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