Am 01.10.2013 02:58, schrieb Lennart Poettering: > Now, if we have the initrd, then I figure root-fsck.service doesn't make > much sense, but there's something missing I think: if we use > fsck@.service for the root device, how do we then communicate to the > root-fsck.service on the host that the file system has already been > checked? How is that supposed to work?
This is how I imagine things should work: 1) initrd fsck's the device used for /sysroot. 2) initrd mounts /sysroot as rw 3) initrd fsck's and mounts /usr and friends 4) switch-root 5) the main system only fsck's and mounts whatever isn't mounted yet. This is what we now have as default in new Arch installations (including / being mounted rw in initrd). What we don't have by default yet is initrd being handled by systemd. In the systemd case, step 1) was missing and the root device was never fsck'ed, thus the patch. The beauty of this setup is that systemd implicitly does everything right, there is no need to serialize any fsck state between initrd and main system. In the setup I am aiming for as a default, neither systemd-root-fsck.service nor systemd-remount-fs.service are needed and both can go away (in fact, I always mask the latter, since that saves me a few milliseconds). The only use case I see for both using fsck in initrd and having / mounted read-only during switch-root is a read-only root file system. In that light, I don't think there is anything to fix.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel