[systemd-devel] A use case for staged startup

[Shawn Landden]

On Sat, Feb 21, 2015 at 7:31 AM, Jeff Waugh <jdub at bethesignal.org> wrote:

> 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?
>
> You could try a bazillion bind mounts from the initrd to the target
filesystem, and then calling switch_root(8) from util-linux, and you do not
need systemctl like the previous post suggests, if you get the dependencies
right. You might also look at overlayfs, which got merged in Linux 3.18. I
think overlayfs will make this possible, and of course share your results!

> Thanks,
> Jeff
>
> [1]
> http://lists.freedesktop.org/archives/systemd-devel/2015-January/027688.html
> [2] https://github.com/jdub/openwrt-systemd
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>


-- 

---
Shawn Landden
ChurchOfGit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150221/d5e72468/attachment.html>