On Sun Nov 29, 2020 at 1:14 PM CET, Lone_Wolf wrote:
It wasn't clear to me (and still is not) what initramfs environment your questions were about.
Do you want answers based on systemd manpages OR on a systemd initramfs as setup by mkinitcpio on archlinux ? As I conjecture below, I don't think there is any difference between the two.
In folder /usr/lib/initcpio/install/ you'll find the systemd , sd-encrypt , sd-lvm2 , sd-shutdown and sd-vconsole hook scripts .
Look at their contents and notice they add specific services and targets.
Basic.target is NOT one of them, which suggests that it doesn't matter in the initramfs stage of a systemd initramfs boot on archlinux.
This is /not/ correct. Please verify your information more carefully before asserting on a public mailing list as to avoid creating confusion for future readers who may stumble upon the archives. basic.target is part of Arch's (and most other distro's) systemd initrd, as you will find /easily/ out by examining the output of `journalctl -b -g "Basic System"`. Although as you correctly observe, it is not explicitly pulled in, so let's take a look at how the systemd install hook works: add_systemd_unit() { # Add a systemd unit file to the initcpio image. Hard dependencies # on binaries and other unit files will be discovered and added. # $1: path to rules file (or name of rules file) (slightly reformatted to better fit the email line limit) I.e. (way) more units are pulled in w.r.t. the ones which are explicitly added. basic.target, in particular, gets pulled in as it is an hard dependency (Required-by) initrd.target. You can verify this by extracting your initrd and observing the hard dependency in /lib/systemd/system/initrd.target (which is explicitly pulled in from the systemd install hook). You can also find this out on a running system with the following command: sudo systemctl list-dependencies --reverse basic.target As far as I can tell, Arch's systemd boot process is pretty much the same as the standard one. Please do point out any real, proven differences there might be between Arch's systemd boot process and what's described in bootup(7), if you can identify any. I would be definitely interesting in knowing, as I'm developing a new software package which might be sensible to those. Until then, I will work under the assumption that there's no such difference - as I cannot identify any - so my original questions still stand. For reference, I found the answer of the final question I posed in my original email. An useful approach in the case of the example is to add a drop-in to the templates of interest, to which you can add a (soft or hard, as needed) dependecy to your templates, propagating the parameter as needed. E.g.: /etc/systemd/systemd/systemd-cryptsetup@.service/10-drop-in.conf: [Unit] Wants=whatever-dependency@%i.service After=whatever-dependency@%i.service systemd-cryptsetup-generator will (if configured correctly) only generate the units for the volumes which still need activation, enabling more granularity in key deployment. Riccardo