Bug 1875140

Summary: g-i-s fails to completely launch following clean install, opens in a tiny non-resizeable window instead
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: gnome-initial-setupAssignee: Rui Matos <tiagomatos>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: awilliam, bugzilla, gmarr, gnome-sig, jstpierr, kparal, lruzicka, robatino, rstrode, tiagomatos
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedFreezeException AcceptedBlocker
Fixed In Version: gnome-initial-setup-3.38.0-2.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-14 06:45:18 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: 1766776, 1766777    
Attachments:
Description Flags
screenshot of problem
none
journal
none
screenshot, silverblue none

Description Chris Murphy 2020-09-02 22:26:40 UTC
Description of problem:

GNOME Initial Setup doesn't run; or it runs and isn't drawing completely on-screen.


Version-Release number of selected component (if applicable):
gnome-initial-setup-3.37.91.1-2.fc33.x86_64

How reproducible:
1 in many, haven't seen it before or since


Steps to Reproduce:
1. Automatic install, reboot
2.
3.

Actual results:

See screenshot


Expected results:

Not that.


Additional info:

Comment 1 Chris Murphy 2020-09-02 22:27:22 UTC
Created attachment 1713518 [details]
screenshot of problem

This is what I see following boot.

Comment 2 Chris Murphy 2020-09-02 22:28:23 UTC
Created attachment 1713519 [details]
journal

Comment 3 Chris Murphy 2020-09-03 18:32:32 UTC
I've experienced this now three times. Twice with Fedora-Workstation-Live-x86_64-33-20200902.n.0.iso clean installs to qemu-kvm. And once with Fedora-Silverblue-ostree-x86_64-33-20200903.n.0.iso.

Comment 4 Fedora Blocker Bugs Application 2020-09-03 18:32:59 UTC
Proposed as a Blocker for 33-beta by Fedora user chrismurphy using the blocker tracking app because:

 Basic:
A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system.

Comment 5 Chris Murphy 2020-09-03 18:34:51 UTC
Created attachment 1713669 [details]
screenshot, silverblue

Comment 6 Chris Murphy 2020-09-03 18:57:11 UTC
I decided to do a test loop to see how often it happens. Boot, do I get the tiny window (fail) or do I get setup, force power off and reboot. 4 out of 10 fail. No discernible pattern.

Comment 7 Adam Williamson 2020-09-03 22:10:24 UTC
Chris: I'd say the summary is still a bit wrong. It doesn't fail to launch, it *does* launch. It just launches in a tiny window. :)

Comment 8 Kamil Páral 2020-09-04 06:41:24 UTC
It's not completely visible, but Adam linked his own upstream report here:
https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/110

Chris, can you double click on that window header, or drag the corner, to enlarge the window?

Comment 9 Chris Murphy 2020-09-04 07:15:30 UTC
Yes. And it turns into g-i-s :) Indistinguishable from a normal/expected launch.

Comment 10 Lukas Ruzicka 2020-09-04 08:38:59 UTC
I have experienced this, but I am convinced that this behaviour is only limited to virtual machines. I have currently installed Fedora Workstation on my two bare metal machines and the initial setup went correctly, as well as the new overview slideshow.

Comment 11 Adam Williamson 2020-09-04 19:31:18 UTC
it's a bit of a small sample size though, doesn't seem enough to say for sure that it's VMs only.

Still, I kinda trend -1 blocker on this for Beta at least, since it's only intermittent and it's not a complete failure, you just need to maximize the window. For Final it would be a closer call as it's pretty awkward.

Comment 12 Chris Murphy 2020-09-04 19:53:10 UTC
Criterion: "must be clearly presented"

Is it? I had no idea that window was g-i-s. It didn't occur to me to resize it until Kamil suggested it. The original title of the bug, it's clear I figured g-i-s wasn't launching at all. *shrug* 

On the plus side, maybe some non-trivial number of users will pull the power cord as the work around, and we get some extra Btrfs power off tests for free. :D

Comment 13 Adam Williamson 2020-09-04 19:55:52 UTC
goddamnit, hoist by my own petard again. i fall back on the 'it doesn't always happen' argument. :P

Comment 14 Chris Murphy 2020-09-04 20:01:03 UTC
CommonBugs should solicit reports if it happens on hardware. We know it happens on VMs, but not if or how often it happens on the real deal.

Comment 15 Kamil Páral 2020-09-07 13:45:20 UTC
(In reply to Adam Williamson from comment #11)
> Still, I kinda trend -1 blocker on this for Beta at least, since it's only
> intermittent and it's not a complete failure, you just need to maximize the
> window. For Final it would be a closer call as it's pretty awkward.

Hi, can you please vote at https://pagure.io/fedora-qa/blocker-review/issue/61 next time so that we have all votes in one place? Thanks a lot.

Rejecting BetaBlocker and accepting BetaFE based on this discussion:
https://pagure.io/fedora-qa/blocker-review/issue/61

Comment 16 Adam Williamson 2020-09-08 16:44:19 UTC
kamil: that was a trend not a vote. :P

Comment 17 Geoffrey Marr 2020-09-08 21:23:26 UTC
Discussed during the 2020-09-08 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion:

"A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system".

When the bug happens, g-i-s is not "clearly presented".

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-09-08/f33-blocker-review.2020-09-08-16.00.txt

Comment 18 Ray Strode [halfline] 2020-09-11 18:43:37 UTC
so there's some code doing some unnecessary step.  for some unknown reason that unnecessary step triggers this bug.  but it shouldn't do that step anyway, so I just did a build that gets rid of it.

Comment 19 Fedora Update System 2020-09-11 18:55:14 UTC
FEDORA-2020-598a49abc4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-598a49abc4

Comment 20 Fedora Update System 2020-09-11 20:18:57 UTC
FEDORA-2020-598a49abc4 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-598a49abc4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-598a49abc4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 21 Fedora Update System 2020-09-14 06:45:18 UTC
FEDORA-2020-598a49abc4 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 22 Adam Williamson 2020-10-23 21:28:05 UTC
Bug fixed, commonbugs not needed.