Bug 2015508
| Summary: | anaconda allows to install a system without an admin user | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||
| Component: | anaconda | Assignee: | Vladimír Slávik <vslavik> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 35 | CC: | anaconda-maint-list, awilliam, jonathan, kellin, lruzicka, robatino, vanmeeuwen+fedora, vponcova, vslavik, w | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | RejectedBlocker AcceptedFreezeException | ||||||||
| Fixed In Version: | anaconda-35.22.2-3.fc35 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2021-10-28 18:28:10 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1891956 | ||||||||
| Attachments: |
|
||||||||
|
Description
Kamil Páral
2021-10-19 11:53:39 UTC
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. 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. |