[systemd-devel] A use case for staged startup

Jeff Waugh jdub at bethesignal.org
Sat Feb 21 07:31:05 PST 2015


Hi all,

Marko Hoyer recently brought up the concept of a staged startup [1] on this
list.

I have a specific use case for some form of staging, though I don't know if
it meets Marko's definition or requirements! Perhaps systemd can handle
this already, but let's see...


So, I've been building a systemd package for OpenWrt [2] to test on my
little VoCore coin-sized MIPS machine. (Stay with me, the weird part is
over.)

The root filesystem is a read-only squashfs blob stored on the VoCore's
generous (!) 8MB of flash memory. During initial testing, I was happy to
boot up into a read-only environment, bring up a few tmpfs mount points,
and then keep mucking around with systemd.

But it's time to get serious. And everyone knows that "serious" means
having a writeable root filesystem. OpenWrt uses overlayfs with JFFS2 as
the top layer. but I'm just using tmpfs for now. (For some values of
"serious".)


I wanted to make best use of systemd's built-in primitives, so here's what
I've done:

- default.target is symlinked to initrd.target in the read-only filesystem
image

- I've added some custom services to prepare all the mounts for the root
switch (including one which changes the default.target symlink on the new,
writeable root)

Yes, I'm abusing systemd's idea of an initrd.


Here's where it breaks down:

- systemd dutifully starts all the services it knows about during the
initrd.target run, because they're all right there on the read-only
filesystem (and they fail a lot)

- then systemd dutifully stops them all again to switch the root

- and dutifully starts them all again once we're headed towards
multi-user.target

That's a *lot* of noise in the startup process!


I did get the impression from the documentation that initrd.target was
somehow special, but it makes complete sense that it's not. If I were using
an initramfs, there wouldn't be any superfluous service files in the
initramfs filesystem, and I'd be happy to know that systemd would behave
*exactly* the same way it would elsewhere.


One hacky idea I had to fix this:

- Pull all of the systemd service symlinks out of the squashfs filesystem
and store them in a tarball

- Add specific symlinks to make the initrd stage works properly

- In the pre-switch prepare service, unpack the tarball into the rw-mounted
/sysroot


Before anyone says it: No, using a real initramfs would be highly
inappropriate. I do not want to store two copies of systemd and friends in
8MB of flash. It's hard enough with just the one!


Is there an existing systemd solution to this problem? Is there a better
way to go about it?

Thanks,
Jeff

[1]
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027688.html
[2] https://github.com/jdub/openwrt-systemd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150222/28950e82/attachment.html>


More information about the systemd-devel mailing list