Debian Bug report logs - #620995
udev is making use of /run when this is not yet supported

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: udev is making use of /run when this is not yet supported

Date: Tue, 05 Apr 2011 19:24:15 +0100

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  libc6                        2.11.2-13   Embedded GNU C Library: Shared lib
ii  libselinux1                  2.0.98-1    SELinux 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-1    Linux USB utilities

udev suggests no packages.

-- debconf information excluded

Message #10 received at 620995@bugs.debian.org (full text, mbox, reply):

From: md@Linux.IT (Marco d'Itri)

To: Roger Leigh <rleigh@debian.org>, 620995@bugs.debian.org

Subject: Re: Bug#620995: udev is making use of /run when this is not yet supported

Date: Wed, 6 Apr 2011 00:59:56 +0200

[Message part 1 (text/plain, inline)]

On Apr 05, Roger Leigh <rleigh@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 (application/pgp-signature, inline)]

Message #15 received at 620995@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Marco d'Itri <md@Linux.IT>

Cc: Roger Leigh <rleigh@debian.org>, 620995@bugs.debian.org

Subject: Re: Bug#620995: udev is making use of /run when this is not yet supported

Date: Wed, 6 Apr 2011 00:22:29 +0100

[Message part 1 (text/plain, inline)]

On Wed, Apr 06, 2011 at 12:59:56AM +0200, Marco d'Itri wrote:
> On Apr 05, Roger Leigh <rleigh@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 (application/pgp-signature, inline)]

Message #20 received at 620995@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@Linux.IT>

To: Roger Leigh <rleigh@codelibre.net>

Cc: 620995@bugs.debian.org

Subject: Re: Bug#620995: udev is making use of /run when this is not yet supported

Date: Wed, 6 Apr 2011 01:33:00 +0200

[Message part 1 (text/plain, inline)]

On Apr 06, Roger Leigh <rleigh@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 (application/pgp-signature, inline)]

Message #27 received at 620995@bugs.debian.org (full text, mbox, reply):

From: Roger Leigh <rleigh@codelibre.net>

To: Marco d'Itri <md@Linux.IT>

Cc: 620995@bugs.debian.org

Subject: Re: Bug#620995: udev is making use of /run when this is not yet supported

Date: Wed, 6 Apr 2011 09:45:20 +0100

[Message part 1 (text/plain, inline)]

On Wed, Apr 06, 2011 at 01:33:00AM +0200, Marco d'Itri wrote:
> On Apr 06, Roger Leigh <rleigh@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 (application/pgp-signature, inline)]

Message #32 received at 620995-close@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@linux.it>

To: 620995-close@bugs.debian.org

Subject: Bug#620995: fixed in udev 167-2

Date: Mon, 11 Apr 2011 01:34:33 +0000

Source: udev
Source-Version: 167-2

We believe that the bug you reported is fixed in the latest version of
udev, which is due to be installed in the Debian FTP archive:

gir1.2-gudev-1.0_167-2_i386.deb
  to main/u/udev/gir1.2-gudev-1.0_167-2_i386.deb
libgudev-1.0-0_167-2_i386.deb
  to main/u/udev/libgudev-1.0-0_167-2_i386.deb
libgudev-1.0-dev_167-2_i386.deb
  to main/u/udev/libgudev-1.0-dev_167-2_i386.deb
libudev-dev_167-2_i386.deb
  to main/u/udev/libudev-dev_167-2_i386.deb
libudev0_167-2_i386.deb
  to main/u/udev/libudev0_167-2_i386.deb
udev-gtk-udeb_167-2_i386.udeb
  to main/u/udev/udev-gtk-udeb_167-2_i386.udeb
udev-udeb_167-2_i386.udeb
  to main/u/udev/udev-udeb_167-2_i386.udeb
udev_167-2.diff.gz
  to main/u/udev/udev_167-2.diff.gz
udev_167-2.dsc
  to main/u/udev/udev_167-2.dsc
udev_167-2_i386.deb
  to main/u/udev/udev_167-2_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 620995@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marco d'Itri <md@linux.it> (supplier of updated udev package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 11 Apr 2011 02:31:04 +0200
