В Sun, 22 Feb 2015 02:31:05 +1100 Jeff Waugh <[email protected]> пишет:
> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
