takes about one minute, then fails (red [!!] status, no error message is given (!)) I tried deleting one udev rule at time, and discovered that problem is in rule 60-persistent-storage.rules. deleting the rule, the above step completes successfully in a couple of seconds.
The waiting process cannot give any error message. But to dig deeper into this, you can look at various things. 1. There are some subdirs in /dev/.udev/ and one of them contains a list of failed events (cannot remember of the exact name). 2. Did you delete one rules file after the other or one rule after the other. If you did the first thing, you can try the second to find out which rule there is that makes udev wait. 3. Maybe udev prints some log-output to syslog. But syslog is not yet running :/ So enlarging log-level of udevd can make it print stuff to the console. in /etc/udev/udev.conf 4. Running "udevadm monitor" in parallel to udevd startup can maybe also show interesting stuff. This needs changing of the addon/init-script.
(In reply to comment #1) > The waiting process cannot give any error message. > But to dig deeper into this, you can look at various things. > 1. There are some subdirs in /dev/.udev/ and one of them contains a list of > failed events (cannot remember of the exact name). you mean /dev/.udev/failed ? $ find /dev/.udev/failed /dev/.udev/failed /dev/.udev/failed/\x2fclass\x2fscsi_device\x2f6:0:0:0 /dev/.udev/failed/\x2fclass\x2fscsi_device\x2f5:0:0:0 /dev/.udev/failed/\x2fclass\x2fscsi_device\x2f4:0:0:0 the above devices are my three sata hard disk drives: $ cat /sys/class/scsi_device/4\:0\:0\:0/device/model MAXTOR STM325031 $ cat /sys/class/scsi_device/5\:0\:0\:0/device/model ST380817AS $ cat /sys/class/scsi_device/6\:0\:0\:0/device/model ST380817AS last two part of a RAID-1+LVM volume > 2. Did you delete one rules file after the other or one rule after the other. > If you did the first thing, you can try the second to find out which rule there > is that makes udev wait. no. I just tried deleting file-by-file the ones named *persistent*.rules as they are known to give such issues (they were only 6 files... unluckily it took 6 reboots to figure out) but, the rules in the affected file are 32, and who knows which combination of rule I have to disable...? in the worst case 2^32 tries? :-D > 3. Maybe udev prints some log-output to syslog. But syslog is not yet running > :/ > So enlarging log-level of udevd can make it print stuff to the console. in > /etc/udev/udev.conf thank you, I'll try this > 4. Running "udevadm monitor" in parallel to udevd startup can maybe also show > interesting stuff. This needs changing of the addon/init-script. an option in /etc/conf.d/udev would be nice to debug udev problems
Some more ideas: * Could you attach emerge --info output. * Does it work better with udev-135-r3
when I put udev_log="debug" or udev_log="info" it prints so much messages in console that probably slowdowns udev at the point that it fails (the system won't boot after, because disk devices, and even /dev/zero are not present) but I saw that udevsettle fails due to some timeout I'll try now the 124-r1 => 135-r3 upgrade and tell you.
seems fine. let's wait some time before confirming this...
Btw. The masked udev-136 now has an option to run udevmonitor at boot time
(In reply to comment #0) > takes about one minute, then fails (red [!!] status, no error message is given > (!)) > > I tried deleting one udev rule at time, and discovered that problem is in rule > 60-persistent-storage.rules. > > deleting the rule, the above step completes successfully in a couple of > seconds. > This used to happen with me on this udev version when I had a CD/DVD inside the CD/DVD drive when booting the system. After that I never left CD/DVDs there when shutting down the computer.
Could you please test this with new stable udev-141 and give feedback.
