Ubuntu 18.04: gdm3 does not switch to graphics after update

[njsf]

After update of gdm and kernel gdm3 no longer enables graphics.

What happens:
=============
With and without:
   WaylandEnable=false
in /etc/gdm3/custom.conf
gdm3 does not switch to graphics.
In both cases I case the X process running (Xwayland or Xorg) but no vt has it.
lightdm does work, but barely. It takes up to a minute to get to the login screen.

What I expected to happen:
==========================
gdm3 switching to graphics in ~20 after boot like pre-update.

Release:
========
$ lsb_release -rd
Description: Ubuntu 18.04 LTS
Release: 18.04
$ apt-cache policy kernel-common gdm3 lightdm xorg xwayland
kernel-common:
  Installed: (none)
  Candidate: 13.018+nmu1
  Version table:
     13.018+nmu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        500 http://us.archive.ubuntu.com/ubuntu bionic/universe i386 Packages
gdm3:
  Installed: 3.28.2-0ubuntu1.3
  Candidate: 3.28.2-0ubuntu1.3
  Version table:
 *** 3.28.2-0ubuntu1.3 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     3.28.2-0ubuntu1.2 500
        500 http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
     3.28.0-0ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
lightdm:
  Installed: 1.26.0-0ubuntu1
  Candidate: 1.26.0-0ubuntu1
  Version table:
 *** 1.26.0-0ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        100 /var/lib/dpkg/status
xorg:
  Installed: 1:7.7+19ubuntu7
  Candidate: 1:7.7+19ubuntu7
  Version table:
 *** 1:7.7+19ubuntu7 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status
xwayland:
  Installed: 2:1.19.6-1ubuntu4
  Candidate: 2:1.19.6-1ubuntu4
  Version table:
 *** 2:1.19.6-1ubuntu4 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

