|Summary:||initial-setup runs after install with user account, shows Installation Destination spoke|
|Product:||[Fedora] Fedora||Reporter:||Adam Williamson <awilliam>|
|Component:||anaconda||Assignee:||Vendula Poncova <vponcova>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, jkonecny, jonathan, kellin, mkolman, robatino, rvykydal, vanmeeuwen+fedora, v.podzimek+fedora, vponcova, wwoods|
|Fixed In Version:||anaconda-34.19-1||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2021-02-04 23:44:44 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Adam Williamson 2021-01-19 22:26:05 UTC
On today's Rawhide, if you install KDE and create a user during installation, the installed system boots not to SDDM (as expected) but to initial-setup, showing an "Installation Destination" spoke: https://openqa.fedoraproject.org/tests/758401#step/_graphical_wait_login/7 I haven't looked yet what happens if you fill that spoke out, but I can't imagine anyone would want to do that... Proposing as a Beta blocker as a violation of "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" - https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior .
Comment 1 Adam Williamson 2021-01-19 22:42:40 UTC
On an install with no user account, initial-setup runs - this is expected - but as well as the normal User Creation spoke, it also shows the "Installation Destination" spoke, and you can't exit initial-setup with it "incomplete". So this is a problem there too. https://openqa.fedoraproject.org/tests/758398#step/_graphical_wait_login/6
Comment 2 Vendula Poncova 2021-01-20 16:50:03 UTC
Fixed in a pull request https://github.com/rhinstaller/anaconda/pull/3105.
Comment 3 Adam Williamson 2021-01-21 17:37:24 UTC
If you could run a build with the fix soon it'd be great, as several openQA tests are blocked on this. Thanks!
Comment 4 Adam Williamson 2021-01-21 18:20:13 UTC
...well in fact it would be good if we could also fix https://bugzilla.redhat.com/show_bug.cgi?id=1918940 , as *Workstation* openQA tests are blocked on that :)
Comment 5 Martin Kolman 2021-01-21 18:44:07 UTC
Anaconda build with fix for this bug: anaconda-34.19-1.fc34
Comment 6 Martin Kolman 2021-01-21 18:46:09 UTC
(In reply to Martin Kolman from comment #5) > Anaconda build with fix for this bug: anaconda-34.19-1.fc34 Forgot the koji build link: https://koji.fedoraproject.org/koji/taskinfo?taskID=60163166 (In reply to Adam Williamson from comment #4) > ...well in fact it would be good if we could also fix > https://bugzilla.redhat.com/show_bug.cgi?id=1918940 , as *Workstation* > openQA tests are blocked on that :) Let's get this one out of the door first & I can do another build with that one tomorrow. :)
Comment 7 Adam Williamson 2021-02-04 23:44:44 UTC
This bug got fixed already. KDE installs are broken ATM, but the fix was confirmed in a few composes before that bug appeared.