Switching to tty does not display anything (no signal)

General system Newbie
21

Post the exact method and text/data you have used. Sometimes there is a small error or typo that blocks it from working.

From a quick glance in nvidia log, maybe KMS vs nouveau may need some allignment.

I may check more later (sorry, no time now).

22

Nvidia do not have a proper framebuffer working … what can also help in some cases is to set gfx resolution to native from auto in Grub config p.e. :
GRUB_GFXMODE=1920x1080

23

Are you referencing this note?

However, the kernel compiled-in efifb module supports a high-resolution console on EFI systems

I already tried this, but because my UEFI only supports a maximum of 1024x768, I can’t get any more with this setting (and GRUB_GFXPAYLOAD_LINUX=keep). So to understand you correctly: with Nvidia driver I only get what UEFI (via efifb) is capable of, but no guaranteed native monitor resolution for the console?

But to be clear: I don’t insist on a high resolution for GRUB, or for the TTYs. The resolution is fine, really. I just like to have the TTYs fully usable, which they aren’t, because when switching from TTY back to X window I only get a black screen (monitor gets a signal). I just don’t know where to look as to why the GUI won’t re-draw.
And sometimes it even works! But just once. When I think about it, it worked every time after I changed the display manager and rebooted. Could this be a lead?

24

you are using quiet boot or showing the “matrix” :wink: ?

25

This looks like something little is missing only…

26

Maybe…

Because of troubleshooting, changing several settings back and forth, the situation has to be stabilized again.
Here is a list of my suggestions:

  • Since/if you intend to not use custom kernel(s), you don’t need nvidia-dkms package. I suggest you replace it with nvidia (and nvidia-lts if usng linux-lts)
  • nvidia driver does not need any Xorg.conf configuration file (until you need to make customizations), so I suggest you remove any existing nvidia-related *.conf files from /etc/X11/xorg.conf.d/, to start clean.
  • Enabling Early KMS for nvidia seems better 1st choice, since your issue might be related to the display manager. This means your mkinitcpio.conf should include this:
MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

Don’t forget to rebuild kernels (mkinitcpio -P)

  • Disable keep in /etc/default/grub, as a starting point.
#GRUB_GFXPAYLOAD_LINUX=keep
  • As a lucky Cinnamon user, you might need to apply this setting
  • If you are using autologin with LightDM. I suggest you disable it for testing/troubleshooting reasons.
  • If you are using screensaver/session-lock, disable it for testing/troubleshooting

Starting from this setup, reboot twice (don’t ask why…).
Then check TTY swapping and if it fails, check journal logs for errors and post

journalctl --no-hostname --no-pager
systemctl --failed

Good luck! :blush:

Off Topic: I suppose enos-sendlog script removes/replaces hostname and username from journal log for privacy. Part of it can be done with --no-hostname, but it’s not a big deal. But it reminded me of a case a few years ago at another forum, where the user had set:

username=error
hostname=failed

or something similar, which made all efforts to grep for errors and failures to fail badly!!!.. :rofl: :rofl:

27

Ok, thanks a lot for the effort. :slight_smile: I did everything you mentioned, unfortunately same behaviour as before.

I did variants both with and without keep, as to the different behaviour I mentioned several times. We can try to fix either issue, but in the end these are either different ones, or the same with different effects … I might summarize and amend:

Without keep:

  • The kernel switches from Grub’s 1024x768 resolution to 800x600 after loading ramdiskfs (might be when Nvidia is loaded). I can see boot messages until resolution changes.
  • All TTYs in this mode do not send any signal to the monitor, though I can access them and type blindly …
  • I can always switch back from (not visible) TTY to X server without problems, using Ctrl+Alt+F7.
  • journal: https://clbin.com/GaeRS

With keep:

  • The kernel stays in Grub’s 1024x768 resolution.
  • TTYs are and stay visible in this resolution, either directly from start or when switching back to after X is started.
  • After switching from X server to any TTY (which changes display resolution), I cannot switch back properly using Ctrl+Alt+F7. The resolution is changed again (presumably to the native one, I think, as my monitor does not provide exact information), but the screen is black. This also happens if the system is started in multi-user mode (not GUI) first and I start X server manually.
  • journal: https://clbin.com/Pr5JK

I found no obvious error in the journal. systemctl returned no errors.

