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-encrypt_hook
[4] https://wiki.archlinux.org/index.php/Mkinitcpio#Runtime_customization
