[systemd-devel] initrd-fs.target

[Tom Gundersen]

On Tue, Mar 5, 2013 at 3:22 PM, Harald Hoyer <harald.hoyer at gmail.com> 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?

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

>> 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?

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

-t