Source: udev
Binary: udev libudev0 libudev-dev udev-udeb udev-gtk-udeb libgudev-1.0-0 gir1.2-gudev-1.0 libgudev-1.0-dev
Architecture: source i386
Version: 167-2
Distribution: unstable
Urgency: high
Maintainer: Marco d'Itri <md@linux.it>
Changed-By: Marco d'Itri <md@linux.it>
Description: 
 gir1.2-gudev-1.0 - libgudev-1.0 introspection data
 libgudev-1.0-0 - GObject-based wrapper library for libudev
 libgudev-1.0-dev - libgudev-1.0 development files
 libudev-dev - libudev development files
 libudev0   - libudev shared library
 udev       - /dev/ and hotplug management daemon
 udev-gtk-udeb - libudev shared library (udeb)
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 620995 621036 622180
Changes: 
 udev (167-2) unstable; urgency=high
 .
   * Only use /run if it is a tmpfs. (Closes: #621036, #620995)
   * Do not create persistent rules for Hyper-V network interfaces.
     (Closes: #622180)
Checksums-Sha1: 
 998d922f2c361d17fcbf5ef347da9a36ce70a781 1441 udev_167-2.dsc
 a59490348ed778f5e1ce54d9f68897dd19a862f0 86344 udev_167-2.diff.gz
 75ee1f598f97869f8ab8b4e94aca2efad0175012 520022 udev_167-2_i386.deb
 557280c824610cc6317f225bc99309180b5d9283 118856 libudev0_167-2_i386.deb
 32255d47c3a08c629542cbb01a6156c5027554c6 56556 libudev-dev_167-2_i386.deb
 1474470103b01a58a297552b1958e36df212f289 183878 udev-udeb_167-2_i386.udeb
 17e23f687ea44635e98e25c19133ea9ebe6fbf07 38560 udev-gtk-udeb_167-2_i386.udeb
 e8117288d9d4061673c928aa2456ba6e1cb6f0d3 104032 libgudev-1.0-0_167-2_i386.deb
 e7ba7551b71730678fbe13aa1680234737b68b9d 2958 gir1.2-gudev-1.0_167-2_i386.deb
 8d09b3f11a93ad3b64a89dc5b68cad9b2357d8eb 44254 libgudev-1.0-dev_167-2_i386.deb
Checksums-Sha256: 
 a7484afc5cb8934761eaaecf753c4f83d85bd956bd7f18c8b376d0ce580cdee2 1441 udev_167-2.dsc
 37fbff5fff24b981c0c8db2b7421fad9f78b4c995284c8b30cf6ac18f1ffa50d 86344 udev_167-2.diff.gz
 4ff9a754db3ebe05a9d64ce56d811d6b2486dcdccbd34261d60901591b3b7396 520022 udev_167-2_i386.deb
 72e978798446c4dfbd30036c5d6e4e5bdea40d4a91d78f28d8fdad33be608961 118856 libudev0_167-2_i386.deb
 2e439b308569df2a28cb17bfa32052ed12859951307e6eb056cb7583c9d2ae02 56556 libudev-dev_167-2_i386.deb
 0ea1fa7fd9ede5bbcf500c3d7cd6df83810327f75a4c1a2d8ed50aa1625cdd4f 183878 udev-udeb_167-2_i386.udeb
 13ff759fa7e0ec4b54174b987b1c512af8f782e1574b94c10ff4c75338fa230c 38560 udev-gtk-udeb_167-2_i386.udeb
 0fbcb106f7517f563b1b95b910be148d8ab9befc806a65a768a50f3d54b3650d 104032 libgudev-1.0-0_167-2_i386.deb
 61635ea2ea2b361cf00e957c1be4eb97e858064cb3710a07f2ee66560784e92a 2958 gir1.2-gudev-1.0_167-2_i386.deb
 b4d1d42ab1abf88e1d2882597c6c83edca9f4a7a09eda5e733356907d27ac87c 44254 libgudev-1.0-dev_167-2_i386.deb
Files: 
 2b47c2f58b4c5211ae25eab081786d58 1441 admin important udev_167-2.dsc
 6464ed378063125ef43597c6b3c52c0a 86344 admin important udev_167-2.diff.gz
 a98ef7ca62fa280132e710c0834c6fe9 520022 admin important udev_167-2_i386.deb
 f491d3b8deac178d3684b6c2653af6c6 118856 libs important libudev0_167-2_i386.deb
 50d02fbab281c28443b220dc07b7c4cb 56556 libdevel optional libudev-dev_167-2_i386.deb
 e15805f832763d2f0c6b252fadda191a 183878 debian-installer important udev-udeb_167-2_i386.udeb
 34ed1f736ec685b96c58ef97908e06e4 38560 debian-installer optional udev-gtk-udeb_167-2_i386.udeb
 ea75f56092f466035f4fe54fb3560b11 104032 libs optional libgudev-1.0-0_167-2_i386.deb
 17e5fa7198a4ab2791066b7adceb1529 2958 libs optional gir1.2-gudev-1.0_167-2_i386.deb
 a5783198c96ae2268aa57b850ec4edd7 44254 libdevel optional libgudev-1.0-dev_167-2_i386.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk2iUtcACgkQFGfw2OHuP7Gu/wCfa7HXAKHk0gZ5bJYDvHwBHV+A
3XYAnR998EQwrkJgYBF4TwJbM+RGxx5Y
=XJiO
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.