Supressing frame buffer console

[Mike Spencer]

I can't make the frame buffer console(s) go away. Old guy, y'know?
Tiny text is the pits.

lilo.conf has "vga = normal" and lilo has been run.

System begins boot in standard VGA text, then switches to frame
buffer. The switch happens at the point marked in the dmesg excerpt
below.

fbcon.txt (in the src Documentation/fb dir) has rather arcane
suggestions for "detaching" fbcon. I've hung the machine a couple of
times trying that stuff.

I just want the consoles to run in "normal mode". Is there a
workaround? Why does lilo.conf fail to do the job? Is the presence
in lilo.conf of append="vt.default_utf8=0" (put there by setup at
install) causing this?

Tnx for any pointers.

- Mike


Slack 14.1, kernel 3.10.17, Panasonic CF-48 laptop, X/twm but no KDE.

--- Excerpt from dmesg ---

[ 0.000000] Console: colour VGA+ 80x25
[ 0.000000] console [tty0] enabled

[snip]

[ 9.903856] [drm] radeon: irq initialized.
[ 9.905225] [drm] Loading R100 Microcode
[ 10.037417] [drm] radeon: ring at 0x00000000EC001000
[ 10.037554] [drm] ring test succeeded in 1 usecs
>>>>> Console switch happens here <<<<<<<<<<<<<<<<
[ 10.038217] [drm] ib test succeeded in 0 usecs

[snip]

[ 10.095694] fbcon: radeondrmfb (fb0) is primary device
[ 10.169577] Console: switching to colour frame buffer device 128x48
[ 10.245614] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 10.245700] radeon 0000:01:00.0: registered panic notifier
[ 10.255635] [drm] Initialized radeon 2.33.0 20080528 for
0000:01:00.0 on minor 0


--
Mike Spencer Nova Scotia, Canada

[Chris Vine]

This is KMS (kernel mode setting). I don't think it is possible to run
without KMS if you also want X to run on some drivers these days. You
could try switching it off with the 'nomodeset' kernel parameter with
the old 'vga' parameters, but some drivers require additional parameters
to work without modesetting and apart from that you may end up with no X
(the most likely outcome) or a completely blank screen.

If your concern is font size then retain KMS but just select a decent
sized font. Go to /usr/share/kbd/consolefont, and try a few out using
setfont (note: if you get into trouble 'setfont' without argument will
reset to the default). Some of the ter* fonts with higher numbers are
extremely large. When you have decided on one make it permanent by
running setconsolefont or edit /etc/rc.d/rc.font directly.

Chris

--------------------------------------
On 20 May 2014 03:28:56 -0300

Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
>
> I can't make the frame buffer console(s) go away. Old guy, y'know?
> Tiny text is the pits.
>
> lilo.conf has "vga = normal" and lilo has been run.
>
> System begins boot in standard VGA text, then switches to frame
> buffer. The switch happens at the point marked in the dmesg excerpt
> below.
>
> fbcon.txt (in the src Documentation/fb dir) has rather arcane
> suggestions for "detaching" fbcon. I've hung the machine a couple of
> times trying that stuff.
>
> I just want the consoles to run in "normal mode". Is there a
> workaround? Why does lilo.conf fail to do the job? Is the presence
> in lilo.conf of append="vt.default_utf8=0" (put there by setup at
> install) causing this?
>
> Tnx for any pointers.
>
> - Mike

[snip]

[buck]

Mike Spencer <m...@bogus.nodomain.nowhere> wrote in
news:87d2f9r...@nudel.nodomain.nowhere:

>
> I can't make the frame buffer console(s) go away. Old guy, y'know?
> Tiny text is the pits.
>
> lilo.conf has "vga = normal" and lilo has been run.
>
> System begins boot in standard VGA text, then switches to frame
> buffer. The switch happens at the point marked in the dmesg excerpt
> below.
>
> fbcon.txt (in the src Documentation/fb dir) has rather arcane
> suggestions for "detaching" fbcon. I've hung the machine a couple
of
> times trying that stuff.
>
> I just want the consoles to run in "normal mode". Is there a
> workaround? Why does lilo.conf fail to do the job? Is the presence
> in lilo.conf of append="vt.default_utf8=0" (put there by setup at
> install) causing this?
>
> Tnx for any pointers.

