Bug#897975: [gdm3]

[rastersoft]

Package: gdm3
Version: 3.28.2-2

Found extra info that, in my opinion, points to a race condition during 
boot process, as already commented in my previous entry.

In my system, when I install debian SID in a mechanical hard disk, GDM3 
boots fine and allows me to enter in both X11 and Wayland.

But if I install debian SID in a SSD hard disk, previously GDM3 didn't 
shown, like other people commented. Now it seems to work sometimes, but 
still it only gives me access to X11, not to wayland.

If I enter a session and exit, now GDM3 allows me to choose Wayland.

In my laptop, with an Intel graphic card, this doesn't happen: I can use 
Wayland freely. In my desktop I have a PCI Express AMD/ATI graphics card.

I tried today to install directly debian testing in my SSD, with gnome 
shell, and after booting I found that GDM didn't work because my graphic 
card lacked the firmware (which is available in non-free, so I had to 
add that repo and install the package).

After several tests, I started to suspect that the problem could be in 
the firmware loading: my hypothesis is that when I use my SSD hard disk, 
the loading is so fast that the graphic card is still not available when 
GDM tries to boot in Wayland mode, so it fails and tries again in X11 
mode. At this moment it has ended loading the firmware as is available, 
so this mode succeeds, but without offering Wayland because that failed 
before. If I enter a session and exit, GDM is reloaded and this time the 
Wayland mode works because the graphics card's firmware is already loaded.

To test this I renamed /usr/sbin/gdm3 to /usr/sbin/gdm3_bin, and created 
a little script at /usr/sbin/gdm3 that waits 3 seconds before launching 
the true gdm3. With this quick and dirty hack everything works fine: 
GDM3 is always shown after booting, and I have Wayland available.

Of course, this is not a true solution: the system should wait until the 
graphics card is fully available before continuing loading, and not just 
"add a delay". But I think it proofs that there is some kind of race 
condition during boot.


--- System information. ---
Architecture:
Kernel: Linux 4.16.0-2-amd64

Debian Release: buster/sid
500 unstable ftp.debian.org
500 stable packages.microsoft.com
500 stable dl.google.com

--- Package information. ---
Depends (Version) | Installed
============================================-+-===============
libaccountsservice0 (>= 0.6.37) | 0.6.45-1
libaudit1 (>= 1:2.2.1) | 1:2.8.3-1
libc6 (>= 2.14) |
libcanberra-gtk3-0 (>= 0.25) |
libcanberra0 (>= 0.2) |
libgdk-pixbuf2.0-0 (>= 2.22.0) |
libgdm1 (= 3.28.2-2) |
libglib2.0-0 (>= 2.39.4) |
libgtk-3-0 (>= 3.0.0) |
libkeyutils1 (>= 1.5.9) |
libpam0g (>= 0.99.7.1) |
libselinux1 (>= 1.32) |
libsystemd0 |
libwrap0 (>= 7.6-4~) |
libx11-6 |
libxau6 |
libxcb1 |
libxdmcp6 |
debconf (>= 0.5) |
OR debconf-2.0 |
gir1.2-gdm-1.0 (= 3.28.2-2) |
adduser |
libpam-modules (>= 0.72-1) |
libpam-runtime (>= 0.76-13.1) |
libpam-systemd |
gnome-session-bin (>= 3.10) |
gnome-settings-daemon (>= 3.24) |
gnome-shell (>= 3.19.92) |
gnome-session |
OR x-session-manager |
OR x-window-manager |
OR x-terminal-emulator |
lsb-base (>= 3.2-14) |
librsvg2-common |
accountsservice (>= 0.6.35) |
policykit-1 (>= 0.105-5~) |
gsettings-desktop-schemas |
libglib2.0-bin (>= 2.35.0) |
dconf-cli (>= 0.20) |
dconf-gsettings-backend (>= 0.20) |
ucf |
x11-common (>= 1:7.6+11) |
x11-xserver-utils |


Recommends (Version) | Installed
=============================-+-===========
zenity | 3.28.1-1
xserver-xephyr | 2:1.20.0-2
x11-xkb-utils | 7.7+4
xserver-xorg | 1:7.7+19
at-spi2-core | 2.28.0-3
desktop-base (>= 6) | 9.0.7


Suggests (Version) | Installed
=====================================-+-=============
libpam-gnome-keyring | 3.28.2-1
gnome-orca | 3.28.1-1
libpam-fprintd (>= 0.8.0-2) |

-- 
Nos leemos
		         RASTER    (Linux user #228804)
raster at rastersoft.com              http://www.rastersoft.com