ttys disappeared after installing xorg

12.2-RELEASE-p7 as dual installation on elderly IMac.

After booting I get the login shell on ttyv0. With startx the KDE desktop starts on ttyv8. However trying to switch back to any ttyv0 ... ttyv7 results in a black screen. Only ctrl-alt-F9 offers the expected response i.e. brings back the KDE desktop.

Is that a well known hangup? Is there an easy remedy? How should I proceed?

Thank you
winkoe
 
Yes, the 340 type. That was the successful one on a previous installation of 11.0-RELEASE
 
But the previous installation with the same NVidia driver did not show the same behaviour. According to Handbook 5.4.3. I tried /boot/loader.conf with and without
Code:
kern.vty=vt
. Also /usr/local/share/X11/xorg.conf.d/10-xorg.conf is identical.
 
# For nvidia use this
kern.vty="vt"
hw.vga.textmode=1
# ... OR this
#kern.vty="sc"

This should be FAQ.
 
No need for text mode or setting kern.vty (setting it to something it's already on by default is pretty useless too) on the latest NVidia drivers. It's the old drivers that aren't KMS aware.
 
I did
Code:
kern.vty="sc"
but now booting comes to a halt even before 'single user' is reached.
With a live Linux Kali disk I can mount and read the faulty /boot/loader.conf, but write i can't.
mount -t ufs -r -o ufstype=ufs2 /dev/... /mnt/
How can I get out of this mess?

winkoe
 
I don't think it even works with Nvidia on FreeBSD (all driver versions).
It does work on my system (GTX1080 using the x11/nvidia-driver). But I do CSM boot the machine, UEFI boot has problems with the efifb, no image but does boot. With a CSM boot I get a good boot and I can switch back and forth between Xorg and TTYs without problems. On an older system, using the 390 driver, I get the same colored blocks as the OP.
 
No need for text mode or setting kern.vty (setting it to something it's already on by default is pretty useless too) on the latest NVidia drivers. It's the old drivers that aren't KMS aware.
vt was there just for the documentation purposes, to explicitly show both alternatives.
I have those settings for many years and wasn't aware that the newer driver does not need them.
Will re-test. Thank you!
 
I don't think it even works with Nvidia on FreeBSD (all driver versions).
It does work on my system (GTX1080 using the x11/nvidia-driver). But I do CSM boot the machine, UEFI boot has problems with the efifb, no image but does boot. With a CSM boot I get a good boot and I can switch back and forth between Xorg and TTYs without problems. On an older system, using the 390 driver, I get the same colored blocks as the OP.
I can confirm.

On my BIOS system

- 13.0-RELEASE
- nVIDIA GT 630 Rev. 2
- (un-patched) * x11/nvidia-driver v470.86
- switched to VBE (VESA BIOS extension) frame buffer mode (loader.conf - vbe_max_resolution="1080p")

I can switch to virtual terminals from a running Xorg session normally, no colored blocks, as it is without VBE enabled, or under 12.2-RELEASE (no VBE support here).

* I haven't checked if a patch has been merged into the nvidia source code.
 
Have you tried switching to VBE (post #14). For my system only the maximum resolution value of 1080p (1920x1080) has an effect.
I just did and it works very well. Much better than my old trick. Thank you!
Just in case, this is what I have in my loader.conf now:
Code:
# For nvidia it's best to use this:
vbe_max_resolution="1080p"
# and this should work just the same as above:
#screen.textmode="0"
# A worse alternative (smaller console screen size):
#-#hw.vga.textmode=1
# Another alternative is to use sc instead of vt
#-#kern.vty="sc"
 
Back
Top