On Sun, Jan 11, 2015 at 10:13 PM, Chris Murphy <li...@colorremedies.com> wrote: > On Sun, Jan 11, 2015 at 8:29 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote: >> В Sun, 11 Jan 2015 12:45:17 -0700 >> Chris Murphy <li...@colorremedies.com> пишет: >> >>> On Sun, Jan 11, 2015 at 4:57 AM, Andrei Borzenkov <arvidj...@gmail.com> >>> wrote: >>> > В Sun, 11 Jan 2015 04:15:41 -0700 >>> >>> > Does it using systemd *inside* of initrd? From upstream dracut: >>> > >>> > if ! dracut_module_included "systemd"; then >>> > inst_hook cmdline 95 "$moddir/parse-block.sh" >>> > inst_hook pre-udev 30 "$moddir/block-genrules.sh" >>> > inst_hook mount 99 "$moddir/mount-root.sh" >>> > ^^^^^^^^^^^^^ here it does it >>> > fi >>> > >>> > Do you have Fedora specific patches to do it differently? >>> >>> So the reason it's mounting all file systems ro by default appears to >>> be strictly because of the ro kernel parameter in the grub.cfg as >>> created by grub-mkconfig. >> >> Again - when using mount-root.sh it will >> >> - *always* mount real root ro >> - fetch other mount options from real root /etc/fstab >> - remount real root rw with correct mount options applied >> >> This all got lost if you use standard systemd-fstab-generator + >> systemd-fsck services. > > I don't agree with this, but here is a journalctl -b -l -o > short-monotonic output from Fedora 21 [1], with > systemd.log_level=debug rd.debug set. I do not see any reference to > mount-root.sh from dracut. What I see is systemd honoring kernel > parameter ro.
(I hit some key that made gmail send before the mail was done.) Anyway, this is what I'm getting: [ 11.956890] f21v.localdomain systemd[257]: Executing: /bin/mount -n /dev/disk/by-uuid/f3332d09-65f9-48c5-8539-c2b9ec8c75b4 /sysroot -t auto -o subvol=root,ro And no reference to mount-root.sh. This isn't new behavior in Fedora 21, Fedora 20 is the same and I think going back more versions too. There are numerous instances of systemd-fstab-generator and systemd-fsck that show up in the journal I referenced. Fedora stays fairly close to upstream systemd, there really is no point for it to be running drastically different. -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
