Hi,
I am trying to run a keyscript while mounting a LUKS volume/container, but
the systemd that I am using, doesn't support keyscripts.
So instead I am trying to let the normal "cryptdisks" run.
I mean the SysV cryptdisks.
However if it runs early it won't work because it needs the LVM volumes to
be activated.
I had it working for a while by creating it as a target for
sysinit.target.wants.
However now another complication arose; if I disconnect a drive that is
used for caching (normally) but which is not actually used at this point,
then pvscan will apparently fail in some way, and the vgchange command
does not succeed, or in any case volumes are not getting activated. This
causes (at this point) the cryptdisks target to be dropped from sysinit.
At the same time vgchange -aay --sysinit won't do anything if lvmetad is
running, but whatever was meant to active it previously, didn't (the LVM
volumes) because of a missing PV. Then, when I remove the /dev/null mask
to lvm.service, it does run (SysV) however the --sysinit prevents it from
doing anything (seeing that lvmetad is running).
Now it is easy to remove --sysinit, but lvm.service runs much later (by
default) than the stuff that would normally cause the volume group to be
activated; causing that drop from sysinit.target.wants.
Now, even though at this point my e.g. /boot is getting mounted (which I
had put as a dependency to cryptdisks) cryptdisks doesn't actually run
anymore.
I mean I can keep on experimenting and trying, trying to figure out how to
force cryptdisks to be run after boot.mount is run, but at this point I do
not have a system, I am writing this from a TTY, and even my "rescue"
stick now fails to load a KDE session even though that is going to be
something entirely unrelated, probably.
So questions are:
- how am I supposed to force cryptdisks to be run after logical volumes
have loaded? (I was trying to depend on boot.mount, but something has to
run cryptdisks as well)
- am I correct in saying that a missing PV will cause the entire VG to no
longer be activated?
- how can I ensure that a mount task for e.g. /var which in fstab is
considered "nofail" actually does not cause the system to fail? At this
point var.mount depends on the activation of a "crypt" volume however when
the crypt volume fails to activate, var.mount stalls indefinitely, there
is not even a timeout, I can reboot and try my stick, because I cannot
boot anything at that point. I am saying that on my system "nofail" is not
honored and if the mount fails because the cryptsetup fails because
cryptdisks was never run because a PV was missing that was not relevant at
all, causing the VG to not even get activated in time......
Well yeah. That.
Regards,
B.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
