When switching to the TTY with Ctrl+Alt+Fx combination, my monitor does not get any display signal. I can still switch back to X server without issues. I tried to narrow the issue down, without much success (e.g. read the Archwiki page about Nvidia issues).
My system (see link below) runs on an Nvidia 1060, I have installed EndeavourOS about a week ago with nvidia drivers, and everything display related works so far. Grub itself displays properly, both graphical and text.
What might be the reason? Maybe an incorrect or missing setting? I did not change anything in that direction from the default installation. I can provide logs if someone would point me to the most useful of them.
On a side note: what would be necessary to add a Grub boot option which does not start X automatically?
Yes of course, and the monitor also … it looks like a graphics mode is chosen which the graphics card cannot process. Or maybe the monitor (but unlikely). I suggest checking what graphics mode should be selected and which is actually selected. But I don’t know much about these low level internals yet.
Can’t see a reason so far, but logs are always useful.
Usually a “normal” login is the situation where nvidia can fail. Never heard that that TTY fails if normal login doesn’t.
You can use the eos-log-tool after the problem and show the journal of the situation when that happens.
The tool gives you an URL address, please show it here.
I did a fresh reboot, tried to switch to tty, then returned after a few seconds. Then I created a log with default settings of eos-log-tool, mainly the boot journal: https://clbin.com/jZHKT
@petsam All the combinations from Ctrl+Alt+F1 to F6 do the same thing, presumably switching to tty in some kind of text mode. But for all of them my monitor goes into „I don’t know this!“ mode.
I also checked with another monitor, using DVI, HDMI and DP over HDMI cable. Same results, so I’m pretty sure it’s graphics mode related.
Thanks for the hint to GRUB settings. I fiddled around a bit with them. So far my results:
The GRUB framebuffer itself seems not to be the problem. I can boot up with both graphics and text/console output.
I can also boot up with the kernel in graphics or in text mode. The initial problem remains after entering GUI.
Being curious, I booted the kernel with runlevel 3 (no automatic X display server). These led to following two interesting insights:
Starting the kernel in graphics mode (same like GRUB) gives me indeed the TTYs and I can start the X server afterwards. I can also switch back to any TTY but not re-switch to X, which then gives me a black screen.
Starting the kernel in text mode (no matter if GRUB was graphics or text) boots properly and displays the TTY login for a fraction of a second, then changes the display signal – back to the initial problem!
This is quite confusing.
I might check later with another graphics driver (e.g. nouveau instead of nvidia).
Edit: the kernel boot parameters are rw efi_no_storage_paranoia loglevel=3 nowatchdog nvme_load=YES nvidia-drm.modeset=1 (I removed the root and resume params).
efi_no_storage_paranoia [EFI; X86]
Using this parameter you can use more than 50% of
your efi variable storage. Use this parameter only if
you are really sure that your UEFI does sane gc and
fulfills the spec otherwise your board may brick.
That was the exact reason. efibootmgr did not let me change the boot order, and my mainboard’s UEFI does not provide an option to sort them in firmware. Everything’s sorted out, so I might remove this option now. (But don’t think it’s the reason …)
Edit:
After a lot experimenting (and learning) I should have been back to the initial configuration, but I’m not sure. GRUB boots up in 1024x768. It might have been 800x600 before, because that’s what GRUB_GFXMODE=auto sets, and which then fails to display the TTY. In 1024x768 though, the ttys work as described above. I can switch to them, but cannot switch back to X because I have a black screen then.
So my findings up to now:
kernel graphics mode set to text or lower than 1024x768: no display signal for tty (or just for a tenth of a second after starting getty)
kernel graphics mode set to 1024x768: tty works, no switching back to X
Also when booting in runlevel 3, starting X (lightdm.service) will result in the mentioned black screen. It only works when being automatically started.
Boy, what a mess. Do I really have to puzzle around in this …?
That is a strange problem. I’m also using Nvidia card (1030) and everything works well.
Maybe checking all settings (kernel parameters, blacklists, /etc/X11/xorg.conf.d contents, etc.) one by one might reveal the issue. Try to find minimal configuration settings that works.
And as you already thought, trying nouveau is also a useful test.
Another DM (like sddm) or Desktop might be good to try, if nothing else helps… maybe that way you’ll get to the root of the issue?
Thanks for the encouragement. I will try to get a minimal working configuration, but do not yet have enough knowledge about these rather low-level kind of things. Can you show me some starting points, e.g. how to use blacklists, xorg conf, or even switching the display manager? (Without breaking anything …)
I am experienced in low level things on Windows but not so much on Linux yet.
Also I am curious about your setup: do you have tty in native monitor resolution? From what I learned yet I can only set any resolution supported by GRUB (using efifb, which limits to what the UEFI supports – for me 1024x768). Or is it possible changing the TTY resolution afterwards? (Just a nice-to-have thing, not really an issue.)
Your logs say EFI is using 800x600, which can be passed to grub with auto. keep will try to keep 1024x768 (when set).
Your monitor may have a broken/unreadable/bad EDID, when read from Linux system.
Nvidia driver may have some helpful module parameter/value that could help (modinfo nvidia).
Testing nouveau (uninstalling nvidia) may show some improvement or other attitude.
Proper KMS settings may be critical (missing or wrong) (mkinitcpio.conf)
SDDM may change things (DM and TTYs are cooperating).
Your system’s exact settings may make a difference in finding a solution (or not).
grep -v "^#" /etc/default/grub | grep .
grep -v "^#" /etc/mkinitcpio.conf | grep .
ls -l /etc/X11/xorg.conf.d/ # post contents, if files exist (except keyboard from localectl)
cat /var/log/Xorg.0.log # to a pastebin web service
The graphics card is almost the newest piece here and the one creating the problems. Also I like my hardware …
I did a lot of possible tricks (e.g. change DM) without success, then finally tried switching to nouveau and back (which is not easy, but at least the Wiki lists all things that can go wrong …) So, after a lot of testing and x times rebooting, I can say: it works with nouveau but not with nvidia-dkms.
About the resolution in GRUB / on startup: I seem to be stuck with the old UEFI, but 1024x768 is fine for me. I set the kernel to keep the resolution to avoid flickering. This is not the issue.
If nouveau is active, the kernel starts with 1024x768 until X is started, then seems to be changing to the native monitor resolution of 1920x1080. (I missed to test if the kernel would switch earlier in the boot process if I didn’t have the keep option set.) I can switch to all six TTYs and back without ever changing the display resolution. Works as expected.™ @manuel: Is this working for you in the same way, but with nvidia driver?
If nvidia-dkms is active, TTYs don’t ever change from 1024x768 to a higher resolution. And, as reported, when they use 80x25 text or 800x600, they aren’t even displayed.
I fiddled around with these some days ago (“early KMS”), but apart from loading the graphics driver some seconds earlier it did not make any difference, so I reverted the changes.
For grub and mkinitcpio I cannot see anything suspicious, and except the boot parameter nvidia-drm.modeset=1 they are identical for both drivers.
nvidia (after reinstalling with nvidia-installer-dkms)
The EDID seems not be a problem in general: xrandr can read it, but get-edid is not successful. I also saw the EDID in the Xorg logs, maybe nouveau is smarter then nvidia? I just don’t know where to go from here.
$ pacman -Qs xf86
local/lib32-libxxf86vm 1.1.4-2
X11 XFree86 video mode extension library (32-bit)
local/libxxf86vm 1.1.4-4
X11 XFree86 video mode extension library
local/xf86-input-libinput 1.2.1-1 (xorg-drivers)
Generic input driver for the X.Org server based on libinput
But Cinnamon + Nouveau works … You brought me to an idea. I tried the live image (with XFCE), which provides both graphic drivers and has a somewhat slower bootup time.
Selecting Nvidia drivers, things are same (or similar) as with the installed system. No large resolution for boot messages / tty. When selecting nouveau default drivers, that’s a different picture again: while the system is still booting, the resolution switches to FullHD, some seconds before the GUI comes up. Everything works.
So this is definitively some problem with nvidia (and my computer / monitor?). I already tried forcing the EDID as described here with no success.
Also I like my hardware …