Attaching journalctl -b.
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 18.04
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-08-27 (673 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
NonfreeKernelModules: wl
Package: gdm3 3.28.2-0ubuntu1.3
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Tags: bionic package-from-proposed
Uname: Linux 4.15.0-24-generic x86_64
UpgradeStatus: Upgraded to bionic on 2018-05-05 (58 days ago)
UserGroups: adm cdrom dip docker lpadmin plugdev sambashare sudo
_MarkForUpload: True
mtime.conffile..etc.gdm3.custom.conf: 2018-06-30T11:12:29.280424
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 18.04
EcryptfsInUse: Yes
InstallationDate: Installed on 2016-08-27 (674 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
NonfreeKernelModules: wl
Package: linux
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18
Tags: bionic package-from-proposed
Uname: Linux 4.15.0-24-generic x86_64
UpgradeStatus: Upgraded to bionic on 2018-05-05 (58 days ago)
UserGroups: adm cdrom dip docker lpadmin plugdev sambashare sudo
_MarkForUpload: True
modified.conffile..etc.gdm3.custom.conf: [modified]
mtime.conffile..etc.gdm3.custom.conf: 2018-06-30T11:12:29.280424

[Daniel van Vugt (vanvugt)]

Please log into a VT and run 'apport-collect 1779476' on the machine. That will send us more information that we need.

[njsf (nelson-ferreira)]

apport information

[njsf (nelson-ferreira)]

apport information

[njsf (nelson-ferreira)]

apport information

[njsf (nelson-ferreira)]

apport information

[Daniel van Vugt (vanvugt)]

Thanks.

Unfortunately we are still missing some information.

Please run 'lspci -k' and send us the output. If you don't know how to do that then just take a photo of the screen.

Please also run 'apport-collect 1779476' again. I have modified the bug so hopefully it will give us more info the second time.

[Mark (1aunchpad-nct)]

I'm suffering this after this update too. It is the latest in a depressingly long list of Ubuntu updates that have ****ed up my system. You really *need* better testing of updates. If you can't improve the testing then there needs to be a way to roll-back the system to before an update.

Instead of the login screen I see the output of a log. Every item the log is [ OK ] except for

    [ .] A start job is running for Hold until boot process finishes up (28s / no limit)[ OK ] Started Show Plymouth BootScreen.

The last entry is

    [ OK ] Started GNOME DisplayManager. Dispatcher Service....upport.hanges.pp link was shut down.

lightdm is not working for me. Yes a login screen is displayed but after login the screen goes black for quite some time then the login screen reappears again. I am unable to use my system so this is a priority 1 bug for me.

[Daniel van Vugt (vanvugt)]

Mark,

Please log a bug of your own so we can figure that out for you.

[Bristow (web-frayssinet)]

Same thing on my laptop Lenovo X240.

[Mark (1aunchpad-nct)]

Daniel,

Which part of what I wrote you do you another bug about? The fundamental issue, gdm doesn't work, hence no login screen, after the latest kernel/gdm update is the same as this bug, so why create a duplicate?

The previous issues were with past distribution versions so filing a bug is not useful.

That leaves the lightdm problem. Is that it?

[njsf (nelson-ferreira)]

apport information

[njsf (nelson-ferreira)]

apport information

[njsf (nelson-ferreira)]

apport information

[njsf (nelson-ferreira)]

After todays update of grub and kernel to 4.15.0-25 it now takes ~4m to get to lightdm.
Never since my '94 486DX2 I had such poor boot-to-use times.

[njsf (nelson-ferreira)]

Another thing I noticed is that since the upgrade, all Xwayland sessions crash on suspend, so they start anew. Only using Xorg now. Previously all worked well with gdm3 in wayland.

[Dimitrij Mijoski (dimztimz)]

I think I got hit by this bug too after the kernel update to 4.15.0-24-generic. Found this on askubuntu https://askubuntu.com/questions/1051555/after-security-update-to-4-15-0-24-generic-26-ubuntu-screen-shows-log-content which solves the problem.

Switcing to another tty and then switching to lightdm solved.

[Mark (1aunchpad-nct)]

> which solves the problem
I don't consider switching to lightdm to be a solution the problem. It's a workaround.

[Daniel van Vugt (vanvugt)]

Mark,

gdm3, mutter, gnome-shell, and sometimes graphics drivers, all have multiple bugs that can result in these same symptoms. So it is helpful to not group bugs on the symptoms and track down the root cause of each person's problem separately.

Otherwise when it comes to declaring a bug fixed, one person will agree it is fixed and another will say it isn't. And the bug will forever be in deadlock because the two people were actually experiencing different bugs that need different fixes.

[Mark (1aunchpad-nct)]

Turns out lightdm is working after all, almost. If you wait patiently when the black screen appears after the Ubuntu 5 dots boot screen, possibly as much as 4 minutes, then the desktop eventually appears, albeit somewhat messed up, with a message box asking you to "unlock the login keychain" because it "was not unlocked when you logged in". After entering the password, the desktop is redrawn correctly and everything works. I'm still on kernel 4.15.0.24. It seems lightdm is just very slow as noted by njsf.

I think, if you touch the mouse during this black screen period, the login screen appears and, if you login you see a black screen for several seconds then it logs you out again. A cycle you can't get out of. That's what led to my comment that lightdm wasn't working for me.

Daniel, I will create a bug of my own. Thanks for the explanation.

[Brad (apeitheo)]

I believe I found a solution (or at least, a temporary workaround until the potential bug is fixed). It seemed the bug was introduced in 4.15.0-24, as 4.15.0-23 works fine. I'm running an up-to-date 18.04 system on top of a Lenovo ThinkPad Yoga.

I would get a blank screen with both GDM and LightDM until I started switching virtual terminals or typing my login info, at which point, it would just start up seemingly at random. I set systemd to boot to multi-user instead of graphical, and ran 'startx' and experienced the exact same delay. I took a look at the startx script source and I traced it down to a call to /usr/bin/mcookie which generates a magic number to be used with xauth. According to the BUGS section in the mcookie manpage, it states that mcookie assumes that "none of the randomness sources will block." Sure enough, doing an strace on mcookie shows it hangs at a call to getrandom(), which I'm assuming (my knowledge is a little fuzzy here) means that entropy is too low for getrandom() to generate a number. Moving the mouse around, typing a few characters or switching virtual terminals, to my knowledge, all generate some entropy so that finally when there's enough, getrandom() returns a number to mcookie, thus allowing xorg to start.

TL;DR: I installed 'haveged' from the repo, which, as far as I understand, adds to the entropy on boot, allowing xorg to start without any delay.

My next step is to take a look at the changelog between kernel releases and see what I can come up with as a potential cause, but I figured I would post what I've found so that others may benefit in the meantime.

[Brad (apeitheo)]

I should add that I've only tested this with 'startx' and GDM; I haven't tried LightDM.

[Brad (apeitheo)]

I had to purge/reinstall lightdm for some reason (otherwise it was flickering on/off), but now both GDM and LightDM are working as they should on 4.15.0-24 with 'haveged' installed.

[Daniel van Vugt (vanvugt)]

I find it disturbing we still have parts of the system that will block start-up waiting for entropy. That's not a good user experience.

But maybe that's not the same problem as njsf is experiencing...

njsf: Do you find an older kernel fixes the problem for you too? Try one of these:

  http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.14.53/
  https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/14927311

You may also want to try:

  sudo apt install haveged

[Mark (1aunchpad-nct)]

Daniel,

Installing haveged fixed my issue so I'm pretty sure its the same as this one. Therefore I won't create a bug of my own.

Thanks for the help.

[Daniel van Vugt (vanvugt)]

That's good news.

Although this bug is primarily owned by njsf so we'll wait to see what he says. I want to make sure the original reporter is actually experiencing the same problems as are being discussed now.

[Daniel van Vugt (vanvugt)]

In trying to identify the source of the problem we will need people to temporarily remove haveged.

Next, please reproduce the issue and just leave the machine running. Do the graphics eventually come up after a few minutes of waiting? Please also repeat the test but wiggle the mouse/touchpad while waiting - does that make it come up sooner?

[Daniel van Vugt (vanvugt)]

Also, after removing haveged, please try some older kernels:

  http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D

and try to find the two versions closest together where one works and the other does not.

[Vasiliy Faronov (vfaronov)]

Can confirm this with GDM, without haveged, on a Lenovo Thinkpad S440:

- with kernel 4.15.0-24, GDM comes up after several minutes
- if I wiggle the touchpad, in a dozen seconds
- with kernel 4.15.0-23, immediately (no issue)

Strangely, I recall that when I first experienced this issue a couple days ago, it seemed to happen with -23 at least once, causing me to fall back further onto -20. May have been some error on my part.

[Daniel van Vugt (vanvugt)]

Sorry, my mistake. Recent kernel changes may be the trigger of this problem but would not be the root cause. If there is any process blocking waiting for entropy then that's the real issue. Because they are blocking waiting indefinitely for something that might theoretically take forever. And that's bad software design.

I guess therefore we don't need to find out which kernel version made it worse recently. We need to find out which process is actually blocking waiting for entropy. If anyone can figure that out from the logs, or by looking at open files of each process and seeing who has /dev/random open then it would help a lot.

[Daniel van Vugt (vanvugt)]

This command should tell you the suspicious process ID(s):

sudo ls -l /proc/*/fd/* | grep /dev/random

[Daniel van Vugt (vanvugt)]

Or just:

  sudo lsof | grep /dev/random

[Charles Burns (chasb)]

I can report a very similar experience after the update to kernel *-24.
The difference with my machine - a barebook Clevo packaged by Pioneer Computers Australia -
is that no keyboarding, usb mouse, or touchpad use reproducably reduces the hang time by plymouth to less than an average 90seconds. The appearance of the cursor is fairly unpredictable within those times and at a rare few boots, CTRL+ALT F2 sent the system into a wobbly dance between the shell and plymouth.
Holding SHIFT during boot however does produce an acceptable and reproducable boot into Xorg time of about 15s.
Installing and enabling haveged in sysctrl has the same effect as holding the SHIFT key.
Booting into the *-23 kernel removes the hang and any of the wobbly moves between shell and plymouth.

As requested, after uninstalling haveged and booting to *-24 kernel, both using the SHIFT workaround and the longer playing with keyboard and pointers, issuing the command:
lsof | grep /dev/random

listed nothing.

Interesting that with sudo prefixed, the command complains:

'lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.'
While it doesn't complain when the user themself issues the command.
Is this a bug too, or is it logical that the virtual gnome file system is indeed run per user
and not by root?

Neither forms of the command list anything.

[monkeybrain2012 (kammon101)]

I think it might be this bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572

[Mark (1aunchpad-nct)]

I agree with monkeybrain2012. The question that must then be raised is how this breakage got into an Ubuntu software update for the masses almost 2 months after it was known that a kernel change had broken gdm3 login, and after commits for the underlying issues had been created in debian.

[njsf (nelson-ferreira)]

Going back to kernel 4.15.0-23 DOES NOT solve the gdm3 issue.
Hence the issue I reported is not solved.

Has for the _workaround_ of using lightdm in 4.15.0-23, yes, it boots faster HOWEVER, once I installed 4.15.0-23 the bcmwl DID NOT GET BUILT/INSTALLED which is also VERY bad, as _no WIFI_.
How then can a _regular_ user go back on kernels and use dkms ?
When providing such suggestions of previous kernels you need to make sure the dkms machinery will work!!!

[njsf (nelson-ferreira)]

Processing triggers for linux-image-4.15.0-23-generic (4.15.0-23.25) ...
/etc/kernel/postinst.d/dkms:
Error! Your kernel headers for kernel 4.15.0-23-generic cannot be found.
Please install the linux-headers-4.15.0-23-generic package,
or use the --kernelsourcedir option to tell DKMS where it's located

root@postel:~# dpkg-query -s linux-headers-4.15.0-23
Package: linux-headers-4.15.0-23
Status: install ok installed
Priority: optional
Section: devel
Installed-Size: 75198

[monkeybrain2012 (kammon101)]

It affected lightdm as well. I run unity in 18.04 and use lighdm and the boot time has gone from 4 secs to 4 minutes with 4.15.0-24. Brad's workaround(#21) by installing haveged also works for lightdm.

[njsf (nelson-ferreira)]

Installed linux-headers-4.15.0-23-generic, now dkms runs properly.

Re-tested w/ 4.15.0-23-generic: gdm3 STILL does not come up, just bounces between black screen and the systemd progress messages.
So, going back to 4.15.0-23-generic does NOT solve the original issue.

I will continue w/ haveged and lightdm workaround, but the bug should remain open.

[Daniel van Vugt (vanvugt)]

Comment #34 indeed sounds like the problem.

Does installing this package fix the bug?;
https://packages.debian.org/sid/amd64/plymouth/download

[Mark (1aunchpad-nct)]

Bug #1779827 appears to be a duplicate of this.

[Daniel van Vugt (vanvugt)]

Someone please test:
https://packages.debian.org/sid/amd64/plymouth/download

If that fixes the problem then we know how to proceed.

[njsf (nelson-ferreira)]

Why was the title changed? It DOES NOT MATCH AT ALL the symptoms I reported!

[Mark (1aunchpad-nct)]

Re. comment #42, how do you install that download package on Ubuntu?

[njsf (nelson-ferreira)]

After installing plymouth_0.9.3-3_amd64.deb gdm3 STILL DOES NOT START.
Without haveged installed lightdm still takes AGES to start.

plymouth 0.9.3-3 is NOT a resolution to this.
And PLEASE change the title back.

The original complaint was: gdm3 does not start, not that the boot process never completed.
As I said:

"In both cases I can see the X process running (Xwayland or Xorg) but no vt has it."

Follow your own advise on comment #19 and do not group the gdm3 issue together with the delay on lightdm

[njsf (nelson-ferreira)]

@Mark, I just used the browser and let the software installer mime-type binding take care of it.

Be warned: after installing this my splash screen was gone (it was using xubuntu theme), so you may need to reconfigure that afterwards

[njsf (nelson-ferreira)]

To restore the splash I reinstalled the ubuntu plymouth.

 apt-get install plymouth=0.9.3-1ubuntu7

[Charles Burns (chasb)]

Installing plymouth 0.9.3-3 over the distro 0.9.3-1 had no effect on this system - amd64 - either.
Steps taken with dpkg for a hash-checked .deb were:

Preparing to unpack .../plymouth_0.9.3-3_amd64.deb ...
Unpacking plymouth (0.9.3-3) over (0.9.3-1ubuntu7) ...
Setting up plymouth (0.9.3-3) ...
update-initramfs: deferring update (trigger activated)
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Processing triggers for systemd (237-3ubuntu10) ...
Processing triggers for ureadahead (0.100.0-20) ...
ureadahead will be reprofiled on next reboot
Processing triggers for man-db (2.8.3-2) ...
Processing triggers for initramfs-tools (0.130ubuntu3.1) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-24-generic

Apt complained about some redundancies, which I deleted.

After uninstalling haveged, the system hung indefinitely once more at various advices of processes waiting, depending on the 3 restarts I tried. GDM featured variously, as did utmp. Not knowing much at that level, I can only report that plymouth 0.9.3-3 doesn't fix the hang I reported upthread. Nor does it change the lack of either keyboard or usb mouse/touchpad access for at least 90s of that hang.
Another symptom, just noticed because of all the restarts, is that wireless networking gets a
significant delay before kicking in after the handover to Gnome - about 30s. With the 16.04 I dual
boot this machine to, wireless networking is ready to go almost as soon as the UI is up.

Reinstalling haveged returns the good handover to Gnome - about 20s, but wireless networking stays
slow to begin its work.

Note that uninstalling plymouth 0.9.3-3 returns the listing of 0.9.3-1 to the system, but a
couple of the Ubuntu display dependencies needed also to be reinstalled to get back a
coherent recognisable splash screen progress.
Probably time for me to get familiar with using the shell at startup. That UI looks like a real
curate's egg and this is a significant bug (or set of bugs maybe).

[Charles Burns (chasb)]

Further to the above on wireless start, booting into *.23 kernel, Bionic loses all the retarding
symptoms for Gnome start and for wireless network start.

[Daniel van Vugt (vanvugt)]

gdm3 failing to start is part of the boot process. But I'm happy to change it back.

[Daniel van Vugt (vanvugt)]

OK, it sounds like plymouth is actually not related to this bug. In that case maybe we need to make this a duplicate of bug 1779827, which already has the kernel team involved.

[njsf (nelson-ferreira)]

I have serious doubts it is the same issue.
Even with haveged installed I do not get gdm3 to start as I have stated several times already.

Please do not mark as a dup of that issue
On Jul 8, 2018, 22:40 -0400, Daniel van Vugt <email address hidden>, wrote:
> OK, it sounds like plymouth is actually not related to this bug. In that
> case maybe we need to make this a duplicate of bug 1779827, which
> already has the kernel team involved.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1779476
>
> Title:
> Ubuntu 18.04: gdm3 does not switch to graphics after update
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1779476/+subscriptions

[Daniel van Vugt (vanvugt)]

If installing haveged doesn't help the original reporter then that means everyone for whom it did help is commenting on the wrong bug.

Please see comment #19.

[Daniel van Vugt (vanvugt)]

njsf,

The next step is that we need to find out what/where things broke for you.

First, please try downgrading gdm3 to the original 18.04 release version:

  https://launchpad.net/ubuntu/+source/gdm3/3.28.0-0ubuntu1/+build/14516225

If that doesn't solve it then please try some older kernels and find which is the last version that works for you:

  http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D

[Daniel van Vugt (vanvugt)]

Everyone else, please either:

  * Wait and watch here without commenting about your own experiences; or
  * Check out bug 1779827 to see if it helps you; or
  * If you are using an older Intel GPU then see bug 1727356; or
  * Log a new bug of your own.

[njsf (nelson-ferreira)]

NOTE: Results w/ haveged installed...

I installed gdm3 3.28.0-ubuntu1 with:

apt-get install gdm3=3.28.0-0ubuntu1 libgdm1=3.28.0-0ubuntu1 gir1.2-gdm-1.0=3.28.0-0ubuntu1

After reboot gdm3 would still not start.

After I noticed the path used I decided to:

rm -rf /var/lib/gdm3/*
rm -rf /var/lib/gdm3/.[a-z]*

After a reboot gdm3 started both w/ Xwayland and Xorg

It seems that the upgrade to kernel 4.15.0-24 together w/ gdm3 upgrade caused some corruption of the gdm3 cached contents under /var/lib/gdm3 that prevented it from starting.

IMO this is not an easy thing to troubleshoot as nothing in the logs indicated any issue.
It is could also be preventable: have the gdm3 package always clear /var/lib/gdm3 as the next start will recreate.

As it stands now, my issue of gdm3 not starting is resolved, the haveged/entropy dependency is properly tracked by bug 1779827.

Leave it up to you whether you want to use this bug to improve the gdm3 upgrade process or close it as I documented how I fixed it

[Daniel van Vugt (vanvugt)]

Great. Thanks for figuring that out.

Was there any sign of corruption? Were you able to upgrade gdm3 to the latest version again?

I wonder - if it happens again then please check:
  1. if your disk/partition is full (run: df -h); or
  2. if the disk has experienced any hardware errors (run the Disks app > burger menu > SMART Data & Self-Tests...).

If most other people here are experiencing bug 1779827 instead of this then it is possible this bug was entirely unique to your machine.

[njsf (nelson-ferreira)]

There was no sign of corruption. Once the original gdm3 also failed and given that the config in etc was the original, the only thing left to check was the var/lib that I saw referenced in the Xorg cmdline.

I was able to upgrade gdm3 without problems.
The SSD did not run out of disk space it has several tens of Gb free.
I will check the SMART stats later but I doubt it had any.
On Jul 9, 2018, 22:15 -0400, Daniel van Vugt <email address hidden>, wrote:
> Great. Thanks for figuring that out.
>
> Was there any sign of corruption? Were you able to upgrade gdm3 to the
> latest version again?
>
> I wonder - if it happens again then please check:
> 1. if your disk/partition is full (run: df -h); or
> 2. if the disk has experienced any hardware errors (run the Disks app > burger menu > SMART Data & Self-Tests...).
>
> If most other people here are experiencing bug 1779827 instead of this
> then it is possible this bug was entirely unique to your machine.
>
> ** No longer affects: linux (Ubuntu)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1779476
>
> Title:
> Ubuntu 18.04: gdm3 does not switch to graphics after update
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1779476/+subscriptions

[njsf (nelson-ferreira)]

No hardware errors on the Smart counters

[Daniel van Vugt (vanvugt)]

OK. If you rediscover this bug in the next two months and figure out the exact cause then that would be helpful. Otherwise the bug will automatically close if no further comments are added after two months.

[Daniel van Vugt (vanvugt)]

I wonder if bug 1780986 is related...

[Kurt Smolderen (kurt.smolderen)]

I tried the solution suggested by njsf (clearing /var/lib/gdm3) and it rescued my system as well.

As suggested by Daniel I validated whether the disk was in a deteriorated state, but this was not the case.

[Kurt Smolderen (kurt.smolderen)]

Thinking about it, I could better have copied the old content to see if I could reproduce the bug by restoring the old values of the folder.

[Daniel van Vugt (vanvugt)]

That's intriguing. Yes please - next time this happens to anyone please copy/move the folder contents instead of deleting them.

[Mark Fraser (launchpad-mfraz)]

Recently upgraded 2 computers to Kubuntu 18.04 and I'm also seeing this problem in that the Kubuntu splash screen stays up for ages. As I have only just upgraded my only other kernel was from 4.13. Installing haveged seems to have fixed it on one computer at least.

[Daniel van Vugt (vanvugt)]

Mark,

You are commenting on the wrong bug. Please see bug 1779827 or create a new one.

[Joachim Schwender (jschwender)]

I noticed similar effect with very recent (4.17) kernels. In 4.16.8 there were changes in random.c due to a security flaw. The function that detects "having enough entropy" is now strictly blocking. In the early boot phase this is bad on any machine without enough entropy sources. The kernel has 3 such sources: character devices, block devices and interrupts. On newer machines you can also have hardware random engines like in intel cores gen3+ (ivy bridge). This effect does not appear on computers with such a hw-rng. If you have one without hw-rng, and with a SSD only (they are not used for entropy gathering) and you don't mode your mouse, you are likely seeing this. The bad thing is, this kernel patch is actually necessary to prevent the system starting with insufficient safe random numbers. I applied a patch that removes commit 43838a23a05fbd13e47d750d3dfd77001536dd33 in the kernel. After this change the startup worked like expected, but this is not a solution as it re-invents CVE-2018-1108. An idea would be to add a hw-rng like https://www.crowdsupply.com/13-37/infinite-noise-trng, but i did not test that so far. Check your cpu for the rdrand flag (lscpu). An entropy deamon like rngd helps only if you have entropy sources that it can use.

[Daniel van Vugt (vanvugt)]

Joachim,

You are commenting on the wrong bug. Maybe see bug 1779827 instead. Otherwise please log a new bug of your own by running: ubuntu-bug linux-generic

[Launchpad Janitor (janitor)]

[Expired for gdm3 (Ubuntu) because there has been no activity for 60 days.]

[bnhede (bnhede-gmail)]

I had similar issues where the upgrade from 16.04 to 18.04 resulted in blank screen,
The key to finding the problems was reviewing the errors in the file /var/log/syslog

gnome-session[2851]: X Error of failed request: BadValue (integer parameter out of range for operation)
gnome-session[2851]: Major opcode of failed request: 154 (GLX)
gnome-session[2851]: Minor opcode of failed request: 3 (X_GLXCreateContext)
gnome-session[2851]: Value in failed request: 0x0
gnome-session[2851]: Serial number of failed request: 19
gnome-session[2851]: Current serial number in output stream: 20
gnome-session[2851]: gnome-session-check-accelerated: GL Helper exited with code 256
gnome-session-c[2979]: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-4UdC671MtT: Connection refused
gnome-session-c[2979]: eglGetDisplay() failed
gnome-session[2851]: gnome-session-check-accelerated: GLES Helper exited with code 256
gnome-session-c[2980]: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-4UdC671MtT: Connection refused
gnome-session[2851]: X Error of failed request: BadValue (integer parameter out of range for operation)
gnome-session[2851]: Major opcode of failed request: 154 (GLX)
gnome-session[2851]: Minor opcode of failed request: 3 (X_GLXCreateContext)
gnome-session[2851]: Value in failed request: 0x0
gnome-session[2851]: Serial number of failed request: 19
gnome-session[2851]: Current serial number in output stream: 20
gnome-session[2851]: gnome-session-check-accelerated: GL Helper exited with code 256

The solution was found in the outline in the link below, to remove the nvidia drivers.
I was surprised this was the solution as my system ran on intel integrated gpu. However its hard to know how things precipitate till they do.

https://www.osso.nl/blog/ubuntu-bionic-crashing-gdm-eglgetdisplay/

First I changed the display manager to lightdm.

$ sudo apt-get install lightdm
$ sudo dpkg-reconfigure lightdm

to select lightdm as the default desktop manager

Then the login screen came up. However , I entered the famous ubuntu login loop , where upon successful login to the system resulted into the same greeter screen again instead of navigating into the desktop.

$ dpkg -l | grep nvidia
$ sudo apt-get remove --purge nvidia-***

Voila, the system starts again as before .

I also had issues with the gnome themes, which cause the menus and window title bars to disappear. I had to install the gnome "tweaks" program to select the right theme and things were back.

[Daniel van Vugt (vanvugt)]

This bug is closed. Please open a new bug if you have any problems.