From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 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: fbcon=map:2 (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 http://linux.bkbits.net:8080/linux-2.6/cset@1.1938.166.45 ?nav=index.html|tags|ChangeSet.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): How reproducible: Always 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: fbcon=map:2 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: fbcon=map:2 When the system boots, the console will stay in text mode, even after the framebuffer kernel module loads. Additional info:
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. - selltc
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 accel=1 mtrr=1 ro /etc/modprobe.conf executing /sbin/modprobe i810fb 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 /sbin/modprobe i810fb to /etc/rc.local which then switches the console to the desired format at the end of the other initialisation scripts. The other solution is to add the module into the initial ram disk image initrd These commands need to be run as root cd /boot 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 root (hd0,6) kernel /vmlinuz-2.6.11-1.1240_FC4 ro root=LABEL=/1 video=i810fb initrd /initrd 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.