[systemd-devel] why is systemd-remount-fs.service needed in stage-2?

[Lennart Poettering]

On So, 03.05.20 23:03, Arian Van Putten (arian at wire.com) wrote:

> Hey list,
>
> I'm in the process of experimenting with a systemd-based initrd.
> However I have two questions concerning the boot process that came up
> whilst reading the documentation.
>
> If I understand "man 7 bootup" correctly so far  the initrd mounts /sysroot
> based on either the root= kernel parameter or through gpt-auto-generator.
> At this point /sysroot is mounted. However /sysroot/etc/fstab might have
> additional entries that need to be mounted in the initrd (marked with
> "x-initrd").
> Next "initrd-parse-etc.service" gets triggered which runs fstab-generator
> which then mounts all the entries marked with "x-initrd".
> If "/usr" is in a separate partition; I would expect it to _need_ to be
> marked "x-initrd" as you want /usr to be present as soon as you boot up the
> system. And this causes the "sysroot-usr.mount" unit to be generated and
> gets pulled in by "initrd-fs.target".

IIRC we imply x-initrd for /usr.

> We're now ready to switch-root to the root-filesystem and move to stage-2.
>
> In stage-2, in early boot.  "systemd-remount-fs.service" runs;  which
> remounts / and /usr with the actual options in /etc/fstab.
>
> Two questions about this:
>
> 1.  if sysroot-usr.mount already gets pulled in in the initrd by parsing
> /sysroot/etc/fstab why do we need to remount /usr   in stage-2 with
> "systemd-remount-fs.service"? Didn't we already parse the correct values
> from fstab, and hence /usr is already guaranteed to be correctly
> mounted?

Two reasons:

1) To cover for non-initrd systems or systems using yesteryear's
   (i.e. non-systemd) initrds.

2) Also, it's for applying mount options to /run, /sys, /proc and
   suchlike, i.e. API VFS which are mounted by systemd itself natively
   early on without any fstab entry, but if the user wants exotic
   mount options can list in fstab too.

> 2. relatedly;  why cant after "initrd-parse-etc.service" is run
> sysroot.mount  be retriggered with the new options parsed from
> /sysroot/etc/fstab as well?  Then to me it sounds like
> "systemd-remount-fs.service" is not needed at all for / and /usr. (though
> maybe still for /sys and /proc)

Yeah, but /sys and /proc and /run do matter.

> My gut feeling the answer to this question is "not all initrd's use
> systemd; so they might not parse /sysroot/etc/fstab so early we need to
> account for that". Is that the case?

Yes, partially, see above.

Lennart

--
Lennart Poettering, Berlin