OMV5 not surviving first reboot

  • The previous thread previous thread talks about a boot problem with debian10, omv5 and cryptsetup. It closed with a temporary solution.

    The solution works for boot process but not for system to work properly as mounting devices is not possible without the lines in fstab.

    The previous thread mainly handles mergefs problems, so this thread might be good for my problem.


    Problems for the solution (sry for double input)

    • One of (temporary(?)) solutions for mergefs problem to not boot:

      adding no-fail (?) to /etc/fstab file. Well, omv5 does it already by default, so its just a check. If it works it would be a full solution in my opinion (=not temporary, but permament). Unfortunately it doesn't work for my system.

    • other temporary solution:

      uncomment problem lines in /etc/fstab

      Temporary, because why should I "fix" a main file in debian thats finally handled by 3rd-party-system = omv.? Btw I need to activate lines after boot to be able to use the problem-drives. Otherwise system doesnt know them.

  • titango20 don't reference that thread it is not relevant, and reading your opening post even I still don't have a clue what your specific problem is, other than the fact OMV doesn't survive a first boot.


    I'm going to tag mi-hol I'm sure he can supply some questions that you can answer, before someone can offer a solution.

    Raid is not a backup! Would you go skydiving without a parachute?


    OMV 6x amd64 running on an HP N54L Microserver

  • One of (temporary(?)) solutions for mergefs problem to not boot:

    adding no-fail (?) to /etc/fstab file. Well, omv5 does it already by default, so its just a check. If it works it would be a full solution in my opinion (=not temporary, but permament). Unfortunately it doesn't work for my system.

    Here is the problem... The mergerfs plugin (unionfilesystems) would have to be re-written to work with luks that isn't auto-unlocking. I'm not going to do that. Maybe mergerfsfolders would work for you since it isn't waiting for filesystems to be mounted?

    omv 6.0.42-2 Shaitan | 64 bit | 5.19 proxmox kernel | plugins :: omvextrasorg 6.1.1 | kvm 6.1.23 | mergerfs 6.3.3 | zfs 6.0.11
    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.
    Please don't PM for support... Too many PMs!

  • So, to write some thoughts...


    - the problem is mergefs plugin. How far does it pick functions in debian system to block system from booting?

    - what would the no-fail flag in fstab effect in (in case it works)?

    - why does mergefs care for devices to be ready or not? At that point 3rd-party-system (omv) is not loaded at all, right?

    - how does mergefs work with luks and encrypted devices? In my understanding services like ovpn and luks work like transparent services (osi-layer < 5) meaning other services (mergefs) don't care.

    - what error tells debian to start in emergency mode? That mode for not finding an unimportant device sounds like a bad joke, doesn't it?


    Is it possible to tell mergefs to not start after boot automatically?


    I will try mergefsfolder.

  • titango20 its seems you don't want to play according to forum best practices. Good luck

    omv 6.0.40-2 (Shaitan) on RPi CM4/4GB with 64bit Kernel 5.15.61-v8+

    2x 6TB 3.5'' HDDs (CMR) formatted with ext4 via 2port PCIe SATA card with ASM1061R chipset providing hardware supported RAID1


    omv 5.6.21-1 (usul) on RPi4/4GB with 32bit Kernel 5.10.63 and WittyPi 3 V2 RTC HAT

    2x 3TB 3.5'' HDDs (CMR) formatted with ext4 in Icy Box IB-RD3662-C31 / hardware supported RAID1

    For Read/Write performance of SMB shares hosted on this hardware see forum here

  • the problem is mergefs plugin. How far does it pick functions in debian system to block system from booting?

    Please ask the author of mergerfs (trapexit) - https://github.com/trapexit/mergerfs


    what would the no-fail flag in fstab effect in (in case it works)?

    trapexit says the flag does nothing.


    why does mergefs care for devices to be ready or not? At that point 3rd-party-system (omv) is not loaded at all, right?

    mergerfs is not the problem. Linux wants a device to be there when you tell it to mount in fstab. If you have not unlocked a LUKS device, then the device is not there. Plain and simple.


    how does mergefs work with luks and encrypted devices? In my understanding services like ovpn and luks work like transparent services (osi-layer < 5) meaning other services (mergefs) don't care.

    Mergerfs doesn't know luks exists. It just creates a union of filesystems. If the filesystem is not there (LUKS not unlocked) then it can't create the union and fails. How would you fix that?? mergerfs is not a service. It is a fuse filesystem.

    what error tells debian to start in emergency mode? That mode for not finding an unimportant device sounds like a bad joke, doesn't it?

    Linux (not just debian) starts in emergency mode when it can't mount a filesystem unless you pass arguments in fstab to not care. How exactly does Linux know it isn't important?

    Is it possible to tell mergefs to not start after boot automatically?

    No, not with entries in fstab because mergerfs isn't a service. I could re-write the whole plugin to use systemd mount files instead of fstab but I don't have the time.

    omv 6.0.42-2 Shaitan | 64 bit | 5.19 proxmox kernel | plugins :: omvextrasorg 6.1.1 | kvm 6.1.23 | mergerfs 6.3.3 | zfs 6.0.11
    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Thanks for answers.

    Unfortunately I don't understand mergefs and debian enough.

    Do the devices need to be mount points in fstab? Maybe Im gonna experiment with that.


    Linux (not just debian) starts in emergency mode when it can't mount a filesystem unless you pass arguments in fstab to not care. How exactly does Linux know it isn't important?

    Thats the point (Somehow bad jokes). I see an error... Not bad that omv creates moint points for devices, but if using luks maybe the mount point is wrong as for locking and no-fail issues...? Just thoughts.

  • How about answering a question that is relevant to the entire problem:

    Why are you using LUKS? The only protection LUKS gives you is "physical protection", in the event that someone steals your data drives. Realize that the overwhelming majority of compromises take place over the network, after drives are unlocked. The only instances of compromise that I'm aware of, where drives were compromised by theft, were when corporate laptops were stolen or forgotten. Such an event (theft) is highly to almost vanishingly improbable with a home server.


    So, again the question is, do you really need LUKS? A second question might be, is LUKS really worth the headaches it appears to be creating?

    The answers to those questions and what you chose to do, is your call.

  • crashtest Short answer: Yes its worth it. Even for testing whats known to be stable... more or less :/ Whatever I don't have a deadline on that, so its just an experiment until its finished :)


    geaves good. I will look and ask on github for mergefs.


    Quote
    Quote from titango20 what would the no-fail flag in fstab effect in (in case it works)?

    trapexit says the flag does nothing.

    So why does this flag exist and doesn't show an error warning? Seems like a bug.

    Quote
    Quote from titango20 how does mergefs work with luks and encrypted devices? In my understanding services like ovpn and luks work like transparent services (osi-layer < 5) meaning other services (mergefs) don't care.

    Mergerfs doesn't know luks exists. It just creates a union of filesystems. If the filesystem is not there (LUKS not unlocked) then it can't create the union and fails. How would you fix that?? mergerfs is not a service. It is a fuse filesystem.

    Either use kind of this flag to tell debian to ignore it (or even dont put to /etc/fstab) or tell mergefs to try mounting devices if user (=omv?) is ready. In omv in file system option there is a button to mount devices. Why not for mergefs = manual ? For me it seems the correct way as I also need to manually mount each device after unlocking (not working for mergefs... weird).

    As of writing this I feel like mergefs service (correct?) tries to run without asking system to be ready or not.

    To repeat: Just my point of view. Pls ignore if totally wrong.

  • titango20

    Added the Label resolved
  • So why does this flag exist

    Adding the no-fail flag to the mergerfs mount point should not be necessary as that flag is already applied to each device #6 is the most explicit explanation, if you don't feel that is enough then raise the issue on github.

    Raid is not a backup! Would you go skydiving without a parachute?


    OMV 6x amd64 running on an HP N54L Microserver

  • FYI

    That is a waste of trapexit's time. It is known that the unionfilesystems plugin doesn't work well with LUKS. I have said a few times that I would have to re-write it to use systemd mount files (and still not sure that would fix it).

    omv 6.0.42-2 Shaitan | 64 bit | 5.19 proxmox kernel | plugins :: omvextrasorg 6.1.1 | kvm 6.1.23 | mergerfs 6.3.3 | zfs 6.0.11
    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Got late, some other things to do... :(

    So just stop it and accept a "bug" in a big, useful system? Sry, thats not my motivation.


    Btw: One of errors found in my system, so need to apologize on that point.

    After showing my /etc/fstab code to github I realized that the one line potentially crashing the system... didn't have the nofail flag O.o

    After adding it and rebooting, all worked "well".

    But with a new hdd and so system rewriting the line the option again disappeared and system didn't boot :(

    Maybe just a little error in plugin?

  • There's not much relevance in calling it a bug. But, just for the sake of argument, we'll call it a bug. Bottom line, it's not going to be fixed.

    Now, let's look at look at an easy fix or work around.

    Options:
    1. Dump LUKS
    2. Dump UnionFS (Mergerfs)

    If it was me I'd dump LUKS. The only real use cases for LUKS (as a client) are with a business or corporate laptop where the threat of theft is very real. In the case of a corporate or business server, there's a potential argument in protecting proprietary data from theft.
    At home there's no real argument for LUKS in that the vast majority of data compromises are over the wire (after LUKS is unlocked).

    Just some thoughts.

  • The plugin has an extra options line. If nofail fixes it for you (trapexit says it shouldn't do anything for a fuse filesystem), then add it.


    All the plugin does is add an fstab entry for existing filesystems. What could be the bug? The default arguments work on all of my systems and test systems but I don't use LUKS underneath. OMV itself isn't happy with filesystems that don't exist when the system boots. So, I'm not going to spend time to try to come up with some ugly (and probably still wouldn't work) workaround.

    omv 6.0.42-2 Shaitan | 64 bit | 5.19 proxmox kernel | plugins :: omvextrasorg 6.1.1 | kvm 6.1.23 | mergerfs 6.3.3 | zfs 6.0.11
    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!