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.
On Thu, Mar 31, 2011 at 1:21 PM, Thomas Bächler thomas@archlinux.org 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 just been reading up on this, and I agree that we should add it.
At some point in the future we should probably consider symlinking /var/run to /run and /var/lock to /run/lock, but we would have to implement https://bugs.archlinux.org/task/18157 first, and /run is useful even without the symlinks. My understanding of the situation is that it is ok or /var/run and /run to be different, but please let me know if I'm wrong on this.
I guess we'll need to add the mountpoint to the filesystem package (possibly with permissions 0000 to avoid accidents) and mount the tmpfs early in rc.sysinit (I'll write the patch as soon as people agree that this is the right thing to do).
Cheers,
Tom
On Thu, Mar 31, 2011 at 01:51:17PM +0200, Tom Gundersen wrote:
On Thu, Mar 31, 2011 at 1:21 PM, Thomas Bächler thomas@archlinux.org 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 just been reading up on this, and I agree that we should add it.
At some point in the future we should probably consider symlinking /var/run to /run and /var/lock to /run/lock, but we would have to implement https://bugs.archlinux.org/task/18157 first, and /run is useful even without the symlinks. My understanding of the situation is that it is ok or /var/run and /run to be different, but please let me know if I'm wrong on this.
I guess we'll need to add the mountpoint to the filesystem package (possibly with permissions 0000 to avoid accidents) and mount the tmpfs early in rc.sysinit (I'll write the patch as soon as people agree that this is the right thing to do).
Cheers,
Tom
Why symlinks? Why not bind mount /run to /var/run and /run/lock to /var/lock once / is available?
Something else to think about: do we want to carry this back to the initcpio?
d
On Thu, Mar 31, 2011 at 2:16 PM, Dave Reisner d@falconindy.com 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
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.
On Thu, Mar 31, 2011 at 3:12 PM, Thomas Bächler thomas@archlinux.org 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
Am 31.03.2011 15:15, schrieb Tom Gundersen:
On Thu, Mar 31, 2011 at 3:12 PM, Thomas Bächler thomas@archlinux.org 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?
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.
I was thinking with regard to mdadm now: Maybe mdadm stores some valuable data there.
On Thu, Mar 31, 2011 at 3:54 PM, Thomas Bächler thomas@archlinux.org 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.
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?
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.
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 Thu, Mar 31, 2011 at 7:21 PM, Thomas Bächler thomas@archlinux.org 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
On Tue, 5 Apr 2011 14:47:06 +0800, Tom Gundersen wrote:
On Thu, Mar 31, 2011 at 7:21 PM, Thomas Bächler thomas@archlinux.org 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?
On Fri, Apr 8, 2011 at 5:42 PM, Pierre Schmitz pierre@archlinux.de wrote:
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?
Once it is added in filesystem and mounted by initscripts. Ill add the patch next week as Im traveling now and my laptop just broke so Ill need to wait until I get home.
-t
arch-projects@lists.archlinux.org