On Sun, Apr 17, 2011 at 01:16:49PM +0200, Marco d'Itri wrote: > On Apr 17, rleigh <rle...@codelibre.net> wrote: > > > The tradeoff here is that if /run is present, udev is broken. That > It is not supposed to, and so far you are the only one who reported this. > Are you sure that you do not have a /run/udev on the underlying root > filesystem?
There is no /run/udev on the root filesystem; I've checked, and it is entirely empty. However, even if there was, udev should not break as a result. Also, the reason I'm reporting it is because I'm the one who wrote the /run support for initscripts and tested it extensively. Other people won't have the new initscripts installed by default yet--I'm telling you what is currently broken which other people haven't encountered yet (but will once it moves from experimental to testing). > > But you can not use /run without a versioned initscripts dependency. > You keep saying so, but except for an alleged bug you have not really > explained why other that "I decided you have to do this". Yes, I have. It's detailed on the wiki page, and I've tried to explain several times. /run is provided by initscripts on install as part of the package contents as an empty directory. It must be provided at this point because at boot the rootfs might be read only. /run does not get anything mounted on it until initscripts has been configured (the postinst is run). As a result, /run can't be used until initscripts has been configured. If the udev daemon is restarted between initscripts being unpacked and configured (which is quite possible for a squeeze→wheezy upgrade), let alone for a normal upgrade, then things will break. Your check for a tmpfs is badly broken. Firstly, it might not be a tmpfs. It might be a bind mount. It might be another sort of filesystem. It might be a chroot environment, in which case you will cripple the host system when you move the contents of /dev/.udev into the chroot. Your check for a writable /run is also broken. If you add the versioned dependency on initscripts, all these problems go away. /run will be guaranteed to be present, and you can use it without needing all these buggy checks. If you want to fall back on /dev/.udev for safety, then do this: - add a versioned dependency on initscripts to ensure /run is present and usable - check if /run is writable (create and remove a temporary file) and fall back if it is not. Unless the system is badly broken, this check will always succeed. Checking if /run is writable on its own is broken, because you might well find something is going to be mounted over the top shortly after, making your files inaccesible. The initscripts dependency ensures this does not happen. Checking if /run is a tmpfs or some other particular filesystem does not protect against this--it's an assumption that may well not turn out to be true in the future, or if someone alters their system from the defaults. Only the initscripts dependency ensures /run is set up (that's its job), and saves you the need to implement what are essentially guesses about what the system is capable of, and as we are seeing are often incorrect. We added the /run setup in the initscripts postinst specifically to allow reliable and easy migration to /run for other packages, and without it you are not getting reliable results (and the udev breakage is a prime example of why not doing this is a bad idea). So, suggestion for fixing: - add a versioned initscripts dependency - in postinst, don't migrate files to /run if in a chroot - in initscript, check if /run is writable, else fall back to /dev/.udev; nothing else is needed with the initscripts dependency This will ensure a reliable, smooth transition without breakage. 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