In lilo.conf's append line, specify
video=640x480

Be sure to rerun lilo.

No, vt.default has nothing to do with this.
--
buck

[Loki Harfagr]

Tue, 20 May 2014 03:28:56 -0300, Mike Spencer did cat :

> I can't make the frame buffer console(s) go away. Old guy, y'know?
> Tiny text is the pits.
>
> lilo.conf has "vga = normal" and lilo has been run.
>
> System begins boot in standard VGA text, then switches to frame
> buffer. The switch happens at the point marked in the dmesg excerpt
> below.
>
> fbcon.txt (in the src Documentation/fb dir) has rather arcane
> suggestions for "detaching" fbcon. I've hung the machine a couple of
> times trying that stuff.
>
> I just want the consoles to run in "normal mode". Is there a
> workaround? Why does lilo.conf fail to do the job? Is the presence
> in lilo.conf of append="vt.default_utf8=0" (put there by setup at
> install) causing this?
>
> Tnx for any pointers.

You may try to play with append in various lilo.conf entries, example
given below, replace obvious blobs by actual infos and use the values
you'd like /and/ which are allowed by your card
(check in X with xrander for instance)

Don't forget to keep an entry for an alredy proven working conf
(and as we're in shootfootproof paragraph, to run lilo before reboot ;-)
----------
image = /boot/vmlinuzWhateveryouuseforkernelimage
append="video:mode_option=1920x1080-16"
root="whateveryouhaveforroot"
label = testHD
read-only

image = /boot/vmlinuzWhateveryouuseforkernelimage
append="video:mode_option=1280x720-16"
root="whateveryouhaveforroot"
label = testSD
read-only

image = /boot/vmlinuzWhateveryouuseforkernelimage
append="video:mode_option=960x540-16"
root="whateveryouhaveforroot"
label = testHalfH
read-only
----------

Note that I haven't tested this way with other than
some Nvidia and Intel cards so I'll make no promises :-)

Good luck.

[Grant]

On 20 May 2014 03:28:56 -0300, Mike Spencer <m...@bogus.nodomain.nowhere> wrote:

>
>I can't make the frame buffer console(s) go away. Old guy, y'know?
>Tiny text is the pits.
>
>lilo.conf has "vga = normal" and lilo has been run.
>
>System begins boot in standard VGA text, then switches to frame
>buffer. The switch happens at the point marked in the dmesg excerpt
>below.

Yes, you want that so you can see how many penguins are running ;)

A sample lilo.conf:

root@deimos:~# cat /etc/lilo.conf
# /etc/lilo.conf for slackware64-14.1 on deimos -- 2013-10-22
#
append=" vt.default_utf8=0 video=1024x768"
#
boot = /dev/sda
root = /dev/sda2
read-only
compact
lba32
prompt
timeout = 50

default = 3.14.3a
#default = WinXPpro

image = /boot/bzImage-3.14.3a
label = 3.14.3a

image = /boot/bzImage-3.13.11a
label = 3.13.11a

image = /boot/vmlinuz
label = Slack64-14.1
#
other = /dev/sda1
label = WinXPpro
table = /dev/sda
#

I just throw in that " video=1024x768" bit into the append line, controls
the tiny text perfectly.

Grant.
[...]

[Chick Tower]

On 2014-05-20, Mike Spencer <m...@bogus.nodomain.nowhere> wrote:
> I can't make the frame buffer console(s) go away. Old guy, y'know?
> Tiny text is the pits.

I inadvertantly did it on this old PC when I removed the video card.
The GPU in the motherboard (nVidia) couldn't run the nouveau driver, so
I black-listed it in /etc/modprobe.d/. I wrote a file in
/etc/X11/xorg.conf.d/ containing the "Device" section of a working
xorg.conf that specifies the nv driver so X wouldn't try to use the
nouveau driver and fail. The pertinent part for you may be that the
kernel mode setting, not being able to use the nouveau driver, doesn't
switch to tiny text. Of course, as others suggested, that might cause
problems if you want to use nouveau while running X, and if you don't
have nVidia graphics, it doesn't apply. I plan to get another nVidia
graphics card so I can go back to nouveau in X, since the old graphics
card was causing problems and needed to be removed. At least, I hope it
was the card, and not something wrong with the AGP slot or something
else on the motherboard.
--
Chick Tower

For e-mail: aols2 DOT sent DOT towerboy AT xoxy DOT net

[Frank P. Westlake]

On 05/20/2014 06:54 PM, Grant wrote:
> A sample lilo.conf:

> lba32

Is LBA32 the default if not specified as above? I know 'lilo' issues the
warning on the command line but LBA32 isn't mentioned in my 'lilo.conf'
Mandoc.

Frank

[Grant]

Well, I put it in to suppress the warning, for neatness?

Grant.
>
>Frank
>
>
>

[Mike Spencer]

Tnx to several posters for pointers!

I'm having so many problems with installing Slack 14.1 on a Panasonic
laptop that I don't know which thing is causing what. I have a
work-around for the tiny console fonts:

Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:

> Go to /usr/share/kbd/consolefont, and try a few out using setfont
> (note: if you get into trouble 'setfont' without argument will reset
> to the default). Some of the ter* fonts with higher numbers are
> extremely large. When you have decided on one make it permanent by
> running setconsolefont or edit /etc/rc.d/rc.font directly.

Thank you. That will do for now.

X isn't working properly and suggestion from...

Buck <bu...@private.mil> who wrote:

> In lilo.conf's append line, specify video=640x480

...works, tnx, but I don't know if it's affecting X until I get X
working. And maybe it's Emacs 24 that's causing my problem. I've
hacked .Xmodmap before but the new Emacs has key bindings I don't
understand -- works right in the console but not in X or in an xterm
over telnet. So I'm going to revert to my familiar Emacs 20.7.2. If
that makes (what I suppose are) X problems go away, then I'll go with
that video setting and lose the setfont bit.

I wouldn't even bother with Slack 14.1 but much groveling through
config stuff, dependencies and C and Python code convinced me that I
won't get wireless working on the laptop with an older system.

And wireless is the only reason I need a laptop, so's to be able to go
out from my dialup home to fetch biggish data lumps from a wifi spot.

Tnx all, more later when I have a working system. Or another
head-banger. :-)

[John K. Herreshoff]

One thing you might try... When this had happened to me (no visible console
/ no text on the screen) I behaved as though I could read everything, and
when the login prompt came up (ie: disk light stopped blinking), I logged
in, and the started the gui with startx. Presto-Chango, and KDE came up.
When I quit KDE, I had a console that I could view.

This happened back with slackware 13.37 or 14.0, and I think it's happened a
few times with 14.1.

The beginning of my lilo.conf looks like this:

>>>>>>>>

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append=" vt.default_utf8=0"
boot = /dev/sda

#compact # faster, but won't work on all systems.

# Boot BMP Image.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

I've also used this line with success:

append=" vt.default_utf8=0 video=1024x768"

HTH.

John.

--
Using the Cubic at home

[Frank P. Westlake]

On 05/23/2014 04:35 AM, John K. Herreshoff wrote:
> One thing you might try... When this had happened to me (no visible
> console / no text on the screen) I behaved as though I could read
> everything, and when the login prompt came up (ie: disk light
> stopped blinking), I logged in, and the started the gui with startx.
> Presto-Chango, and KDE came up.
> When I quit KDE, I had a console that I could view.

It's always a pleasant experience when we outsmart the computer. You
should try going against IBM's Watson.

Frank

[Mike Spencer]

"John K. Herreshoff" <No...@not.here> writes:

> One thing you might try... When this had happened to me (no visible

> console / no text on the screen)...

Oh, I have text on screen. It's just that despite having rejected the
frame-buffer option in the 14.1 Setup installation script, having
selected 25x80 VGA at that point and despite lilo.conf being correctly
auto-written, consoles come up in a tiny font.

I only lose the console completely if I try the explicit instructions
given in /usr/src/linux-3.10.17/Documentation/fb/fbcon.txt. :-(

> ...I behaved as though I could read everything, and

> when the login prompt came up (ie: disk light stopped blinking), I logged
> in, and the started the gui with startx. Presto-Chango, and KDE came up.
> When I quit KDE, I had a console that I could view.

I think that might qualify as a Heisenbug?

I once installed ndiswrapper (Slack 10, PII CPU) to get a Broadcom
wireless card working in a desktop box. And the PS2 mouse stopped
working in X. Completely reverting to the status quo ante, expunging
every trace of ndiswrapper, the Win Broadcom driver, config lines
etc. and rebooting didn't help. Nothing helped, ever. A PS2 mouse
never worked on that box again.

Plugged in a serial mouse and all was well. That PII is still sitting
over there in the corner as the support box for some SCSI scanners,
using ndiswrapper and the Broadcom wireless. With a serial mouse.

> This happened back with slackware 13.37 or 14.0, and I think it's
> happened a few times with 14.1.

I'll be alert for that possibility, tnx.

> I've also used this line with success:
>
> append=" vt.default_utf8=0 video=1024x768"

Or 640x480 or whatever. After I tweak X some more.

[Rinaldi J. Montessi]

Mike Spencer decreed, Read These Runes!:

> "John K. Herreshoff" <No...@not.here> writes:
>
>> One thing you might try... When this had happened to me (no visible
>> console / no text on the screen)...
>
> Oh, I have text on screen. It's just that despite having rejected the
> frame-buffer option in the 14.1 Setup installation script, having
> selected 25x80 VGA at that point and despite lilo.conf being correctly
> auto-written, consoles come up in a tiny font.

I have found the entries in lilo.conf only work until my radeon module
gets loaded, then, as with you, i get a very small font using roughly
2/3ds of the monitor. I suspect this to be a byproduct of using two
monitors; one a standard Dell in 4/3 ratio and another in 16/9.

My solution is two pronged: First; in rc.local I do

fbset -a -xres 1280 -yres 1024

which sets all consoles to my desired size

followed by:

for n in 1 2 3 4 5 6 7 8 9 ; do /etc/rc.d/rc.font < /dev/tty$n ; done

where rc.font contains my desired font (an easily readable) setfont -v
iso02-12x22.psfu.gz

This does not seem to effect X in any fashion. My only modification
there is to:

alias startx='startx -- -dpi 120 -logverbose 1'

HTH

Rinaldi

--
It's not enough to be Hungarian; you must have talent too.
-- Alexander Korda

[Grant]

This is when I log in with ssh and compile a custom kernel, not for all
people but custom kernel does result in faster boots and less issues for
me. Though I'm still not a big user of GUI interface on my Slack boxen.

>
>This happened back with slackware 13.37 or 14.0, and I think it's happened a
>few times with 14.1.

Yes, screen issues been going on for some time, it is stuff like this keeps
many 'doze users from switching to Linux. I don't know if it is Slack's
one size fits all setup (you'd think the modular kernel should solve
everything?) or the current state of the kernel. I've been running custom
kernel since 1997 (on redhat back then).

Grant.

[Mike Spencer]

"Rinaldi J. Montessi" <rin...@notaserver.com> writes:

> I have found the entries in lilo.conf only work until my radeon module

> gets loaded...

Scrutinizing dmesg, that's exactly so.

> ... then, as with you, i get a very small font using roughly 2/3ds

> of the monitor. I suspect this to be a byproduct of using two
> monitors; one a standard Dell in 4/3 ratio and another in 16/9.

Laptop, only one monitor here.

Solved the problem with X: I was using ~/.Xmodmap copied from my
desktop with Slack 11. But xev says the newer X on the laptop sees
different keycodes. As well, X's parsing of .Xmodmap seems to be more
picky so exact order of expressions makes a difference.

Anyhow, X working, old Emacs working in X, then referring to...

buck <bu...@private.mil>, who opined:

> In lilo.conf's append line, specify video=640x480

Did that. Consoles come up in default 25x80 mode with readable text.
Happy now.

Thanks, all, for pointers and background info.

(But I'll be back. Had to puzzle out on my own that Perl's "split" no
longer defaults to splitting into @_. Who knows what weevil lurks in
the heart of an upgrade from 11 to 14.1?)