Bug 1875140 - g-i-s fails to completely launch following clean install, opens in a tiny non-resizeable window instead
Summary: g-i-s fails to completely launch following clean install, opens in a tiny non...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-initial-setup
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rui Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
Depends On:
Blocks: BetaFreezeException, F33BetaFreezeException F33FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-09-02 22:26 UTC by Chris Murphy
Modified: 2020-09-14 06:45 UTC (History)
10 users (show)

Fixed In Version: gnome-initial-setup-3.38.0-2.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-14 06:45:18 UTC
Type: Bug


Attachments (Terms of Use)
screenshot of problem (1.24 MB, image/png)
2020-09-02 22:27 UTC, Chris Murphy
no flags Details
journal (196.59 KB, text/plain)
2020-09-02 22:28 UTC, Chris Murphy
no flags Details
screenshot, silverblue (1.27 MB, image/png)
2020-09-03 18:34 UTC, Chris Murphy
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Gitlab GNOME/gnome-initial-setup - issues 110#note_904931 None None None 2020-09-03 22:10:24 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.