CentOS8 Boot Black Screen After Kernel Selection

linuxbecauseideology · 01-08-2021, 08:07 AM

Okay, so I'm at my wits end here.

On CentOS8, and every time I boot, I get to the kernel selection, pick the kernel as usual, then it gets to those 3 loading dots, and then a black screen. Occasionally, it will flash the readout of what's happening then stay black.

The odd thing is that since I've moved from CentOS7 to CentOS8, 8 has always had this boot bug, and the fix was to just restart a couple times, and it would eventually boot into the GUI.

But since today, I've tried rebooting numerous times (10+), and it won't boot into the GUI as normal. I'm actually on the desktop now but that was after 20+ reboots.

So, I went in and checked with systemctl and then journalctl, there were no issues I could find.
But I'm assuming it's the nvidia driver because I'm using Xorg with 450.80.02

(because apparently nvidia cards work badly with wayland, and I need an nvidia card because I use davinci resolve, which works poorly with AMD apparently.)

and I've had issues with nvidia drivers before, so I'm assuming it's that.

I recently updated Inkscape and exfat-utils but I uninstalled them thinking they may be the issue. They were not the issue.

I also tried this https://forums.centos.org/viewtopic.php?t=74712, which was a script that has something to do with xorg. But that hasn't seemed to work.

As you can imagine, it's frustrating. Please help.

jsbjsb001 · 01-08-2021, 11:23 AM

Quote:

Originally Posted by linuxbecauseideology

Okay, so I'm at my wits end here.

On CentOS8, and every time I boot, I get to the kernel selection, pick the kernel as usual, then it gets to those 3 loading dots, and then a black screen. Occasionally, it will flash the readout of what's happening then stay black.

The odd thing is that since I've moved from CentOS7 to CentOS8, 8 has always had this boot bug, and the fix was to just restart a couple times, and it would eventually boot into the GUI.

But since today, I've tried rebooting numerous times (10+), and it won't boot into the GUI as normal. I'm actually on the desktop now but that was after 20+ reboots.

So, I went in and checked with systemctl and then journalctl, there were no issues I could find.
But I'm assuming it's the nvidia driver because I'm using Xorg with 450.80.02

(because apparently nvidia cards work badly with wayland, and I need an nvidia card because I use davinci resolve, which works poorly with AMD apparently.)

and I've had issues with nvidia drivers before, so I'm assuming it's that.

I recently updated Inkscape and exfat-utils but I uninstalled them thinking they may be the issue. They were not the issue.

I also tried this https://forums.centos.org/viewtopic.php?t=74712, which was a script that has something to do with xorg. But that hasn't seemed to work.

As you can imagine, it's frustrating. Please help.

A few questions:

Is this a clean install of CentOS 8?
If it is a clean install of CentOS 8; did the NVIDIA drivers install without any problems?
How did you install the NVIDIA driver (eg. from packages from ELRepo or the .run installer downloaded from NVIDIA's website)?
Can you get to the console without loading the graphical environment?
Can you post the X log recorded when the graphical environment fails to load?

The X log is at:

Code:

/var/log/Xorg.0.log

linuxbecauseideology · 01-08-2021, 11:54 AM

No, not a clean install. I've had it installed for about a month now. Literally installed a few days before they announced the new EOL.

I installed the nvidia drivers via Elrepo, yes.
I can only get to the console without loading the graphical environment if I add "rd.break" into grub.

But I'm logged in right now, and in the GUI. I won't shutdown until I've solved this because it will take 20 boots to get back to the GUI again.

Attached the xorg log as a PDF because of the character limit.

jsbjsb001 · 01-08-2021, 12:12 PM

You can add "3" at the end of your kernel parameters to boot into the console without loading the graphical environment.

Anyhow, and based on the link you posted; it looks like you need to run the follow command as root:

Code:

setsebool -P domain_can_mmap_files 1

And also rename or delete the /etc/X11/xorg.conf file. I suggest to just rename xorg.conf to xorg.conf.old As your X log does look a little funny, although I couldn't see any actual errors it in though.

Try the above and see if you still have the same problem. If you do still have the same problem, use the "3" kernel parameter to get to the console by adding it at the GRUB screen, then make sure you grab the X log and re-post it here in that case. It's important that you get the log when it actually fails to load the graphical environment rather than after it has loaded the graphical environment, so we can hopefully see any error messages written to it.

mrmazda · 01-08-2021, 06:45 PM

Quote:

Originally Posted by linuxbecauseideology

apparently nvidia cards work badly with wayland, and I need an nvidia card because I use davinci resolve, which works poorly with AMD apparently.)

and I've had issues with nvidia drivers before, so I'm assuming it's that.

NVidia's drivers don't have a stellar reputation with Plymouth, so if Plymouth is enabled, try disabling it, or uninstalling it. I prefer seeing all those text messages zooming by, so I never have it enabled, and in most installations, I have it explicitly blocked from installation.

linuxbecauseideology · 01-09-2021, 04:04 AM

Quote:

Originally Posted by mrmazda

NVidia's drivers don't have a stellar reputation with Plymouth, so if Plymouth is enabled, try disabling it, or uninstalling it. I prefer seeing all those text messages zooming by, so I never have it enabled, and in most installations, I have it explicitly blocked from installation.

I'll give it a try.

linuxbecauseideology · 01-09-2021, 04:14 AM

Quote:

Originally Posted by jsbjsb001

You can add "3" at the end of your kernel parameters to boot into the console without loading the graphical environment.

Anyhow, and based on the link you posted; it looks like you need to run the follow command as root:

Code:

setsebool -P domain_can_mmap_files 1

And also rename or delete the /etc/X11/xorg.conf file. I suggest to just rename xorg.conf to xorg.conf.old As your X log does look a little funny, although I couldn't see any actual errors it in though.

Try the above and see if you still have the same problem. If you do still have the same problem, use the "3" kernel parameter to get to the console by adding it at the GRUB screen, then make sure you grab the X log and re-post it here in that case. It's important that you get the log when it actually fails to load the graphical environment rather than after it has loaded the graphical environment, so we can hopefully see any error messages written to it.

Had to get permissions to delete files in the log folder, so I right clicked in the /var/ directory, and selected "open in terminal". Then used

Code:

chmod 777 log

Then I renamed the "Xorg.0.log" to "Xorg.0.log.old2" because there was already one that had ".old".

Then I rebooted to let it fail.
Turned off my pc with the power off button.
Booted up again and added "3" to the end of the Linux line in grub at the kernel stage.

Logged in via the command line.

Then used

Code:

 cat /var/log/Xorg.log.old >> xorgpoop.txt

which created a text file for the xorg log, and placed it in my Home directory.

I've attached that file here.

jsbjsb001 · 01-09-2021, 06:39 AM

Quote:

Originally Posted by linuxbecauseideology

Had to get permissions to delete files in the log folder, so I right clicked in the /var/ directory, and selected "open in terminal". Then used

Code:

chmod 777 log

Then I renamed the "Xorg.0.log" to "Xorg.0.log.old2" because there was already one that had ".old".
...

I was talking about renaming the /etc/X11/xorg.conf file to /etc/X11/xorg.conf.old not renaming the X log file. This way you could not have it loaded by X, but still have a copy of it in case it didn't help. You should not be giving all permissions to all users by running chmod 777 - so you should undo that.

But yes, I did mean copying the X log to somewhere safe and posting it here as you've done.

In any case, we can confirm it is the NVIDIA driver that is preventing your graphical environment from loading:

Code:

[    47.173] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU at PCI:16:0:0.  Please
[    47.173] (EE) NVIDIA(GPU-0):     check your system's kernel log for additional error
[    47.173] (EE) NVIDIA(GPU-0):     messages and refer to Chapter 8: Common Problems in the
[    47.173] (EE) NVIDIA(GPU-0):     README for additional information.
[    47.173] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA graphics device!
[    47.173] (EE) NVIDIA(0): Failing initialization of X screen

...so now that we can confirm that, we need to see what's in the kernel log about it. So repeat the same process as you did when you got the last X log, boot into the console, and run the following command (as a normal user), and post the contents of the resulting file;

Code:

dmesg | grep nvidia > ~/kernel_log.txt

linuxbecauseideology · 01-09-2021, 11:18 AM

Quote:

Originally Posted by jsbjsb001

I was talking about renaming the /etc/X11/xorg.conf file to /etc/X11/xorg.conf.old not renaming the X log file. This way you could not have it loaded by X, but still have a copy of it in case it didn't help. You should not be giving all permissions to all users by running chmod 777 - so you should undo that.

But yes, I did mean copying the X log to somewhere safe and posting it here as you've done.

In any case, we can confirm it is the NVIDIA driver that is preventing your graphical environment from loading:

Code:

