[Pkg-sysvinit-devel] Bug#623174: Bug#621803: Add support for /run directory

rleigh rleigh at codelibre.net
Wed Apr 27 16:13:50 UTC 2011

On Tue, Apr 26, 2011 at 06:48:15PM +0200, Marco d'Itri wrote:
> On Apr 26, rleigh <rleigh at codelibre.net> wrote:
> > Testing with initramfs-tools (maks/run) with current unstable shows
> > udev appearing to work correctly with it using /dev/.udev when /run
> > is not present on the host system.  And also with /run present on
> Did you check with LVM and that all its persistent symlinks are still
> there?

Patch attached which rectifies this, AFAICT.  If /run is not present on
the rootfs, instead of losing the /run/udev from the initramfs, we move
it to /dev/.udev:

@@ -227,10 +227,20 @@ run_scripts /scripts/init-bottom
 mount -n -o move /sys ${rootmnt}/sys
 mount -n -o move /proc ${rootmnt}/proc
-# Loosing information on old boxes without /run
+# Preserve information on old systems without /run on the rootfs
 if [ -d ${rootmnt}/run ]; then
 	mount -n -o move /run ${rootmnt}/run
+	# If the rootfs does not have /run, the initramfs udev database must
+	# be migrated from /run/udev/ to /dev/.udev/.
+	if [ -d /run/udev ] && [ ! -d /dev/.udev ]; then
+		mv /run/udev /dev/.udev
+	fi
+	# If the rootfs does not have /run, the initramfs debug info must
+	# be migrated from /run/initramfs/ to /dev/.initramfs/.
+	if [ -d /run/initramfs ] && [ ! -d /dev/.initramfs ]; then
+		mv /run/initramfs /dev/.initramfs
+	fi
 	umount /run
This is against initramfs-tools branch maks/run.  This preserves historical
behaviour, and will make udev/lvm work correctly during the transitional
period, i.e. the state is kept in the same place it always has been.  Once
you install a new initscripts which puts a /run on the rootfs, the udev
state will stay in /run.  So this caters for either possibility.  Is this

> No, there is no such code in the udev package. What you are seeing is
> /run/udev/ being lost when the initramfs is destroyed and a new
> /dev/.udev/.

The above patch should mean this does not occur any longer, unless the
lvm state is kept in places other than /run/udev.  I've saved the
contents of /run/udev or /dev/.udev at break=bottom and after boot
with initramfs-tools (unstable, maks/run and maks/run with the above
patch), and I see additional device-mapper info in the diff with the
patch applied.

(maks) The only other part of the patch is this:

@@ -25,7 +25,7 @@ if ! mount -t devtmpfs -o mode=0755 none /dev; then
 mkdir /dev/pts
 mount -t devpts -o noexec,nosuid,gid=5,mode=0620 none /dev/pts || true
-mount -t tmpfs -o nodev,noexec,nosuid,mode=0755 none /run
+mount -t tmpfs -o "nosuid,size=20%,mode=0755" tmpfs /run
 mkdir /run/initramfs
 # Export the dpkg architecture

This bit syncs the mount options with the initscripts defaults, but
most importantly the s/none/tmpfs/ makes the initscripts mount checks
not mount a second tmpfs on /run, obscuring the one from the initramfs.
domount() checks for already mounted filesystems to guard against
mounting an already mounted filesystem.  But it mounts all tmpfs
filesystems with "tmpfs" as mnt_fsname, and having this as "none"
breaks that check, leading to a second tmpfs mount.  Please could you
do the s/none/tmpfs whether or not you also pick up the mount defaults
changes, which are optional (we remount with the user-defined options


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: initramfs-tools-run-preserve-state.patch
Type: text/x-diff
Size: 1190 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110427/4ecd9d14/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20110427/4ecd9d14/attachment.pgp>

More information about the Pkg-sysvinit-devel mailing list