On Wed, Jul 02, 2014 at 12:39:54PM +0100, Daniel Drake wrote: > Hi, > > I'm trying to understand dracut/systemd fsck behaviour, in the context > of an ext4 filesystem root mounted read-only from dracut, remaining > read-only even when the system is fully booted (kiosk-style). > > I see that systemd's fstab-generator rightly creates a mount unit for > /sysroot from the initramfs, and causes e2fsck to be run on it from > inside the dracut initramfs, before it is mounted. So far so good. > > > Then the system continues booting, switches root, and then > system-fsck-root.service starts from the root fs, and runs fsck on / > again. This is the bit I don't understand - we already checked from > the initramfs, why check again now? > > There used to be a marker file in /run to let systemd know that the > initramfs already checked it, but that was removed in commit > 956eaf2b8d6c9999024705ddadc7393bc707de02.
Thinking about it, I'm not sure how the new systemd would know that systemd-fsck@dev-something.service from the initramfs is the same thing as systemd-fsck-root.service. Maybe that's the problem? Currently systemd-fsck-root.service does nothing if / is mounted rw, which of course is used by almost everybody, so I think you might be using codepaths that are rarely tested. > Also, systemd-fsck-root.service in itself seems a little questionable, > is it really safe in any context to run fsck on a mounted partition? > That could modify data structures which have already been cached in > memory in the kernel fs driver. In fact, e2fsck refuses to run on > partitions that are mounted, even ones that are ro. Isn't it how it always has been, until initramfs became common? Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel