Arch Linux

http://mailman.archlinux.org/pipermail/arch-dev-public/2011-October/021797.html

The errors are a separate (harmless) issue, as pointed out by Karol, it should be fixed with the new mkinitcpio in [testing].

I am not able to reproduce your problem with /dev/null. Could you point out any other wrong permissions? Any relevant errors in dmesg?

Just to make absolutely sure: you are booted using the stock Arch kernel?

I am using the latest stock kernel (linux 3.0.7-1), which works with udev-173-3

I attached the outputs of "ls -lR /dev" (without timestamps), using udev-173 and udev-174 and the output of dmesg using udev-174

Dmesg indicates that udev starts *twice*, once version 173, later version 174.

With udev-173 it also starts twice on this system, but with the same version number.

Rebuild your initramfs. udev starts once in early userspace, is killed before the switch_root call, and then restarted under the real root.

Check for udevd messages in /var/log/daemon.log. Custom rules may have become invalid - udev 174 removed some deprecated keys, etc.

Better yet -- make sure `/lib/udev/rules.d/50-udev-default.rules' actually exists on the initramfs and /. This is the file that ensures /dev/null is perm'd 0666.

Big hammer approach if the above suggestions don't help:

Delete /etc/udev/rules.d/*
Reinstall udev (and verify that the rule file dave mentioned is installed correctly)
Make sure /boot is mounted
mkinitcpio -p linux

Reboot.

I hit a similar issue tonight, downgrading to udev 173 fixed it indeed.

Thanks for the fix, it also worked. I had some old udev rules under rules.d

Tom's approach fixed it. There were some files in /etc/udev/rules.d.

Sorry to re-open, but I'm still having this problem despite having tried to fix it with Toms advice.

@crobe: are you able to give any more information? such as the output asked for above? I'm to be honest at a loss as to what is causing this...

Thanks for reopening, I think I fixed the problem for me.

I checked for the /dev/null rule to be added to the ramdisk:

# mkinitcpio -v -p linux
...
adding file: /lib/udev/rules.d/50-udev-default.rules
...

And

$ dmesg | grep udev
[ 1.006147] udevd[37]: starting version 174
[ 14.928376] udevd[332]: starting version 174

So that was not the problem. Then I killed udevd, started it in debugging mode and checked for errors, which gave me this:

[717.203453] [7046] parse_file: reading '/lib/udev/rules.d/90-alsa-restore.rules' as rules file
[717.203547] [7046] parse_file: reading '/lib/udev/rules.d/95-calibre.rules' as rules file
[717.203604] [7046] add_rule: unknown key 'BUS' in /lib/udev/rules.d/95-calibre.rules:2
[717.203633] [7046] add_rule: unknown key 'SYSFS{idProduct}' in /lib/udev/rules.d/95-calibre.rules:2
[717.203656] [7046] add_rule: unknown key 'SYSFS{idVendor}' in /lib/udev/rules.d/95-calibre.rules:2
[717.203770] [7046] util_lookup_group: specified group 'usb' unknown
[717.203822] [7046] parse_file: reading '/lib/udev/rules.d/95-cd-devices.rules' as rules file

Interestingly, this information did not appear in /var/log/daemond.log and in no other logfile.

Obviously, this is a faulty rule residing in /lib/udev/rules.d, like mentioned in this post except for the path.
I removed it, rebuilt my initrd and rebootet. Also I discovered an old calibre install on my system, but this is another topic.

Of course its my own fault, but the question is, WHY does udev stop working because of ONE single wrong rule?

@crobe: thanks for taking the time to debug this!

I think now I finally understand what is going on. I had assumed your logs would be filled with warnings about broken rules if you had any SYSFS keys, but apparently not.

You are right that udev should not break just because of one broken key. I think a recent patch in git solves the issue by ignoring the whole rule, rather than just the broken key. I guess we still might get lots of problems even with that patch applied though (imagine a set of rules that starts with a rule that matches on SYSFS and jumps to "end" if it does (or does not) match, this set of rules would now be applied unconditionally to all devices as the first line is ignored.

The only thing we can do is to hunt down broken packages and fix their rules (there should have been warnings about this for years already).

@crobe: thanks for taking the time to debug this!

I think now I finally understand what is going on. I had assumed your logs would be filled with warnings about broken rules if you had any SYSFS keys, but apparently not.

You are right that udev should not break just because of one broken key. I think a recent patch in git solves the issue by ignoring the whole rule, rather than just the broken key. I guess we still might get lots of problems even with that patch applied though (imagine a set of rules that starts with a rule that matches on SYSFS and jumps to "end" if it does (or does not) match, this set of rules would now be applied unconditionally to all devices as the first line is ignored.

The only thing we can do is to hunt down broken packages and fix their rules (there should have been warnings about this for years already).