[systemd-devel] A use case for staged startup

[Andrei Borzenkov]

В Sun, 22 Feb 2015 02:31:05 +1100
Jeff Waugh <jdub at bethesignal.org> пишет:

> 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
> 

Do you really need to fully overlay root? I.e. is it possible to just
(bind-)mount /etc, /var? /usr should be possible to retain read-only.


> - and dutifully starts them all again once we're headed towards
> multi-user.target
> 
> That's a *lot* of noise in the startup process!
>

But does it actually work?
 
> 
> 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
> 

I believe that if you just overlay /etc with probably new
default.target and run daemon-reload followed by isolate it /should/
detect that some services are missing from new default.target and
continue.

> 
> 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