[    47.173] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA GPU at PCI:16:0:0.  Please
[    47.173] (EE) NVIDIA(GPU-0):     check your system's kernel log for additional error
[    47.173] (EE) NVIDIA(GPU-0):     messages and refer to Chapter 8: Common Problems in the
[    47.173] (EE) NVIDIA(GPU-0):     README for additional information.
[    47.173] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA graphics device!
[    47.173] (EE) NVIDIA(0): Failing initialization of X screen

...so now that we can confirm that, we need to see what's in the kernel log about it. So repeat the same process as you did when you got the last X log, boot into the console, and run the following command (as a normal user), and post the contents of the resulting file;

Code:

dmesg | grep nvidia > ~/kernel_log.txt

This is what came up in the kernel log

Code:

[    2.925128] nvidia: loading out-of-tree module taints kernel.
[    2.925136] nvidia: module license 'NVIDIA' taints kernel.
[    2.937552] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[    2.948037] nvidia-nvlink: Nvlink Core is being initialized, major device number 238
[    2.965251] nvidia 0000:10:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
[    3.234013] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  450.80.02  Wed Sep 23 00:48:09 UTC 2020
[    3.235315] [drm] [nvidia-drm] [GPU ID 0x00001000] Loading driver
[    3.235317] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:10:00.0 on minor 0
[   16.987885] caller _nv000745rm+0x1af/0x200 [nvidia] mapping multiple BARs
[   33.722761] caller _nv000745rm+0x1af/0x200 [nvidia] mapping multiple BARs
[   35.576986] caller _nv000745rm+0x1af/0x200 [nvidia] mapping multiple BARs
[   41.323104] caller _nv000745rm+0x1af/0x200 [nvidia] mapping multiple BARs

jsbjsb001 · 01-09-2021, 12:02 PM

Was that the kernel log when it failed to load the graphical environment?

Because for the same reason as I said about getting the X log when the graphical environment failed to load, it's also important to get the NVIDIA related parts of the kernel log when the graphical environment fails to load.

If the graphical environment did load successfully when that kernel log posted above was written, try to grab the NVIDIA related parts of the kernel log when the graphical environment fails to start, and then post it here.

linuxbecauseideology · 01-09-2021, 01:17 PM

Can't grab the kernel log right when it fails because I can't get into the command line. I must reboot and go into grub.

But when I do that, the logs don't output the errors. I've tried 3 times now.

mrmazda · 01-09-2021, 03:35 PM

Quote:

Originally Posted by linuxbecauseideology

I need an nvidia card because I use davinci resolve, which works poorly with AMD apparently.)

What do NVidia's drivers provide that the two competent FOSS X drivers do not provide that Davinci Resolve requires?

Note that Nouveau is not the only FOSS X driver for NVidia. This primer may provide insight.

mrmazda · 01-09-2021, 03:44 PM

Quote:

Originally Posted by linuxbecauseideology

Can't grab the kernel log right when it fails because I can't get into the command line. I must reboot and go into grub.

Do you have access to another networked PC or laptop? If so, you should be able to remotely login via ssh to fetch logs.

linuxbecauseideology · 01-09-2021, 03:45 PM

Quote:

Originally Posted by mrmazda

What do NVidia's drivers provide that the two competent FOSS X drivers do not provide that Davinci Resolve requires?

Note that Nouveau is not the only FOSS X driver for NVidia. This primer may provide insight.

I can't remember exactly but seth goldin provided the instructions that I followed when I did my install

https://sethgoldin.github.io/install...esolve-centos/

Actually, I think I remember Blackmagicdesign themselves specifying what drivers to install that suit the program best. And it's the one I have installed.

I also tried disabling plymouth like you suggested. Wasn't the solution, unfortunately.

mrmazda · 01-09-2021, 04:27 PM

Those instructions make no mention that NVidia's own drivers are a requirement. It could be that their use is an obsolete legacy from the period when the only FOSS option was the reverse-engineered Nouveau X driver.

A newer technology alternative was introduced around 8 years ago, after KMS was well entrenched in the kernel. Its name is Modesetting. It became the upstream default, and included with it, in server 1.17.x around six years ago. It's automatically employed when the optional Nouveau DDX driver is not installed, and can be specifically configured via /etc/X11/xorg.con* in any event, as long as none of NVidia's proprietary software or supporting configuration modifications are present.

Knowledge of the Modesetting DDX is rather uncommon, as most distros' default installations include either every DDX package, or install at least one that is specific to the GPU present at installation time.

If Davinci Resolve doesn't require some particular feature(s) that the Modesetting DDX doesn't support, it may be worth trying.