On Jun 24, 2014, at 8:46 PM, Andrey Borzenkov <arvidj...@gmail.com> wrote:
> В Tue, 24 Jun 2014 11:03:06 -0600 > Chris Murphy <li...@colorremedies.com> пишет: > >> >> On Jun 24, 2014, at 2:12 AM, Colin Guthrie <gm...@colin.guthr.ie> wrote: >>> >>> Well, the initramfs should mount the rootfs readonly, and then it can >>> read it's /etc/fstab (and the /forcefsck file) and determine if any >>> further action should be taken before doing any kind of pivotroot type >>> stuff to transition to the host OS. This should all be handled by your >>> initramfs really. Not sure what systemd bits do that in a systemd+dracut >>> combo tho', as not fiddled with it for a while! >> >> These are selective extractions, but are in order. I see no evidence the >> initramfs attempts to mount root. The first mount that happens is initiated >> by systemd. >> > > systemd can also be used in initrd^Wamfs. It has the whole set of units > specifically for use in initrd. May be it is your case? I know the initramfs has a subset of systemd unit/service files, I don't know enough about it to investigate if dracut is actually putting the right ones in it or not. So I've just filed two bugs: RFE: honour rs.skipfsck in fstab-generator: which is the report about fs_passno for root being ignored; i.e. whether to honor fs_passno directly, or something else like systemd always initiating fsck for ext234, and never for xfs or btrfs. And I'm not sure if there's a valid debug use case to reverse those behaviors (i.e. never fsck for ext234, always fsck xfs & btrfs to "test the consequences") - not my expertise. https://bugzilla.redhat.com/show_bug.cgi?id=1098799 initrd: Failed to load configuration for systemd-fsck-root.service: which is now closed as notabug because it's an informational message only appearing with debug level logging https://bugzilla.redhat.com/show_bug.cgi?id=1107818 I think there's no catastrophe happening here, it's just a bit confusing that we have a place holder for whether fsck happens or not, and yet it's always happening even for file systems that don't need it. But it's also not a new problem, because many installers have been wrongly setting fs_passno to a non-zero value for xfs and btrfs for years. And now some installers wrongly not setting fs_passno non-zero for EFI System partitions (FAT) while also wrongly always mounting them rw by default. Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
