[nSLUG] Frame buffer console(s) won't go away

Mike Spencer mspencer at tallships.ca
Tue May 20 03:34:22 ADT 2014

This may be a bit Slackware-specific. Or not.  Googling turns up
people who want to turn frame buffer console *on*.  

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

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", 80x25. Is there a
fix? 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


[    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


[   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

More information about the nSLUG mailing list