Bug 840160 - specifying bootloader --password results in system that won' t boot without the password
Summary: specifying bootloader --password results in system that won' t boot without t...
Status: CLOSED DUPLICATE of bug 840204
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: https://fedoraproject.org/wiki/Common...
: 882721 (view as bug list)
Depends On:
Blocks: 1030176
TreeView+ depends on / blocked
Reported: 2012-07-13 23:41 UTC by Nathanael Noblet
Modified: 2015-01-09 17:28 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-01-09 17:28:12 UTC
Type: Bug

Attachments (Terms of Use)
Kickstart file that will result in grub prompting for username and password (986 bytes, text/plain)
2012-09-06 13:20 UTC, Andrew Rechenberg
no flags Details
/mnt/sysimage/var/log/anaconda tarball prior to rebooting (59.56 KB, application/x-bzip)
2012-09-12 04:34 UTC, Nathanael Noblet
no flags Details
resulting grub.cfg (5.14 KB, text/plain)
2012-09-12 04:57 UTC, Nathanael Noblet
no flags Details

Description Nathanael Noblet 2012-07-13 23:41:13 UTC
Description of problem:
When installing a system using a kickstart I have a password set for the bootloader. In F15 it would mean that I couldn't alter the boot parameters without the password. Now specifying a password results in a machine that doesn't boot without the username and password. I think this is a regression.

Also it would be nice if one is to set user names or what not for grub2 that it can be done from the kickstart file.

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

How reproducible:

Steps to Reproduce:
1. include a --password in the bootloader config of a kickstart
2. install system & reboot
Actual results:
a username and password is request to boot

Expected results:
system boots normally, if changes to the boot params are made a password is required

Additional info:

Comment 1 Andrew Rechenberg 2012-09-06 13:19:07 UTC
I'm having a similar issue kickstarting while specifying an updates repo in my kickstart file.

If I do not include the updates repo in my ks.cfg file then the machine loads fine and updates without issue.  If I include the updates repo when the machine boots I am presented with a username and password prompt from grub.  Since I didn't specify a username in the bootloader ks option the system will not boot.

If I try to update the kickstarted machine that was ks'd with the updates repo a package named "grub2-tools" is installed to resolve dependencies.  Not sure if this is related information but thought to include it in case it helps resolve the issue. 

If I remove the --md5pass option from the bootloader line in my ks.cfg file then the machine loads fully updated with no prompt from grub.

Not sure if this is an anaconda bug or a grub2 bug, but the kickstart documentation for f17 needs to be updated or amended to include this issue.

Sanitized ks.cfg file attached.


Comment 2 Andrew Rechenberg 2012-09-06 13:20:19 UTC
Created attachment 610326 [details]
Kickstart file that will result in grub prompting for username and password

Comment 3 Andrew Rechenberg 2012-09-06 13:23:18 UTC
As additional info, I am starting my installations via PXE booting and using the vmlinuz and initrd.img that came with the original f17 installation media.

Here is my PXE config:

label f17-x86_64-min
        menu label Fedora 17 x86_64 - Minimal
        kernel kernels/f17/x86_64/vmlinuz
        append initrd=kernels/f17/x86_64/initrd.img ks=http://ksserver/ks/prod/f17-x86_64-min.cfg proxy=http://myproxy

