[systemd-devel] /run needs to be mounted? ugh.

[Dave Reisner]

On Tue, Feb 11, 2014 at 05:25:19PM +0000, Colin Guthrie wrote:
> 'Twas brillig, and Reindl Harald at 11/02/14 16:34 did gyre and gimble:
> > 
> > 
> > Am 11.02.2014 17:29, schrieb Andrey Borzenkov:
> >> В Tue, 11 Feb 2014 17:20:15 +0100
> >> "Jason A. Donenfeld" <Jason at zx2c4.com> пишет:
> >>
> >>> On Tue, Feb 11, 2014 at 5:15 PM, Dave Reisner <d at falconindy.com> wrote:
> >>>> I don't think there's any change needed here. The interface states:
> >>>>
> >>>>   "The initrd should mount /run as a tmpfs".
> >>>
> >>>> And sure enough, this isn't a requirement, but there's many valid
> >>>> reasons to do this.
> >>>
> >>>
> >>> Ahh, okay. I suppose what I'm wondering is what the advantages are to
> >>> mounting /run (if the remaining interfaces in the list aren't used)?
> >>> It looks like mounting /run occurs pretty soon in core/main.c. Could
> >>> it be that the only advantages of mounting /run early on are for using
> >>> the more advanced systemd initrd interfaces, such as giving control
> >>> back during shutdown? Or are there benefits in doing this even for the
> >>> most minimal of initrd?
> >>
> >> /run is used to pass state between initrd and system for such
> >> components as udev or mdadm. I do not know how your initramfs
> >> implementation works and whether it is using udev, but if you support
> >> root on MD, you likely will need /run
> > 
> > in context systemd maybe, in context MD not
> > 
> > the machine in front of me running F20 with systemd has root
> > on RAID10 originally installed with F14 before /run and systemd
> > existed in the setup
> 
> Yeah for various values of "works".
> 
> Without /run in such a setup, there is no way to pass udev db
> information to the running system.

This isn't really wanted. dracut, mkinitcpio, and systemd itself will
all clean out the udev DB before switching to the real root filesystem
by calling udevadm info --cleanup-db. Unfortunately, certain storage
stacks (looking at you, DM) require that some of the data stored in the
udev DB survive the switch root. This leads to udev rules like:

SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", ACTION=="add|change", OPTIONS="db_persist"

> If this pre-dates using udev in the initrd, then the initrd will have
> bring up the h/w by itself and udev still misses important metadata when
> it finally kicks in and will thus give an incomplete picture to the rest
> of userspace.

In an ideal world, calling 'udevadm trigger ...' should be sufficient to
completely recreate the udev DB with no help from early userspace.

> As has been mentioned elsewhere on this thread, there are a number of
> "gotchas" and corner cases, that this mechanism solved, even in the
> cases of things "working".
> 
> Col
> 
> 
> 
> -- 
> 
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
> 
> Day Job:
>   Tribalogic Limited http://www.tribalogic.net/
> Open Source:
>   Mageia Contributor http://www.mageia.org/
>   PulseAudio Hacker http://www.pulseaudio.org/
>   Trac Hacker http://trac.edgewall.org/
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel