Bug 1996901
| Summary: | gnome-initial-setup hangs when clicking Next on the Software page | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> | ||||
| Component: | gnome-initial-setup | Assignee: | Kalev Lember <klember> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 35 | CC: | gnome-sig, jstpierr, klember, lruzicka, mcatanza, robatino, tiagomatos | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | AcceptedBlocker openqa | ||||||
| Fixed In Version: | gnome-initial-setup-41~beta-1.fc35.1 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-08-24 22:13:16 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: | 1891953 | ||||||
| Attachments: |
|
||||||
|
Description
Adam Williamson
2021-08-23 23:14:17 UTC
Hm, gnome-initial-setup assumes that fedora-third-party finishes instantaneously. I can try reworking it to use a spinner until the command finishes, which would avoid a UI hang, but of course that won't fix the OpenQA test. Would it be possible to run 'sudo fedora-third-party' in a tty to see why it's getting stuck? I couldn't get into a tty when I first tested. I'll try it again tomorrow... I can confirm, this is also happening for me. I cannot log onto the VM tty, because the liveuser user does not seem to work any longer and no new user has been created, so there is no way how to log into it. You can set a root password and/or create a user from the installed system root after install but before rebooting (as we do in openQA), I will try that today. There's also the systemd debug shell, but for some reason that didn't work when I tried it yesterday; I'll try that again today as well. (In reply to Adam Williamson from comment #4) > You can set a root password That's probably best. I'm going to try soon, probably later today since this is pretty urgent, and see what I find. > and/or create a user from the installed system > root after install but before rebooting (as we do in openQA), Huh, doesn't that prevent gnome-initial-setup from running at all? It should. > I will try > that today. There's also the systemd debug shell, but for some reason that > didn't work when I tried it yesterday; I'll try that again today as well. I can't use that because it's going to be qwerty only and it's just too hard to guess which key corresponds to which letter. > Huh, doesn't that prevent gnome-initial-setup from running at all? It should. Oh, yeah, I guess creating a user would. Wasn't thinking. :D > I can't use that because it's going to be qwerty only and it's just too hard to guess which key corresponds to which letter. I'm not actually sure it necessarily is. We need to be able to set a correct keymap much earlier to decrypt encrypted partitions, so theoretically the rescue shell could use the correct layout. I don't think I've ever tested to see if it *does*, though. OK, so now I have the rescue shell working. ps aux shows `pkexec --user root /usr/bin/fedora-third-party disabled` running, and `/usr/lib/polkit-1/polkit-agent-helper-1 root`. Perhaps there's an issue with policykit expecting user interaction or something? attaching strace to the fedora-third-party process shows it sitting at: restart_syscall(<... resuming interrupted read ...> and stracing the polkit-agent-helper-1 process shows: read(0, so it definitely looks like they're just sort of sitting around waiting for...something...that isn't happening. Journal doesn't show anything interesting from polkit. Running either 'fedora-third-party disable' or 'pkexec --user root /usr/bin/fedora-third-party disable' from the root console directly returns immediately. Oh, the problem definitely *is* that we're waiting for authentication. I killed the fedora-third-party process from the debug shell. That caused tty1 (where g-i-s was running) to go to the "Oh no! Something went wrong" screen. I then alt-f4'ed the "Oh no" screen, and found an authentication prompt hiding "behind" it: ==== AUTHENTICATING FOR org.fedoraproject.thirdparty.run ==== Authentication is required to configure software repositories Authenticating as: root Password: so that definitely appears to be the issue. Looks like adding `org.fedoraproject.thirdparty` to the things allowed in the g-i-s policykit policy fixes this, I tested by editing it live. kalev has run a scratch build with the same change, I'll run that through openQA to confirm the fix there. Should be hopefully fixed in gnome-initial-setup-41~beta-1.fc35.1 FEDORA-2021-41d8b36cd2 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-41d8b36cd2 +3 in https://pagure.io/fedora-qa/blocker-review/issue/400 , marking accepted. FEDORA-2021-41d8b36cd2 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. |