On 10/15/2013 04:23 PM, Juerg Haefliger wrote: >> On 10/15/2013 02:47 PM, Juerg Haefliger wrote: >>> All, >>> >>> The (admittedly hacky) dracut-modules-growroot package installs a >>> dracut script that runs in the pre-pivot stage. It unmounts the root >>> partition, extends it to the maximum possible size and then tries to >>> remount it. What I noticed in F20 is that as soon as the >>> repartitioning finishes (its an sfdisk command), something >>> automatically remounts the root partition and the growroot script >>> fails when it tries to mount the already mounted partition. >>> >>> Can somebody shed some light on what is happening and why the root >>> partition is automatically remounted and if I can rely on that and not >>> have the growroot script try to remount it? >>> >>> Thanks >>> ...Juerg >>> >> >> Oh, that is systemd, because it generates a unit file from the kernel command >> line called sysroot.mount, which is required by the following systemd targets. > > That's what I thought. So I can rely on that? Did that change for F20? > I don't remember seeing that behaviour with F19. > > ...Juerg > Well, it "should" be the same in F19. Maybe some internal ordering of the units changed. You can rely on it, as long as the kernel command line contains a valid "root=" in the form of: root=/dev/... root=LABEL=... root=UUID=... root=PARTUUID=... root=PARTLABEL=... which "should" be always the case, except for network dhcp booting, where the dhcp "root-path" can determine the root. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
