gnome-shell (gdm) not automatically starting after cold boot

[sgseidel]

I have a curious issue with gnome-shell (GNOME DISPLAY MANAGER a.k.a. gdm) not launching automatically after CentOS 7 (with latest patches installed) is "cold started". This issue does not occur when CentOS is "rebooted", nor it does not occur at all when the operating system is CentOS Stream 8 or CentOS Stream 9. Note that in this case CentOS 7, as well as CentOS Stream 8 and 9 are all virtual machines running on Virtualbox 6.1.38 (with Guest Additions 6.1.38 installed) on a mid-2012 Mac Pro running on macOS 10.14.6 with the latest patches.

What is meant by "cold start" is when CentOS 7 is launched from the Oracle VM Virtualbox Manager app running on macOS, and CentOS 7 had previously been halted either with the "sudo shutdown -h now" command in Terminal or with the "Power Off" button in the gdm GUI. if CentOS is restarted with "sudo shutdown -r now" or with the "Reboot" button in the GDM gui, all is well: gdm boots properly and I have no further complaint.

The sequence to reproduce this issue on my system follows.
1. Launch CentOS 7 from the Virtualbox Manager app
2. After a minute or so, the login screen shows up with the name of the non-root administrator (i.e., a sudo user)
3. After clicking with a mouse on the name of the non-root administrator, the password screen shows up and the password is entered. All good up to here.
4. Now, instead of the familiar gdm background, the screen is all black, except for the Home folder and the Trash icons.
5. It is possible to right-click on the black background and bring up a terminal.
6. In the terminal, running as the non-root administrator, if "gnome-shell &" is entered, the expected gdm background comes up properly, everything seems to be working, and all is well.
7. If the system is then stopped with "sudo shutdown -h now" or with the "Power Off" button, and subsequently launched from the Virtualbox app, the identical issue is seen. However, if the system is rebooted with "sudo shutdown -r now" or with the "Reboot" button, the expected gdm background launches automatically and all is well.

One thing I tried is adding the following code to the non-root administrator's .bash_profile

# start /usb/bin/gnome-shell if tty1
JunkFile=junk
echo "DISPLAY is ${DISPLAY}" > ${JunkFile}
echo "tty is ${tty}" >> ${JunkFile}
# if [[ "$DISPLAY" = ":0" ]] && [[ (tty) = tty1 ]]
# if [[ "$DISPLAY" = ":0" ]]
# then
# echo "Start GNOME DISPLAY MANAGER (gdm)" >> ${JunkFile}
# /usr/bin/gnome-shell
# logout
# else
# echo "Did not GNOME DISPLAY MANAGER (gdm)" >> ${JunkFile}
# fi


However, rather than starting gdm, this appears to completely freeze CentOS 7.

Now I realize CentOS 7 is long in the tooth and either nearing or at EOL. However, it annoys me that I can't fix this seemingly obvious issue. I have spent hours over days on Google, trying every likely suggestion, all without success. I have re-installed CentOS from scratch six or eight times, and restarted the system innumerable times, all without success.

Any suggestions are welcome.

[TrevorH]

Recreate the problem and without making it work, go read /var/log/Xorg.0.log and /var/log/messages and see if there is an explanation there.

[sgseidel]

@TrevorH Thanks for your reply.

I have gone through /var/log/Xorg.0.log on CentOS 7 after recreating the problem:

https://pastebin.com/DADBQfCQ

and compared it with /var/log/Xorg.9.log (that is indeed a "nine" and not a "zero") on a CentOS Stream 9 server. Although the files are slightly (and for obvious reasons) different, as far as I could tell there was nothing significantly different except near the end of the CentOS 7 file where there are quite a few connects and disconnects:

