Description of problem: Anaconda is supposed to make the user either set up a root password, or create an admin user. However, a flaw in its logic allows to perform an installation which has neither. The resulting system then can't be maintained, because there is no way to get admin privileges. This affects all installer and Live images (e.g. Everything netinst, Server DVD, KDE Live) except Workstation Live (where user creation is not available in anaconda at all, and everything is handled in gnome-initial-setup during the first boot). Version-Release number of selected component (if applicable): anaconda-35.22.2-2.fc35 How reproducible: always Steps to Reproduce: 1. boot the installer 2. set up the root account, i.e. select a password 3. create a regular user (keep all defaults, including not setting it as admin) 4. change up your mind and disable the root account 5. start the installation 6. try to get root privileges in the installed system, you can't Additional info: At least for the KDE Live case, this problem should be mitigated by the initial-setup, which should detect that there's no admin user present and force the user to create one. However, that detection doesn't occur properly (which is probably very similar or the same problem as in bug 2015490), and initial-setup immediately exits after start.
Created attachment 1834614 [details] bug demonstration video
Proposing for a blocker discussion, similarly to the proposed bug 2015490.
Yes, I can reproduce this behaviour.
Ditto. I did a quick check and it has been in 34 too so it's not the redesign. In fact I am almost certain that this was the same even before we started with the D-Bus thing some 6 Fedoras back or so. The mechanism is: - The root + user spokes are mandatory (must be completed) if there is no admin user - The criterion for an admin user is that it exists, has password and is unlocked (simplified) - This together means that an enabled root or created admin user make both spokes no longer mandatory = completion does not matter - The criterion for completion of the root spoke is that the root password is set. The last point is where the error is, the spoke is mandatory b/c no admin, but it's finished because root has password, even if locked. Strictly speaking, the redesign made the locked root's password invisible, but it's wrong anyway so let's fix it.
-4 (blocker) +4 (FE) in https://pagure.io/fedora-qa/blocker-review/issue/557 , marking acceptedFE / rejectedblocker.
Looking at this, the problem is a bit deeper. An easy, quick, and dirty fix is a one liner. However the real problem here is that there is an ambiguity: If no administrator exists, that can be fixed in two spokes at once: root and user. Which one should the user pick, why, and how do we signal it?
Sorry, that got lost somehow.
Created attachment 1834742 [details] insufficient accounts in anaconda > If no administrator exists, that can be fixed in two spokes at once: root and user. Which one should the user pick, why, and how do we signal it? Perhaps the same way you do it already in anaconda in a more regular workflow (see the attachment)? Yes, it's not ideal, but using the same approach in both cases makes sense, and can be improved in the future.
I think this used to be indicated by both spokes being 'uncompleted', but if the condition was satisfied in either, both got marked as completed? It's a tricky problem, not just because we have to indicate "you have to achieve some condition that can potentially be done from either of these two spokes", but also "you could potentially 'complete' either spoke without actually achieving the condition"...
Note we slipped Final today, so we do have a window to fix this if we can get a sufficiently safe fix in the next few days.
Please define sufficient? If the fix prevents starting an installation that yields no admin, is that enough?
Answering on behalf of Adam - This bug has been rejected as a blocker, and therefore we'll accept a fix only if the fix seems trivial enough, sp that it won't be likely to break other stuff. That means a complex patch which changes too many places would likely be rejected, a simple "few-liner" would get pulled in through the freeze.
PR: https://github.com/rhinstaller/anaconda/pull/3665
yeah, "sufficiently safe" means "improves the situation with a small and easily reviewable/testable change", ideally.
FEDORA-2021-97506f4570 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-97506f4570
(In reply to Fedora Update System from comment #15) > FEDORA-2021-97506f4570 has been submitted as an update to Fedora 35. > https://bodhi.fedoraproject.org/updates/FEDORA-2021-97506f4570 The fix works correctly, it doesn't let me start the installation without an admin user.
FEDORA-2021-97506f4570 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-97506f4570` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-97506f4570 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-97506f4570 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.