Hi all,
I apologize in advance if I once again am asking a question covered multiple times, but I haven't been able to track down anything specific.

Sometime in the recent past, I screwed up the mod settings for /dev/null. It was preventing me from logging into KDE/X/whatever thru anything other than root.
Googling the problem, I managed to stumble onto something saying that /dev/null needed to be chmod'd, which I did, setting it to the suggested "666". I can then log in as a regular user quite nicely, till the system reboots. Then it's back to before.

Can anyone please tell me what the painfully obvious solution that I fail to grasp with my foggy, tired mind so that I don't have to keep chmod'ing /dev/null every time the system gets rebooted?

Thanks for the help. SimplyMepis does kick a$$, I'm much closer to kicking the M$ habit than I thought I'd ever be. And I'm just getting my toes wet! (I suppose that last sentence is obvious.. <sigh>)

-A

On my system using udev, the permissions are set in /etc/udev/permissions.rules
permissions.rules:KERNEL=="null", MODE="0666"

Now /dev/null is a special device. I'm not sure but I think it's created very early, in my case in the initial ram disk. The initial ramdisk contains a copy of the above file.

So I would say: check this file above and regenerate your initrd:
sudo dpkg-reconfigure linux-image-`uname -r`

When you did your chmod, did you literally type "666" as the arg to chmod? you want to pass that as base8 (ie, octal) 666. So it's "chmod 0666 /dev/null" (that's a zero before the sixes...) If you wanted to pass the argument as a base10 number, you'd use "chmod /dev/null 438" -- both of which result in the proper base2 (binary) bitmask to give you crw-rw-rw- when you look at a long listing of /dev/null. ('c' because it's a character-special device, you can't wreck the 'c' with chmod.

-c

cconstantine,

I hope I haven't totally misunderstood your post & its advice, but . . .

Your advice goes against years of use of chmod. Just to be sure, I tested your code:
I then did the classic RTM & found this in the info system: If you're running KDE, enter "info:/coreutils/Numeric Modes" in the Konqueror Location (Address) bar.

How to use a basic utility is not a matter of opinion, but of testable fact. Please, before you post on a factual subject, check your facts & test your code.

And--for completeness--"chmod dirname 438" does not work either....

But--back to the original topic: Why on earth would the permissions for /dev/null affect the ability to log in to the system?

You're right. I re-read what I originally posted -- it's patently incorrect. And worse, my post doesn't have any relation to the poster's original question.

wonderboy1999: I have no experience on the distro you're using, sorry.
-c

Well, folks, here's the rundown-

nx5000:

MEPIS set up my system with the permissions.rules file in /etc/udev/rules.d/40-permissions.rules. Or at least I think it's the same file or serves the same purpose. Anyhow, the mode for null was listed as 0666 already. This did, however, get me sniffing around to try and solve the /home problem that I will mention below.

pixellany:

Well, I really don't understand for certain myself; but from what I gather, if one doesn't have write permissions for /dev/null, all the stuff that is directed there when KDE/X initiates login can't be written, and.. ? bounces back, perhaps? At any rate, what I've learned is that at least with MEPIS it definitely needs correct permissions in order for things to work right. ;-)

-----
I did manage to fix on accident, or at least band-aid the problem, by adding /home as a path under mtab. For some reason, on startup my system was failing to create the link that produces /home from /mnt/hda6 (which is where my /home directory is located) and by doing this, it seemed to alleviate the /dev/null problem.

Unfortunately, this was all for naught because I ended up having to re-install MEPIS today after I foolishly decided to play around with some feisty repositories in an attempt to get my damned DVD burner working.

Well, thanks for the help guys! Cheers!

-A

Did you do what I adviced? Or half of it?

Too bad to reinstall for a simple permission problem...

nx5000,
Why do you advise sudo'ing in MEPIS?
Although MEPIS does use Ubuntu repositories, it is a very independent distro & does not use the Ubuntu sudo system. Anything needing admin privilege is simply done as root.


OP,
Here's what I would have asked if you hadn't done the re-install:

1. Any ideas about how you messed up the /dev/null permissions?
2. BYW, what have they been set to?
3. Both my SimplyMEPIS systems (3.3.2 & 6.0) use '666'.
4. I have never tried editing /etc/udev/rules.d/40-permissions.rules, but I think it would (have) work(ed), it seems to be the only file where the mode is set:
   
   Code:

   $ grep -R 'KERNEL=="null"'  /etc/udev/*
   /etc/udev/rules.d/40-permissions.rules:\
   KERNEL=="null",                          MODE="0666"

5. I agree that the probable reason that bad permissions on /dev/null cause boot up failure is the errors when the init scripts can't re-direct their output into it.

If you can remember the answers to any of the Q's above, I would be curious to see them.

For the curious, here's a picture of a sailor's tool that almost perfectly embodies the dilemma contained in the Alexander reference in my sig block: http://www.newyorknautical.com/Image...NHRIGGKN51.jpg. When I was growing up they didn't have the shackle key & even better illustrated the dilemma.

The parent page for the image is here: http://www.newyorknautical.com/1PersonalAccess.htm

Oh I dunno
I used mepis only a few days, it was quite good. So I can't really remember...
I guess i mentionnned sudo because:
-> I didn't need to say log in as root , its quicker and I'm lazy.
-> I like sudo, because it's quicker and you share the same bash history
I installed it on debian eventhough it's not by default, I guess mepis has it too.

No no, far from me the idea that I want to start a flamewar about sudo!

MEPIS has sudo, but it's not set up w/ the elaborate root login replacing system that the *buntu's have.

It won't work as you hoped:
If you don't want to log in as root, su - works nicely.