Bug#622309: udev: Network, sound and X input broken
notfound 622309 168-1 notfound 622309 168-2 thanks You are right, I'm sorry. It looks more like #624469 now. I will present my findings there. Am Mittwoch, 11. Mai 2011 schrieb Marco d'Itri: So it obviously cannot be the same bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
This bug still exists in the latest unstable version of udev on my system. At boot time, it gives the following output (transcribed from a photo taken with my cellphone camera): Starting the hotplug events dispatcher: udevdudevd[435]: error: directory '/run/udev/ not writable, for now falling back to '/dev/.udev/' udevd[435]: bind failed: Address already in use error binding udev control socket udevd[435]: error binding control socket failed! If I boot to maintenance mode and log in with the root password, then manually stop and restart udev it functions and boots up correctly, however. -- Rens Houben |opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP key at http://proteus.systemec.nl/~shadur/shadur.key.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
On May 12, Rens Houben sha...@systemec.nl wrote: This bug still exists in the latest unstable version of udev on my system. No, it does not. This is about #624469: udevd[435]: bind failed: Address already in use error binding udev control socket udevd[435]: error binding control socket failed! -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
found 622309 168-1 found 622309 168-2 thanks I have the same problem again with both versions 168-1 and 168-2. And I double checked there is no /run. There must be yet another trigger. Downgrading to 167-3 from snapshot ensures a working computer again. Regards, Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
On May 11, Matthias Dellweg 2...@gmx.de wrote: I have the same problem again with both versions 168-1 and 168-2. And I double checked there is no /run. So it obviously cannot be the same bug. There must be yet another trigger. Then find out what it is. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
I have installed the 168-1 and it broke my X input. I did not have /run directory but it was still broken. I have downgrade to 161-1 following babilen i cthuluh guides this packages: libgudev-1.0-0_161-1_amd64.deb libudev0_161-1_amd64.deb udev_161-1_amd64.deb And that fixed the problem for me. Thanks :) -- René -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
On Tue, Apr 19, 2011 at 03:37:50PM +0200, Marco d'Itri wrote: On Apr 19, rleigh rle...@codelibre.net wrote: (eth0 is configured here after changing the config to force it to use dhcp). Since the interface is already up, maybe that's the reason the events aren't generated. So I guess the question now is, what's bringing up the interface before ifupdown does? Could it be udev? Or something else in early boot or the initramfs? Definitely not udev. uevents for wired interfaces are generated when they appear and disappear, they do not follow link state. If eth1 is up but is not mentioned in interfaces then I have really no ideas, but if they are both configured in interfaces to use dhcp and after the boot they are up but dhcp did not work then the problem is dhcpd failing. I highly recommend that you boot the system with init=/bin/bash and manually run each rcS.d init script to see exactly what is happening. Finally pinned down the cause on my system. If the dnet-common package is installed, this triggers installation of the decnet kernel module at boot. Not sure whether the init script or the kernel module cause the problem, but when they are installed, DHCP doesn't work, and when removed, I get working DHCP at reboot. It looks like dnet-common can mess with the NIC's MAC address, which might be a potential issue. Whatever the reason, it's not an issue with udev or ifupdown. 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#622309: udev: Network, sound and X input broken
On Tue, Apr 19, 2011 at 03:37:50PM +0200, Marco d'Itri wrote: On Apr 19, rleigh rle...@codelibre.net wrote: (eth0 is configured here after changing the config to force it to use dhcp). Since the interface is already up, maybe that's the reason the events aren't generated. So I guess the question now is, what's bringing up the interface before ifupdown does? Could it be udev? Or something else in early boot or the initramfs? Definitely not udev. uevents for wired interfaces are generated when they appear and disappear, they do not follow link state. If eth1 is up but is not mentioned in interfaces then I have really no ideas, but if they are both configured in interfaces to use dhcp and after the boot they are up but dhcp did not work then the problem is dhcpd failing. I highly recommend that you boot the system with init=/bin/bash and manually run each rcS.d init script to see exactly what is happening. Looks like it's fine until /etc/rcS.d/S16networking. So definitely not a udev issue. Probably a bad interaction with ifupdown and /dev/shm availability, though I'll need to do some more checking to confirm and fix this. 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#622309: udev: Network, sound and X input broken
On Apr 18, Marco d'Itri m...@linux.it wrote: As a result, I am still unconvinced that the udev logic is correct. You can test your theory by rebuilding udev without the use_run_tmpfs patch, I cannot reproduce your problem and apparently nobody else can. Are there any news? The current status is that 167-2 is known not work correctly only in the following cases: - if /etc/network/run/ is a symlink - when installed your system -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Tue, Apr 19, 2011 at 12:48:06PM +0200, Marco d'Itri wrote: On Apr 18, Marco d'Itri m...@linux.it wrote: As a result, I am still unconvinced that the udev logic is correct. You can test your theory by rebuilding udev without the use_run_tmpfs patch, I cannot reproduce your problem and apparently nobody else can. Are there any news? The current status is that 167-2 is known not work correctly only in the following cases: - if /etc/network/run/ is a symlink - when installed your system I've tried to track this down further, but without success. In addition to having initscripts from experimental installed, I also installed initramfs-tools (branch maks/run with my patch from #621803). This makes /run get mounted in the early initramfs, and is then moved to the rootfs /run. udev is making use of it (no /dev/.udev; /run/udev is created and used). I've also updated /etc/init.d/mountdevsubfs.sh to symlink /dev/shm to /run/shm as soon as it is mounted, so it's never a dangling link or nonexistent. However, given that /etc/network/run wasn't symlinked there on my system, this made no difference. I also tried symlinking /etc/network/run to /run/network. This works perfectly, but networking is still broken. I have both eth0 and eth1 interfaces. Both are brought up, but there's no dhcp query/lease taken on eth0 as expected (only eth0 is connected). Overall, with or without the /run in initramfs, udev appears to be working correctly on my system. ifupdown creates /etc/network/run if a symlink, and uses it directly if just a directory. ifdown eth0 ifup eth0 cause a dhcp query/lease and it's then fully functional. So if this is a defect in udev, it's not obvious what it is--it appears to be working fine. Maybe there's some altered behaviour in ifupdown if /run is present? But again, it's not an issue with /etc/network/run/[ifstate], which is created correctly under all configurations. It simply appears it's just not automatically obtaining a lease. Since I have allow-hotplug eth0 iface eth0 inet dhcp could it be related to not getting a hotplug event from udev? 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#622309: udev: Network, sound and X input broken
On Tue, Apr 19, 2011 at 01:53:19PM +0100, Roger Leigh wrote: On Tue, Apr 19, 2011 at 12:48:06PM +0200, Marco d'Itri wrote: On Apr 18, Marco d'Itri m...@linux.it wrote: As a result, I am still unconvinced that the udev logic is correct. You can test your theory by rebuilding udev without the use_run_tmpfs patch, I cannot reproduce your problem and apparently nobody else can. Are there any news? The current status is that 167-2 is known not work correctly only in the following cases: - if /etc/network/run/ is a symlink - when installed your system It simply appears it's just not automatically obtaining a lease. Since I have allow-hotplug eth0 iface eth0 inet dhcp could it be related to not getting a hotplug event from udev? I switched allow-hotplug eth0 to auto eth0 and rebooted. It then gets a dhcp lease without trouble. So it would appear to be an issue with hotplug. One things that looks different is that both eth0 and eth1 are up but unconfigured: eth0 Link encap:Ethernet HWaddr aa:00:04:00:0a:04 inet addr:192.168.1.5 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::222:15ff:fe1b:4d10/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:764 errors:0 dropped:0 overruns:0 frame:0 TX packets:821 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:125215 (122.2 KiB) TX bytes:89192 (87.1 KiB) Interrupt:17 eth1 Link encap:Ethernet HWaddr aa:00:04:00:0a:04 inet6 addr: fe80::a800:4ff:fe00:a04/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:18 (eth0 is configured here after changing the config to force it to use dhcp). Since the interface is already up, maybe that's the reason the events aren't generated. So I guess the question now is, what's bringing up the interface before ifupdown does? Could it be udev? Or something else in early boot or the initramfs? 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#622309: udev: Network, sound and X input broken
On Apr 19, rleigh rle...@codelibre.net wrote: (eth0 is configured here after changing the config to force it to use dhcp). Since the interface is already up, maybe that's the reason the events aren't generated. So I guess the question now is, what's bringing up the interface before ifupdown does? Could it be udev? Or something else in early boot or the initramfs? Definitely not udev. uevents for wired interfaces are generated when they appear and disappear, they do not follow link state. If eth1 is up but is not mentioned in interfaces then I have really no ideas, but if they are both configured in interfaces to use dhcp and after the boot they are up but dhcp did not work then the problem is dhcpd failing. I highly recommend that you boot the system with init=/bin/bash and manually run each rcS.d init script to see exactly what is happening. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Sun, Apr 17, 2011 at 08:50:23PM +0200, Marco d'Itri wrote: On Apr 16, rleigh rle...@codelibre.net wrote: Maybe your initramfs was not rebuilt to include the code which mounts /run? Why would that be required? /run is mounted by mountkernfs, before udevd is started. Because if /run in the initramfs does not exist or is not a tmpfs then /dev/.udev/ will be used instead. Well, the logic must be faulty, because it *is* using /run, and it *is* broken. The logic is correct and works as intended, networking does not work anymore on your system because /etc/network/run/ is a symlink to /dev/shm/network/ which does not exist anymore after installing the new initscripts package (because S12ifupdown is run before the /dev/shm/ link is created or something like this). /etc/network/run is a directory, not a symlink, on my system. While it's possible that something might fail if /dev/shm does not exist, which will be the case until mountall has run, this is still well before ifupdown runs and creates the run directory. (In the case of /dev/shm, we can make this happen at the point /run/shm is mounted unlike for the other filesystems; it looks like for dependency-based boot, this might be required. But on my system, this is /not/ the cause of the networking failure.) As a result, I am still unconvinced that the udev logic is correct. You can test this theory by adding the appropriate mkdir command to /etc/init.d/networking or just looking at the error messages displayed by the init script. I'll double check if any errors occur. But as I mentioned above, this isn't because /etc/network/run does not exist. I will open a separate bug for /run not being present in the initramfs, which leads to to /dev/.udev/ being used and breakage in LVM. Thanks. While making /run available in the initramfs is a good thing (#621803), udev should not break if it is unavailable. udev should work correctly irrespectively of what the initramfs does. If the initramfs makes /run available, udev should use it of course, but it should correctly fall back to e.g. /dev/.udev otherwise. It should cope with all these cases: 1) No /run in initramfs, no /run on system 2) No /run in initramfs, /run on system 3) /run in initramfs and /run on system A versioned initscripts dependency will ensure (1) will never happen, but (2) and (3) are both possibilities depending upon if the user rebuild their initramfs and/or upgraded initramfs-tools, so both need to be handled. 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#622309: udev: Network, sound and X input broken
On Apr 18, rleigh rle...@codelibre.net wrote: (In the case of /dev/shm, we can make this happen at the point /run/shm is mounted unlike for the other filesystems; it looks like for dependency-based boot, this might be required. But on my system, this is /not/ the cause of the networking failure.) It definitely is on my system. As a result, I am still unconvinced that the udev logic is correct. You can test your theory by rebuilding udev without the use_run_tmpfs patch, I cannot reproduce your problem and apparently nobody else can. Thanks. While making /run available in the initramfs is a good thing (#621803), udev should not break if it is unavailable. udev should work correctly irrespectively of what the initramfs does. If the The best I can do is move /dev/.udev/ to /run/udev/ . -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Sun, Apr 17, 2011 at 01:37:27AM +0200, Marco d'Itri wrote: On Apr 16, rleigh rle...@codelibre.net wrote: Whether or not /run is a tmpfs or not is *irrelevant* to whether or not udev should use it. The choice of filesystem is entirely up to the admin, and while the default is to use tmpfs, it is not udev's business to alter its behaviour depending on the filesystem in use at that location. That's *utterly broken*. I consider it an acceptable tradeoff, I can remove the code when udev will depend on the new sysvinit. The tradeoff here is that if /run is present, udev is broken. That is not acceptable. You should not be using /run at all, unless you have a versioned initscripts dependency. udev needs a dependency on initscripts, and then it can *unconditionally* make use of /run without relying on broken hacks. I have no plan to disable the /dev/.udev/ fallback unless it will be clearly proven that it cannot be viable (hint: the alternative is the daemon exiting with an error, which is supposed to be worse). Having the fallback is fine. But you can not use /run without a versioned initscripts dependency. You're trying to be too clever, and making assumptions that are not warranted. But so far you have not been able to show what I did wrong. I like to fix bugs, not symptoms. I've shown you what the cause of the problem is. I don't know exactly what is broken. I expect that it is, in part or in full, the broken checks for /run. The initscripts package is available in experimental. You could install it and find out, please. I'm not the udev expert here, but you are. 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#622309: udev: Network, sound and X input broken
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? 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. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
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
Bug#622309: udev: Network, sound and X input broken
On Apr 16, rleigh rle...@codelibre.net wrote: Maybe your initramfs was not rebuilt to include the code which mounts /run? Why would that be required? /run is mounted by mountkernfs, before udevd is started. Because if /run in the initramfs does not exist or is not a tmpfs then /dev/.udev/ will be used instead. Well, the logic must be faulty, because it *is* using /run, and it *is* broken. The logic is correct and works as intended, networking does not work anymore on your system because /etc/network/run/ is a symlink to /dev/shm/network/ which does not exist anymore after installing the new initscripts package (because S12ifupdown is run before the /dev/shm/ link is created or something like this). You can test this theory by adding the appropriate mkdir command to /etc/init.d/networking or just looking at the error messages displayed by the init script. I will open a separate bug for /run not being present in the initramfs, which leads to to /dev/.udev/ being used and breakage in LVM. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Tue, Apr 12, 2011 at 11:06:46AM +0200, Marco d'Itri wrote: On Apr 12, Krzysztof Krzyżaniak e...@wikia-inc.com wrote: - after boot there is /run folder, it's regular filesystem not tmpfs. Then rm -rf /run/udev/ and everything will work fine, this behaviour is expected. This is resulting in massive breakage on systems with the new initscripts implementing /run. Please fix it, as asked! Just don't make *any* use of /run until the new initscripts is uploaded and /run is correctly set up. It's that simple. Please see http://wiki.debian.org/ReleaseGoals/RunDirectory for a guide on how to implement migration to /run. Without an versioned initscripts dependency, you can't rely on /run being set up /and/ functional. Checking it's a tmpfs is not enough: it might not be a tmpfs, and / might be a tmpfs as well, so we might still mount something on top. Without the versioned initscripts dependency, all bets are off, and this breakage is the consequence. Example of breakage: udev 167-2 initscripts 2.88dsf-13.3 (http://people.debian.org/~rleigh/run/sysvinit_2.88dsf-13.3.dsc) initscripts provides /run, and this is set up during boot: tmpfs on /lib/init/rw type tmpfs (rw,nosuid,size=5242880,mode=755) tmpfs on /run type tmpfs (rw,nosuid,size=10%,mode=755) tmpfs on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880,mode=1777) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=20%,mode=1777) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) udev on /dev type tmpfs (rw,mode=0755) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,relatime,size=1639608k) So, we have a working /run: % ls /run ... console dictd.pid postgresqludev ConsoleKit gpm.pidpppd2.tdb utmp ... udev fails to bring up networking, as originally reported in this bug. udev is using /run: % ls -l /run/udev total 4 drwxr-xr-x 2 root root 4300 Apr 16 10:30 data drwxr-xr-x 157 root root 3140 Apr 16 10:30 links -rw-r--r-- 1 root root 548 Apr 16 10:30 queue.bin drwxr-xr-x 2 root root 60 Apr 16 09:02 rules.d drwxr-xr-x 3 root root 60 Apr 16 09:02 tags drwxr-xr-x 2 root root 740 Apr 16 09:02 watch udev is also using /dev/.udev: % ls -l /dev/.udev total 0 drwxr-xr-x 2 root root 2780 Apr 16 09:02 data drwxr-xr-x 70 root root 1400 Apr 16 09:02 links drwxr-xr-x 2 root root 40 Apr 16 09:02 rules.d drwxr-xr-x 2 root root 260 Apr 16 09:02 watch Not sure why udev is broken; it's using both locations from the look of things. Maybe something it needs has been written to one and it's not present in the other or something? Either way, please fix udev to work with the above sysvinit package so that udev doesn't break everyone's systems when it gets uploaded. 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#622309: udev: Network, sound and X input broken
On Apr 16, rleigh rle...@codelibre.net wrote: Not sure why udev is broken; it's using both locations from the look of things. Maybe something it needs has been written to one and it's not present in the other or something? rm -rf /run/udev/ ffs! It will not be created again by -2 unless /run really is a tmpfs. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Sat, Apr 16, 2011 at 02:34:02PM +0200, Marco d'Itri wrote: On Apr 16, rleigh rle...@codelibre.net wrote: Not sure why udev is broken; it's using both locations from the look of things. Maybe something it needs has been written to one and it's not present in the other or something? rm -rf /run/udev/ ffs! It will not be created again by -2 unless /run really is a tmpfs. Marco, please read what I wrote. I provided all the detail to show what is needed to reproduce the breakage. If you want any more, I'll provide it. /run really is a tmpfs. udev is broken. ** udev is broken when /run is a tmpfs ** How clearly do I have to say this! This is broken, right now, with 167-2 in unstable. 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#622309: udev: Network, sound and X input broken
On Apr 16, rleigh rle...@codelibre.net wrote: Not sure why udev is broken; it's using both locations from the look of things. Maybe something it needs has been written to Maybe your initramfs was not rebuilt to include the code which mounts /run? Either way, please fix udev to work with the above sysvinit package so that udev doesn't break everyone's systems when it gets uploaded. Fix how? You say you already installed the new sysvinit package which mounts the tmpfs, so how would depending on it change anything? Anyway, I will not do any changes until I will know why the current package is not working. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Sat, Apr 16, 2011 at 03:15:33PM +0200, Marco d'Itri wrote: On Apr 16, rleigh rle...@codelibre.net wrote: Not sure why udev is broken; it's using both locations from the look of things. Maybe something it needs has been written to Maybe your initramfs was not rebuilt to include the code which mounts /run? Why would that be required? /run is mounted by mountkernfs, before udevd is started. This is guaranteed through the # Required-Start:mountkernfs in /etc/init.d/udev Either way, please fix udev to work with the above sysvinit package so that udev doesn't break everyone's systems when it gets uploaded. Fix how? You say you already installed the new sysvinit package which mounts the tmpfs, so how would depending on it change anything? Anyway, I will not do any changes until I will know why the current package is not working. Well, it would probably be best if you could install the updated sysvinit package yourself and find out, since you're the udev expert here. My knowledge of udev is limited. I will be uploading it to experimental later today, and it will require an updated udev that doesn't break before it can go into unstable. But as said repeatedly, you simply *can* *not* use /run without a versioned dependency on initscripts. This is because there is a window between initscripts being unpacked (/run created) and being configured (/run gets a tmpfs mounted). Without the versioned dependency, you could find yourself using it when it's not actually usable, which will cause breakage. This is a hard requirement, you can't avoid it and not cause breakage. Here's what's broken right now: I use the current udev in unstable I install the new sysvinit/initscripts package → udev breaks (no networking) I don't know when and why it's breaking, but it's definitely using both /dev/.udev and /run/udev. And /run is being mounted by mountkernfs. While it might be good to have /run mounted by the initramfs, udev should not break if it is not mounted at that point, which is the case right now. 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#622309: udev: Network, sound and X input broken
On Apr 16, rleigh rle...@codelibre.net wrote: Maybe your initramfs was not rebuilt to include the code which mounts /run? Why would that be required? /run is mounted by mountkernfs, before udevd is started. Because if /run in the initramfs does not exist or is not a tmpfs then /dev/.udev/ will be used instead. This will break some LVM features, but is not supposed to break anything else. Well, it would probably be best if you could install the updated sysvinit package yourself and find out, since you're the udev Not right now. But as said repeatedly, you simply *can* *not* use /run without a versioned dependency on initscripts. This is because there is a window between initscripts being unpacked (/run created) and being configured (/run gets a tmpfs mounted). Without the versioned dependency, you could find yourself using it when it's not actually usable, which will cause breakage. This is a hard requirement, you can't avoid it and not cause breakage. Actually I think I did: in this scenario /run/udev/ will NOT be used because /run is not a tmpfs. While it might be good to have /run mounted by the initramfs, udev should not break if it is not mounted at that point, which is the case right now. It is not supposed to. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Sat, Apr 16, 2011 at 06:01:20PM +0200, Marco d'Itri wrote: On Apr 16, rleigh rle...@codelibre.net wrote: Maybe your initramfs was not rebuilt to include the code which mounts /run? Why would that be required? /run is mounted by mountkernfs, before udevd is started. Because if /run in the initramfs does not exist or is not a tmpfs then /dev/.udev/ will be used instead. Well, the logic must be faulty, because it *is* using /run, and it *is* broken. Well, it would probably be best if you could install the updated sysvinit package yourself and find out, since you're the udev Not right now. It's now uploaded to experimental. sysvinit_2.88dsf-13.4 But as said repeatedly, you simply *can* *not* use /run without a versioned dependency on initscripts. This is because there is a window between initscripts being unpacked (/run created) and being configured (/run gets a tmpfs mounted). Without the versioned dependency, you could find yourself using it when it's not actually usable, which will cause breakage. This is a hard requirement, you can't avoid it and not cause breakage. Actually I think I did: in this scenario /run/udev/ will NOT be used because /run is not a tmpfs. Whether or not /run is a tmpfs or not is *irrelevant* to whether or not udev should use it. The choice of filesystem is entirely up to the admin, and while the default is to use tmpfs, it is not udev's business to alter its behaviour depending on the filesystem in use at that location. That's *utterly broken*. udev needs a dependency on initscripts, and then it can *unconditionally* make use of /run without relying on broken hacks. You're trying to be too clever, and making assumptions that are not warranted. While it might be good to have /run mounted by the initramfs, udev should not break if it is not mounted at that point, which is the case right now. It is not supposed to. Well, it is. Please, implement the initscripts dependency as we requested, and don't make any use of /run otherwise. It's simple, foolproof and robust. We went to a lot of effort to make it so, and it's really rather frustrating that udev is persisting in breaking systems when there is really do need for it to be doing so. 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#622309: udev: Network, sound and X input broken
On Apr 16, rleigh rle...@codelibre.net wrote: Whether or not /run is a tmpfs or not is *irrelevant* to whether or not udev should use it. The choice of filesystem is entirely up to the admin, and while the default is to use tmpfs, it is not udev's business to alter its behaviour depending on the filesystem in use at that location. That's *utterly broken*. I consider it an acceptable tradeoff, I can remove the code when udev will depend on the new sysvinit. udev needs a dependency on initscripts, and then it can *unconditionally* make use of /run without relying on broken hacks. I have no plan to disable the /dev/.udev/ fallback unless it will be clearly proven that it cannot be viable (hint: the alternative is the daemon exiting with an error, which is supposed to be worse). You're trying to be too clever, and making assumptions that are not warranted. But so far you have not been able to show what I did wrong. I like to fix bugs, not symptoms. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Tuesday, 12 April 2011 at 4:45, Marco d'Itri wrote: It makes a difference if you have a /run directory. Do you have one *now*? If you do, rm -rf /run/udev/ and reboot. Removing /run completely helped. I'm not sure why it was there, but since just by existing it breaks udev, maybe whatever package created it should remove it again until it actually works? Best regards, Christian Ohm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
I can confirm bug and can give you more details if you tell me how to do this. So far: - ii udev 167-2 /dev/ and hotplug management daemon - after reboot on first phase of boot there is information that /etc/init.d/udev can't write into /run/ - after boot there is /run folder, it's regular filesystem not tmpfs. eloy@zygzak:/run$ ls -la razem 12 drwxr-xr-x 3 root root 4096 04-06 12:36 . drwxr-xr-x 22 root root 4096 04-06 12:32 .. drwxr-xr-x 7 root root 4096 04-12 10:45 udev eloy@zygzak:/run$ LC_ALL=C df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1463222820 375684896 64007524 86% / tmpfs 3032576 4 3032572 1% /lib/init/rw udev 3023716 140 3023576 1% /dev tmpfs 3032576 1412 3031164 1% /dev/shm eloy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
On Apr 12, Krzysztof Krzyżaniak e...@wikia-inc.com wrote: - after boot there is /run folder, it's regular filesystem not tmpfs. Then rm -rf /run/udev/ and everything will work fine, this behaviour is expected. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On 12.04.2011 11:06, Marco d'Itri wrote: On Apr 12, Krzysztof Krzyżaniake...@wikia-inc.com wrote: - after boot there is /run folder, it's regular filesystem not tmpfs. Then rm -rf /run/udev/ and everything will work fine, this behaviour is expected. confirmed. eloy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
Package: udev Version: 166-1 Severity: critical Justification: breaks unrelated software Hello, after updating my system to udev 167-2 and rebooting, things stopped working. Sound and network were completely dead, X input (ps2 keyboard and usb mouse) was dead until I dis- and reconnected the mouse. Downgrading udev / libudev / libgudev to 166-1 made everything work again. Possibly this is the same problem as in #621036, except that is marked as being fixed in 167-2, which didn't work here. Best regards, Christian Ohm -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (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 166-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: udev/new_kernel_needed: false udev/title/upgrade: udev/reboot_needed: udev/sysfs_deprecated_incompatibility: -- Q: What do you have when you have a lawyer buried up to his neck in sand? A: Not enough sand. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
On Apr 12, Christian Ohm chr@gmx.net wrote: Possibly this is the same problem as in #621036, except that is marked as being fixed in 167-2, which didn't work here. Then looks like you will have to find out why, because so far it is working for everybody else. Do you have a run? Is it a tmpfs? Does it contain anything? -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Tuesday, 12 April 2011 at 4:07, Marco d'Itri wrote: Then looks like you will have to find out why, because so far it is working for everybody else. Do you have a run? Is it a tmpfs? Does it contain anything? I have to admit that I am not very keen on experimenting much with my main system (and my second one is not working atm). Do you have anything specific to look for? There was a /run on the harddisk after running 167-2, which had iirc five subdirectories. Reading the other bugreport I deleted it though. In case it makes a difference, I updated from 166-1 to 167-1 and without rebooting to 167-2. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622309: udev: Network, sound and X input broken
On Apr 12, Christian Ohm chr@gmx.net wrote: I have to admit that I am not very keen on experimenting much with my main system (and my second one is not working atm). Do you have anything specific to look for? And I have to admit that I have no time to waste with reticent bug reporters. Your call. There was a /run on the harddisk after running 167-2, which had iirc five subdirectories. Reading the other bugreport I deleted it though. In case it makes a difference, I updated from 166-1 to 167-1 and without rebooting to 167-2. It makes a difference if you have a /run directory. Do you have one *now*? If you do, rm -rf /run/udev/ and reboot. If it still does not work, you will have to find out why the init script is exiting prematurely. -- ciao, Marco signature.asc Description: Digital signature
Bug#622309: udev: Network, sound and X input broken
On Tuesday, 12 April 2011 at 4:45, Marco d'Itri wrote: There was a /run on the harddisk after running 167-2, which had iirc five subdirectories. Reading the other bugreport I deleted it though. In case it makes a difference, I updated from 166-1 to 167-1 and without rebooting to 167-2. It makes a difference if you have a /run directory. Do you have one *now*? If you do, rm -rf /run/udev/ and reboot. I had one after rebooting with 167-2, not sure where it came from. As mentioned, I deleted that, didn't try 167-2 again then though, will try that when I get some time. If it still does not work, you will have to find out why the init script is exiting prematurely. You mean /etc/init.d/udev? Looking at that, I see /sbin/MAKEDEV mentioned which I installed recently because i2c-tools failed to install without. Not sure if that is usually needed/installed these days. Best regards, Christian Ohm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
