On Sat, Feb 21, 2015 at 7:31 AM, Jeff Waugh <j...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > -- --- Shawn Landden ChurchOfGit.com
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