Comment 4 Brian Lane 2012-09-10 23:24:14 UTC
Please switch to tty2 (ctrl-alt-f2) and attach the logs from /tmp/*log to this bug as individual text/plain files.

Comment 5 Nathanael Noblet 2012-09-11 22:23:44 UTC
Will do - it may take a bit to test this out.

One clarifying question. You mean at the grub2 prompt I can go to tty2?

Comment 6 Brian Lane 2012-09-11 23:47:52 UTC
No, after the install has completed. Or on the installed system you can find the logs in /var/log/anaconda/

Comment 7 Andrew Rechenberg 2012-09-12 00:33:33 UTC
My system won't boot after installation because grub is prompting for a username and a password.  Unless there is a "default" username implied during the kickstart that I don't know about, there is no username to enter because the only thing specified in the ks.cfg file is the md5pass option.

Do you just want us to boot via a rescue environment to get those logs?

Comment 8 Andrew Rechenberg 2012-09-12 00:34:39 UTC
Or just remove the "reboot" option from the ks.cfg so that the machine doesn't reboot automagically? :)

Comment 9 Nathanael Noblet 2012-09-12 04:34:21 UTC
Created attachment 611985 [details]
/mnt/sysimage/var/log/anaconda tarball prior to rebooting

Comment 10 Nathanael Noblet 2012-09-12 04:50:26 UTC
I should comment that I can boot if I answer

Username: root
Password: the non hashed password

It will boot. So I'd like to confirm that it isn't that you can't get past the grub prompt, but that the issue is that it asks for a user and password simply to boot... Which is a change from previous grub versions. If this is the desired behavior I would very much enjoy there to be an option whereby *changing* the boot params require a user/password of some type instead.

Comment 11 Nathanael Noblet 2012-09-12 04:57:52 UTC
Created attachment 611989 [details]
resulting grub.cfg

Figured it may be nice to see the resulting grub.cfg I've removed the actual hash otherwise its unchanged.

Comment 12 Andrew Rechenberg 2012-09-12 13:20:35 UTC
Using root and the non-hashed password does not work in my case.  I know what the password is and I know I'm typing it properly :)

Comment 13 Adam Williamson 2012-09-12 19:29:22 UTC
Discussed at 2012-09-12 NTH review meeting. Rejected as NTH - this isn't really key functionality for Alpha and we're reluctant to touch really core packages at this point.

pjones says this is a bug, not a behaviour change in grub2.

Comment 14 Lawrence Lowe 2012-11-02 17:28:44 UTC
I've found the same problem (again F17). 

Background: like many admins I expect, I use a bootloader password in the kickstart (or interactive install) because the PCs are for a student cluster: the bootloader password is used to prevent the student getting root, and is the final part of the security jigsaw (so the BIOS and the physical case is secured and boot-order limited to the hard-disk).

But this purpose is defeated because the password now has to be known by anybody booting the system and selecting any grub menu item. Anybody knowing that password can then get root. So this is a clear (and undocumented) change of function for the bootloader password. Personally I'm not that interested in extra NTH features, just a return to the previous behaviour (F15, RHEL6, etc) please!

It seems (for me anyway after a quick test) there's a circumvention after installation of adding a --unrestricted option on any menuentry which is to be available for unmodified use by the ordinary user, without knowing a password. So to fix the problem for everybody, maybe there's a way of tweaking the /etc/grub2.d/ scripts so that this option gets set for the menuentry for the target installed system, but not for "recovery system" entries.

Comment 15 marcindulak 2012-12-11 10:17:43 UTC
(In reply to comment #12)
> Using root and the non-hashed password does not work in my case.  I know
> what the password is and I know I'm typing it properly :)

Same situation for me (tried --md5pass in kickstart). Todays Fedora 18.
Even if typing in the grub password worked, i cannot imagine walking around
and typing in passwords to let people boot their machines.
Maybe this feature should be only activated by a --lock option to bootloader,
similar to recent rootpw changes?

Comment 16 Stijn Hoop 2013-01-24 14:56:40 UTC
Seeing this with Fedora 18 release.

Reading around (docs here https://help.ubuntu.com/community/Grub2/Passwords ) it seems that specifying simply a user / password and NOT protecting any entries specifically, GRUB2 will interpret this to mean protecting any boot at all.

This is a change from the F16 and previous kickstart --md5pass option, which only protected changing / editing the GRUB menu.

It can be fixed by adding --unrestricted to the entries generated by anaconda (which I presume simply runs grub2-mkconfig in the chroot -- but I have not yet verified that).

Comment 17 Stijn Hoop 2013-01-24 15:02:30 UTC
Another thing to note: our --md5passwd entry started with $1$ (presumably a hashing identifier in previous version).

The "fun" fact about grub2's arcane shell-script-as-config-file syntax is that this breaks having any $ in the password, as anaconda happily writes out /etc/grub.d/01_user

cat << EOF
password root $1$....

Which results in the actual /boot/grub2/grub.cfg as follows:

password root /

Which will not ever result in a working boot. My guess is that Andrew ran into this bug in comment 12.

Comment 18 Adam Williamson 2013-01-24 20:16:49 UTC
This was also broken in F18, and is becoming kind of a common refrain. It would be nice if we could get it fixed for F19. If anyone has a patch, of course, that'd be welcome...clearing WB field as that was from a previous release.

Comment 19 Adam Williamson 2013-01-24 20:18:20 UTC
let's commonbugs this for F17 and F18 for now...

Comment 20 Adam Williamson 2013-01-29 22:14:36 UTC
*** Bug 882721 has been marked as a duplicate of this bug. ***

Comment 21 Fedora End Of Life 2013-04-03 17:04:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:

Comment 22 James A. Peltier 2013-05-29 02:58:25 UTC
I provided possible patches to grub2-mkconfig to support unrestricted here


Comment 23 Fedora End Of Life 2015-01-09 17:15:28 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Comment 24 Adam Williamson 2015-01-09 17:28:12 UTC
I believe this was (finally) fixed for 19 and 20 back in June 2014, as part of 840204 , so closing as a dupe.

*** This bug has been marked as a duplicate of bug 840204 ***

Note You need to log in before you can comment on or make changes to this bug.