Bug 1557529 - Setting root password on live images fails since anaconda-28.22.2-3.fc28
Summary: Setting root password on live images fails since anaconda-28.22.2-3.fc28
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 28
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Martin Kolman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F28BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2018-03-16 19:48 UTC by Adam Williamson
Modified: 2019-05-21 21:53 UTC (History)
10 users (show)

Fixed In Version: anaconda-28.22.2-5.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-21 21:53:14 UTC
Type: Bug


Attachments (Terms of Use)

Description Adam Williamson 2018-03-16 19:48:21 UTC
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.

Comment 1 Adam Williamson 2018-03-16 19:58:01 UTC
Note, this seems to work OK in Rawhide.

Comment 2 Martin Kolman 2018-03-19 17:33:38 UTC
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

Comment 3 Fedora Update System 2018-03-19 18:44:19 UTC
anaconda-28.22.2-5.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2c066076a2

Comment 4 Adam Williamson 2018-03-19 21:04:28 UTC
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.

Comment 5 Fedora Update System 2018-03-20 14:52:26 UTC
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

Comment 6 Fedora Update System 2018-03-21 00:21:39 UTC
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.

Comment 7 Fedora Update System 2018-04-05 16:23:02 UTC
anaconda-28.22.3-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-9fd9270cd5

Comment 8 Fedora Update System 2018-04-06 18:55:06 UTC
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

Comment 9 Ben Cotton 2019-05-02 21:57:01 UTC
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.

Comment 10 Adam Williamson 2019-05-21 21:53:14 UTC
This should've been closed all along.


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