В Sat, 10 Jan 2015 16:51:24 +0300 Nikolai Zhubr <n-a-zh...@yandex.ru> пишет:
> Hi, > 09.01.2015 23:48, Chris Murphy: > [...] > >> I might be missing something, but what's wrong with the existing "root=... > >> rootfstype=... rootflags=... rw" options? Why is the remount even > >> necessary? > > > > Seems to be distro specific. I see rw for opensuse or Ubuntu, and ro for > > Fedora. > > > > The ro seems antiquated to me, meant for interactive fsck on an ro > > mounted filesystem when booting single user. 'btrfs check' refuses to > > run on mounted file systems, even if ro. And xfs_repair requires the > > use of -d "repair dangerously" to do so. > > > > Both XFS and Btrfs have placeholder fsck's, if you man fsck.xfs or > > fsck.btrfs you'll see. These filesystems are designed to fix most > > Ok. I've invented a quick-and-dirty fix. I'll modify systemd-fsck so > that when run with no argument it does nothing and exit successfully. > This way I'll still have rootfs fsck'ed every boot, but never twice. > Uh. Why not simply mount rootfs rw in initrd then? > I'll soon need this box for work anyway, reverting to some 12.x does not > seem very attractive, and living with this bug every day won't give me a > good feeling either. (Just a week ago I had one single erroneous fsck > rendering my rootfs essentially to a complete trash) > > Hope someone will come up with a better solution though :) The more I think about it the more I find it non-issue. As was already mentioned, systemd-fsck checks whether rootfs is mounted read-write and will skip check in this case. Could someone give a compelling reason why initrd would want to mount rootfs read-only after having fsck'ed it? Otherwise the only way to prevent second fsck is to pass some flag from initrd to real root, like /run/systemd/fsck-root-done. There is no feasible way to reuse the same systemd-fsck-root.service without introducing hard dependency on initrd implementation. I hoped to get away by just symlinking systemd-fsck-root.service to systemd-fsck@root-dev.service, but it's not possible. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel