Red Hat Bugzilla – Bug 840160
specifying bootloader --password results in system that won' t boot without the password
Last modified: 2015-01-09 12:28:12 EST
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):
Steps to Reproduce:
1. include a --password in the bootloader config of a kickstart
2. install system & reboot
a username and password is request to boot
system boots normally, if changes to the boot params are made a password is required
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.
Created attachment 610326 [details]
Kickstart file that will result in grub prompting for username and password
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:
menu label Fedora 17 x86_64 - Minimal
append initrd=kernels/f17/x86_64/initrd.img ks=http://ksserver/ks/prod/f17-x86_64-min.cfg proxy=http://myproxy
Please switch to tty2 (ctrl-alt-f2) and attach the logs from /tmp/*log to this bug as individual text/plain files.
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?
No, after the install has completed. Or on the installed system you can find the logs in /var/log/anaconda/
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?
Or just remove the "reboot" option from the ks.cfg so that the machine doesn't reboot automagically? :)
Created attachment 611985 [details]
/mnt/sysimage/var/log/anaconda tarball prior to rebooting
I should comment that I can boot if I answer
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.
Created attachment 611989 [details]
Figured it may be nice to see the resulting grub.cfg I've removed the actual hash otherwise its unchanged.
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 :)
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.
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.
(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?
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).
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.
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.
let's commonbugs this for F17 and F18 for now...
*** Bug 882721 has been marked as a duplicate of this bug. ***
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:
I provided possible patches to grub2-mkconfig to support unrestricted here
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.
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 ***