authentication failed repeat message on login screen

[AlanBartlett]

[quote]Looks like Alan is working so late at night...[/quote]

Just trying to catch up on all that I've missed . . .

[quote]This is missing one field

root::13811:0:99999:7::: :-D
[/quote]

Touche. :oops:

I have never yet - in my life to date - got the better of a fully awake feline! ;-)

Thanks, [b]toracat[/b]. :-)

[cfinwolfe]

Woops, I forgot to update this.

I tried doing the listed above (I talked ot my brother and he walked me through it) but the system was still doing the same thing. I tried a e2fsck and fsck with -p -b and a few other things that I could think of... from the rescue CD and the live CD. They both gave me block errors (could not locate the primary block and told me to try other ones like 1983 or 32) no matter what I did I couldn't get it to work right. I reloaded the system and it took me less time to get it back up that way. Guess I'll have to remember this info if I run into it in the future.

Thanks for all the help guys, I couldn't have tried fixing this with out you all :D

[AlanBartlett]

Rough handling of the disk drives when moving the server?
A possible head-platter interaction?
I do hope you thoroughly tested the disks with the manufacturer's standalone diagnostic program before re-installing the OS and your data . . .

Glad to know you have finally resolved the issue.

Alan.

[cfinwolfe]

Well I'm guessing it was 1 of 2 things.

1) Either the movers jarred the system when they were moving it, but seeing as how current HDDs are only subsequent to damage when the drive is spinning (for the most part, anything hitting it hard enough to hurt the drive would usually make it nonfunctional).

Which leads me to believe it was the following (which I take full responsibility for not preventing it)

2) My Boss was overseeing the move and just unplugged the server...

[AlanBartlett]

Now that [b]is[/b] an honest response. Number 2 does look like a good candidate to be the cause of your problems. D'oh.

[b]The[/b] most fundamental rule: [i]Bosses must be kept away from all computer hardware at all times[/i]. (In the right situation - and under secretarial supervision - they may be allowed to use something as complex as a staple gun.)

Alan.
:-D

[emoulton]

I've just done a fresh install of Trixbox 2.6.0.7, (CentOS 5.1 based I think), and when I went to log in for the first time I kept getting authentication errors. Thinking that I had mistyped my root password when installing, I booted single user and tried to reset the password, and I got the "passwd: Authentication token manipulation error." message. I've not yet tried some of the suggestions that I've seen here, but I'll let you know how it goes.

I do have one question that perhaps somebody could help me with. When I tried to take a look at the /etc/shadow file I found that it was missing. I thought that maybe CentOS, (which I'm not too familiar with), used some other method of "hiding" passwords, but from what you guys are saying it sounds like shadow passwords are the default for CentOS, is this the case?

Thanks for posting your thoughts, as well as problems everyone; there's nothing worse then searching the net for a problem, and not finding a thing.

P.S. I ran across this thread on linuxquestions.org: it might be helpful,
[url=http://www.linuxquestions.org/questions/linux-security-4/authentication-token-manipulation-error-2813/]http://www.linuxquestions.org/questions/linux-security-4/authentication-token-manipulation-error-2813/[/url]

[emoulton]

I just tried using pwconv to regenerate my missing shadow file while booted in single user mode. After running pwconv, I was able to reset my root password. If you have a /etc/shadow file you should back it up before running this though. (Also your /etc/passwd, /etc/groups, and /etc/gshadow files just to be safe).

Does CentOS 5.1 use a gshadow file? If so, I'm missing that file too.

I think I might reinstall anyway, as I don't know what else might be wrong with the installation, and having the shadow file completely missing after a fresh install is a bit worrying. *shrugs* It's an old machine. Maybe the ten-year-old 20GB Maxtor disk I found in my work's boneyard wasn't the best of choices.

Here's a good guide on resetting root passwords on linux systems without needing to boot a rescue CD and chrooting. I offer the refinement of just typing 'exit' on the single user shell instead of rebooting, which on CentOS 5.1 seems to cause you to go into multiuser mode, (runlevel 3, which is the "normal" mode). You could also type 'init 3' which should accomplish the same thing as typing exit in this case.
[url=http://www.madpenguin.org/cms/html/17/6.html]http://www.madpenguin.org/cms/html/17/6.html[/url]

[AlanBartlett]

Please don't hijack another persons thread - even if your issue is similar to theirs. It is far better to start a thread of your own and refer to the other thread when explaining exactly what your issue is, what you have tried, etc. It makes things a lot easier for people who may be willing to help you.

To answer your main question, both the [b]/etc/passwd[/b] and [b]/etc/group[/b] files are shadowed by default and with a standard install - unless you disabled the feature - the files [b]/etc/shadow[/b] and [b]/etc/gshadow[/b] are created.

You say it is a new install and you are prepared to re-install. That may be a good idea. Regard the first attempt as a trial run. I would be very surprised if there are not a few things you have realised that could (should) have been done differently . . .

And finally, please do have a look at the installation guide (if you have not already done so) - http://www.centos.org/docs/5/html/5.1/Installation_Guide/

[emoulton]

Thank you for your reply. My problem turns out to be hardware related. I apologize for hijacking cfinwolfe's thread, and I'll keep your advice in mind when making any more posts.

[AlanBartlett]

Thank your for telling us you have resolved the issue. Hope your re-installation now proceeds smoothly.