[arch-general] Systemd boot

[Lone_Wolf]

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