Bug#621803: Add support for /run directory
On Tue, Apr 26, 2011 at 06:48:15PM +0200, Marco d'Itri wrote: On Apr 26, rleigh rle...@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? I created a new kvm VM this morning which uses LVM, so I'll test all the combinations later tonight. In a kvm VM, I do see some errors from udev at startup: These are unrelated and harmless (the errors are old, only the message is new). Why does /run should not be noexec? If /run/shm is also on /run (not a separate mount), it needs to be executable. Why do we need it executable? From what I've read from past initscripts and other bug reports, it's required for mmapping shared memory with PROT_EXEC, but I have not verified this by writing a testcase. Marco, have you tested this upgrade path? That is /run in the initramfs and no /run on the rootfs? Is udev checking for that and No, but if the database is not copied to the initramfs then LVM will be annoyed. Which database is this? Is this something that the LVM scripts need updating to handle? It is /dev/.udev/ or /run/udev/. I do not know exactly how LVM interacts with it, just that it must be preserved. OK. I feel that doing something like this: if [ -d /run ] [ ! -d /root/run ]; then mv /run/udev /dev/.udev (or mv /run/udev /root/dev/.udev) fi at the point where we mount --move in the initramfs would be the best action to take. It preserves the udev state from the initramfs when it would otherwise be lost. In the case where /run also exists on the rootfs, no action needs taking. When I do the testing in my new VM, I'll test this type of change as well. Regards, 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. signature.asc Description: Digital signature
Bug#621803: Add support for /run directory
block 623174 by 621803 thanks On Fri, Apr 22, 2011 at 08:14:47PM +0100, Roger Leigh wrote: On Mon, Apr 18, 2011 at 07:38:41PM +0100, Roger Leigh wrote: By the way, could you consider adding this patch to your branch: diff --git a/init b/init index 38c8a5d..cdbfe50 100755 --- a/init +++ b/init @@ -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 Slightly simpler than the previous patch, but does the same job. Please note that I've now patched initscripts (http://paste.debian.net/114826/ and http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-April/004990.html) so that the filesystems mounted in the initramfs and later moved over to the root filesystem are remounted with the mount options specified in /etc/fstab (or /etc/default/tmpfs if no fstab entry exists). In consequence, it's no longer critical that the mount option defaults in the initramfs match the real root filesystem defaults, because they will always be applied by mountkernfs/ mountdevsubfs. So if you choose not to apply this, that's fine--it's just a nice to have addition; the patch as it stands without the above change is equally acceptable. Thanks for doing this. Do we have any ETA on an upload? The updated initscripts should be uploaded to experimental later today. This includes all the changes listed above. I've added the block above because we can't make an upload of sysvinit/ initscripts to unstable until we have an updated initramfs-tools in unstable, or else udev will break. Therefore in order to have a smooth transition we need initramfs-tools uploading first, followed by initscripts. Marco, have you tested this upgrade path? That is /run in the initramfs and no /run on the rootfs? Is udev checking for that and not using /run in this scenario (or moving the files from /run to /dev/.udev)? We will need to cope with this for a brief transitional period when initramfs-tools is updated and initscripts is not. 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. signature.asc Description: Digital signature
Processed: Re: Bug#621803: Add support for /run directory
Processing commands for cont...@bugs.debian.org: block 623174 by 621803 Bug #623174 [initscripts] /run must exist in the initramfs and be moved to the root filesystem Was not blocked by any bugs. Added blocking bug(s) of 623174: 621803 thanks Stopping processing here. Please contact me if you need assistance. -- 623174: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623174 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130381598517807.transcr...@bugs.debian.org
Bug#621803: Add support for /run directory
On Apr 26, rleigh rle...@codelibre.net wrote: -mount -t tmpfs -o nodev,noexec,nosuid,mode=0755 none /run +mount -t tmpfs -o nosuid,size=20%,mode=0755 tmpfs /run Why does /run should not be noexec? I've added the block above because we can't make an upload of sysvinit/ initscripts to unstable until we have an updated initramfs-tools in unstable, or else udev will break. Therefore in order to have a smooth Yes, if /run exists in the initramfs then it needs to be moved to the root filesystem. Marco, have you tested this upgrade path? That is /run in the initramfs and no /run on the rootfs? Is udev checking for that and No, but if the database is not copied to the initramfs then LVM will be annoyed. not using /run in this scenario (or moving the files from /run to /dev/.udev)? We will need to cope with this for a brief transitional period when initramfs-tools is updated and initscripts is not. The udev initscript cannot know if there was a /run/udev in the initramfs and it was lost. Right now I can't see how to work around this. If there is no /run in the initramfs then /dev/.udev/ will be used, and since udev 167-3 the udev init script will move it to /run/udev/ (as long as /run is a mount point, check the init script). -- ciao, Marco signature.asc Description: Digital signature
Bug#621803: Add support for /run directory
On Tue, Apr 26, 2011 at 12:06:14PM +0100, Roger Leigh wrote: block 623174 by 621803 thanks On Fri, Apr 22, 2011 at 08:14:47PM +0100, Roger Leigh wrote: On Mon, Apr 18, 2011 at 07:38:41PM +0100, Roger Leigh wrote: By the way, could you consider adding this patch to your branch: diff --git a/init b/init index 38c8a5d..cdbfe50 100755 --- a/init +++ b/init @@ -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 Slightly simpler than the previous patch, but does the same job. Please note that I've now patched initscripts (http://paste.debian.net/114826/ and http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-April/004990.html) so that the filesystems mounted in the initramfs and later moved over to the root filesystem are remounted with the mount options specified in /etc/fstab (or /etc/default/tmpfs if no fstab entry exists). In consequence, it's no longer critical that the mount option defaults in the initramfs match the real root filesystem defaults, because they will always be applied by mountkernfs/ mountdevsubfs. So if you choose not to apply this, that's fine--it's just a nice to have addition; the patch as it stands without the above change is equally acceptable. Thanks for doing this. Do we have any ETA on an upload? The updated initscripts should be uploaded to experimental later today. This includes all the changes listed above. I've added the block above because we can't make an upload of sysvinit/ initscripts to unstable until we have an updated initramfs-tools in unstable, or else udev will break. Therefore in order to have a smooth transition we need initramfs-tools uploading first, followed by initscripts. Marco, have you tested this upgrade path? That is /run in the initramfs and no /run on the rootfs? Is udev checking for that and not using /run in this scenario (or moving the files from /run to /dev/.udev)? We will need to cope with this for a brief transitional period when initramfs-tools is updated and initscripts is not. 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 the host system in addition. In the former case, it uses /run in the initramfs and moved it to /dev/.udev on the host. In the latter it uses /run in the initramfs and on the host as well. So from the udev side, it does appear to be working correctly in all cases. So from this POV, the maks/run branch is working just fine. In a kvm VM, I do see some errors from udev at startup: -- Loading Linux 2.6.38-2-amd64 ... Loading initial ramdisk ... Loading, please wait... udevd[125]: exec of program 'net.agent' failed udevd[126]: exec of program 'net.agent' failed udevd[137]: exec of program 'cdrom_id --export /dev/sr0' failed udevd[142]: exec of program 'cdrom_id --export /dev/sr0' failed INIT: version 2.88 booting Using makefile-style concurrent boot in runlevel S. Starting the hotplug events dispatcher: udevd -- This is with udev 168-1. However, I see the above without any changes to initramfs-tools or initscripts, and this doesn't changes with /run present in the initramfs or both the initramfs and rootfs, so it's a separate issue, and so far specific to the VM image. Regards, 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. signature.asc Description: Digital signature
Bug#621803: Add support for /run directory
On Tue, Apr 26, 2011 at 05:12:49PM +0200, Marco d'Itri wrote: On Apr 26, rleigh rle...@codelibre.net wrote: -mount -t tmpfs -o nodev,noexec,nosuid,mode=0755 none /run +mount -t tmpfs -o nosuid,size=20%,mode=0755 tmpfs /run Why does /run should not be noexec? If /run/shm is also on /run (not a separate mount), it needs to be executable. If they are separate mounts, it does add the noexec option back: [mountkernfs.sh] # If /run/shm is separately mounted, /run can be safely mounted noexec. RUNEXEC= if [ yes = $RAMSHM ] || read_fstab_entry /run/shm tmpfs; then RUNEXEC=',noexec' fi # TODO: Add -onodev once checkroot no longer creates a device node. domount $MNTMODE tmpfs shmfs /run tmpfs -onosuid$RUNEXEC$RUN_OPT I've added the block above because we can't make an upload of sysvinit/ initscripts to unstable until we have an updated initramfs-tools in unstable, or else udev will break. Therefore in order to have a smooth Yes, if /run exists in the initramfs then it needs to be moved to the root filesystem. This is being done by initramfs-tools, and it's working nicely AFAICT. Marco, have you tested this upgrade path? That is /run in the initramfs and no /run on the rootfs? Is udev checking for that and No, but if the database is not copied to the initramfs then LVM will be annoyed. Which database is this? Is this something that the LVM scripts need updating to handle? not using /run in this scenario (or moving the files from /run to /dev/.udev)? We will need to cope with this for a brief transitional period when initramfs-tools is updated and initscripts is not. The udev initscript cannot know if there was a /run/udev in the initramfs and it was lost. Right now I can't see how to work around this. If there is no /run in the initramfs then /dev/.udev/ will be used, and since udev 167-3 the udev init script will move it to /run/udev/ (as long as /run is a mount point, check the init script). I just sent a separate mail after doing some testing. The current logic in 168-1 does appear to move /run/udev (initramfs) to /dev/.udev when /run is not present on the host. Looks good to me. Regards, 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. signature.asc Description: Digital signature
Bug#621803: Add support for /run directory
On Apr 26, rleigh rle...@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? In a kvm VM, I do see some errors from udev at startup: These are unrelated and harmless (the errors are old, only the message is new). Why does /run should not be noexec? If /run/shm is also on /run (not a separate mount), it needs to be executable. Why do we need it executable? Marco, have you tested this upgrade path? That is /run in the initramfs and no /run on the rootfs? Is udev checking for that and No, but if the database is not copied to the initramfs then LVM will be annoyed. Which database is this? Is this something that the LVM scripts need updating to handle? It is /dev/.udev/ or /run/udev/. I do not know exactly how LVM interacts with it, just that it must be preserved. I just sent a separate mail after doing some testing. The current logic in 168-1 does appear to move /run/udev (initramfs) to /dev/.udev when /run is not present on the host. Looks good to me. 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/. -- ciao, Marco signature.asc Description: Digital signature
Bug#621803: Add support for /run directory
On Mon, Apr 18, 2011 at 07:38:41PM +0100, Roger Leigh wrote: On Mon, Apr 18, 2011 at 05:58:07PM +, maximilian attems wrote: On Mon, Apr 18, 2011 at 05:43:02PM +0100, rleigh wrote: I didn't see a patch in git, so I've attached a simple one here. This creates /run as a tmpfs, and moves the mount to the rootfs /run as done for other filesystems. please look harder next times! the git archive, don't know where you looked, so here it is: http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary checkout the branch maks/run Ah, found it, thanks. If this is all that is needed in the main initramfs, will it take long to get the /run support into unstable? It looks like this might be a prerequisite for a fully functional udev, and for other tools that store state in the initramfs, and it's a simple and safe change to make. I've raised the severity due to the /run transition being dependent on this being fixed. there is *no* point in posting trivial patches round and round. if you'd build i-t with that branch and have it *well* tested in several different configuration, then that would be a help. What different types of configuration would you like testing? I'll be happy to test, but I'm not sure exactly what you would like varying. Current tests have been on a system with root on LVM on md RAID1 using grub2. I've also tested on a powerpc wheezy system and amd64 unstable kvm VM. No issues found. If you would like any other scenarios testing, I'll be happy to accommodate you if possible. However, given the simple nature of the patch, I'm confident it's working correctly given that it's mounted unconditionally and will be moved onto the host if /run exists in all cases. By the way, could you consider adding this patch to your branch: diff --git a/init b/init index 38c8a5d..cdbfe50 100755 --- a/init +++ b/init @@ -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 Slightly simpler than the previous patch, but does the same job. Please note that I've now patched initscripts (http://paste.debian.net/114826/ and http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2011-April/004990.html) so that the filesystems mounted in the initramfs and later moved over to the root filesystem are remounted with the mount options specified in /etc/fstab (or /etc/default/tmpfs if no fstab entry exists). In consequence, it's no longer critical that the mount option defaults in the initramfs match the real root filesystem defaults, because they will always be applied by mountkernfs/ mountdevsubfs. So if you choose not to apply this, that's fine--it's just a nice to have addition; the patch as it stands without the above change is equally acceptable. Thanks for doing this. Do we have any ETA on an upload? Regards, 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. signature.asc Description: Digital signature
Bug#621803: Add support for /run directory
severity 621803 important
tags 621803 + patch
thanks
On Sat, Apr 09, 2011 at 03:08:37AM +0200, Michael Biebl wrote:
Package: initramfs-tools
Version: 0.98.8+45+g08fbe1e-1
Severity: normal
User: rle...@debian.org
Usertags: run-transition
Hi maks,
we already talked about this and you already started implementing /run
support in initramfs-tools [1], so this is merely a bug to keep track
of this transition [2].
I didn't see a patch in git, so I've attached a simple one here.
This creates /run as a tmpfs, and moves the mount to the rootfs
/run as done for other filesystems.
If this is all that is needed in the main initramfs, will it
take long to get the /run support into unstable? It looks like
this might be a prerequisite for a fully functional udev, and
for other tools that store state in the initramfs, and it's a
simple and safe change to make. I've raised the severity due
to the /run transition being dependent on this being fixed.
Many 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.
diff --git a/debian/changelog b/debian/changelog
index 441b810..329ba4b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+initramfs-tools (0.98.8run0) unstable; urgency=low
+
+ [ Roger Leigh ]
+ * Non-maintainer upload.
+ * Mount /run in initramfs and move onto root filesystem
+(Closes: #621803). This means that /run is available as a writable
+location from early boot, through to rcS and during normal system
+operation.
+
+ -- Roger Leigh rle...@debian.org Mon, 18 Apr 2011 17:23:27 +0100
+
initramfs-tools (0.98.8) unstable; urgency=high
[ maximilian attems ]
diff --git a/init b/init
index 1a178ff..1b5f75d 100755
--- a/init
+++ b/init
@@ -4,10 +4,14 @@ echo Loading, please wait...
[ -d /dev ] || mkdir -m 0755 /dev
[ -d /root ] || mkdir -m 0700 /root
+[ -d /run ] || mkdir -m 0755 /run
[ -d /sys ] || mkdir /sys
[ -d /proc ] || mkdir /proc
[ -d /tmp ] || mkdir /tmp
mkdir -p /var/lock
+
+run_tmpfs_size=20%
+mount -t tmpfs -o size=$run_tmpfs_size,mode=0755 run /run
mount -t sysfs -o nodev,noexec,nosuid none /sys
mount -t proc -o nodev,noexec,nosuid none /proc
@@ -224,6 +228,7 @@ run_scripts /scripts/init-bottom
[ $quiet != y ] log_end_msg
# Move virtual filesystems over to the real filesystem
+mount -n -o move /run ${rootmnt}/run
mount -n -o move /sys ${rootmnt}/sys
mount -n -o move /proc ${rootmnt}/proc
signature.asc
Description: Digital signature
Processed: Re: Bug#621803: Add support for /run directory
Processing commands for cont...@bugs.debian.org: severity 621803 important Bug #621803 [initramfs-tools] Add support for /run directory Severity set to 'important' from 'normal' tags 621803 + patch Bug #621803 [initramfs-tools] Add support for /run directory Added tag(s) patch. thanks Stopping processing here. Please contact me if you need assistance. -- 621803: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621803 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13031455738993.transcr...@bugs.debian.org
Bug#621803: Add support for /run directory
On Mon, Apr 18, 2011 at 05:43:02PM +0100, rleigh wrote: severity 621803 important tags 621803 + patch thanks On Sat, Apr 09, 2011 at 03:08:37AM +0200, Michael Biebl wrote: Package: initramfs-tools Version: 0.98.8+45+g08fbe1e-1 Severity: normal User: rle...@debian.org Usertags: run-transition Hi maks, we already talked about this and you already started implementing /run support in initramfs-tools [1], so this is merely a bug to keep track of this transition [2]. I didn't see a patch in git, so I've attached a simple one here. This creates /run as a tmpfs, and moves the mount to the rootfs /run as done for other filesystems. please look harder next times! the git archive, don't know where you looked, so here it is: http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary checkout the branch maks/run If this is all that is needed in the main initramfs, will it take long to get the /run support into unstable? It looks like this might be a prerequisite for a fully functional udev, and for other tools that store state in the initramfs, and it's a simple and safe change to make. I've raised the severity due to the /run transition being dependent on this being fixed. there is *no* point in posting trivial patches round and round. if you'd build i-t with that branch and have it *well* tested in several different configuration, then that would be a help. currently this /run thingy seems like a useless mass_panic(). happy hacking -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418175807.gb13...@vostochny.stro.at
Bug#621803: Add support for /run directory
On Mon, Apr 18, 2011 at 05:58:07PM +, maximilian attems wrote: On Mon, Apr 18, 2011 at 05:43:02PM +0100, rleigh wrote: I didn't see a patch in git, so I've attached a simple one here. This creates /run as a tmpfs, and moves the mount to the rootfs /run as done for other filesystems. please look harder next times! the git archive, don't know where you looked, so here it is: http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary checkout the branch maks/run Ah, found it, thanks. If this is all that is needed in the main initramfs, will it take long to get the /run support into unstable? It looks like this might be a prerequisite for a fully functional udev, and for other tools that store state in the initramfs, and it's a simple and safe change to make. I've raised the severity due to the /run transition being dependent on this being fixed. there is *no* point in posting trivial patches round and round. if you'd build i-t with that branch and have it *well* tested in several different configuration, then that would be a help. What different types of configuration would you like testing? I'll be happy to test, but I'm not sure exactly what you would like varying. Current tests have been on a system with root on LVM on md RAID1 using grub2. By the way, could you consider adding this patch to your branch: diff --git a/init b/init index 38c8a5d..c7e5909 100755 --- a/init +++ b/init @@ -25,7 +25,8 @@ 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 +run_tmpfs_size=20% +mount -t tmpfs -o nosuid,size=$run_tmpfs_size,mode=0755 none /run mkdir /run/initramfs # Export the dpkg architecture This syncs the mount options with the defaults in initscripts. Note that the nodev option was removed, because it's currently required on some systems by /etc/init.d/checkroot.sh (it uses mknod /dev/rootdev to get a device node to mount /root). I hope that we can remove this at some point, but for now mounting /run with nodev will cause some systems to break. It also mounts with noexec, since this is potentially needed for some uses of /dev/shm. Again, I hope we can remove it, but it will need testing whether or not exec perms are needed to map with PROT_EXEC on current kernels. WRT these mount options, I aim to get initscripts to remount /run with options from /etc/fstab or /etc/default/tmpfs which will allow the system to be configured to use more restrictive mount options after boot, should the admin choose. And, depending upon the configuration, we may be able to automatically determine if stricter permissions are possible (e.g. /run/shm is a separate mount, so noexec is safe to use). So this patch uses the options we know are safe, and initscripts can tighten them up later, if possible. This remounting with user-specified options will apply to all filesystems mounted in mountkernfs/mountdevsubfs. Regards, 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. signature.asc Description: Digital signature
Bug#621803: Add support for /run directory
Package: initramfs-tools Version: 0.98.8+45+g08fbe1e-1 Severity: normal User: rle...@debian.org Usertags: run-transition Hi maks, we already talked about this and you already started implementing /run support in initramfs-tools [1], so this is merely a bug to keep track of this transition [2]. I also did a quick check of all packages installing initramfs-hooks: scripts/live: ( mkdir -p /dev/.initramfs/varrun scripts/live: pidof unionfs-fuse /dev/.initramfs/varrun/sendsigs.omit || true ) scripts/local-top/cryptroot:elif [ -p /dev/.initramfs/usplash_outfifo ] [ -x /sbin/usplash_write ]; then live-boot-initramfs-tools: /usr/share/initramfs-tools/scripts/live cryptsetup: /usr/share/initramfs-tools/scripts/local-top/cryptroot This means we should update those two packages, too. cryptsetup should drop the usplash code completely and live-boot-initramfs-tools needs a separate bug report to use /run. Cheers, Michael [1] http://git.debian.org/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/maks/run [2] http://wiki.debian.org/ReleaseGoals/RunDirectory -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 14M Apr 7 18:43 /boot/initrd.img-2.6.38-2-686 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-2.6.38-2-686 root=UUID=9a6d2bd2-58d1-4a75-baff-166b8637e3cc ro -- resume RESUME=LABEL=Swap -- /proc/filesystems btrfs ext4 fuseblk -- lsmod Module Size Used by usblp 17083 0 usb_storage34951 0 uas12975 0 hid_microsoft 12497 0 usbhid 35168 0 hid59736 2 hid_microsoft,usbhid tun17663 0 sha1_generic 12511 0 ppp_mppe 12789 0 ppp_async 12845 0 ppp_generic21823 2 ppp_mppe,ppp_async slhc 12498 1 ppp_generic michael_mic12490 4 arc4 12418 2 ecb12649 2 lib80211_crypt_tkip12939 1 aes_i586 16608 1 aes_generic37066 1 aes_i586 lib80211_crypt_ccmp12677 1 sco13219 2 rfcomm 31960 0 bnep 17147 2 l2cap 35435 6 rfcomm,bnep acpi_cpufreq 12737 0 mperf 12387 1 acpi_cpufreq cpufreq_userspace 12520 0 cpufreq_stats 12670 0 cpufreq_powersave 12422 0 cpufreq_conservative13598 0 vboxnetadp 13120 0 vboxnetflt 23683 0 vboxdrv 147237 2 vboxnetadp,vboxnetflt binfmt_misc12778 1 snd_intel8x0 22287 2 snd_intel8x0m 17400 2 snd_ac97_codec 83645 2 snd_intel8x0,snd_intel8x0m ac97_bus 12462 1 snd_ac97_codec snd_pcm52774 3 snd_intel8x0,snd_intel8x0m,snd_ac97_codec snd_seq39172 0 joydev 16906 0 snd_timer 22171 2 snd_pcm,snd_seq snd_seq_device 12995 1 snd_seq pcmcia 32024 0 ipw2200 113855 0 libipw 25874 1 ipw2200 btusb 17209 2 cfg80211 106889 2 ipw2200,libipw smsc_ircc2 17427 0 lib80211 12870 4 lib80211_crypt_tkip,lib80211_crypt_ccmp,ipw2200,libipw yenta_socket 22152 0 bluetooth 50119 9 sco,bnep,rfcomm,l2cap,btusb pcmcia_rsrc17314 1 yenta_socket snd38153 15 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm,snd_seq,snd_timer,snd_seq_device rfkill 18510 4 cfg80211,bluetooth pcmcia_core17973 3 pcmcia,yenta_socket,pcmcia_rsrc parport_pc 21895 0 irda 78115 1 smsc_ircc2 psmouse45863 0 serio_raw 12758 0 pcspkr 12515 0 tpm_tis12949 0 evdev 13084 16 soundcore 12878 1 snd tpm17454 1 tpm_tis snd_page_alloc 12841 3 snd_intel8x0,snd_intel8x0m,snd_pcm tpm_bios 12799 1 tpm i2c_i801 12670 0 parport27018 1 parport_pc rng_core 12550 0 processor 26983 2 acpi_cpufreq shpchp 26653 0 battery12926 0 crc_ccitt 12331 2 ppp_async,irda ac 12552 0 container 12525 0 pci_hotplug26303 1 shpchp fuse 55640 3 autofs422558 7 ext4 251726 2 mbcache12810 1 ext4 jbd2 55701 1 ext4 crc16 12327 2 l2cap,ext4 btrfs 419245 0 zlib_deflate 21186 1 btrfs crc32c 12576 1 libcrc32c 12394 1 btrfs radeon641556 2 sg 21385 0 sd_mod
