On Thu, Feb 2, 2012 at 5:19 PM, Yasha Karant <[log in to unmask]> wrote:
> I have been discussing the failure mode that I have observed:
>
> also documented in
>
> https://bugzilla.redhat.com/show_bug.cgi?id=636628
>
> after fsck fails during a (re)boot
>
> 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...".
>
> as an endless loop.
>
> The argument has been presented on this list that it is the root user
> failure to configure a password into grub.conf or other bootloading or
> initialization applications/routines configuration or input data files.

Yes, it was presented by you. You are the *only one* who has
associated this problem with grub's internal passwords, tied to your
deductions about a memory of how this used to work. But that's a
different password storage and handling entirely. It has to be
separate for a whole stack of security and maintenance reasons: one
cracked or corrupted OS image should not provide "init=/bin/sh" and
other access to all the other operating systems that may be accessible
from grub.

The login being requested when fsck failed. is the normal root
password out of /etc/passwd, /etc/shadow, or other network based
authentication mechanisms. And since your disk is demonstrably corrupt
at this point due to that power failure, the state of /etc/shadow (the
likely repository) is indeterminate, as is the state of the normal
login utilities for /bin/sh and /bin/login.

The problem with the login screen is easy to test. Just add a line to
/etc/fstab, something like this:

      /dev/sdf1       /mnt/test             ext4     defaults     0 2

Then reboot. Grub will perform some sleight of hand to gain access to
the "/" partition and gain access to the OS startup tools, /etc/fstab
will be parsed, fsck will fail (as it did for your "/" partition), and
grub will give "init" the "-b" option to summon the "/sbin/sulogin"
program. The init and sulogin handling is documented in the sulogin
man page.

Then you can verify that it was *not* grub, or a software bug, but
rather your corrupted disk causing the mishandled password entry
problems you encountered (which is my theory).