Red Hat Bugzilla – Bug 50865
First boot after install fails do to fsck
Last modified: 2007-04-18 12:35:28 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010802 Description of problem: When I first rebooted after upgrading it gave me an error stating that the root file system check failed and dumped me into maintenance mode. I tried checking all the file systems and they were fine. Tried rebooting a couple more times and the same thing kept happening. In order to boot I had to comment out the fsck lines in /etc/rc.d/rc.sysinit and set the return code to 0. During the upgrade I converted most of my file systems(inc /) to ext3. Boot messages are indicating that the systems still thinks I have ext2, but mount shows that they are ext3. How reproducible: Always Steps to Reproduce: 1.convert file systems to ext3 during upgrade 2.reboot 3. Actual Results: Kicked out to maintenance mode and told to check filesystems. Expected Results: Normal boot Additional info:
Re-assigning to anaconda.
Oops, forgot to change assignee...
We (Red Hat) really need to fix this defect before next release.
We have not experienced this problem - how reproducible is it?
I can reproduce it every time I reboot, but I'm not sure how to get it to happen in the first place. Also I am curious as to why this got assigned to anaconda because I don't think that is the problem. The problem occurs when fsck is run from /etc/rc.d/rc.sysinit I recorded a few of the messages I see when this happens: e2fsck 1.22, 22-Jun-2001 for EXT2 FS 0.5b, 95/08/09 /dev/hda8 is mounted e2fsck: cannot continue ***an error occured during the file system check. ***Dropping you to a shell; the system will reboot ***when you leave the shell I then enter the root passwd when prompted and get the following errors bash: id: command not found bash: id: command not found bash: id: command not found [: too many arguements (repair filesystem) 1# The only way that I can boot is by editing /etc/rc.d/rc.sysinit while in maintenance mode. Is there anything that you want me to try that might help us find a way to reproduce it?
I also saw this problem. I "migrated" two partitions and reformatted the rest. The "migrate from ext2 to ext3" option did not appear to work. On reboot, the fstab had "ext3" for the fstype, and the mount failed. Two ways to resolve the problem: 1) set type under fstab to auto, which allows it to try to detect ext3 and failover to ext2. 2) upon failure, run tune2fs -j /dev/partition Both worked for me. The second actually promoted the ext2 partitions to ext3. From what I can tell, this step (creating the journal) did not happen in anaconda).
We've added code to make sure the tune2fs command we run in the installer actually wrote out the journal (even if it returns a 0 exit code). This way we will not rewrite the fstab entry to use ext3 instead of ext2. If you have additional information add to this bug report please reopen.