On Wed, Feb 1, 2012 at 9:04 PM, jdow <[log in to unmask]> wrote:
> On 2012/02/01 15:38, Tom H wrote:
>>
>> On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia<[log in to unmask]>
>>  wrote:
>>>
>>> On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant<[log in to unmask]>  wrote:
>>>
>>>> Back to my primary point:  the bug in accepting the root password upon a
>>>> failed fsck during boot is from TUV and documented (please see a
>>>> previous
>>>> post nominally in this thread).  Is there any fix?  I do not care if the
>>>> fix
>>>> "breaks" TUV bug-for-bug compatibility -- is there a fix to which
>>>> routine(s)
>>>> are causing the problem?
>>>
>>>
>>> This is, in fact, an option to configure in grub in the older LILO
>>> boot loader. Run the command "info grub-md5-crypt" for more
>>> information.
>>>
>>> This is not normally considered a "bug". The software is not doing
>>> anything that is not expected or undocumented. It's a *risk*, and some
>>> folks might think it's a security flaw. But the burden of storing and
>>> managing  separate password for deployed systems is not, hirsorically,
>>> taken up by default. It would have to be written into the OS instaler
>>> to apply on the existing boot loader software. So it's not set by
>>> default.
>>
>>
>> It's not a bug; it's a TUV decision. Requiring the root password for
>> single user mode can be set through "/etc/sysconfig/init".
>>
>> As Nico's shown, you can also set a grub password to prevent anyone
>> from adding "init=/bin/sh"/"init=/bin/bash" to the "kernel" line
>> without that password.
>
> It is a bug, IIRC. The original complaint is that it claims it is ready
> to accept the root password and something prevents it by causing the
> login prompt to recycle with each character typed. That has been declared
> a TUV bug. I think somebody mentioned there might be a fix for it that has
> not percolated through yet. It'd be worth checking TUV's bugzilla.

I've just re-read the whole thread. You're right; it started out about
a bug entering the root password in single-user mode after filesystem
corruption.

A solution was pointed to

http://listserv.fnal.gov/scripts/wa.exe?A2=ind1202&L=scientific-linux-users&T=0&P=243

but Yasha somehow decided that it would turn off the password prompt
for single-user mode when all it does is turn off plymouth and allow
someone in his situation (according to the Fedora bug) to enter the
root password.