Although /etc/init.d/udev-trigger bug seems to have fixed (See https://bugs.gentoo.org/show_bug.cgi?id=551644), the symptoms are the same: Machine 1 (desktop machine with a dedicated nVidia card and nouveau driver): -KMS doesn't work (low standard resolution) -X isn't started (no screen found) -after "/etc/init.d/udev-trigger restart", the screen resolution switches and "/etc/init.d/xdm restart" starts X Machine 2 (laptop with optimus graphics): -KMS works (Intel integrated graphics) -X starts (Intel integrated graphics) -Wireless network interface cannot be started (no kernel module loaded) -Integrated keyboard and touchpad aren't working within X (and thus I cannot switch to the console) -After plugging an external mouse, I can get to the console -after "/etc/init.d/udev-trigger restart" and "/etc/init.d/xdm restart" I can use X with keyboard and touchpad -after "/etc/init.d/udev-trigger restart" and "/etc/init.d/net.wlan0 restart" I can use the wireless network interface Reproducible: Always
I can confirm same problems
The same here. No modules other than zram and vbox get loaded. X does not start. Have to login and /etc/init.d/udev-trigger status says it is started. I restarted the service and then all needed modules were loaded. Typed "rc" and all normally with X then.
It is good to have a ps2 keyboard when USB does not work. Adapters for USB keyboards can work too. I think, it depends what you have in kernel and what you have as module.
same problem, fixed by downgrading to version 27. NVIDIA graphics, atheros wireless. USB mouse. PS2 keyboard. with versions 28 and 29: my wifi card driver isn't modprobed, my X11 has no mouse or keyboard. X11 outputs two lines saying: ConnectSession: DBUS_SESSION_BUS_ADDRESS missing or invalid however dbus is running. looking at the X11 logs, nvidia X11 module is not loaded.
Sctach that, it does load the nvidia module, but not evdev.
Same problem, USB keyboard and mouse aren't working within X. Fixed by boot with init=/bin/bash, remove xdm from default runlevel, reboot, downgrade udev-init-scripts to version 27, ...
Please, *stop messing around with init scripts*!!! This was the second consecutive upgrade causing boots to end up with no working network cards, usb devices, graphic cards and so on. If you *really* have to make changes to init scripts, test them *thoroughly* before releasing them into the wild. I am masking ">=sys-fs/udev-init-scripts-28", but I expect that you do it at profile level until new versions of udev-init-scripts are *really working for everyone*. Thank you in advance.
Rough words, but in general I agree (although I'm aware that I'm using an "unstable" profile).
(In reply to Ivan Iraci from comment #7) > Please, *stop messing around with init scripts*!!! > This was the second consecutive upgrade causing boots to end up with no > working network cards, usb devices, graphic cards and so on. And I suspect this had nothing to do with the *init scripts*, but might be part of bug #551808, which had to do with some changes to *udev* itself which needed to be backported. > If you *really* have to make changes to init scripts, test them *thoroughly* > before releasing them into the wild. Remember that you are on ~arch, and sometimes things will happen. I do not have all of the hardware in the world, so there is no way for me to know exactly what will happen on your machine. > I am masking ">=sys-fs/udev-init-scripts-28", but I expect that you do it at > profile level until new versions of udev-init-scripts are *really working > for everyone*. It would be helpful if you could upgrade again and let me know if the issue is solved. Thanks, William
sys-fs/udev-220-r2 with sys-fs/udev-init-scripts-29 Still broken with the same symptoms. No error message about udev-trigger at boot.
To make things even more confusing: I have two nearly identical HP Microserver N40L, one of them starts without any problem, the other one breaks in 3 of 5 times. My HP Microserver G8 breaks everytime and my Netbook (Samsung NC10) starts without problems. If it breaks, the udev rules are not executed completely, the "/dev/disk/by-id"-folder is missing and the network interfaces are eth0 or eth1 instead of enp3s0 or eno0...
(In reply to William Hubbs from comment #9) > And I suspect this had nothing to do with the *init scripts*, but might be > part of bug #551808, which had to do with some changes to *udev* itself > which needed to be backported. I already had the latest udev. It all worked as expected with sys-fs/udev-init-scripts-27, so I think the problem is not with udev itself. > Remember that you are on ~arch, and sometimes things will happen. I do not > have all of the hardware in the world, so there is no way for me to know > exactly what will happen on your machine. On ~arch things CAN happen, but the boot process should (almost) *never* fail. It could, some times, but we had two consecutive updates which lead to broken boots and that is not acceptable. And no, "I do not have all of the hardware in the world" doesn't apply as an answer in this case. Updates tho the init system should be conservative and well tested. > It would be helpful if you could upgrade again and let me know if the issue > is solved. udev-220-r2 doesn't build for me.
Well, if you want predictable and reliable boot, you can always switch over to systemd :D.
(In reply to Michał Górny from comment #13) > Well, if you want predictable and reliable boot, you can always switch over > to systemd :D. Nice try. Ah. Ahah. Ah. :|
(In reply to Ivan Iraci from comment #12) > (In reply to William Hubbs from comment #9) > > > And I suspect this had nothing to do with the *init scripts*, but might be > > part of bug #551808, which had to do with some changes to *udev* itself > > which needed to be backported. > > I already had the latest udev. It all worked as expected with > sys-fs/udev-init-scripts-27, so I think the problem is not with udev itself. > > > Remember that you are on ~arch, and sometimes things will happen. I do not > > have all of the hardware in the world, so there is no way for me to know > > exactly what will happen on your machine. > > On ~arch things CAN happen, but the boot process should (almost) *never* > fail. > It could, some times, but we had two consecutive updates which lead to > broken boots and that is not acceptable. u-I-s-27 is stable, which means not only I, but the arch teams approved it. 28 was broken, sure, and I missed that. After it was pointed out, I fixed the breakage that was pointed out within 24 hours. That is a reasonable response. > And no, "I do not have all of the hardware in the world" doesn't apply as an > answer in this case. > Updates tho the init system should be conservative and well tested. Here's the bottom line: ~arch helps with that testing. If you sign up for ~arch, you are part of the testing pool. I appreciate bug reports and I'll work with you all day to try to figure out what's going on as will any of the developers. However, complaints about updates with breakage on ~arch being unacceptable will get you nowhere pretty fast. > > > It would be helpful if you could upgrade again and let me know if the issue > > is solved. > > udev-220-r2 doesn't build for me. Make sure you are using patchset 3, the ebuild was masked for a short time then unmasked after I confirmed that it builds correctly here.
I'm running udev-220-r2, and this bug still affects me. X starts, but I can't use my mouse or my keyboard. I need to disable xdm service, then log in as root, run "/etc/init.d/udev-trigger --verbose restart", then "/etc/init.d/net.enp2s0 start", and finally "/etc/init.d/xdm start".
(In reply to Ramon Dantas from comment #16) > I'm running udev-220-r2, and this bug still affects me. X starts, but I > can't use my mouse or my keyboard. I need to disable xdm service, then log > in as root, run "/etc/init.d/udev-trigger --verbose restart", then > "/etc/init.d/net.enp2s0 start", and finally "/etc/init.d/xdm start". Ok, let's see if it is caused by the init scripts. There are two versions in the tree, are you running 27 or 29? Please let me know if using udev-init-scripts-27 or udev-init-scripts-29 with this version of udev makes a difference. Thanks, William
> Ok, let's see if it is caused by the init scripts. There are two versions in > the tree, are you running 27 or 29? Please let me know if using > udev-init-scripts-27 or udev-init-scripts-29 with this version of udev makes > a difference. I'm running udev-init-scripts-29. Downgrading to udev-init-scripts-27 makes it work correctly. Apparently, the 29 version skips the "waiting for uevents to be processed" phase in the boot, while the 27 doesn't.
(In reply to Ramon Dantas from comment #18) > > Ok, let's see if it is caused by the init scripts. There are two versions in > > the tree, are you running 27 or 29? Please let me know if using > > udev-init-scripts-27 or udev-init-scripts-29 with this version of udev makes > > a difference. > > I'm running udev-init-scripts-29. Downgrading to udev-init-scripts-27 makes > it work correctly. Apparently, the 29 version skips the "waiting for uevents > to be processed" phase in the boot, while the 27 doesn't. What happened with 29 was that the phase of the udev setup you are talking about became optional; I was following the lead of systemd on this thinking that most systems do not need the settle phase. It sounds like you have something that needs it, so we need to figure out what that is and why.
(In reply to William Hubbs from comment #19) > What happened with 29 was that the phase of the udev setup you are talking > about became optional; I was following the lead of systemd on this thinking > that most systems do not need the settle phase. It sounds like you have > something that needs it, so we need to figure out what that is and why. What's is strange, is that the keyboard works if xdm doesn't start, however, it stops working if X starts.
(In reply to William Hubbs from comment #19) > What happened with 29 was that the phase of the udev setup you are talking > about became optional; I was following the lead of systemd on this thinking > that most systems do not need the settle phase. It sounds like you have > something that needs it, so we need to figure out what that is and why. For me (and I am not the only one), with version 28 onwards network doesn't work, usb doesn't work, sound doesn't work, X doesn't work, etc. It sounds like *almost anything* needs whatever you removed from udev-init-scripts working routine. Did you ever take a look at /usr/portage/profiles/package.mask? Did you ever notice how many packages (even far more harmless than udev-init-scripts) are «Masked for testing» (for any profile, ~arch included)? Well, IMHO this is the case for ">=sys-fs/udev-init-scripts-28". You cannot treat all ~arch users as beta testers for init scripts, especially when there is evidence of systems that stop booting well as a result of these updates. If there is someone eager to help testing, he can always unmask ">=sys-fs/udev-init-scripts-28". My 2 cents.
(In reply to William Hubbs from comment #17) > (In reply to Ramon Dantas from comment #16) > > I'm running udev-220-r2, and this bug still affects me. X starts, but I > > can't use my mouse or my keyboard. I need to disable xdm service, then log > > in as root, run "/etc/init.d/udev-trigger --verbose restart", then > > "/etc/init.d/net.enp2s0 start", and finally "/etc/init.d/xdm start". > > Ok, let's see if it is caused by the init scripts. There are two versions in > the tree, are you running 27 or 29? Please let me know if using > udev-init-scripts-27 or udev-init-scripts-29 with this version of udev makes > a difference. > > Thanks, > > William Let's try one more test. What happens if you run udev-init-scripts-29 with <udev-220? Thanks much for your help. William
Created attachment 405106 [details, diff] Start udevd in daemon mode >=udev-inits-scripts-28 starts udevd using start-stop-daemon --background. This prevents openrc from actually detecting when udevd is "ready". This patch goes back to --daemon mode, with a workaround for bug 547916.
*** Bug 552056 has been marked as a duplicate of this bug. ***
(In reply to Ramon Dantas from comment #20) > What's is strange, is that the keyboard works if xdm doesn't start, however, > it stops working if X starts. Same here - mouse and keyboard stopped working when starting xdm (using -29). Downgrading to -27 did fix the problem. Another problem I've encountered (apart from the broken X after upgrading to 29): My external hard drive (used as a backup device) connected via usb didn't get recognized at boot time - openrc just rushed through the boot process, telling me that /dev/disk/by-uuid/79440abd-413c-4a4b-ae5a-fbdd783d4f91 was not found and immediately continued to boot. At 27 (and below) openrc stopped, apparently waiting for devices to settle and found the disk. To conclude: 29 is currently completely unsuable, it should be masked right now - till the bugs can be fixed. Please test more before releasing such a broken init-script. Thanks.
The good news is I can still interact with my system after booting with udev-init-scripts 29. The bad news is the this interaction is limited to holding down the power button and/or pressing reset button. I have no keyboard, no mouse, no network after boot. I would investigate further, but without a keyboard or network, I have no ability to do anything. I was able to downgrade from udev-init-scripts 29 to 27 and everything works again. Could you please mask udev-init-scripts 29? It is clearly completely broken.
(In reply to Mike Gilbert from comment #23) > Created attachment 405106 [details, diff] [details, diff] > Start udevd in daemon mode > > >=udev-inits-scripts-28 starts udevd using start-stop-daemon --background. This prevents openrc from actually detecting when udevd is "ready". > > This patch goes back to --daemon mode, with a workaround for bug 547916. This works for me.
+ 14 Jun 2015; Patrick Lauer <patrick@gentoo.org> package.mask: + Mask broken udev-init-scripts #551724 And now lets wait for a proper fix ... and maybe, maybe, next time we don't use users as guinea pigs?
(In reply to Patrick Lauer from comment #28) > + 14 Jun 2015; Patrick Lauer <patrick@gentoo.org> package.mask: > + Mask broken udev-init-scripts #551724 > > And now lets wait for a proper fix ... and maybe, maybe, next time we don't > use users as guinea pigs? *Standing ovation.*
(In reply to Patrick Lauer from comment #28) > And now lets wait for a proper fix ... and maybe, maybe, next time we don't > use users as guinea pigs? WTF do we have ~arch for then?
(In reply to Mike Gilbert from comment #30) > (In reply to Patrick Lauer from comment #28) > > And now lets wait for a proper fix ... and maybe, maybe, next time we don't > > use users as guinea pigs? > > WTF do we have ~arch for then? If you can't tell the difference between a single software/library working bad/erratically and an unusable OS, well, it's *your* problem. FYI, I've been in ~amd64 for 13 years now and I can recall not more than 4 occasions in which one of my computers was unable to boot or was totally unusable after boot. Of these 4 (max) times, two in a strike where caused by this package. If only I could mask packages by package maintainer...
(In reply to William Hubbs from comment #22) > Let's try one more test. What happens if you run udev-init-scripts-29 with > <udev-220? > > Thanks much for your help. > > William Sorry for the delay. Well, I must say that's strange, but... Booting with udev-219 and udev-init-scripts-29 worked. I need to try this more, however, the network worked, and, when xdm was started, the mouse and keyboard also worked.
(In reply to Ramon Dantas from comment #32) > (In reply to William Hubbs from comment #22) > > Let's try one more test. What happens if you run udev-init-scripts-29 with > > <udev-220? > > > > Thanks much for your help. > > > > William > > Sorry for the delay. > > Well, I must say that's strange, but... Booting with udev-219 and > udev-init-scripts-29 worked. I need to try this more, however, the network > worked, and, when xdm was started, the mouse and keyboard also worked. Not that strange, if you look at https://bugs.gentoo.org/show_bug.cgi?id=547916 and https://bugs.gentoo.org/show_bug.cgi?id=551928 It seems, udev-init-scripts uncovered a bug in udev.
(In reply to Johannes Hirte from comment #33) > Not that strange, if you look at > https://bugs.gentoo.org/show_bug.cgi?id=547916 and > https://bugs.gentoo.org/show_bug.cgi?id=551928 > > It seems, udev-init-scripts uncovered a bug in udev. Well, udev-init-scripts updated to 30. Is there any fixes contained in it, or any meaningful changes?
Apparently running udev-init-scripts-30 with udev-220-r2 fixes the problem.
yes udev-init-scripts-30 work now.
(In reply to Patrick Lauer from comment #28) > + 14 Jun 2015; Patrick Lauer <patrick@gentoo.org> package.mask: > + Mask broken udev-init-scripts #551724 The only reason I didn't fix this sooner after the patch was posted was that I have family here and have been very busy the past few days. That will slow down after today.
Hi everyone. udev-init-scripts-30 and udev-220-r2 are working for me, but devices at /dev/dri have lost their proper permissions. Now they are owned by root:root with 600 mode. Previously it was root:video 660.
(In reply to Paul Bordukov from comment #38) > Hi everyone. udev-init-scripts-30 and udev-220-r2 are working for me, but > devices at /dev/dri have lost their proper permissions. Now they are owned > by root:root with 600 mode. Previously it was root:video 660. Sounds like a separate issue. File a new bug please.
This has been fixed with >=sys-fs/udev-init-scripts-30
