| View previous topic :: View next topic |
| Author |
Message |
gluonman
n00b
Joined: 17 Jun 2025
Posts: 9
|
 Posted: Sun Jun 22, 2025 2:49 am Post subject: [SOLVED] No console output on boot with nvidia-drivers |
 |
|
Hello, my fellow penguin people. I am setting up a Gentoo system for the first time in roughly 8 years, and after much celebrating the successful booting of my initial kernel, the occasion has soured as I have been unable to repeat that success following the installation of the latest version of the proprietary Nvidia drivers (575.64). Here is what's happening now, regardless of the kernel config tweaks I've been trying lately:
I boot my machine and it boots my kernel, but instead of the bootup process being outputted to my screen, I just get the following message:
| Code: | EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: UEFI Secure Boot is enabled |
The screen remains stuck with this output and I am unable to interact. From what I've researched, the system may be booting fine behind the scenes, but there is a failure for the output to reach the appropriate TTY. Usually Alt+F{N} does nothing. And another theory I have read suggests that the bootup process is hanging after those messages without reporting an error. Some people have suggested the normal bootup process continued after waiting a couple minutes, but mine hasn't done that even after waiting up to 10 minutes. So I just power cycle the machine and return to the Gentoo liveUSB and chroot back into my system to try and troubleshoot.
SYSTEM DETAILS
KERNEL DETAILS
The last time I had a working kernel that could boot fine, I had Plymouth installed, but I decided to remove that because it was annoying (it wouldn't die automatically after boot), and after testing my kernel post nvidia-drivers installation the first time, I booted to a completely black screen and I figured nvidia-drivers and Plymouth may not get along well (either the nvidia-drivers wiki article or the Plymouth one warns of that being potentially the case). So I rebooted to the liveUSB and chrooted again and removed Plymouth and rebuilt the kernel again. But after rebuilding nvidia-drivers following that kernel rebuild, Portage sent me a message:
| Code: | CONFIG_DRM_KMS_HELPER: is not set but is needed for Xorg auto-detection
of drivers (no custom config), and for wayland / nvidia-drm.modeset=1.
Cannot be directly selected in the kernel's config menus, and may need
selection of a DRM device even if unused, e.g. CONFIG_DRM_QXL=m or
DRM_AMDGPU=m (among others, consult the kernel config's help), can
also use DRM_NOUVEAU=m as long as built as module *not* built-in.
CONFIG_DRM_FBDEV_EMULATION: is not set but is needed for
nvidia-drm.fbdev=1 support, currently off-by-default and it could
be ignored, but note that is due to change in the future.
Please check to make sure these options are set correctly.
Failure to do so may cause unexpected problems. |
So I enabled CONFIG_DRM (which had been disabled with my bootable kernel) and that unlocked the DRM submenu where CONFIG_DRM_KUNIT_TEST=y was already enabled, which enabled CONFIG_DRM_KMS_HELPER=m. But to unlock the menu needed for me to enable CONFIG_DRM_FBDEV_EMULATION=y, I also enabled CONFIG_DRM_SIMPLEDRM=m. Then I built this kernel (again) and then ran emerge -a @modules-rebuild (again), and after nvidia drivers were rebuilt, Portage dropped me another message:
| Code: | CONFIG_DRM_TTM_HELPER: is not set but is needed to compile when using
kernel version 6.11.x or newer when DRM_FBDEV_EMULATION is set.
Cannot be directly selected in the kernel's config menus, and may need
selection of a DRM device even if unused, e.g. CONFIG_DRM_QXL=m or
DRM_AMDGPU=m (among others, consult the kernel config's help), can
also use DRM_NOUVEAU=m as long as built as module *not* built-in.
Please check to make sure these options are set correctly.
Failure to do so may cause unexpected problems.
Once you have satisfied these options, please try merging
this package again.
ERROR: x11-drivers/nvidia-drivers-575.64::gentoo failed (setup phase):
Incorrect kernel configuration options |
So I disabled CONFIG_DRM_KUNIT_TEST and CONFIG_DRM_SIMPLEDRM and instead enabled CONFIG_DRM_NOUVEAU=m, because DRM_NOUVEAU also selects CONFIG_DRM_KMS_HELPER as well as unlocks the submenu needed to enable CONFIG_DRM_FBDEV_EMULATION (which was previously accomplished with the two I just disabled). And not only that, but CONFIG_DRM_NOUVEAU=m also enabled CONFIG_DRM_TTM_HELPER=m, which needed to get set per the previous Portage error. Hence, this change should satisfy those requirements, but would it eliminate the boot up "error?" Sadly, no. After rebuilding the kernel with this new config, I get the exact same behaviour when booting up with those two EFI stub messages. I also tried booting in non-UEFI mode, but in this case the behaviour is almost the same, just missing the second EFI stub message reporting UEFI Secure Boot being enabled.
I also tried adding console=tty0 to the kernel cmdline, but that didn't do anything. And I have tried one more kernel reconfiguration, where I disabled CONFIG_DRM_NOUVEAU and tried CONFIG_DRM_QXL=m instead. I also enabled CONFIG_FRAMEBUFFER_CONSOLE=y, disabled CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER, disabled CONFIG_FB_SIMPLE, and disabled CONFIG_FB_VESA, only leaving CONFIG_FB_EFI=y enabled. My reasoning was to try to rule out the possibility that different framebuffer devices were interfering with each other, so only enabling one of them, and then also trying to have nothing to do with DRM_NOUVEAU just because the handbook says it's bad. Anyway, long story short, this kernel didn't work either. And no change in symptom, as I'm still just booting up to those two EFI stub messages.
I did notice some kernel build errors about the same time my efforts to configure the kernel for Nvidia started failing. I haven't seen them in the logs, so I don't think my full kernel build output is being logged, so I don't have a paste.gentoo.zip file for that. And I'd have to go through another kernel build to see it again for exact wording (it gets cut off because I can't scroll up on my console and I haven't been using screen or tmux), but to the best of my recollection, those errors involved systemd-cryptsetup. And I have zero clue why anything cryptsetup related would be happening on my system given I'm not using LUKS and haven't configured or installed cryptsetup and aren't using any related USE flags. But the errors are like the following:
| Code: | | dracut[I]: 90crypt: Could not find any command of '/usr/lib/systemd/systemd-cryptsetup'! |
90crypt-gpg and/or 90crypt-loop may also have thrown the same complaint, and then something about a missing key map. I don't remember the entire error. And not sure why I'm getting cryptsetup errors at all, since I did not install cryptsetup or attempt to encrypt my drive or anything like that. I'm also not sure if that error was already happening when I built a successful, bootable kernel prior to nvidia-drivers and I just didn't notice until now. And the error doesn't halt the kernel build process, the install script continues beyond that. The errors might not be relevant to my bootup issue, but I just thought I'd mention it.
I can't think of anything else to add. Short of trying out different DRM devices until I find one that doesn't cause an issue, I'm not sure what to do or what exactly causes my bootup issue. Googling around for answers has lead to not a single repeated solution, everyone has a different reason it happens and a different solution that fixed it for them, and nothing I've tried so far has worked. Without me understanding what exactly the problem is and why it's happening, any continued effort on my part to troubleshoot this is just me taking blind guesses and shots in the dark. But each shot in the dark is expensive because of the amount of time it takes to build the kernel. So help figuring this out would be much appreciated.
Cheers!
_________________
Brought to you by Carl's Jr.
Last edited by gluonman on Sun Jun 22, 2025 7:23 pm; edited 1 time in total |
|
| Back to top |
|
 |
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5829
Location: Bavaria
|
| Posted: Sun Jun 22, 2025 10:30 am Post subject: |
|
|
gluonman,
the "trick" is to enable i915 statically <*> in the kernel to get all options enabled which NVIDIA needs ... and to disable bad options ... we have 3 "SIMPLEs" for graphics; two of them are bad ... the third does not harm (do all changes via "make menuconfig" and not via editing the .config file) ->
| Code: | 1)
CONFIG_SYSFB_SIMPLEFB=y
2)
# CONFIG_DRM_I915 is not set
3)
# CONFIG_DRM_SIMPLEDRM is not set
4)
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=y
# CONFIG_FB_SIMPLE is not set
5)
# CONFIG_FB_DEVICE is not set |
1) BAD. Disable it.
2) enable it as built-in
3) BAD. Leave it disabled
4) Enable all 3
5) Enable it because it is needed by some apps
Why intel_pstate=passive ?
Internal note:
| Code: | CONFIG_CPU_SUP_INTEL=y
CONFIG_CMDLINE="root=PARTUUID=ecebfbf3-ebf0-4d33-b752-0867afef5465 intel_pstate=passive kernel.split_lock_mitigate=0"
Jun 20 19:04:10 Hermes kernel: Hardware name: ASUS All Series/Z97-A, BIOS 3503 04/18/2018 |
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gluonman
n00b
Joined: 17 Jun 2025
Posts: 9
|
| Posted: Sun Jun 22, 2025 12:06 pm Post subject: |
|
|
Thank you, pietinger! This is my first time getting a kernel setup with proprietary Nvidia drivers, so I had no idea about those specific config restrictions. Yes, I know not to just edit the .config directly, since whatever text editor I use won't be aware of config dependencies. I always edit using make *config. Well, I might directly edit .config if I'm, say, just editing my kernel cmdline string, or some other string. But never to enable/disable config parameters.
I won't be able to test out another build until later this afternoon, but I'll test and then report if the changes you suggested fix my issue.
| Quote: | | Why intel_pstate=passive ? |
This is for me to test a theory related to a particularly aggressive ondemand governor. That passive mode with the modded ondemand gov reportedly boosts FPS when gaming by non-negligible amounts, to the point of being a superior option than a performance gov.
_________________
Brought to you by Carl's Jr. |
|
| Back to top |
|
|
gluonman
n00b
Joined: 17 Jun 2025
Posts: 9
|
| Posted: Sun Jun 22, 2025 7:21 pm Post subject: |
|
|
Pietinger, I can confirm the kernel config changes you recommended did in fact do the "trick." Thank you so much, I really appreciate it. The kernel booted just fine, AND I was able to see it and interact with the console.
Cheers!
_________________
Brought to you by Carl's Jr. |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5829
Location: Bavaria
|
| Posted: Sun Jun 22, 2025 7:28 pm Post subject: |
|
|
| gluonman wrote: | | Pietinger, I can confirm the kernel config changes you recommended did in fact do the "trick." [...] |
Happy to hear that! 
| gluonman wrote: | | [...] Thank you so much, I really appreciate it. [...] |
You are very Welcome!
TBH you need only one of them:
| Code: | # CONFIG_FB_VESA i
CONFIG_FB_EFI=y
# CONFIG_FB_SIMPLE |
... but I wanted to be on a safe side. They dont harm ... but if you really want ,you can disable the two you dont need (but this is really not strict necessary) 
Have fun with Gentoo. 
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
gluonman
n00b
Joined: 17 Jun 2025
Posts: 9
|
| Posted: Sun Jun 22, 2025 7:47 pm Post subject: |
|
|
Prior to installing Nvidia drivers, I did have all three of those framebuffer options enabled, but when I was struggling to get things working with Nvidia, I disabled the two I don't technically need just to test if maybe they were somehow interfering with each other. It was a shot in the dark. But with them not causing any issues all being enabled, I'm not worried about it. I'm just happy to be able to proceed with the rest of my setup now.
_________________
Brought to you by Carl's Jr. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
