Bug 162980

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
following context:
.....
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
time.

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
wins.

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."
comment.

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
modules themselves".

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).