Red Hat Bugzilla – Bug 162980
Some recent change in a startup makes a text console unusable
Last modified: 2014-03-16 22:54:48 EDT
Description of problem:
When booting in a text mode everything looks normal until the moment when
prints on a screen "Initializing hardware... storage network audio"
and before a final "done" is printed a screen blinks and comes back
with a tall and narrow font, with a serious barrel distortion, and a
text column on screen becomes also tall and narrow with top and bottom rows
way beyond display borders (but with wide margins on left and right).
I understand that startup is supposed to load only some kernel modules but it
seems to have other side-effects because if I am booting older kernels,
where this distortion was previously absent, I am getting the same
treatment. Even attempts to specify some other vga modes end up with
the same messed up console. Font is changes until initrd starts. Then
it goes back to a normal 80x25 system font and few moments later I am back
staring at unusable display.
If booting to level 1 I see the following modules loades after sound
modules (where video was yet normal):
dm_mod 68625 0
video 23497 0
button 12257 0
battery 15433 0
ac 10057 0
ohci1394 42273 0
ieee1394 379865 1 ohci1394
uhci_hcd 41441 0
ehci_hcd 41421 0
radeonfb 135069 1
i2c_algo_bit 14281 1 radeonfb
shpchp 103529 0
i2c_viapro 13657 0
i2c_core 29505 3 radeonfb,i2c_algo_bit,i2c_viapro
Any ideas what gives? There is apparently a new message in logs:
Console: switching to colour frame buffer device 90x25
and this is likley screwing me up.
Version-Release number of selected component (if applicable):
always - unfortunately
I think that maybe just updated 'udev' may be reponsible for this mess. But
if this is really the case it is really not clear to me how to prevent it
from doing what it is doing. I did not get much wiser looking through
documentation and udev config files.
Can you get a lsmod on the screwed up display? (via remote login, for example.)
Created attachment 116635 [details]
all modules loaded with a display junked
This is an lsmod output in the original report while booted into level 1
(so various other modules are not loaded yet and taken mostly "in blind" :-).
At least that part which comes after sound modules when video is still good.
If you want to see the whole thing, still from a boot to a level 1, it is
attached here. Unfortunately I do not have a similar listing from "before".
"Console: switching to colour frame buffer device 90x25" message comes
from .../drivers/char/vt.c; but why this was not happening previosly, and how
to prevent that from showing up, I still have no idea.
Hm, nothing here that would screw with video (in theory).
Are you using rhgb?
No, there is no rhgb. These are "pure runlevel 1" boots and with selinux
turned off as well.
I booted an i386 machine also with radeon video card but which lacks
sound and with "simpler" other things. A console is also unusable there
but a list of modules loaded at level 1 is shorter. Here it is:
Module Size Used by
dm_mod 59741 0
video 19909 0
button 10577 0
battery 13381 0
ac 8773 0
ohci_hcd 26209 0
radeonfb 127773 1
i2c_algo_bit 13257 1 radeonfb
i2c_amd756 10437 0
i2c_core 24897 3 radeonfb,i2c_algo_bit,i2c_amd756
3c59x 45673 0
mii 9409 1 3c59x
floppy 62613 0
ext3 133833 2
jbd 61913 1 ext3
The same "Console: switching to colour frame buffer device 90x25" showed
up there as well and this is definitely something new. It comes in the
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 18 (level, low) -> IRQ 185
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=145.00 Mhz, System=145.00 MHz
radeonfb: PLL min 12000 max 30000
radeonfb: Monitor 1 type CRT found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
Console: switching to colour frame buffer device 90x25
radeonfb (0000:02:06.0): ATI Radeon QY
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
but, as I mentioned before, even with kernels even with kernel which were
not doing that before. Hm, 'module-init-tools' were updated too.
Actually on the recent try that i386 box on a reboot switched video,
printed " ... done [OK]" and immediately died in a startup sequence.
SysRq key was not turned on yet, so even that is ineffective. Power button
The last one operation turned out to be "interesting". After taking that
machine down I had to unplug it entirely and wait around a minute before
I was able to power it up again. Before that there was no reaction on
a power button at all. I do not remember seeing ever a non-laptop machine
messed up to such extent.
So, presumably if you have "install radeonfb /bin/true" in /etc/modprobe.conf,
this doesn't happen?
Yes, in the meantime I just put "install radeonfb :" into my /etc/modprobe.conf
and my console display is sane again (and no radeonfb on my list of modules).
Somebody was way too kind for me. Sigh!
Which modutils do you have installed?
Erm, module-init-tools. *whack*.
Yes, indeed, module-init-tools-3.2-0.pre7.1. Was in a pile of rawhide
updates which I put in today.
Something apparently also added 'include /etc/modprobe.d' at the bottom
of my /etc/modprobe.conf with such effect that whatever was in this directory
was added twice; once before what I have in /etc/modprobe.conf, apparently
automatic, and the second time after. I thought that the latest re-definition
Actually, a change was made to automatically include /etc/modprobe.d; I'd
suspect that you had the include there already.
> suspect that you had the include there already
No. At least not in an explicit form. At this moment there are there no
include directives and if I will do 'modprobe -c | less' the I see first
a content of files in /etc/modprobe.d, so it looks that this inclusion
is automatic, followed by all lines from /etc/modprobe.conf. After that
there is a big chunk after "# Aliases extracted from modules themselves."
What is more, although I do not see that documented anywhere, files from
/etc/modprobe.d seem to be included by name in a _reverse_ alphabetical
order. I happen to have an extra file there. That could be a coincidence
and that may be really an order given by 'find' (so this will be 'readdir()'?).
If I will put back the last line with 'include /etc/modprobe.d', then
'modprobe -c | less' shows lines from modprobe.d, lines from modprobe.conf,
lines from modprobe.d files again, and after that "Aliases extracted from
This should be fixed in current rawhide - the blacklisting was broken.
Indeed, in an output of 'modprobe -c' I see now 'blacklist radeonfb' and
this likely has similar effects like 'install radeonfb :' :-) although I do
not see that documented anywhere save some comments in /etc/modprobe.d/blacklist
Actually, that was there before (it's pulled from /etc/modprobe.d/blacklist.)
The problem was that initscripts wasn't looking at that file (oops).