[systemd-devel] About systemd in initrd support

Lennart Poettering lennart at poettering.net
Mon Aug 25 17:53:18 PDT 2014


On Mon, 25.08.14 21:04, Luca Bruno (lethalman88 at gmail.com) wrote:

> Thank you all for the replies. After the first answers I've ported the
> initrd to systemd (only the basic stuff, no luks, lvm, etc.) and works very
> fine.
> Except one thing, that I hoped to find in dracut but does not seem to do
> anything special about it. It just goes through switch-root it seems.
> 
> As I understood it, systemctl switch-root will either run the specified
> init, or exec to the systemd in the new root. Looking a little through the
> code, it seems to do some kind of state-passing that I still have to study
> (--switched-root --deserialize etc.).

Yes, we serialize the state of all units into a file, and pass its fd
plus all other open fds we need need to pass over via the exec(). On the
other side we deserialize the stream, and try to match the passed fds to
what the serialization says. But this is mostly internal, the file is
never visible in the filesystem (it is deleted right after creation),
nobody should interfere with that.

> Problem: in NixOS we need to run a further stage in the new root, before
> starting systemd. For example /etc is a symlink to a configuration tree
> which gets created at boot (we call it activation), and so on.
> Our init script activates the NixOS system and ultimately exec to
> systemd.

I'd recommend doing that in an initrd service, that you run after
/sysroot is mounted, and before we actually switch roots.

The serialization is only enabled if we detect that the binary we invoke
is actually systemd. Because otherwise the invoked process could get
seriously confused by the open fds we dump on it...

> initrd init -> setup some env vars and mount points -> systemd/initrd ->
> switch-root -> system activation script -> systemd.
> 
> Questions:
> 1) What are the advantages to let switch-root exec to systemd directly?
> Does executing it from our init is the same thing?

Well, you get the state serialization and stuff, which means after
boot-up you can investigate what happened to the initrd services and
stuff... Also, you get fancy stuff like that we switch-root back into
the initrd, so that the initrd can unmount the root file system before
going down.

> 2) In case it's not the same thing, where is the best place to run that
> script? As a service in the new-root systemd?

As a service in the initrd.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list