[arch-general] Systemd boot

u34 at net9.ga u34 at net9.ga
Sat Nov 28 19:33:33 UTC 2020


"Riccardo Paolo Bestetti" <pbl at bestov.io> 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

I am confused my self about the exact booting procedures.
Yet I do believe that you are missing the important issue of chroot.
In a simplistic decription, the system boots into an initrd. Then it shutoff.
CHROOT. And now it will reboot into a working system.
Do examine the journal of a boot process. In particular, look for
the chroot line:
    systemd[1]: Switching root.
And examine carefully what happen before that line. And after it.

--
u34


More information about the arch-general mailing list