/dev/null: permission denied

[meba]

after upgrading to dapper, any program willing to write to /dev/null returns with permission denied. after correcting to proper permissions, it works safely.

i think this is critical blocker (gnome stopped to work after upgrade due to this)

initscripts 2.86.ds1-6ubuntu6
sysvinit 2.86.ds1-6ubuntu6
kernel 2.6.15-14-386

Please let me know, if you need more debugging

[Tormod Volden (tormodvolden)]

WorksForMe... initscripts 2.86.ds1-6ubuntu7, sysvinit 2.86.ds1-6ubuntu7, linux-image-386 2.6.15.12.

Did you update directly from Breezy to current dapper?

From where did you get that kernel 2.6.15-14-386 ? The newest one out is 2.6.15.13 AFAICS.

[Phil Bull (philbull)]

Dropping severity until this can be confirmed.

[meba (jakub-rtfm)]

Yes, i changed sources.list and did apt-get update && apt-get dist-upgrade. But it seems that this bug is caused by some package which has been updated 2-3 days ago, because directly after update, it worked. I did apt-get upgrade yesterday, which started causing this bug.

Adding attachment as list of all installed packages

[meba (jakub-rtfm)]

My installed packages

[meba (jakub-rtfm)]

Maybe the kernel version is caused by some non-official repositories, see this

[Leo Milano (lmilano)]

I can confirm this. In fact, I cannot use X at all unless I login in console and change the permissions of /dev/null. KDM starts ok, but you cannot login as a user. After passing the password, the screen blannks and kdm restarts.

I debugged this by running startx from the console, and getting errors in the startx script when trying to write to /dev/null

I am running latest Kubuntu Dapper.

kernel 2.6.15-14-k7
initscripts 2.86.ds1-6ubuntu6

[Leo Milano (lmilano)]

Note that even if I correct the permissions, next reboot will change the permissions back to "0600" and I have to change the permissions manually one more time.

Udev seems to be setting the permissions OK however:

localhost: rules.d> grep null /etc/udev/rules.d/40-permissions.rules
KERNEL=="null", MODE="0666"

Something else is screwing the permissions.

Like meba, I've seen this problem recently. I have been upgrading daily to Dapper latest, and I saw the problem on Feb. 3 for the first time. And I reboot daily to test dapper.

[meba (jakub-rtfm)]

Another information: it appears, that something is changing file permissions when running, not just when rebooting. My /dev/null attributes now changed twice in a hour...
Found nothing in syslog

[Phil Bull (philbull)]

What have they been changed from/to?

[meba (jakub-rtfm)]

Not sure, but i think that default setting is root:root 600 and i changed it to root:root 666

-rw-rw-rw- 1 root root 472 2006-02-07 00:50 /dev/null

Please note, that it is not marked as character device? I don't know why...

[Leo Milano (lmilano)]

These are the permissions after boot:

#####
crw------- 1 root root 1, 3 2006-02-04 10:20 null
#####

To be able to login to KDE, I first do a shell login from KDM.
Then I run:

#####
root@grisell:~# chmod a+rw /dev/null; killall kdm; kdm
#####

Sure enough, the new permissions are ok:

#####
localhost: ~> ls -l /dev/ |grep null
crw-rw-rw- 1 root root 1, 3 2006-02-04 10:20 null
#####

Now KDM lets me login because startx can output to the null device.

[Alessio Caiazza (nolith)]

I've solved this bug.

sudo update-rc.d udev -f remove
sudo dpkg-reconfigure udev

in my case udev starts more than once and so permission on /dev/null were corrupted (????)
After this procedure udev starts only once and works correctly.

[Leo Milano (lmilano)]

I can confirm that Alessio's workaround fixed it for me, at least so far (great finding Alessio).

BTW, there is a typo in the first command, I think it should be

sudo update-rc.d -f udev remove

So, was this caused by a bad udev package in the dev cycle or is it going to show in a fresh install ? This bug should probably stay open until the problem is fully understood.

[Alessio Caiazza (nolith)]

I presume to have modified the initv sequence by myself.
But this remain a bug, because a multiple udev's start cant change /dev/null pemission.

bye

[meba (jakub-rtfm)]

Well, i did as Alessio wrote and bug still present...using last dapper udev

[Scott James Remnant (Canonical) (canonical-scott)]

There is nothing here that suggests a bug in the sysvinit initscripts package.

[Scott James Remnant (Canonical) (canonical-scott)]

I am rejecting this bug because it has been cross-polluted by various people with different problems exhibiting the same symptom.

The fact that /dev/null's permissions are wrong is just the first noticeable symptom of a udev bug.

If people are still having this problem, please file separate new bugs with more details (especially note whether your machine hangs at the "Loading drivers" stage) and leave it up to me to combine them later.