Re: [systemd-devel] OSTree mount integration
On Mon, 24.09.12 18:12, Colin Walters (walt...@verbum.org) wrote: > > On Mon, 2012-09-24 at 22:19 +0200, Lennart Poettering wrote: > > > i.e. my suggestion would be to patch dracut (or write a dracut module) > > that sets up your target OS tree with /var and friends directly, and > > then transitions directly to it via moving it to / rather than first > > moving into the host OS tree via a move/bind mount and then using > > chroot() for the second step. (That said, whether you do this in one or > > two steps is not important, what is important however is that you do not > > use chroot()). > > For reference by the way, the current ostree_switch_root code that gets > called from dracut is here: > http://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-switch-root.c > (It's a fork of util-linux switch_root). > > The issue with your suggestion I think is that the "deployment root" as > I call them (ostree chroots) isn't a mount point, so I can't just > MS_MOVE move the whole directory to /. Although I can make it into a > mount point I guess with the trick of bind-mounting it to itself, and > then move that? Instead of moving it you can simply bind mount it to / instead. (But note that bind mounting on itself is not really considered a "trick", it's actually a core part of the kernel API). > Hm. So something something like this, from dracut's perspective, > where /sysroot is the "target rootfs", and its / is the initramfs: > > mount(/sysroot/ostree/current/,/sysroot/ostree/current/) Hmm, so the dir is already a mount point? > move(/dev, /sysroot/ostree/current/dev) > move(/proc, /sysroot/ostree/current/proc) > move(/sys, /sysroot/ostree/current/sys) Note that you need /run here, too. We need the runtime data from the initrd in the host system too. More importatnly though note that systemd will do this bit for you anyway btw, as part of "systemctl switch-root". You just need to pass it the right path. (See src/core/switch-root.c which is the code in PID1 that backs "systemctl switch-root"). > bind(/sysroot, /sysroot/ostree/current/sysroot) > bind(/sysroot/home, /sysroot/ostree/current/home) > bind(/sysroot/ostree/var, /sysroot/ostree/current/var) > bind(/sysroot/ostree/current-etc, /sysroot/ostree/current/etc) THis is the part that is actually truly ostree specific, and should be in a dracut module. > move(/sysroot/ostree/current/, /) > execv(/sbin/init) This is what systemd already can do for you. > But I don't think this will exactly the solve all the problems. In this > case / is still a bind mount, not the real backing store. So for > example if I have a normal / entry in /etc/fstab, systemd is going to > fail to remount it read/write. No, this should work properly. We accept mounts as they are, we do not check the backing device of this, and the root fs check ignores /etc/fstab anyway and uses stat() to determine the backing device. Note that OLPC is actually using a setup very similar to yours. It appears to work fine for them these days. > I should get a chance to try out some patches here within a few weeks. > The main thing that needs fixing is /etc/fstab : > > https://mail.gnome.org/archives/ostree-list/2012-September/msg8.html I can't say I follow here. The root fsck is very special. It is not done via fsck@.service, but via root-fsck.service, and follows very different semantics, as it requires read-only root. On top of that we actually do the root fsck in the initrd anyway, to avoid having to run the fsck tool from the disk it is supposed to check/fix. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OSTree mount integration
On Mon, 2012-09-24 at 22:19 +0200, Lennart Poettering wrote: > i.e. my suggestion would be to patch dracut (or write a dracut module) > that sets up your target OS tree with /var and friends directly, and > then transitions directly to it via moving it to / rather than first > moving into the host OS tree via a move/bind mount and then using > chroot() for the second step. (That said, whether you do this in one or > two steps is not important, what is important however is that you do not > use chroot()). For reference by the way, the current ostree_switch_root code that gets called from dracut is here: http://git.gnome.org/browse/ostree/tree/src/switchroot/ostree-switch-root.c (It's a fork of util-linux switch_root). The issue with your suggestion I think is that the "deployment root" as I call them (ostree chroots) isn't a mount point, so I can't just MS_MOVE move the whole directory to /. Although I can make it into a mount point I guess with the trick of bind-mounting it to itself, and then move that? Hm. So something something like this, from dracut's perspective, where /sysroot is the "target rootfs", and its / is the initramfs: mount(/sysroot/ostree/current/,/sysroot/ostree/current/) move(/dev, /sysroot/ostree/current/dev) move(/proc, /sysroot/ostree/current/proc) move(/sys, /sysroot/ostree/current/sys) bind(/sysroot, /sysroot/ostree/current/sysroot) bind(/sysroot/home, /sysroot/ostree/current/home) bind(/sysroot/ostree/var, /sysroot/ostree/current/var) bind(/sysroot/ostree/current-etc, /sysroot/ostree/current/etc) move(/sysroot/ostree/current/, /) execv(/sbin/init) I may try this and see if it works. But I don't think this will exactly the solve all the problems. In this case / is still a bind mount, not the real backing store. So for example if I have a normal / entry in /etc/fstab, systemd is going to fail to remount it read/write. (Right now, rather hackily, I just remount the backing store r/w in ostree_switch_root, but...) One notable complication with this whole setup is the read-only bind mount over /usr (and /bin, /lib at the moment), which I've elided from the above. > I am not totally against that, but I'd really like to keep explicit > virtualization checks at a minimum and use them as solution only if > nothing else works nicely. Right, definitely agree. But even with the above setup I'm not sure how we can completely avoid it. I should get a chance to try out some patches here within a few weeks. The main thing that needs fixing is /etc/fstab : https://mail.gnome.org/archives/ostree-list/2012-September/msg8.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] OSTree mount integration
On Sun, 23.09.12 22:26, Colin Walters (walt...@verbum.org) wrote: > So I have this "boot into chroot" system that I wrote for GNOME: > > https://live.gnome.org/OSTree/ > > Where the two interesting aspects here are: > > 1) I want the ability to allow people to try GNOME builds natively >without destroying their root partition - hence, chroots. > 2) This allows for fully atomic upgrades. > > Now, basically right now systemd doesn't understand the fact that it's > in a chroot, and fails to do things like remount the rootfs read-only > when rebooting, etc. > > https://live.gnome.org/OSTree/MultipleRoots Hmm, why do you use chroot()? I think for these kind of OS booting games chroot() is not really the best way to do things, you actually want proper bind mounts for that. i.e. my suggestion would be to patch dracut (or write a dracut module) that sets up your target OS tree with /var and friends directly, and then transitions directly to it via moving it to / rather than first moving into the host OS tree via a move/bind mount and then using chroot() for the second step. (That said, whether you do this in one or two steps is not important, what is important however is that you do not use chroot()). > Is there any opposition to having systemd support this setup? It > already detects virtualization and containers at the moment, so it seems > like it'd make sense. > > I'm totally willing to change around the bind mount setup, but I think > the most basic support is going to be basically just looking for the > root filesystem on /sysroot instead of /. > > If there's no objections I'll be looking at doing some patches for the > GNOME 3.8 cycle. I am not totally against that, but I'd really like to keep explicit virtualization checks at a minimum and use them as solution only if nothing else works nicely. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] OSTree mount integration
So I have this "boot into chroot" system that I wrote for GNOME: https://live.gnome.org/OSTree/ Where the two interesting aspects here are: 1) I want the ability to allow people to try GNOME builds natively without destroying their root partition - hence, chroots. 2) This allows for fully atomic upgrades. Now, basically right now systemd doesn't understand the fact that it's in a chroot, and fails to do things like remount the rootfs read-only when rebooting, etc. https://live.gnome.org/OSTree/MultipleRoots Is there any opposition to having systemd support this setup? It already detects virtualization and containers at the moment, so it seems like it'd make sense. I'm totally willing to change around the bind mount setup, but I think the most basic support is going to be basically just looking for the root filesystem on /sysroot instead of /. If there's no objections I'll be looking at doing some patches for the GNOME 3.8 cycle. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
