[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
else
+ # 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
fi
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
OK?
> 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
fi
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
later).
Thanks,
Roger
--
.''`. 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