Hide Forgot
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): initscripts-8.11.1-1 How reproducible: 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 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).