I've been using a 'pure' udev setup for quite a while now, and for the last month or two, my /dev/null appears to be just a regular file. It's full of junk that's been >'d there, which I'm sure is a security issue. It is also not using the permissions set in udev.permissions. All other nodes appear to be in fine working order. ( floam@Aluminum ~ ) ll /dev/null -rw-r--r-- 1 root root 0 Feb 27 18:06 /dev/null If I dump the udev db, it appears it knows what should be happening: P: /class/mem/null N: null M: 0666 S: O: root G: root Could something be overwritting it?
Actually, :s/last month or two/last week or two/. It just feels like a long time.
I'm getting this issue too. Using mknod to create the node statically works but as you'd expect, it'll disappear at the next reboot. I've tried creating an additional rule in udev.rules but no dice there either.
if you setup udev incorrectly when first utilized this could have cropped up then ... if you do this does it still come back ? rm /dev/null mknod /dev/null c 1 3 reboot if so, try this: rm /dev/null mknod /dev/null c 1 3 tar -jclpf /lib/udev-state/devices.tar.bz2 reboot
Spanky: No, because I am using a "pure" udev system. (No devices tarball, turned off in /etc/conf.d/rc.) Everything is generated on boot.
(I am very sure it work work fine if I used a device tarball, but in my mind a static /dev/ defeats part of the purpose of udev.)
are you using the rcscript run in parallel option ?
I was until two days ago, but feared something may have been writing to /dev/null before it existed. Parallel has been off for about two days and it made no difference.
# ln -snf ../../../sbin/udev /etc/hotplug.d/default/udev.hotplug and reboot - see if that fixes it?
Zero change.
Should I revert back, or is it safe be using /sbin/udev instead?
This issue just appeared on my system too (and caused some other strange problems, like portmap and sshd not starting). I've also been running a "pure" udev setup for about a week now, and just this morning the problem occured. I'm not sure what I could have done that would have caused it... perhaps the initscripts should automatically create /dev/null and /dev/console every boot 'just to be sure'? Also, RC_PARALLEL_STARTUP="no", and basically everything else is in a pretty generic configuration.
Created attachment 26542 [details, diff] udev-019-unlink-existing.patch Remove all files before creating nodes/symlinks.
Basically null gets touched after /dev is mounted, but *before* the nodes is created, and as /dev/null is then a file, udev do not remove it and replace with corret node. Patch fix this. Anyhow, floam tested this, and its in 019-r1.
As said on IRC, patch works like a charm here.
Oops, should learn to not wait 3 minutes between typing and clicking Commit.
I'm having issues with this also. Description: 1. I boot the computer and gdm starts. 2. Change to vt/1 and login as root. 3. ls -la /dev/null root:root 666 4. logout 5. Change to vt/7 and login as my user 6. Change to vt/2 and login as another user -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied ... 7. Change to vt/1 and login as root 8. ls -la /dev/null <my user>:root 660 Variations: step 6. With gdmflexiserver instead (vt/8) gnome crashes. step 8 and/or 3. result: <myuser>:floppy 660 System: RC_DEVICE_TARBALL="no" sys-fs/udev-025-r1 sys-kernel/gentoo-dev-sources-2.6.5-r1 sys-apps/baselayout-1.8.12 Any tip on how to catch the process changing ownerships?
I don't know if it's related but this shows up in my log: Jun 1 06:32:10 xxxx (xxxx-32486): iid OAFIID:BrokenNoType:20000808 has a NULL type Jun 1 06:32:10 xxxx (xxxx-32486): invalid character '#' in iid 'OAFIID:This#!!%$iid%^$%_|~!OAFIID_ContainsBadChars' Jun 1 06:32:13 xxxx (xxxx-32486): iid OAFIID:BrokenNoType:20000808 has a NULL type Jun 1 06:32:13 xxxx (xxxx-32486): invalid character '#' in iid 'OAFIID:This#!!%$iid%^$%_|~!OAFIID_ContainsBadChars' where 32486 = /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=18
It wasn't related. I had a line with /dev/fd/0 in /etc/fstab which didn't play well with pam_console.
