(In reply to bugreports2005 from comment #0)
> Actual results:
> 
> It doesn't work.

Just to be explicit, this means: grub2 still prompts for password, but does not accept valid / previously working password any more; rather than: grub2 no longer prompts for password.

Please comment if you're seeing different results.

I'm seeing this problem also.  On my RHEL 7.1 systems that were upgraded to RHEL 7.2, the /etc/grub.d/01_users was replaced, but no user.cfg file was ever created.  Net result is that now I can reboot my servers and get into the grub menu and do anything I want with no password.

My 01_users file used to contain:

cat <<EOF
set superusers="admin"
password_pbkdf2 admin grub.pbkdf2.sha512.10000.3...<redacted>...3
EOF


I have an active RedHat case on this. Case # 01547015

(In reply to Ken Long from comment #16)
> I'm seeing this problem also.  On my RHEL 7.1 systems that were upgraded to
> RHEL 7.2, the /etc/grub.d/01_users was replaced, but no user.cfg file was
> ever created.  Net result is that now I can reboot my servers and get into
> the grub menu and do anything I want with no password.
> 
> My 01_users file used to contain:
> 
> cat <<EOF
> set superusers="admin"
> password_pbkdf2 admin grub.pbkdf2.sha512.10000.3...<redacted>...3
> EOF

The migration script looks for "password_pbkdf2 root", i.e. what anaconda installer generates.  As you used a different user name, user.cfg did not get created.

I think your options to consider:

- Use grub2-setpassword to create user.cfg and user "root" username in grub instead of "admin".  The new rpm-provided 01_users assumes the password in user.cfg is for user root and does not allow specifying a different one.

- If you prefer to keep using "admin", restore your old 01_users under a different name that does not conflict with other scripts in /etc/grub.d that are provided by grub2 packages.  Regenerated grub.cfg with grub2-mkconfig.

Out of curiosity, did you run grub2-mkconfig manually during the upgrade form 7.1 to 7.2?  It's not normally run during such upgrade.

Actually, now that you mention it, I believe I did run it manually on the one that I'm using for testing.  I ran it when I was initially troubleshooting.  Wouldn't that command get run again the next time a kernel is updated?  Either way, I hate leaving something dangling out there that may break me the first time some script runs that I wasn't expecting to run.

As for the username, I added the password later when I was CIS hardening the boxes, so it was never done by anaconda.  I just arbitrarily picked a name that wasn't quite as obvious as "root", but that's not any sort of requirement.

I just went on my test machine and ran grub2-setpassword and let it set the password and rebooted and used the username "root" and that worked great, so that's definitely a viable work around since I have less than a dozen systems.  

If you need me to test any more general fixes, let me know.

Thank you for your help!

(In reply to Ken Long from comment #19)
> Actually, now that you mention it, I believe I did run it manually on the
> one that I'm using for testing.  I ran it when I was initially
> troubleshooting.  Wouldn't that command get run again the next time a kernel
> is updated?

The information I got is that grub2-mkconfig is only run during installation.  new-kernel-pkg/grubby is used during kernel upgrades, which does not invoke grub2-mkconfig.  This should be the reason why the issue was not initially reproduced successfully after it was reported.

> If you need me to test any more general fixes, let me know.

Proposed fixes address issues with migration of password from anaconda generated 01_users to user.cfg and do not aim to address handling of custom files.  There's also separate work on getting documentation corrected and updated to reflect changes in 7.2.

Fair enough.  Although, that leads to the larger question that if grub2-mkconfig is ONLY run during installation, then when would the new 01_users and the  automatically created user.cfg files EVER be used?

But back to the more immediate issue, my only suggestion would be that since users may have modified 01_users with custom users, that you check and if the file has been customized from the original, treat it like any other configuration file and rather than replacing it, just create the new file as 01_users.rpmnew with a comment line at the top telling how to create the user.cfg file.  As long as the old config file isn't incompatible with grub in 7.2, I would tend towards the "do no harm" approach.  Just a suggestion.

(In reply to Ken Long from comment #21)
> Fair enough.  Although, that leads to the larger question that if
> grub2-mkconfig is ONLY run during installation, then when would the new
> 01_users and the  automatically created user.cfg files EVER be used?

Apparently, mkconfig run is needed for user.cfg configuration to work.  It seems the upgrade case was not fully considered.

> But back to the more immediate issue, my only suggestion would be that since
> users may have modified 01_users with custom users, that you check and if
> the file has been customized from the original, treat it like any other
> configuration file and rather than replacing it, just create the new file as
> 01_users.rpmnew with a comment line at the top telling how to create the
> user.cfg file.  As long as the old config file isn't incompatible with grub
> in 7.2, I would tend towards the "do no harm" approach.  Just a suggestion.

This is bit of a corner case, as 01_users was not previously part of the package, it was only generated during system installation.  Hence there was no original, not customized version from RPM point of view.  There was not supported tools for updating or customizing 01_users after installation.  The migration script only covers the specific format generated by anaconda.

Reproduced on RHEL-7.2 GA x86_64 Server (upgraded from RHEL-7.1)
Verified fix on RHEL-7.3-20160729.1 (upgraded for x86_64 Server with grub2-2.02-0.41.el7.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2336.html