gdm doesn't start on a fresh installation of Cosmic Desktop

[Jean-Baptiste Lallement]

ubuntu cosmic desktop 20180925

After installation gdm fails to start and there is only a black screen with a blinking cursor on the top left of the screen.

gdm3 can be started manually from a tty.
Switching to another tty then back also starts gdm.

It happens on bare metal and VM.

Originally, when this issue happened there was a plymouth crash reported in bug 1794292 but this issue is still happening without the plymouth crash.

ProblemType: Bug
DistroRelease: Ubuntu 18.10
Package: gdm3 3.30.0-0ubuntu2
ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
Uname: Linux 4.18.0-7-generic x86_64
ApportVersion: 2.20.10-0ubuntu11
Architecture: amd64
Date: Tue Sep 25 13:54:45 2018
InstallationDate: Installed on 2018-09-25 (0 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180925)
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: gdm3
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.gdm3.custom.conf: 2018-09-25T13:49:41.053012

[Jean-Baptiste Lallement (jibel)]

journal from a failed boot

[Iain Lane (laney)]

marco's going to look at this

for what it's worth, I tried with today's daily and didn't manage to reproduce (virt-manager/qemu, cosmic host, qxl)

[Jean-Baptiste Lallement (jibel)]

Lowering because it is not reproducible. It seems that first boot takes a lot of time but eventually gdm will start.

[Jean-Baptiste Lallement (jibel)]

reproduced again.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1794280

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Łukasz Zemczak (sil2100)]

I have reproduced it running the beta image on a local kvm instance. Command line used:
kvm -cdrom cosmic-desktop-amd64.iso -drive if=virtio,file=hdd.qcow2 -m 2048 -boot c

Got the black screen + blinking cursor on first boot. Trying to see if gdm will eventually start.

[Marco Trevisan (Treviño) (3v1n0)]

Still I can't find a way to reproduce this here...

Using that command fails here as probably my user isn't part of libvirtd or something similar (I'm getting qemu-system-x86_64: failed to initialize KVM: Permission denied).

While installing from virt-manager seem to work properly.

If you've machines with reproducible results, sharing an image (shrinked) would be the only way I think.

[Jean-Baptiste Lallement (jibel)]

@Marco, can you try to deselect "Download updates" and select "Minimal installation"?

[Jean-Baptiste Lallement (jibel)]

There is also the crash reported in bug 1794292 when this happens. Not sure if it's related or not

[Marco Trevisan (Treviño) (3v1n0)]

Jean-Baptiste, that's what I did... It's the 4th time now. But still, no way to reproduce here (in a bionic host, if that matters).

Any kvm config I should set?

[Marco Trevisan (Treviño) (3v1n0)]

Soooo... Running from kvm itself it seems that this is reproducible but seems related to some lower level issue (both using sil's command and adding -vga qxl):

journalctl: https://paste.ubuntu.com/p/rdkvsqs8Rs/ (with vga https://paste.ubuntu.com/p/vJsWbvwdDR/)
xorg.log: https://paste.ubuntu.com/p/Dt3tMsHgPc/

In both wayland and xorg tries to get a drm device, but that's not set..

Generally when using `-vga gxl` this issue is happening in a randomic way, while it's 100% happening when using the default vga (std, or just not passing it) that is actually using vbe.

So, the weird thing here is that with the same kvm vga configurations, we get a working session when just booting from the cdrom.

For some reason it looks like that the vbe driver for X isn't even tried in this case; compare Xorg.log above with the one when booting from livecd: https://paste.ubuntu.com/p/QHJsTY2cms/

Then I think this is indeed not a gdm bug per se.

[Marco Trevisan (Treviño) (3v1n0)]

FYI to reproduce I've done this:

# Create the disk
qemu-img create -f qcow2 /tmp/disk.qcow2 10G

# Boot from the iso and install
kvm -drive if=virtio,file=/tmp/disk.qcow2 -m 4096 -cdrom cosmic-desktop-amd64.iso -boot once=d -vga std

# After install... Then run with just:
kvm -drive if=virtio,file=/tmp/disk.qcow2 -m 4096 -vga std

As said passing `-vga std` is optional, but I never got issues with `-vga vmware`, while it sometimes fails also with `-vga qxl`

# Can pass -netdev user,id=mynet0,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=mynet0 for ssh debugging

[Marco Trevisan (Treviño) (3v1n0)]

Ah, one more thing to notice, if starting in recovery mode from grub, and then resuming the run, it was always working (with std vga too).

Thus this looks like a race in initializing the things that xorg needs to initialize vbe driver

[Timo Aaltonen (tjaalton)]

The difference between live-image and installed system is that the live-image session doesn't have /dev/fb0 around while an installed system does (by efifb). I've no idea why that is.

but for some reason fbdev fails to use that device set up by efifb

[Timo Aaltonen (tjaalton)]

and compared to Debian, our kernel doesn't seem to enable bochs-drm because of an old bug

https://bugs.launchpad.net/ubuntu/+source/kmod/+bug/1378648

which probably should be re-enabled by now

[Timo Aaltonen (tjaalton)]

while enabling bochs-drm just works around the actual bug, I think it's best for cosmic at this stage

[Timo Aaltonen (tjaalton)]

and again comparing to Debian, it doesn't have efifb messing around at any stage, though it's enabled in the kernel config

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael (cerberus-ace)]

