Bug 531047

Summary: f-13 system stopped booting up at file system check (and upon fstab typo)
Product: [Fedora] Fedora Reporter: Perazim <perazim>
Component: plymouthAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: low    
Version: 13CC: ajschult784, dbuggzie, dougsland, fedora, gansalmon, gwync, itamar, kernel-maint, Lcstyle, M8R-7fin56, meyering, michal, notting, ovasik, pknirsch, rda, rstrode
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-27 14:28:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Perazim 2009-10-26 16:41:19 UTC
Description of problem: Installed f-12 beta. Ran without exception for several days. Now at startup, I receive the following error:

*** An error occurred during the file system check
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
*** Warning --SELinux is active.
*** Disabling security enforcements for system recovery.
*** Run 'setenforce 1' to reenable.

Give root password for maintenance
(or type Control-D to continue)

This is displayed as white on black text apparently over the top of the blue startup screen and the text is skewed all over the screen. When I type the first character of the password, it displays "Login incorrect" and then repeats the Give root password... sequence. I am unable to enter a password hence I am unable to get a usable command prompt. Entering Control-D starts the system shutdown.

I have started the system in recovery mode from the f-12-beta DVD and run fsck on the only partition on the hard drive with no change.

Since I cannot seem to get control at the startup to get more info, I cannot be sure that the offending partition is really the / partition. There are only two disk partitions listed in the fstab, / and swap.

You should also know that the hard drive is /dev/sdb a sata drive attached via a usb controller. The PC is a notebook and I am not using the internal drive.

This did work for several days with quite a few reboots.

Version-Release number of selected component (if applicable): f-12-beta

How reproducible: Every boot.

Steps to Reproduce:
Actual results:

Expected results:

Additional info: Even if this turns out to be only a related problem, f-12 shouldn't behave in the manner I am seeing at startup

Comment 1 Gwyn Ciesla 2009-10-26 16:49:39 UTC
Nothing to do with zzuf, reassigning to possible candidate.

Comment 2 Ondrej Vasik 2009-10-27 06:22:29 UTC
I don't see any connection to setup, however, maybe you could try to get at least some control by start to single mode - to prevent possible issues in classic boot sequence. I'm not really sure where to reassign that bugzilla, but I'll try to get some opinions and possibly find better candidate than setup. Anyway, without additional information it will be very hard to find the culprit of problem.

Comment 3 Ondrej Vasik 2009-10-27 08:13:46 UTC
Maybe some corruption on the filesystem - do you use ext4? I'll reassign it to kernel, they might have some idea how to get more informations about the corruption.

Comment 4 Bug Zapper 2009-11-16 14:21:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:

Comment 5 Bob Arendt 2009-11-19 15:59:49 UTC
I've just encountered this on a fresh F12 x86_64 install, with updates as of 11/19  (kernel-  I had a fsck fail on a secondary disk.  As with the original poster I got this prompt: 
  Give root password for maintenance
  (or type Control-D to continue)

It was skewed across the screen. Any single keystroke on the USB keyboard resulted in "Login Incorrect", even ctl-D.  Only ctl-alt-del was recognized, which rebooted the system.

The distressing part was that appending a "1" or "single" to the grub kernel line still resulted in the full fsck being run and getting stuck at the same point.  The only work-around was to append "init=/bin/bash" to the grub kernel line.  This booted directly to bash.  Then I was able to "mount -o remount,rw /" and edit my /etc/fstab to comment out the drive for later examination.

There seem to be two bugs.  This one, where the maint login prompt fails to operate correctly.  The other one is that single-user mode seems to attempt too much;  It shouldn't fsck non-root drives.

Comment 6 Andrew Schultz 2009-11-22 17:09:12 UTC
looks like bug 519763

Comment 7 Bob Arendt 2009-11-22 19:00:11 UTC
Agreed.  One main difference is bug 519763 is against F11, while this one is against the F12 line.  And there are different maintainers assigned .. though sometimes the maintainers keep separate instances open.  It would be good to have these associated.  Hopefully the bug is fixed in both places.

Comment 8 Michal Jaegermann 2010-05-28 10:27:57 UTC
I do not think that kernel is the right component.  That is probably sysvinit or maybe dracut which is responsible here.  I just got hit by it few times in a row courtesy of a broken display driver (intel, bug 571525) which locks up the whole machine quite regularly.  sysvinit-tools-2.87-4.dsf.fc12.i686, dracut-005-2.fc12. An error on any file system which fsck will refuse to repair automatically will provoke such behaviour.

In an absence on hands of any other means to boot a stricken laptop but from its hard disk the only way out I found was to boot with 'init=/bin/bash'. run fsck from there to clean an offending file system(s) and reboot the whole thing  again.
Whatever one tries to type at

Give root password for maintenance
(or type Control-D to continue)

prompt is rejected and we are in an infinite loop.

> One main difference is bug 519763 is against F11

I just bumped the other one to F12.  Anybody can tell how this looks like with F13?  Likely the same.

Comment 9 Bill Nottingham 2010-05-28 21:10:58 UTC
*** Bug 519763 has been marked as a duplicate of this bug. ***

Comment 10 Jim Meyering 2010-06-04 07:16:18 UTC
I've just confirmed that this is a problem with F13, too.
To demonstrate, I added this line to /etc/fstab:

LABEL=no-such /no-such-dir ext4 relatime 1 1

and tried to reboot.
I got to the "Give root password..." prompt, but got stuck as described above.

Comment 11 Bill Nottingham 2010-06-04 15:40:19 UTC
I still can't reproduce this... I get the prompt, but entering the root password works.

Comment 12 Anonymous account 2010-06-06 15:46:28 UTC
I can reproduce this, and I'm using F13 as well.

Comment 13 Jim Meyering 2010-06-06 16:02:45 UTC
I've tried again, and this time, giving the root password does work.
FYI, this is on i686, with selinux enforcing enabled.

I guess it's possible that I mistyped it before.  Or maybe there's something nondeterministic.  In that vein, I saw a glibc warning about a double free in plymouthd on that same system 2 or 3 days ago, but haven't seen it since.

Comment 14 Jim Meyering 2010-06-06 16:14:59 UTC
FYI, I did one more iteration.  giving the root password worked again.
However, ^D still results in a reboot.

Comment 15 Ron Gonzalez 2010-11-18 02:53:34 UTC
I Just experience this on my fedora box after adding an ISCSI Target and creating /dev/sdb using pvcreate.  The iscsi target volume was formatted with ext4, upon reboot I recieved the fsck failed error, and now I am stuck in the infinite reset loop.

Does anyone have a temporary workaround to this issue so I can boot my system again?

Comment 16 Bob Arendt 2010-11-18 04:32:30 UTC
See Comment 5 - add  init=/bin/bash on your boot line to get a low-level shell.  fsck and reboot.

Comment 17 Ron Gonzalez 2010-11-18 05:05:48 UTC
Thanks Bob, I added init=/bin/bash ran mount / -o remount,rw 

edited my /etc/fstab which had my iscsi target VG as /dev/Media/Media for some reason, my logical volume is named Media.  Apparently fsck wanted to run on it.  In any case, the bug is still there and by following my steps (adding an iscsi target to your /etc/fstab) and then not setting it up properly to autoremount you can reproduce the issue described in this ticket.

Comment 18 Bug Zapper 2011-06-02 17:33:40 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 19 Bug Zapper 2011-06-27 14:28:26 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 20 Dale Snell 2011-09-01 19:09:24 UTC
I can confirm that this bug still exists in F14.  I got stuck in the infinite reset loop when a secondary disk failed.  Booting to single-user made no difference.  (The "init=/bin/bash" trick on the kernel boot line never occurred to me.  I must remember that one.)  I was able to use a live CD and edit /etc/fsck that way.  I hope this can be fixed, it's really annoying.  Just telling the user to boot with "init=/bin/bash" to get around the loop would probably be enough.  I can just imagine what a non-tech-savvy person would say if they got caught by this bug.