F8 freezes during boot - "getpwnam failed for roota"
FedoraThis forum is for the discussion of the Fedora Project.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm running F8 dual-boot with XP on a Dell Inspiron 6000. Yesterday, Fedora ran fine all day - no sign of problems. Last night I switched over to the Win side for a few hours, and then shut the computer down for the night. This morning, I tried to boot into Fedora, and it hung on "Enabling local filesystem quotas". Left it for an hour or so, nothing happened. Tried rebooting into both available kernels several times, same thing. Windows still boots fine.
I booted into text mode and found an error "getpwnam failed for roota" at "Enabling local filesystem quotas". I can't find any information on this problem and 'roota' seems very strange to me. Any ideas??
I booted into text mode and found an error "getpwnam failed for roota" at "Enabling local filesystem quotas". I can't find any information on this problem and 'roota' seems very strange to me.
From 'man getpwnam': "The functions getpwnam() and getpwuid() search the password database for the given login name or user uid, respectively, always returning the first one encountered.". The password database is /etc/passwd, and 'getent passwd root roota' should show the account info. By default you should have only one account with UID 0 called "root". AFAIK it's still in kernel time when the "Enabling local filesystem quotas" message appears, so that's definately not good. Have there been any situations earlier on where the system performed "weird"? Or did you experience any crashes earlier on or do things that made the system instable? Anyway. Check your login database ('last') and system and daemon logs for irregularities, verify your installation with 'rpm -qVa 2>&1> /tmp/rpmqVa.log' and check rpmqVa.log for details like missing files and MD5 hashes not matching (see 'man rpm' for explanation of verify output). If you are going to post details or errors, please use BB code tags for readability and post *exact* messages, not descriptions of.
Thanks for your response. This is the first case of this behavior or of an all-out crash of which I am aware. I didn't do anything that I know of that made the system unstable, certainly not during the days right before the problem began.
In /var/log/messages I found the following (repeated every 30 minutes during the day before the boot-up freezing started until I shut down to switch to the Windows partition):
May 4 04:29:14 localhost smartd: Device: /dev/sda, 1 Currently unreadable (pending) sectors
May 4 04:29:14 localhost smartd: Device: /dev/sda, 1 Offline uncorrectable sectors
Running 'badblocks -v -v /dev/sda' gives:
Pass completed, 0 bad blocks found
Running 'fsck -p /dev/sda' gives
fsck 1.40.2 (12-Jul-2007)
WARNING: couldn't open /etc/fstab: No such file or directory
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda
The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device>
1. Digging back through old /var/log/messages files, I see that the bad sector message was appearing for over one month. Running a selftest with smartctl (smartctl -l selftest /dev/sda) gives the following:
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA
#1 Extended offline Completed without error 0% 7 -
2. If I change the entry for root in /etc/passwd to roota (after booting into the system with the rescue CD), I then get a message of "getpwnam failed for root" during bootup at the same point, and the same freeze.
3. Also, looking at lastlog shows only one entry. The full text of lastlog is below:
Username Port From Latest
root **Never logged in**
This strikes me as strange since I have certainly logged in as root and I usually login with another account on this machine (e.g., magmagal, which I still see a line for in the /etc/passwd file).
Is is possible that some file went corrupt? That I got hacked or got a virus somehow?? Any thought or suggestion would be appreciated.
Well, I still have no idea what caused the problem, despite spending lots of time trying to figure it out, but I solved it. Running fsck manually and answering yes to all prompted changes solved whatever was wrong.
Here's what I did:
1. Boot from Rescue CD
2. Answer no to prompt about mounting the filesystem ('Skip')
3. At the command line, enter the following sequence of commands:
> lvm pvscan
> lvm vgscan
> lvm lvscan
> lvm -lvchange -ay /dev/VolGroup00/LogVol00 (using information from previous commands)
4. Run fsck and answer 'y' to all prompts:
> fsck /dev/VolGroup00/LogVol00
After fsck finished I rebooted and the system appears to be completely back to normal. There were lots of changes made by fsck, but I did not document them.