On Thu, Mar 31, 2011 at 2:16 PM, Dave Reisner wrote:

Why symlinks? Why not bind mount /run to /var/run and /run/lock to /var/lock once / is available?

I thought symlinks would be easier to maintain in the long run, and it is what the other distro's are planning to do (at least Fedora will in F16 after bindmounting in F15). That said, I don't have strong feelings about the pro's and con's of bindmounting v. symlinking. What would be the benefit?

Something else to think about: do we want to carry this back to the initcpio?

Ah, yes, we probably do (like what we do with /proc and /sys). Cheers, Tom

On Thu, Mar 31, 2011 at 3:12 PM, Thomas Bächler wrote:

Am 31.03.2011 14:21, schrieb Tom Gundersen:

...

...

Something else to think about: do we want to carry this back to the initcpio?

Ah, yes, we probably do (like what we do with /proc and /sys).

We kill every process before leaving initramfs, and in initramfs, everything is writable. IMO, there is no need to keep a persistent /run between initramfs and system.

Sorry, I don't know the details of initramfs, so I might be wrong on this, but shouldn't the udev database (former /dev/.udev, now /run/udev) be preserved? Cheers, Tom

On Thu, Mar 31, 2011 at 3:54 PM, Thomas Bächler wrote:

This database is (re)created when we (re)start udevd in rc.syinit. Udev doesn't know that it was running before, so there is no need to reuse any database.

From udev's NEWS file:

*** The udev runtime data moved from /dev/.udev/ to /run/udev/. The /run mountpoint is supposed to be a tmpfs mounted during early boot, available and writable to for all tools at any time during bootup, it replaces /var/run/, which should become a symlink some day. If /run does not exist, or is not writable, udev will fall back using /dev/.udev/. On systemd systems with initramfs and LVM used, packagers must make sure, that the systemd and initramfs versions match. The initramfs needs to create the /run/ mountpoint for udev to store the data, and mount this tmpfs to /run in the rootfs, so the that the udev database is preserved for the udev version started in the rootfs. *** The last paragraph is admittedly referring to systemd, but I think this is not important (I think the same case would apply to any init system mounting /run). Here I get the impression that there is something valuable in the udev database that could and should be preserved from initramfs to normal init (I don't fully understand what is happening here, so maybe it does not apply to Arch).

I was thinking with regard to mdadm now: Maybe mdadm stores some valuable data there.

From all the discussions on this topic I really got the impression

They certainly store something in /run, but I don't know what happens if we throw it away at the end of initramfs. that /run is supposed to be created in the initramfs and then preserved until shutdown. Maybe it is worth having a look at what dracut is doing?

On Thu, Mar 31, 2011 at 05:04:27PM +0200, Thomas Bächler wrote:

Am 31.03.2011 16:44, schrieb Tom Gundersen:

...

On systemd systems with initramfs and LVM used, packagers must make sure, that the systemd and initramfs versions match. The initramfs needs to create the /run/ mountpoint for udev to store the data, and mount this tmpfs to /run in the rootfs, so the that the udev database is preserved for the udev version started in the rootfs. ***

The last paragraph is admittedly referring to systemd, but I think this is not important (I think the same case would apply to any init system mounting /run). Here I get the impression that there is something valuable in the udev database that could and should be preserved from initramfs to normal init (I don't fully understand what is happening here, so maybe it does not apply to Arch).

...

I was thinking with regard to mdadm now: Maybe mdadm stores some valuable data there.

They certainly store something in /run, but I don't know what happens if we throw it away at the end of initramfs.

...

From all the discussions on this topic I really got the impression that /run is supposed to be created in the initramfs and then preserved until shutdown. Maybe it is worth having a look at what dracut is doing?

We can do that easily (identical as the /proc, /sys, /dev stuff). However, prepare to run into problems when the initramfs udev version does not match the version in the system.

Shouldn't be a problem unless there's a format change, as udev can convert the DB. Relevant snippets from dmesg on my work VM (which i abuse mercilessly): udev[36]: starting version 166 <30>udev[462]: converting old udev database <30>udev[462]: starting version 167 dave

On Tue, 5 Apr 2011 14:47:06 +0800, Tom Gundersen wrote:

On Thu, Mar 31, 2011 at 7:21 PM, Thomas Bächler wrote:

...

This was discussed in a bug report iirc, here is some summary: http://www.h-online.com/open/news/item/Linux-distributions-to-include-run-di...

Apparently, many tools (among them udev) will soon require a /run/ directory that is mounted early (as tmpfs). It is probably a good idea to add this to the filesystem and initscripts packages.

I have prepared patches (https://github.com/teg/initscripts-arch/commits/bootlogd) that mounts /run if it is not already mounted in initscripts.

I'll push them out if /run is added to filesystem (my requires /run to exist, but an existing /run without write permissions will not cause any problems, so it would be best to add this to filesystem first and then for initscripts to follow).

Do the filesystem maintainer(s?) agree to add this?

Cheers,

Tom

I'll add the /run dir to the next filesystem package. I guess once this is done we could start updating our packages to use /run instead of /var/run, right? -- Pierre Schmitz, https://users.archlinux.de/~pierre