Hi,
Guillermo schrob:
> It was observed that OpenRC ships a "localmount" service script
> responsible for doing that, and that the core of that script was
> essentially a 'mount -a' command that reads /etc/fstab. Then, when
> discussing how dependencies and service ordering worked for both
> service managers, someone asked about different situations involving,
> for example, mounting filesystems in LVM logical volumes, or handling
> LUKS containers with encrypted LVM physical volumes.
Well, you can certainly do that in the way described (by you and other
replies).
However, since (afaik) none of the invocations involved require starting
an actual long-lived process, I'd argue that would be (ab)using oneshot
services to reinvent shell scripting. ;-)
My approach therefore would be a single oneshot repeatedly running
"mount -a" and invoking the appropriate cryptsetup/mdraid/...
incantations on relevant devices, until either "mount -a" is happy or
nothing has changed for long enough that you decide to give up.
If you use "udevadm monitor" to watch for newly appearing devices and
trigger things in response, that should be as fast as possible, no
explicit ordering knowledge needed.
(If udev udev rules weren't such a horror, it would be even nicer to use
those to automatically trigger the decrypting/assembling/... of any
newly appearing device.)
The thing you're losing with this approach is being able to manage the
mounted/unlocked/... state of your devices with s6 commands.
(I tend to think that's actually an advantage, but YMMV.)
HTH,
Jan
Received on Tue May 19 2026 - 19:46:43 CEST