[systemd-devel] initrd-fs.target

[Harald Hoyer]

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,

> 
>> 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).