"Riccardo Paolo Bestetti" <pbl@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