It seems easier to me to fix the issue with keep, namely the black X window, because sometimes it works, but supposedly only when changing something like the display manager. Maybe looking into what Xserver does?

The longer this goes, the less desire I have this to be working … and Nvidia hates me. :frowning:

28

I can feel that. FYI I have a Fermi (old) nvidia card on my desktop PC and use nouveau successfully, using both Intel iGPU and nvidia (nouveau) with PRIME (DRI_PRIME=1 <appname>). This way I can select nvidia to run obs studio (my Intel is not capable).
I have difficulties with usual DEs with multi-head, so I turned to bspwm and I have peace of mind!!

Your(our?) issue may have workarounds with some nvidia module or kernel parameters (like video=uvesafb:mode_option=1680x1050-24,mtrr=3,scroll=ywrap for example, which I have no idea how to set properly, if there is actually an expected good setting…).

Searching the web may help you, but I can’t (won’t :grin: ) help…
FWIW I still don’t understand what you mean with your descriptions…

In the same spirit, I could answer:
I have a solution that sometimes will work and might be the desired one, or may not. :rofl:

29

I have edited my text a bit, hopefully it is now less confusing. :slight_smile: Just to point out that in the second case (with keep option) things almost work correct, but the screen stays black, though the monitor seems to be switching back to its native resolution.

Thanks again to you and the other users trying to help. I will set the issue aside for awhile, maybe when I have time and passion I will try other things. Sometimes the solution comes by chance … And of course I have learned a lot about the inner workings of the boot process and its configuration.

1 Like
30

Indeed, but still…

They do, but the monitor cannot handle the resolution (or whatever, font etc) setting.

How do you know without feedback? Do you login? What commands do you test and you think they act? Try touching a file in CWD. Type touch testfile in your logged in user session and check if a file with name testfile exists in $HOME/.

Do you mean Cinnamon, or LightDM? A user session may make a difference. Explain.

Re/start LightDM, or startx a Cinnamon session both start X. What do you use? What commands?
Are you using any of the troubleshooting advice at Archwiki? It seems Cinnamon do some abrasive handling of Xorg server and you should check if your issue is because Cinnamon crashes.

Also, check your console settings in /etc/vconsole.conf. A different or wrong setting in the file may help (or not).
When/if you start again troubleshooting, you might want to test applying TTY/console settings using .bashrc. With a test for running in TTY, you can apply specific font or keyboard layout. A console font setting may affect the resolution.

My opinion is that the source of your issue is the monitor (HW). If/when you have another monitor available, try replacing, or adding as second.

Why a failing situation is better than a less succeeding?
IMO without keep is closer to a solution. A proper console setup may be all what you need, or stopping Cinnamon daemons that interfere Xserver/xrandr settings.

Archwiki has several methods for correcting this and also how to start or restart a cinnamon session.

Again, cinnamon and LightDM may not work with your hardware as advertised. Try changing one or both, to see any difference.

Good luck! :slightly_smiling_face:

31

Thanks for more possible things to investigate. I don’t have the time currently for trying out everything you suggested, but I will try to clear misunderstandings, and add more details.

You mixed both behaviour descriptions. But then maybe I am not good at explaining. :disappointed: And yes, it is difficult handling both variants in one topic. Maybe these are two different problems … I don’t know.

Without keep:

  • only lower resolution for TTY (800x600)
  • boot sequences are visible, until nvidia(?) enables a graphics mode the monitor cannot display
    • This is also the case in multi-user target (no GUI).
  • TTY is responsive (e.g. touch a file)
  • GUI always works, no matter how or when it is started. This includes lightdm, Cinnamon or the naked broken thing with two xterms I get, when I type startx (seems to be just xinit).

Withkeep:

  • TTY resolution remains on 1024x768
  • boot sequences are visible, nvidia(?) then still enables a different graphics mode for the consoles. This is indeed a 1920x1080 mode (in fact the same as used for the GUI), but only with 1024x768 pixels upscaled. The monitor can display the TTYs always.
  • GUI only works when started automatically by systemd
  • GUI works not when:
    • starting Linux in multi-user target and then start lightdm.service manually
    • from working GUI switching to TTY and then back

„GUI works not“ means, the GUI should be displayed. The monitor video mode is correct, only the GUI screen is black: the content itself (windows, background, mouse cursor and everything) is missing. The GUI is responsive though, I can touch a file blindly.

