Hi, El mar, 19 may 2026 a las 14:46, Jan Braun escribió: > > 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. ;-)
I don't object to moving away from nontrivial shell scripts in the init system :P Anyway, for my testing Gentoo computer with LVM logical volumes (but no LUKS), the problem of mounting filesystems with s6-rc is solved with an OpenRC-like set of services, and I'm happy about it. The service database includes "udev" and "udev-trigger" services for doing the udev magic, an "lvm" oneshot for activating LVM volume groups, a "fsck" oneshot for checking filesystems in /etc/fstab (which include those in logical volumes), a "root" oneshot for remounting the root filesystem read/write if "fsck" succeeded, and a "localmount" oneshot for mounting filesystems in /etc/fstab with a variation of "mount -a". With the right dependency specifications, the boot sequence looks similar to OpenRC's, and the final computer state is the same. What I wish to highlight, more related to what was discussed in the Gentoo forums, is that at a surface level this set of services appears to be shareable, but in reality, not completely. Silly, simplified representation: A: "Hey, I have this set of s6-rc service definitions that I use for Gentoo." # s6 system boot s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service udev: starting s6-rc: info: service udev successfully started s6-rc: info: service udev-trigger: starting s6-rc: info: service udev-trigger successfully started s6-rc: info: service lvm: starting s6-rc: info: service lvm successfully started s6-rc: info: service fsck: starting s6-rc: info: service fsck successfully started s6-rc: info: service root: starting s6-rc: info: service root successfully started s6-rc: info: service localmount: starting s6-rc: info: service localmount successfully started A: "See? It works. Do you want a copy of the service store? Just set the storelist= line in s6-frontend.conf accordingly." B: "OK, sure." # s6 repository init s6-rc-compile: info: adding sources from /home/user/.local/share/s6-rc/repository/sources/..atomics:ACGZSu s6-rc-compile: info: adding sources from /home/user/.local/share/s6-rc/repository/sources/..bundles:NQJhN8 s6-rc-compile: warning: source /home/user/.local/share/s6-rc/repository/sources/..bundles:NQJhN8 is empty s6-rc-compile: info: making bundles for pipelines s6-rc-compile: info: resolving bundle names s6-rc-compile: info: resolving service names s6-rc-compile: info: writing compiled information to /home/user/.local/share/s6-rc/repository/compiled/..ref:@400000006a0d1a3a035548aa:t2UBP4 # s6 set status root active udev-trigger active lvm active udev active localmount active fsck active B: "Cool. Oh wait, I don't have LVM logical volumes, so I didn't install package sys-fs/lvm2." A: "Well, mask service lvm then." # s6 set mask lvm s6-rc-set-change: warning: the following services (depending on the ones given as arguments, or part of the same pipeline) also need to be changed to "masked": root localmount fsck B: "Hmmm." # s6 set commit s6-rc-set-commit: fatal: unable to commit: found inconsistent dependencies B: "Guess that didn't work..." # s6 set check s6-rc-set-fix: info: (dry run) in set current of repository /home/user/.local/share/s6-rc/repository: moving service root from active to masked s6-rc-set-fix: info: (dry run) in set current of repository /home/user/.local/share/s6-rc/repository: moving service localmount from active to masked s6-rc-set-fix: info: (dry run) in set current of repository /home/user/.local/share/s6-rc/repository: moving service fsck from active to masked B: "What do you think?" A: "Hmm, you might have to delete that fsck/dependencies.d/lvm file..." B: "So you are saying I should modify the service store?" A: "Uuuuh, I guess? Let me ask..." G.
