harald.hoyer at gmail.com
Mon Mar 4 22:22:06 PST 2013
Am 05.03.2013 06:26, schrieb Tom Gundersen:
> Hi Harald,
> On Tue, Mar 5, 2013 at 4:09 AM, Harald Hoyer <harald.hoyer at gmail.com> 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,
> The new target references the systemd.special manpag, but does not update it.
True... will fix.
> 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
> 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
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
Yes, that would be the ideal way (as we do in dracut now).
More information about the systemd-devel