Am 05.03.2013 08:08, schrieb Tom Gundersen: > On Tue, Mar 5, 2013 at 3:22 PM, Harald Hoyer <[email protected]> wrote: >> Am 05.03.2013 06:26, schrieb Tom Gundersen: >>> 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, > > I posted the alternative fix that I have been using locally. What do > you think of that?
Works for me, except that I really need: diff --git a/units/initrd-parse-etc.service b/units/initrd-parse-etc.service index 4bfbb0f..3a71a7e 100644 --- a/units/initrd-parse-etc.service +++ b/units/initrd-parse-etc.service @@ -16,4 +16,5 @@ ConditionPathExists=/etc/initrd-release [Service] Type=oneshot ExecStartPre=/usr/bin/systemctl daemon-reload +ExecStart=/usr/bin/systemctl start local-fs.target ExecStart=/usr/bin/systemctl --no-block start initrd-cleanup.service > >>>> 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. > > Hm, for me this works because the initrd-switch-root.target pulls in > the fs.target and is isolated. Having another look at these units I > think we can probably drop initrd-cleanup.service (merge it into > initrd-parse-etc.service), which should make things a bit clearer... For me the sysroot-usr.mount is not mounted in my testsuite unless I patch it like mentioned above. > >>> 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. > > Right, but if we call these functions in the right order, and > sysroot.mount is configured more than once (in both /proc/cmdline and > /etc/fstab), then the one from /proc/cmdline will be used and the > generation of the second unit will simply fail, won't it? ok, ok :) > >>> 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). > > Ok, I'll implement this when I get a chance (unless you beat me to it). What we might want is fsck before we mount it rw and maybe store the fsck result in /run/initramfs/<mountpoint>-fsck. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
