Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#26583 - [udev] wrong permissions on /dev/null

Attached to Project: Arch Linux
Opened by Otto Allmendinger (OttoA) - Sunday, 23 October 2011, 11:23 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 01 November 2011, 18:32 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

[tomegun: trimmed away unrelated stuff]

Upgrading udev to 174-1 caused some nodes under /dev/ to have the wrong permissions. For example, the permissions /dev/null are set to 0660 instead of 0666, causing all kinds of problems.

Downgrade to 173-3 fixes all issues.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 01 November 2011, 18:32 GMT
Reason for closing:  None
Additional comments about closing:  Nothing we can do. Remove old rules, or if a package ships with broken rules (they should not), report a bug.
Comment by Karol Błażewicz (karol) - Sunday, 23 October 2011, 12:09 GMT Comment by Tom Gundersen (tomegun) - Sunday, 23 October 2011, 21:16 GMT
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?
Comment by Otto Allmendinger (OttoA) - Monday, 24 October 2011, 16:37 GMT
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.
Comment by Dave Reisner (falconindy) - Monday, 24 October 2011, 16:38 GMT
Rebuild your initramfs. udev starts once in early userspace, is killed before the switch_root call, and then restarted under the real root.
Comment by Jesse Crews (jcrews) - Monday, 24 October 2011, 21:12 GMT
Check for udevd messages in /var/log/daemon.log. Custom rules may have become invalid - udev 174 removed some deprecated keys, etc.
Comment by Dave Reisner (falconindy) - Monday, 24 October 2011, 23:34 GMT
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.
Comment by Tom Gundersen (tomegun) - Monday, 24 October 2011, 23:46 GMT
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.
Comment by FRLinux (frlinux) - Tuesday, 25 October 2011, 18:44 GMT
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

Comment by Otto Allmendinger (OttoA) - Tuesday, 25 October 2011, 18:54 GMT
Tom's approach fixed it. There were some files in /etc/udev/rules.d.
Comment by robert r (crobe) - Tuesday, 01 November 2011, 16:23 GMT
  • Field changed: Percent Complete (100% → 0%)
Sorry to re-open, but I'm still having this problem despite having tried to fix it with Toms advice.
Comment by Tom Gundersen (tomegun) - Tuesday, 01 November 2011, 16:51 GMT
@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...
Comment by robert r (crobe) - Tuesday, 01 November 2011, 17:52 GMT
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?
Comment by Tom Gundersen (tomegun) - Tuesday, 01 November 2011, 18:16 GMT
@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).
Comment by Tom Gundersen (tomegun) - Tuesday, 01 November 2011, 18:16 GMT
@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).

Loading...