windows uses a completely different driver. I would say the driver is misconfigured (like incorrect - out of range - resolution). But if the live CD worked properly you can try to check how the kernel was booted and which driver was used. Probably the same settings will help you....

1 members found this post helpful.

Live CD uses Noveau driver. I installed with proprietary Nvidia driver. So yes, I could use Noveau driver to avoid this problem.

However I'd prefer to figure out how to make it work with Nvidia driver, as my understanding is the nvidia driver is supposed to be better, cuz nvidia doesn't share enough details with open source community.

So it looks like Noveau is better.
https://askubuntu.com/questions/1844...ode-resolution
I cannot say anything else, just find out a working config and try to apply it to the nvidia driver. It should work if that was supported. Maybe the old and low-res setups are not supported by the official driver.

1 members found this post helpful.

If that was the case, then that'd solve all my problems, I'd just use it, but I can't find anything to support that, everything seems to say the opposite. I did use it for a while with my previous install, then later switched to nividia for some reason-or-another that I wish I could recall. However one of the features that supposedly works with nvidia driver but not noveau is suspend, and I just tested suspend, doesn't seem to work anyway, so I guess I don't need to consider that!

I read that thread you linked, slightly different problem. In my case, changing the grub resolution works for me within grub for everything I tried, except 1920x1080. But I can successfully increase it from what it was before changing settings, i.e. 1280x800 or 1280x1024 work. vbeinfo within grub doesn't list 1920x1080, whereas that's my panels native resolution and the resolution I use in GUI. Maybe that has something to do with it.

You say you can 'blind type'? is there a possibility that this isa resolution problem in the other ttys? Perhaps the window sizes in the ttys are 'too big' for the screen which you are using? This would explain the 'blind typing' that you describe. I wonder if you are actually calling the ttys, but because of the large window size, simply cannot see the terminal prompt.

1 members found this post helpful.

tty1 under bodhi is the primary console output, so usually it already has a bunch of output text there. And tty 2-6 require login before user can do stuff,and I've done stuff that would fill up the screen, even ls -l would do that.... But there is no output; if I hook up my tv in clone mode, when I switch to tty it screensavers cuz no input til I switch back to tty7/gui....

[I tested this with my tv hooked up to hdmi output on laptop for two reasons - one of the zillions of threads I'd read about this problem said their tty's showed up only on their 2nd display, and plus when I install from iso it puts the installer on the tv automatically intsead of primary laptop screen (which I assume is a problem with the installer). However I dont think this is really related, cuz the 5.0 version didnt have that issue yet I still have blank ttys with nvidia driver).

1 members found this post helpful.

What driver version? VGA or DVI? Because I get this with 390.x on VGA (older 340.x legacy works fine).
Consult the README, see on the website if your chip is supported by 340.x

Sorry, I didn't see the 2nd page in the thread until I looked for my quick post. There was already some discussion of resolutions, so I came 'late to the ball game'. For curosities sake, I did a web search on "Couldn't get a file descriptor referring to the console". While this may mean nothing, there was a mention of a problem in ./bashrc for a user querying about same error. Could the Nvidia driver add something to your ./bashrc that would make your ttys invisible? Another thought I had was could there be no font set for tty terminals? Perhaps ttyx opens, but with no font set maybe prompt or output would not be seen?

The Nvidia driver is always better, unless it's not. The only reason for not being better would be the relationship between the driver and the hardware. But, since it works fine in the GUI but not in a tty, then it's a setting.

If your video chip is truly ancient, then it may be that an older Nvidia would work better.

Or just use the perfectly fine Nouveau driver.

I am using 340.108 now; started with 340.107 but both behave the same in regards to this. This is laptop screen, dunno if it uses vga or dvi internally. Chip is GT330M which is too old for newer driver version. Previous driver, 304, is only supported up to kernel 4.13, and isn't packaged for ubuntu 18.

At one point, on my Kubuntu desktop, Nvidia was having a hard time with my not young (not very old anyway) Nvidia graphics card was starting to act up after an Kubuntu upgrade. After poking around on Google and the Nvidia site, I installed the http://ppa.launchpad.net/graphics-drivers/ppa/ubuntu/ bionic main PPA. It is the only PPA I have and is among only a very small number that I have ever used. After setting it up in sources, I inquired using the ubuntu-drivers utility and updated the driver to the "recommended" as is shown below.
And along with that, installed the Nvidia Xserver Settings application, which shows the exact version as 390.132, and which in turn shows as a DKMS package in Synaptic. That was the product of installing using the PPA.

Using a PPA is always a bit dicey, and while it could be a savior for older hardware, it could also generate a big steaming pile. So be careful.

That is in fact the ppa I used to update from 340.107 that was automatically installed from ubuntu repos to 340.108; as mentioned before no difference in behavior, changelog indicates its for support up to kernel 5.4; I'm using 5.3 now but had the same problem with 4.15.

I don't have an nvidia card or bodhi linux(I just downloading it though), but because I tried to change tty resolution the last days I found some related infos. For tty consoles is the kernel responsible and it loads the correct module and resolution automatic. There are also alternative framebuffer solutions as uvesafb which you can try. I found a pretty old thread(from 2011) in arch linux forums about nvidia drivers and high resolutions in tty consoles. According to that high resolutions don't work with nvidia driver, so you need to use nouveau if you want a high resolution. There is a command line application which change tty resolutions though. The name of that is "fbset". Probably you will need to install it, but I don't remember the name of the package(google it).
Also you can try, as I wrote above a different framebuffer. In archwiki there are some information which may help:
https://wiki.archlinux.org/index.php...l_mode_setting
https://wiki.archlinux.org/index.php/Linux_console
https://wiki.archlinux.org/index.php/Uvesafb

2011 is possibly relevant as thats how old my hardware is, but I would be happy enough with a low-resolution console, as my primary use is to kill misbehaving apps and/or reboot when problems arise. My problem is completely invisible console.

But thanks for those links. They didn't solve my problem, but I learned some useful stuff starting there. Even tweaked some nvidia options to my liking.

I think I'm just going to stick with nvidia drivers and no console. I will keep looking for a solution tho.

I don't know what you did, and if the "invisible" ttys problem caused by something else, but as I found when I searched about these stuff, because I have a problem(a different one) with ttys too, the framebuffer driver is responsible for the tty display. So, if you use another framebuffer driver you don't need to change the NVIDIA driver which used in X. This means that you can still have the nvidia driver for X and another framebuffer driver for ttys. But you need to exclude it from blacklisted devices, because I think all other framebuffer drivers are blacklisted, and maybe to add it to initramfs modules and rebuild it.
Also check here:
https://devtalk.nvidia.com/default/t...on-340-and-343
there is a workaround from jam666 in seccond page