Since anaconda-28.22.2-3.fc28 - I think since the change to use the new user module to handle root password setting, in fact - setting root password on live images appears to be broken. It acts as if it works fine, but you cannot in fact log in with the root password you set during install. To reproduce, just grab a recent KDE live image, like https://kojipkgs.fedoraproject.org/compose/branched/Fedora-28-20180316.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-28-20180316.n.0.iso , install it - creating a root password during the install - then try to log into the installed system as root, using the password you set. It will fail. The anaconda logs claim the root password was set, but if you look at /etc/shadow , the root line looks like this: root:!::0:99999:7::: wherein I believe the ! indicates the password is locked (set to an intentionally invalid hash). Note, this cannot be reproduced on Workstation, as Workstation now suppresses the root password spoke. I haven't tested live images other than KDE, but I suspect they are affected. I think it's at least plausible to propose this as a blocker, per Basic criteria: "A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system. A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility." those specify *user* accounts, but anaconda does allow you to create an install with only the root password set, and KDE will usually let you boot and log in as root with no user account. So it's possible to run an install that results in an entirely unusable system, due to this bug.
Note, this seems to work OK in Rawhide.
So this is what happens, quite an interesting sequence of events: During the switch to handle the rootpw command by a kickstart module the str() method of the Kickstart command object has not been overridden, resulting in the command missing from the output kickstart Anaconda saves after the installation into /root. This had the unintended consequence of making Initial Setup lock the root account during it's run after the installation. Initial Setup read the kickstart file in /root created by Anaconda and noticed the rootpw command is missing, which it equaled to root password not being set. There is logic in place preventing Anaconda/IS from creating root accounts with empty root password, which triggered and locked the root account. So make sure the rootpw command is present in the output kickstart by adding the overlooked str() method override as with all other kickstart commands handled by DBUS modules. Fix PR: https://github.com/rhinstaller/anaconda/pull/1398
anaconda-28.22.2-5.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2c066076a2
Discussed at 2018-03-19 Fedora 28 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-03-19/f28-blocker-review.2018-03-19-16.02.html . Accepted as a Beta blocker as a violation of the criteria cited in the description, read as applying to the root account; we were substantially swayed by the fact you can complete an install with a non-admin user account and a broken root account, which renders the root account inaccessible without emergency surgery.
anaconda-28.22.2-5.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2c066076a2
anaconda-28.22.2-5.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.
anaconda-28.22.3-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9fd9270cd5
anaconda-28.22.3-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9fd9270cd5
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. 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 28 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.
This should've been closed all along.