On Wed, Aug 21, 2013 at 06:03:34PM +0800, Tom Gundersen wrote: > On Wed, Aug 21, 2013 at 5:56 PM, Colin Guthrie <gm...@colin.guthr.ie> wrote: > > 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 21/08/13 04:38 did > > gyre and gimble: > >> On Wed, Aug 21, 2013 at 05:21:59AM +0200, Stephan Raue wrote: > >>> Hi, > >>> > >>> i try to port systemd on a own embedded OS which is stored in a > >>> squashfs file. This file is on a fat partition (later mounted as > >>> /flash) on the drive. > >>> > >>> In our own initramfs (which dont uses systemd) /flash will be > >>> mounted and then the Squashfs file as /sysroot. later we do a > >>> switch_root and start systemd. On shutdown systemd trys now (5 > >>> times) to unmount /flash and times out later with a error message. > >>> This delays the shutdown/reboot much. Systemd also trys to cleanup > >>> /dev/loop0. I need to prevent systemd to unmount /flash and clean > >>> /dev/loop0 (which is the / mount from the squashfs file). > >>> > >>> can i actually prevent this in some way and if nout could i request > >>> a feature to add a mount option which if avaible prevents systemd > >>> from unmounting single partitions and cleanup /dev/loopX if its > >>> still mounted as / ? I need this as mount option or a systemd unit > >>> file but for fstab based systems it would be usefull as a fstab > >>> option too (we dont use fstab) > >> I don't think it's possible currently with fstab. But with > >> a mount unit, I think > >> DefaultDependencies=no > >> RequiredBy=-.mount > >> should work. Have you tried something like that? > > > > Hmm, I thought the umount logic was such that it just tries to unmount > > everything from/proc/mounts rather than looking at units etc. OTOH, if systemd manages to unmount something on top of which another filesystem is mounted, is a kernel bug, no?
> > I asked a similar question a while back and we figured at the time that > > adding a mount option might be a solution as there is already a fstab > > option to indicate a given filesystem should be mounted in the initrd, > > and it would make sense to honor that during shutdown (by not trying to > > umount it), but the problem was the umount loop doesn't read fstab or > > any mount options to check... > > I have also been thinking of this problem recently. I have some > patches to not add a conflict with umount.target when a mount is > marked with x-initrd.mount, but as you point out we need to do > something to also cover the final umount loop. One option is to simply > jump to the shutdown ramfs straight away if it exists and let that do > all the final unmounting/killing, which should always work. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel