On 01/31/2012 11:35 PM, =?ISO-8859-1?Q?Geoffroy_Turtaut?= wrote:
> rd_NO_PLYMOUTH
>
> On Wed, 1 Feb 2012 01:32:53 -0600, Geoffroy Turtaut
> <[log in to unmask]>  wrote:
>
>> Hi,
>>
>> If you add RD_NO_PLYMOUTH kernel boot option, you will be able to enter
>> single user password.
>>
>> Regards,
>>
>> Geoffroy
>>

From:
https://bugzilla.redhat.com/show_bug.cgi?id=636628

Tesfamariam Michael 2010-09-22 14:31:57 EDT

Description of problem:
When a Lenovo T500 is re-booted after it crashed (battery run out is one
reason), the machine hangs because its root filesystem needs to go 
through fsck
(BZ 558851). When "rhgb quite" is removed from grub, it reports:

/dev/mapper/vg0-root contains a file system with errors, check forced.
/dev/mapper/vg0-root: inodes that were part of a corrupted orphan linked 
list
found.
/dev/mapper/vg0-root: UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY   [FAILED]
...
*** 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 enforcement for system recovery.
*** Run 'setenforce 1' to reenable
Give root password for maintenance
(or type Control-D to continue):

At this stage, at every second key stroke, it reports "Login incorrect." and
repeats the above "Give root password...".

The only way I have been able to recover from this is to reboot the machine
with a Live image and run "fsck.ext4 /dev/mapper/vg0-root" and reboot.

Version-Release number of selected component (if applicable):
Fedora 13

How reproducible:
All the time on my laptop

Steps to Reproduce:
1. Install Fedora 13 on T500
2. Boot to Fedora 13
3. Press power button
4. watch get to the above state

Actual results:


Expected results:
To not get to above state. At the worst, to be able to run fsck

Additional info:

End quote.  The above is my direct experience, but with SL 6x .

Quote from above URL:

Geeky 2011-06-04 09:02:40 EDT

Also present in RHEL6.1 ! paid, licensed, commercial support :(

End quote.  Thus, this serious bug is present in TUV with "paid, 
licensed, commercial support", not a strong recommendation for such 
support from TUV.

The work-around you suggest is mentioned in the above URL; however, it 
appears to disable the root password under reboot failure -- allowing 
anyone with physical access to a machine and sound knowledge to get root 
access.  Am I correct?

Yasha Karant