Hi - new here, can confirm that this issue also occurs when logging out. Black screen and hardware completely unresponsive. How can I contribute my system details?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Timo Aaltonen (tjaalton)]

I've moved linux/kmod tasks to enable bochs-drm to bug 1795857

[Timo Aaltonen (tjaalton)]

the issue seen with kvm -vga std is a regression in x-x-v-fbdev 0.5.0, same thing happens on bionic if that version is used there. It doesn't have a huge number of commits, so it should be easy to bisect.

[Timo Aaltonen (tjaalton)]

well, bisected already, will discuss with upstream tomorrow

[Daniel van Vugt (vanvugt)]

@jibel, as a workaround can you please test if switching VTs kicks the machine into action? Just Alt+F2, Alt+F1, and maybe then the login screen will appear. If that works for you then maybe we can declare bug 1795637 a duplicate of this one.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xserver-xorg-video-fbdev - 1:0.5.0-1ubuntu1

---------------
xserver-xorg-video-fbdev (1:0.5.0-1ubuntu1) cosmic; urgency=medium

  * revert-ae0aeffae665746.diff: Revert a commit which broke using grub
    with gfxpayload=keep. (LP: #1794280)

 -- Timo Aaltonen <email address hidden> Thu, 04 Oct 2018 10:11:49 +0300

[Marco Trevisan (Treviño) (3v1n0)]

It still seem to crash in my kvm installation:

ubuntu@ubuntu-Standard-PC-i440FX-PIIX-1996:~$ apt-cache policy xserver-xorg-video-fbdev
xserver-xorg-video-fbdev:
  Installed: 1:0.5.0-1ubuntu1
  Candidate: 1:0.5.0-1ubuntu1
  Version table:
 *** 1:0.5.0-1ubuntu1 500
        500 http://it.archive.ubuntu.com/ubuntu cosmic/main amd64 Packages
        100 /var/lib/dpkg/status

See attached journalctl that includes the Xorg.log

It's also weird that using `std` driver works in live, while not once installed.

[Xavier Guillot (valeryan-24)]

Hi,

I have the same problem since 3 weeks on a fresh install of Ubuntu Cosmic, with Wayland session enabled by default : 2/3 of the time, login screen doesn't appear and screen remains black, pushing power button makes Ubuntu background visible again and computer stops.

I join some Auth.log since 17th September, here is an extract - will do some further tests :

Session c1 logged out. Waiting for processes to exit.
Unregistered Authentication Agent for unix-session:c1 (system bus name :1.35, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale fr_FR.UTF-8) (disconnected from bus)
Removed session c1.
session closed for user gdm
session opened for user root by (uid=1000)
Executing command [USER=root] [TTY=unknown] [CWD=/home/valeryan24] [COMMAND=/usr/lib/update-notifier/package-system-locked]
Operator of unix-session:2 successfully authenticated as unix-user:valeryan24 to gain TEMPORARY authorization for action org.debian.apt.install-or-remove-packages for system-bus-name::1.336 [/usr/bin/python3 /usr/bin/update-manager --no-update --no-focus-on-map] (owned by unix-user:valeryan24)
asked to register item /org/freedesktop/secrets/collection/login/1, but it's already registered
[system] Failed to activate service 'org.bluez': timed out (service_start_timeout=25000ms)
Registered Authentication Agent for unix-session:2 (system bus name :1.190 [/usr/bin/gnome-shell], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale fr_FR.UTF-8)

New seat seat0.
pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
New session c1 of user gdm.
session opened for user gdm by (uid=0)
gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session closed for user gdm
Session c1 logged out. Waiting for processes to exit.
Removed session c1.
pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0)
New session c2 of user gdm.
pam_systemd(gdm-launch-environment:session): Failed to create session: Start job for unit user-121.slice failed with 'canceled'
session closed for user gdm
session opened for user gdm by (uid=0)
pam_unix(gdm-launch-environment:session): session closed for user gdm
Session c2 logged out. Waiting for processes to exit.
Removed session c2.
systemd: pam_unix(systemd-user:session): session closed for user gdm
systemd-logind[815]: Power key pressed.
systemd-logind[815]: Powering Off...
systemd-logind[815]: System is powering down.

[Will Cooke (willcooke)]

Could be related to this:
https://gitlab.gnome.org/GNOME/gdm/merge_requests/37