OMV5 not surviving first reboot

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.

Zitat von titango20

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?

Zitat von titango20

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

Zitat von titango20

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

trapexit says the flag does nothing.

Zitat von titango20

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.

Zitat von 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.

Zitat von titango20

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?

Zitat von titango20

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.

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.

Zitat von titango20

Unfortunately I don't understand mergefs

The documentation is here perhaps you should raise your question about using LUKS on mergerfs on github.

Zitat von titango20

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.

Zitat von titango20

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).

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.