Am 05.03.2013 06:26, schrieb Tom Gundersen: > Hi Harald, > > On Tue, Mar 5, 2013 at 4:09 AM, Harald Hoyer <[email protected]> wrote: >> please review > > Could you comment on why this is necessary? It would be nice if we > could reuse as much as possible from the real root rather than making > initrd-spcific files, but perhaps it is not possible in this case? > > I am aware of one problem that your patch solves (at least for this > particular case). > > When we switch root we use JOB_REPLACE to default.target. This means > that units which are pulled in by default.target, but already active > in the initrd (such as local-fs.target) will not be pulled in again, > so if they get new dependencies (in this case the entries from the > real /etc/fstab) these are not started. I was going to suggest solving > this by using JOB_ISOLATE when switching root, but didn't yet have the > chance to check if this causes any problems. Did you consider this, or > did you have a different reason for the patch?
Yes, this is the problem. local-fs.target would be already active and e.g. systemd-remount-fs.service is never started, > >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=39b83cdab37623a546344622db9bbbc784c15df5 > > The new target references the systemd.special manpag, but does not update it. True... will fix. > >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=7d89ce303fb59743a4392eeb3110c00f100172ca > > Why is it necessary to "start" initrd-fs.target in addition to Require it? All the newly generated mount units are not started, because initrd-fs.target is already active. > >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=8330847e949fc0c26b16910e5240eef1fe2c330a > > Hm, wouldn't this mean that any other storage related service we might > want to include in the initrd would have to be special-cased to deal > with initrd-fs rather than local-fs? Yes, but local-fs is still active in the initrd. Of course, if there is a possibility to avoid this, I am all for it. > > Why do you need the 'skip generation of sysroot.mount if exists' > logic? Shouldn't we just generate it in the correct generator > directory? This was for the /run/systemd/generator/*.mount units, that the fstab-generator already generated itsself. /run/systemd/generator/ is emptied anyway on daemon-reload. > > I think you changed the priority order of /proc/cmdline, /etc/fstab > and /sysroot/etc/fstab, could you comment on why it is the way it is? Ok, I started to write my arguments five times now and every time I find my arguments are flawed... I'll revert this patch. > I think /sysroot/etc/fstab should have the highest priority, as that > what will be used to remount the filesystems in the real root (I have > patches to do the remounting in the initrd to avoid doing any mounting > twice, but that's a separate issue), and that /etc/fstab should have > the lowest as it has to be set at initrd generation time. What do you > think? Yes, that would be the ideal way (as we do in dracut now). _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