[ 31.644] AUDIT: Sat Oct 29 11:44:41 2022: 1806: client 1 connected from local host ( uid=0 gid=0 pid=1925 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 31.651] AUDIT: Sat Oct 29 11:44:41 2022: 1806: client 1 disconnected
[ 31.659] AUDIT: Sat Oct 29 11:44:41 2022: 1806: client 1 connected from local host ( uid=0 gid=0 pid=1951 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 31.668] AUDIT: Sat Oct 29 11:44:41 2022: 1806: client 1 disconnected
[ 31.668] AUDIT: Sat Oct 29 11:44:41 2022: 1806: client 1 connected from local host ( uid=0 gid=0 pid=1379 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 32.780] AUDIT: Sat Oct 29 11:44:42 2022: 1806: client 2 connected from local host ( uid=42 gid=42 pid=1988 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 33.528] AUDIT: Sat Oct 29 11:44:43 2022: 1806: client 3 connected from local host ( uid=42 gid=42 pid=1993 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 33.564] AUDIT: Sat Oct 29 11:44:43 2022: 1806: client 4 connected from local host ( uid=42 gid=42 pid=1996 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 33.710] AUDIT: Sat Oct 29 11:44:43 2022: 1806: client 5 connected from local host ( uid=42 gid=42 pid=1996 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 33.710] AUDIT: Sat Oct 29 11:44:43 2022: 1806: client 5 disconnected
[ 33.727] AUDIT: Sat Oct 29 11:44:43 2022: 1806: client 5 connected from local host ( uid=42 gid=42 pid=1998 )
Auth name: MIT-MAGIC-COOKIE-1 ID: 955
[ 33.728] AUDIT: Sat Oct 29 11:44:43 2022: 1806: client 5 disconnected

...

The /var/log/messages file on the CentOS server does have some indications that there are some problems with gnome-shell:

https://pastebin.com/t7wPutRE

For example, on line 1061 we see: 1061 Oct 29 11:45:06 centOS7 journal: Cannot open display:

Prior to that gnome-shell has core dumped:

1050 Oct 29 11:45:06 centOS7 abrt-hook-ccpp: Process 2494 (gnome-shell) of user 1000 killed by SIGABRT - dumping core

There are numerous other indications of problems with the gnome session at this point:

1048 Oct 29 11:45:06 centOS7 org.gnome.Shell.desktop: **
1049 Oct 29 11:45:06 centOS7 org.gnome.Shell.desktop: mutter:ERROR:backends/x11/meta-monitor-manager-xrandr.c:440:apply_crtc_assignments: assertion failed: (width > 0 && height > 0)
1050 Oct 29 11:45:06 centOS7 abrt-hook-ccpp: Process 2494 (gnome-shell) of user 1000 killed by SIGABRT - dumping core
1051 Oct 29 11:45:06 centOS7 gnome-session-binary[2266]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
1052 Oct 29 11:45:06 centOS7 gnome-session: gnome-session-binary[2266]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
1053 Oct 29 11:45:06 centOS7 org.gnome.Shell.desktop: **
1054 Oct 29 11:45:06 centOS7 org.gnome.Shell.desktop: mutter:ERROR:backends/x11/meta-monitor-manager-xrandr.c:440:apply_crtc_assignments: assertion failed: (width > 0 && height > 0)
1055 Oct 29 11:45:06 centOS7 abrt-hook-ccpp: Process 2503 (gnome-shell) of user 1000 killed by SIGABRT - ignoring (repeated crash)
1056 Oct 29 11:45:06 centOS7 gnome-session-binary[2266]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
1057 Oct 29 11:45:06 centOS7 gnome-session-binary: Unrecoverable failure in required component org.gnome.Shell.desktop
1058 Oct 29 11:45:06 centOS7 gnome-session: gnome-session-binary[2266]: WARNING: Application 'org.gnome.Shell.desktop' killed by signal 6
1059 Oct 29 11:45:06 centOS7 gnome-session: gnome-session-binary[2266]: WARNING: App 'org.gnome.Shell.desktop' respawning too quickly
1060 Oct 29 11:45:06 centOS7 gnome-session-binary[2266]: WARNING: App 'org.gnome.Shell.desktop' respawning too quickly
1061 Oct 29 11:45:06 centOS7 journal: Cannot open display:

However, it's not clear to me why these errors would occur when CentOS 7 is cold booted and not after it has been restarted.

If you have any ideas for further investigation, I'm all ears.

[sgseidel]

For now the workaround is to launch CentOS 7 from the Virtualbox Manager app, select the non-root administrator that is presented, and enter in the password. When the aforementioned black screen comes up, right-click and bring up terminal. In Terminal, type: "sudo shutdown -r now". After the system reboots, the non-root administrator and password are entered, CentOS 7 will correctly bring up the GNOME DISPLAY MANAGER (gnome-shell a.k.a. gdm).