[systemd-devel] initrd-fs.target

[Harald Hoyer]

Am 05.03.2013 08:08, schrieb 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?

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.