I meant GUI generally, but it doesn’t matter whether I am still on lightdm’s login screen, on the Cinnamon desktop or just in the basic thing startx (xinit?) displays. The graphical content is missing.

I tried both startx (which gives some naked and quite unusable graphical screen with two xterm windows) and systemd start lightdm.service. No difference on restart.

But I played around with restarting lightdm. Two additional findings (without interpretation from me):

  • if lightdm has been started (or restarted) manually, after a reboot the GUI already won’t come up automatically (black screen issue). On a second reboot it works again.
  • when rebooting and the black screen occurs initially, sometimes switching to tty and back fixes it. I only once ever get it two times in a row displaying correctly – nothing repeatable though.

I initially did, see here. That was for the initial issue without keep, but I very much doubt it will make a difference on the „no GUI content“ issue.

In the lower resolution mode I have a problem between nvidia and my monitor. The GUI doesn’t have to be started at all.

In the mode with keep it’s „just“ the content of the X server (or whatever program is responsible) that’s missing, but not every time. Something seems to get lost on the way from switching TTY to GUI, responsible for redrawing. I will try a different desktop than Cinnamon (not today), but I am convinced the problem is underlaying. (So it’s still an nvidia-related problem, just with different effect.)

32

I think I will respectfully disagree.
After searching and reading a lot of relevant technical info and bug reports, it is fairly possible (probable) it’s a LightDM and/or Cinnamon bug/issue.

I suggest you install and enable/use SDDM and Plasma. Anyway, the looks you prefer can be achieved easily, even Plasma has a good GTK compatibility and appearance.

33

So idk if anyone figured this out yet, but I had the exact same problem, and it was to do with Intel graphics conflicting with Nividia, so to fix it…

  1. disable keep in grub
  2. set native res in grub
  3. add nvidia nvidia_modeset nvidia_uvm nvidia_drm to your /etc/mkinitcpio.conf in MODULES=()
    3.5 run sudo mkinitcpio -p
  4. add nvidia-drm.modeset=1 to /etc/default/grub in GRUB_CMDLINE_LINUX_DEFAULT=""
    4.5 run sudo grub-mkconfig -o /boot/grub/grub.cfg
  5. (most important) add
install i915 /usr/bin/false
install intel_agp /usr/bin/false

to /etc/modprobe.d/blacklist.conf
6. reboot should fix it right up

btw I run Arch
lol, but for real I run actual Arch as in from the Arch wiki, so I dont know if my fix will work on Endeavor OS, but assuming E-OS is a moderately clean Arch install, then your situation should be the same as mine as is sound way too much like my problem to not be, hopefully I helped in some way

sauce: https://wiki.archlinux.org/title/NVIDIA#Early_loading
https://wiki.archlinux.org/title/mkinitcpio
https://wiki.archlinux.org/title/NVIDIA/Troubleshooting#Black_screen_on_systems_with_Intel_integrated_GPU
https://wiki.archlinux.org/title/GRUB#Generate_the_main_configuration_file
https://wiki.archlinux.org/title/NVIDIA#DRM_kernel_mode_setting

1 Like
34

So, um, I don’t believe you, respectfully, of course.
his issue is clearly graphics related if you just look at what he wrote, plus I replicated the issue on plasma base Arch

not trying to offend, just stating what I believe to be fact here

1 Like
35

Dear fellow Arch user,
I sincerely thank you for the respect :smile: and the contribution to this unsolved mystery.

It’s pretty adding info sources to help understand your proposal. I didn’t click on any :rofl:
I would, if there was a suspicion that one of them would explain how blocking Intel video drivers would improve video behavior on an Nvidia only machine. OP has no Optimus or even Laptop.

Even if it was replicated on a Nvidia only machine with Cinnamon, it would still (probably) be different than OP’s one. Not every system HW/SW is the same.

No offend taken. It’s nice to co-operate with fellow Arch users on solving Linux mysteries :wink:

On topic,

I agree, disagreeing.
Yes, nvidia drivers is the real problem. But we know that, and we can’t do a lot with closed source software, so DM/DE developers try to fix issues in the blind. In this view, they have another issue to solve. If we agree it’s Nvidia’s task, what are the chances that they will fix it? :person_shrugging:
Plus there are other elements of code in the game…