On 28-11-2020 10:22, Riccardo Paolo Bestetti wrote:
I2'm trying to fully make sense of the boot process with systemd.
I've read various pages from the manual, including bootup(7). There are two points I don't fully understand.
* Filesystem mounts during initrd The man page, under the initrd section, says: "systemd detects that it is run within an initrd [...]. The bootup process begins identical to the system manager bootup (see above) until it reaches basic.target. [...] Before any file systems are mounted, it must be determined whether the system will resume from hibernation or proceed with normal boot."
In my mind, that part self-contradicts when both saying that 1) the bootup proceeds identical to the system manager bootup and 2) a determination on whether to mount file systems is made /after/ basic.target. This is because some file systems (including, in most cases, the root file systems) would have been mounted before local-fs.target, which is ordered before basic.target.
So either the process is not really identical until basic.target, or I'm getting something wrong.
* Instances I gather that the systemd which runs inside the initrd is a completely separate instance from the one which then runs in the booted system. Which implies - as discussed above - that the system initialization sequence from beginning to basic.target actually happens twice.
Does this means than any initialization units which could potentially be run twice - once in the initrd and once in the booted system - should be instrumented to avoid running their logic twice (in the cases where that's not needed or even harmful)?
Let's consider for example an hypothetical service with "WantedBy=cryptsetup-pre.target", which decrypts a keyfile using an hardware token. This keyfile is then consumed by systemd-cryptsetup-generator with keyfile-erase=on. What happens if the service is run twice, but the key is consumed only the first time? A decrypted keyfile remains in the system.
What's the correct approach to avoid such a scenario?
Riccardo
Archlinux has its own boot process, described at [1] Check the initramfs section and you'll see a reference to mkinitcpio [2] . On the mkinitcpio page look at the Common Hooks section. Basically there are 2 systems that archlinux can use in initramfs : busybox and systemd . Check the hooks in your mkinitcpio.conf : are you using the systemd hook or any of the sd-* hooks ? If yes, mkinitpio sd-encrypt hook is what handles your encrypted drives. see [3] for details If no, busybox encrypt hook is responsible, see [4]. Lone_Wolf [1] https://wiki.archlinux.org/index.php/Arch_boot_process [2] https://wiki.archlinux.org/index.php/Mkinitcpio [3] https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration#Using_sd-... [4] https://wiki.archlinux.org/index.php/Mkinitcpio#Runtime_customization