Description of problem: Even though my kickstart files specify passwords for both grub and user root, if I start the kickstart install in interactive mode, such passwords are silently discarded. This is not so much of a problem for the root password, since it won't let you get past that screen with a blank password (maybe it could use the ks file password if I tried?), but as for the grub password, not even the option that says grub should use a password is selected, so you may accidentally skip it. Version-Release number of selected component (if applicable): anaconda-10.92.4-1 How reproducible: Every time Steps to Reproduce: 1.Create an interactive ks file with passwords for grub and root 2.Proceed to the boot loader screen, and then to the root password screen Actual results: In the boot loader screen, the button to enable password checking is not even checked, nevermind the password is remembered. In the root password screen, the password is just blank, and it won't let me proceed unless I enter the password twice Expected results: Ideally, it should remember the passwords in the kickstart files, such that users could e.g. customize package selections for their boxes at install time without the administrator having to let them know the passwords for the system. Of course they might then be able to change those passwords, but that's not as much of a problem as having to tell users the passwords that are only to be known by whoever manages to open a safe and break the seal of the envelope where the only copy of the password is stored, after which it must be changed immediately. Additional info:
This has always been the case (in fact, I'm pretty sure you've even filed it before). We don't have an uncrypted form of the password, so really can't make use of it in the UI. Pretty sure there's not anything new we can do, but I'll let Chris look and see if he can come up with something clever
I thought I'd filed this before, indeed. It doesn't matter if the password length is correct in the GUI; in fact, I wouldn't matter at all if a blank password in the GUI implied the confirmation screen would pop up and ask me whether to use the password from the ks file, instead of just warning about the blank password. Simply taking a blank default to imply the ks file password without warnings would be fine as well; point is to avoid having to re-enter the password, and dropping even the choice of enabling a boot loader password.
After thinking about this for a while, I don't believe there's really anything good we can do here. Inferring something from blank UI elements is not behavior that anyone's going to expect or reasonably guess, and it just seems like something we shouldn't be doing. If you do need to allow user customizations through an interactive kickstart file but can't have the user know the password, you could probably just whip something up in a %post script in a few lines of shell.
*** Bug 258981 has been marked as a duplicate of this bug. ***