Bug#620995: udev is making use of /run when this is not yet supported
On Wed, Apr 06, 2011 at 01:33:00AM +0200, Marco d'Itri wrote: On Apr 06, Roger Leigh rle...@codelibre.net wrote: /run has been added to base-files today (6.2). initscripts will mount a tmpfs there shortly (#620191), but for the moment it's just an empty directory. Looks like this one is the real bug: systems should not have a /run unless it will actually be available as such. Why should base-files not depend on the newer initscripts? Other programs could behave like udev does. The plan for transition is that packages wanting to use or transition to use /run *must* have a versioned initscripts dependency. base-files can not depend on initscripts, because it will hinder migration to systemd and other init systems (which will themselves initially require initscripts, but plan on implementing it themselves after wheezy). Given its job, I also doubt that base-files is allowed to depend on much else; we have done it the other way around, having initscript depend on base-files = 6.2. We have spent the last week implementing /run in initscripts and planning how to do the transition. We decided that a versioned initscripts was the way to go. I was going to post a detailed mail to debian-devel-announce once initscripts was uploaded decribing all this, but udev has jumped the gun and started using it before we've got all the uploads done! use /run if a tmpfs is also mounted there. The way to do that is to depend upon initscripts (= xxx) once it's uploaded. Is a dependency even enough to handle upgrades, or would it need to be a pre-depends? A dependency will be sufficient; initscript sets up a working /run in its postinst. initscripts should be uploaded soon, and it will be fine to use /run then, but for now it would be best if udev could stop using it. 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
Bug#620995: udev is making use of /run when this is not yet supported
Package: udev Version: 167-1 Severity: important Hi Marco, The new udev is creating files in /run (if present): % ls -l /run total 1 drwxr-xr-x 7 root root 1024 Apr 5 19:03 udev % ls -l /run/udev total 19 drwxr-xr-x 2 root root 5120 Apr 5 19:03 data drwxr-xr-x 121 root root 10240 Apr 5 19:03 links -rw-r--r-- 1 root root 8 Apr 5 19:03 queue.bin drwxr-xr-x 2 root root 1024 Apr 5 19:03 rules.d drwxr-xr-x 3 root root 1024 Apr 5 19:03 tags drwxr-xr-x 2 root root 1024 Apr 5 19:03 watch While it will be fine for udev to do this when /run is supported in initscripts, right now it's not. From today, base-files will add /run, but we're currently waiting on initscripts to actually start mounting a tmpfs there. As a result, udev is going to start putting things there on the root filesystem, and this is going to interfere with upgrades since we'll end up mounting stuff over the top, hiding the udev directory. It might also break things, given that it might well be read only. Would it be possible to explicitly disable this for the time being? Once initscripts is updated, it should be possible for udev to add a versioned dependency on = the initscripts version adding /run support, and then using /run can be made unconditional since it will be guaranteed to be present. Many thanks, Roger -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (550, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages udev depends on: ii debconf [debconf-2.0]1.5.38 Debian configuration management sy ii libc62.11.2-13 Embedded GNU C Library: Shared lib ii libselinux1 2.0.98-1SELinux runtime shared libraries ii libudev0 167-1 libudev shared library ii libusb-0.1-4 2:0.1.12-17 userspace USB programming library ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip ii util-linux 2.17.2-9.1 Miscellaneous system utilities Versions of packages udev recommends: ii pciutils 1:3.1.7-8 Linux PCI Utilities ii usbutils 1:001-1Linux USB utilities udev suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620995: udev is making use of /run when this is not yet supported
On Apr 05, Roger Leigh rle...@debian.org wrote: The new udev is creating files in /run (if present): Indeed. While it will be fine for udev to do this when /run is supported in initscripts, right now it's not. So how could /run be present if it is not supported by the system init scripts? As a result, udev is going to start putting things there on the root filesystem, and this is going to interfere with upgrades No: /run needs to be writeable when udev is started, this happens before / is remounted rw so udev will not use it even if the empty mount point exists at boot time. Would it be possible to explicitly disable this for the time being? Only if you can show a situation in which something will break because of the current code. Cases in which the local admin caused the breakage do not count. -- ciao, Marco signature.asc Description: Digital signature
Bug#620995: udev is making use of /run when this is not yet supported
On Wed, Apr 06, 2011 at 12:59:56AM +0200, Marco d'Itri wrote: On Apr 05, Roger Leigh rle...@debian.org wrote: While it will be fine for udev to do this when /run is supported in initscripts, right now it's not. So how could /run be present if it is not supported by the system init scripts? /run has been added to base-files today (6.2). initscripts will mount a tmpfs there shortly (#620191), but for the moment it's just an empty directory. As a result, udev is going to start putting things there on the root filesystem, and this is going to interfere with upgrades No: /run needs to be writeable when udev is started, this happens before / is remounted rw so udev will not use it even if the empty mount point exists at boot time. I certainly found udev using /run on my system. I haven't restarted it since the new udev was uploaded. I think that what may have happened here is that udev was restarted on upgrade because / was writable and /run existed, it started using it. Would it be possible to explicitly disable this for the time being? Only if you can show a situation in which something will break because of the current code. Cases in which the local admin caused the breakage do not count. base-files provides /run as an empty directory. When udev is upgraded (restarted), it will start using it. When initscripts is upgraded using the patch in #620191, it will set up a couple of mounts over the top of /run, hiding the /run/udev directory. This will probably cause problems for udev since they will be inaccessible. Restarting udev will correct this; and restarting the system will also correct it (a tmpfs will be mounted), but it will cause breakage for running systems; udev should not have used /run when it isn't actually functional yet. The problem is that udev is using /run if it's present and writable, but this check is not sufficient. It should only use /run if a tmpfs is also mounted there. The way to do that is to depend upon initscripts (= xxx) once it's uploaded. I think the best solution here would be to comment out /run use temporarily, and remove /run/udev in the postinst if present in order to clean up the rootfs. Once that is done and the new initscripts is in place, you can uncomment the /run use and remove the postinst rm and add a versioned depends upon initscripts. At this point, initscripts will guarantee /run is set up and working, and it will be safe to use just like you're doing now, but with a tmpfs backing store. 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#620995: udev is making use of /run when this is not yet supported
On Apr 06, Roger Leigh rle...@codelibre.net wrote: /run has been added to base-files today (6.2). initscripts will mount a tmpfs there shortly (#620191), but for the moment it's just an empty directory. Looks like this one is the real bug: systems should not have a /run unless it will actually be available as such. Why should base-files not depend on the newer initscripts? Other programs could behave like udev does. use /run if a tmpfs is also mounted there. The way to do that is to depend upon initscripts (= xxx) once it's uploaded. Is a dependency even enough to handle upgrades, or would it need to be a pre-depends? -- ciao, Marco signature.asc Description: Digital signature
