Bug 1086146 - after updating tumblweed from 20180313->20180318 gdm does not start anymore
after updating tumblweed from 20180313->20180318 gdm does not start anymore
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: GNOME
Current
x86-64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-03-21 01:05 UTC by Arun Persaud
Modified: 2019-03-24 11:28 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
dcermak: needinfo? (arun)


Attachments
journalctl -b (from boot into 20180318) (781.69 KB, text/plain)
2018-03-21 01:05 UTC, Arun Persaud
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Arun Persaud 2018-03-21 01:05:07 UTC
Created attachment 764354 [details]
journalctl -b  (from boot into 20180318)

after updating tumblweed from 20180313->20180318 gdm does not start anymore. I also tried to use xdm instead, in which case I get the xdm login screen, but when trying to log in, my windowmanager (i3) doesn't start and instead I get the xdm login screen again.
I have an intel i7 system with 2 monitors (one 4k, one not), so this might be monitor related? A tumbleweed upgrade on another computer I have worked without any problems.
I also tried to boot 20180318 with the old kernel and got the same issue.

Using tumbleweed-cli to revert to 20180313 fixed the problem.

During boot into 20180318 I get errors like:
"gnome-shell[2138]: Failed to set CRTC mode 3840x2160: Invalid argument"

I added the journalctl -b output from booting into 20180318.

Let me know if I can provide more information. Since I now figured out how to use tumbleweed-cli to revert the changes, I'm happy to go back to 0318 and create more debug output if needed.
Comment 1 Arun Persaud 2018-04-10 01:02:11 UTC
Same issue still consists at 20180406-0.
Comment 2 Arun Persaud 2018-04-13 00:15:53 UTC
Had the same issue on 20180410, but managed to get things running again, by disabling Wayland in /etc/gdm/custom.conf (WaylandEnable=false).
Comment 3 Dan Čermák 2019-03-19 13:46:47 UTC
Sorry for the long silence and I guess you already resolved the issue ages ago, but could you give it a try again and see if you can reproduce the problem?

To me it looks like gdm switched from an X session to Wayland by default and that broke i3, which only speaks X.org and not Wayland.
Comment 4 Arun Persaud 2019-03-24 01:50:59 UTC
yes, it's working again and has been for a while. Currently it works even without setting WaylandEnabled=False in the gdm config (e.g. now I just use the default value in the gdm config, which I assume enabled Wayland).
Comment 5 Dan Čermák 2019-03-24 11:28:36 UTC
(In reply to Arun Persaud from comment #4)
> yes, it's working again and has been for a while. Currently it works even
> without setting WaylandEnabled=False in the gdm config (e.g. now I just use
> the default value in the gdm config, which I assume enabled Wayland).

Thanks for the confirmation, I'll close this bug then.