Re: Systemd boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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



[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux