Red Hat Bugzilla – Bug 146003
framebuffer console (fbcon) cannot be disabled or configured via kernel command line
Last modified: 2013-03-06 00:58:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Description of problem:
With a properly-functioning kernel, you can disable framebuffer
console (fbcon) dynamically by adding something like this to the
kernel command line:
(This syntax is also used to assign specific framebuffers to specific
VT ttys, but is also used to disable fbcon altogether if you specify a
framebuffer number that is out of range.) This will NOT work on
kernels prior to 2.6.10, due to a bug. You can apply changeset
1.1938.166.45 to 2.6.9 to make this work (see
?nav=index.html|tags|ChangeSet@1.1938.156.17) in 2.6.9 if you need it.
Although this ability to disable/configure framebuffer consoles has
been broken in ALL 2.6 kernels prior to 2.6.10, this bug becomes
particularly significant in 2.6.9. Prior to 2.6.9, video framebuffer
drivers did NOT need to also function correctly as console drivers.
Prior to 2.6.9, a framebuffer driver loaded as a kernel module only
needed to function as required by X Windows. Beginning in 2.6.9, as
soon as you load any framebuffer driver as a kernel module, Linux will
attempt to use it as a console driver (if the kernel was compiled with
CONFIG_FRAMEBUFFER_CONSOLE=y, which the default RHEL4-rc1 kernel is).
If the framebuffer driver isn't prepared for this, you lose your
console. I suspect that many of the existing framebuffer drivers are
not prepared to function as a framebuffer console, which is why I
think it would be in RedHat's best interest to provide the fix
(changeset 1.1938.166.45) that allows for the console framebuffer
behavior to be disabled dynamically ("fbcon=map:2").
Version-Release number of selected component (if applicable):
Steps to Reproduce:
System must be configured such that a single framebuffer driver (under
drivers/video) is loaded as a kernel module.
1. On RHEL4-rc1, boot with the kernel parameter:
When the system boots, as soon as the framebuffer kernel module loads,
the console will switch into 100x37 mode (if the framebuffer driver
works as a console correctly), or will stop working (if the
framebuffer driver does NOT work as a console correctly).
2. On vanilla 2.6.10, boot with the kernel parameter:
When the system boots, the console will stay in text mode, even after
the framebuffer kernel module loads.
Is the related to the fact that i can't get a full size console on my laptop?
On FC1 FC2 this worked fine but now my consoles are much smaller than my screen.
my videocard is intel i815 in a vaio and running vbeprobe from grub lists no
modes. setvbe faild for all modes that I've tried and adding vga=773 etc to the
kernel boot lines does nothing.
(In reply to comment #2)
> Is the related to the fact that i can't get a full size console on my laptop?
> On FC1 FC2 this worked fine but now my consoles are much smaller than my screen.
> my videocard is intel i815 in a vaio and running vbeprobe from grub lists no
> modes. setvbe faild for all modes that I've tried and adding vga=773 etc to the
> kernel boot lines does nothing.
Yes, this COULD cause you not to be able to get a full-size console
on your laptop. The reason for that is that Linux is opting to use the
framebuffer driver instead of the legacy console.
If this is the case, then the only way to get around this is to
reconfigure/recompile your Linux kernel with CONFIG_FRAMEBUFFER_CONSOLE=n.
Thanks for commments.
I've found twootehr solutions which are simpler than recompiling the kernel. The
information concerning this type of thing seems very out of date, incorrect and
scattered about. Lots of it refere to setting vga=... or video=... on the kernel
boot line which will not work ordinarily. I don't know where this information
should go, but it would be helpful to be included in the fedora stuff somewhere.
I have found two solutions, which I imagine should work for other videocards also.
in both cases add a line like the following
options i810fb xres=1024 yres=768 hsync1=30 hsync2=55 vsync1=50 vsync2=85
then sets up the consoles to use this
simnply adding a line "video=i810fb" to kernel in grub.conf will fail becuase
the module is not in /boot/initrd
The simplest solution is to add
which then switches the console to the desired format at the end of the other
The other solution is to add the module into the initial ram disk image initrd
These commands need to be run as root
and look at the version number of your kernel.
eg if it is vmlinuz-2.6.11-1.1240_FC4 then execute
/sbin/mkinitrd --preload=i810fb -v -f /boot/initrd 2.6.11-1.1240_FC4
this creates an intrd with the framebuffer loaded and any other necesary
modules. the options are taken from /etc/modprobe.conf
Then replicate your default entry in /boot/grub/grub.conf
and add video=i810fb and change initrd to point to your new one/ If you don't
have a boot partition the path must be prefixed with /boot.
title test framebuffer initrd
kernel /vmlinuz-2.6.11-1.1240_FC4 ro root=LABEL=/1 video=i810fb
If all works well you can make this your default boot entry.
We have a similar problem in FC10. FC10 is now loading frame buffered consoles by default and forcing a 160x64 display. This is nearly unreadable
on smaller LCDs that are used in text only mode for configuring servers, etc.
Countless efforts to try to disable this "feature" have failed. The commonly
suggested fbcon=map:n where n is 1, 2, 3, etc. result in the system loosing
console (ie, black screen, no output) as soon as the fbcon takes over.
We need a way to easily disable the fbcon mode or at least be able to set
the resolution (in characters) to 80x25. The default of 160x64 is far too
dense for traditional text-only applications.
you can ban the drivers with something like
"install radeon /bin/true" in your /etc/modprobe.conf file
where radeon is the driver its loading.
in newer os's the files live in /etc/modprobe.d/
this is how weve fixed issues with problems on the HP ilo and with random iscsi drivers loading that we dont want (and we cant disable the hardware)
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.