When booting, it stalls when it reaches "waiting for uevents to be processed" right after "populating /dev with existing devices through uevents" and then won't continue. After I remove 80-drivers.rules from /etc/udev/rules.d/ it works fine and has no trouble booting. This has worked for sys-fs/udev-124-r1 and now sys-fs/udev-124-r2. But it won't work for newer versions like sys-fs/udev-141 where the file 80-drivers.rules doesn't appear in /etc/udev/rules.d/ at all. Reproducible: Always Steps to Reproduce: 1. Emerge newer udev or put 80-drivers.rules back in /etc/udev/rules.d 2. Reboot 3. Actual Results: Won't go further than uevents when booting. Expected Results: Should have booted. I use sys-kernel/genkernel-3.4.10.904 at the moment, and have had the same trouble with udev on earlier kernels. My personal tech support changed some parameters in genkernel to make it boot (when we originally installed Gentoo); then there was only troubles with udev. He said something about my harddrive being weird.
First fact: The file did not disappear, it was just moved to /lib/udev/rules.d/80-drivers.rules Second: If these modprobe-rules do stop your system from booting up properly, I suggest you try setting rc_coldplug=no in /etc/conf.d/udev and try if you can boot up then. Does the system really stop booting, or is it just it runs into a long timeout of udevsettle? How long did you wait for boot to complete?
(In reply to comment #1) > Second: If these modprobe-rules do stop your system from booting up properly, I > suggest you try setting rc_coldplug=no in /etc/conf.d/udev and try if you can > boot up then. This worked! Thank you so much.
(In reply to comment #2) > (In reply to comment #1) > > Second: If these modprobe-rules do stop your system from booting up properly, I > > suggest you try setting rc_coldplug=no in /etc/conf.d/udev and try if you can > > boot up then. > > This worked! Thank you so much. > Well, I would not consider this fixed, but maybe you can try what exactly makes it hang by running # udevadm monitor and in parallel # udevadm trigger
(In reply to comment #3) > (In reply to comment #2) > Well, I would not consider this fixed, but maybe you can try what exactly makes > it hang by running > # udevadm monitor > and in parallel > # udevadm trigger When I run udevadm trigger, the computer freezes and I have to turn it off using the power button. I tried this twice. Then I removed 80-drivers.rules from /lib/udev/rules.d/ and it didn't freeze when I ran udevadm trigger. Can you tell me what I might be looking for in the output?
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > Well, I would not consider this fixed, but maybe you can try what exactly makes > > it hang by running > > # udevadm monitor > > and in parallel > > # udevadm trigger > > When I run udevadm trigger, the computer freezes and I have to turn it off > using the power button. I tried this twice. Then I removed 80-drivers.rules > from /lib/udev/rules.d/ and it didn't freeze when I ran udevadm trigger. Can > you tell me what I might be looking for in the output? > Oh, and now it's happened twice that it freezes (without running udevadm trigger). Is this just my hardware being freaky? This didn't happen with udev-124-r2 (where I had removed 80-drivers.rules).
I guess this is about loading kernel modules. So you should try to find out which modules get loaded. You could change the /sbin/modprobe calls in the udev-rules to some own shell script /sbin/log-modprobe-call that contains #!/bin/bash exec >>/tmp/modprobe.log 2>&1 echo "Called $0 $@" /sbin/modprobe -v -n "$@" Then you get a list of modprobe calls in /tmp/modprobe.log Then you can try to load them one at a time to see which one locks up your system.
Any news here? Did you test modprobe or other kind of logging. You also could login on two text consoles. On one you run "sleep 30s && udevadm trigger" and then switch to the other and run "udevadm monitor". Then you see the monitor output even if your system freezes.
Waiting for more info from you. Else I consider this as a kernel or driver bug where we cannot do anything.
(In reply to comment #8) > Waiting for more info from you. Else I consider this as a kernel or driver bug > where we cannot do anything. > I'm sorry I haven't responded. I didn't understand how to do what you described in #6 so it's been left on my todo-list since then. I've tried running udevadm trigger and udevadm monitor in parallel a few times (also with the 30 seconds delay), and everytime it's a different thing udevadm monitor prints right before the computer freezes. I've tried to spot a pattern, but I haven't been able to since I've no idea what I'm looking for. I tried udevadm monitor >> testing to save the output for a better look-through, but it didn't work. As you can see, I'm a lousy amateur. But, since my computer will propably never accept the newest kernels, I'm stuck with sys-fs/udev-141-r1 anyway, so perhaps we might as well just give up?
