http://bugzilla.opensuse.org/show_bug.cgi?id=912209 Bug ID: 912209 Summary: Incorrect handling of rootfs ckecking from initrd (excessive fsck after mounted r/o) Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: zhubr@mail.ru QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.1.4) Gecko/20091016 MRA 5.3 (build 02564) Firefox/3.5.4 Build Identifier: The sequence of fsck'ing and mounting rootfs at boot time (initrd-driven) is not correct. What happens is: 1. In initrd, root disk is (correctly) detected as "uuid-XXXX..." and successfully fsck'ed. This is performed by systemd-fsck@.service. 2. Next, it is mounted read-only to /sysroot. It is important to note here that mounting read-only AFAIK is no guarantee that no modifications can happen to the underlying media, as e.g. some filesystems might choose to start background recovery or whatever internal activity even in read-only mode, including IIRC ext3+). 3. Before remounting root fs to / as read-write, a second fsck is performed. This time it is performed by systemd-root-fsck.service. I think this is wrong and dangerous, because: -- in the best case, second fsck is simply unnecessary and just increases boot time, -- in the worst case, if root fs is in some trouble or performing some internal activities, fsck'ing it while still mounted might break integrity of filesystem (depending on fs type and condition) Reproducible: Always Steps to Reproduce: 1. Complete the installation of opensuse 13.2 from full DVD (x86_64 in my case) using just default settings, reboot. 2. Use "journalctl | grep fsck" to find out dev name and uuid of root partition (in my case it is /dev/md0 and uuid-588d...) 3. Use "journalctl | grep md0" (Replace md0 by your real root dev name) and/or "journalctl | grep fsck" to see relevant fragments of boot log. Actual Results: 01:54:58 systemd[1]: Starting File System Check on /dev/disk/by-uuid/588d9a9c-4c4e-4400-9e2b-a79f5fce670e... ... 01:54:59 systemd-fsck[334]: /dev/md0: clean, 130091/1313280 files, 1176795/5242880 blocks ... 01:54:59 systemd[1]: Mounting /sysroot... ... 01:54:59 systemd[340]: Executing: /bin/mount -n -t auto -o ro /dev/disk/by-uuid/588d9a9c-4c4e-4400-9e2b-a79f5fce670e /sysroot ... 01:54:59 kernel: EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) 01:54:59 systemd[1]: Mounted /sysroot. ... 01:55:12 systemd-fsck[432]: /dev/md0: clean, 130091/1313280 files, 1176795/5242880 blocks ... 01:55:12 systemd[1]: Starting Remount Root and Kernel File Systems... ... 01:55:12 kernel: EXT4-fs (md0): re-mounted. Opts: noacl Expected Results: The second fsck should not happen. * Supposedly the problem comes from dracut upstream. * Comment from Lennart Poettering: "The fsck of the root file system is done by systemd-root-fsck.service. It exists both in the initrd and on the host. When the transition between the initrd and the host takes place the state of the unit is serialized/unserialized. And since RemainAfterExit=yes is set if it was started once it will not be started again because it will still be considered started." * However, systemd-root-fsck.service is not present in initrd here. -- You are receiving this mail because: You are on the CC list for the bug.