Gutsy Gibbon poses problems unknown to Feisty Fawn

[sktsee]

On Sun, 2007-11-04 at 15:29 +0100, Thilo Six wrote:
> Gerald Dachs wrote the following on 04.11.2007 14:03
> > 
[snip]

> > So it is not chip set specific. I have no time to dig deeper into it,
> > but I think that the frame buffer modules didn't make it into the
> > initrd, or there is no udev rule for loading them. Assuming that
> > udev is used inside the initrd for loading modules. I don't know
> > whether it could work to load the frame buffer modules manually and
> > then update the initrd. In other distributions I know, the currently
> > loaded modules are copied into the initrd. Anyone who want to give
> > this a try?
> > 
> > Gerald 
> 
> $ cat /etc/modprobe.d/blacklist-framebuffer
> # Framebuffer drivers are generally buggy and poorly-supported, and cause
> # suspend failures, kernel panics and general mayhem.  For this reason we
> # never load them automatically.

[snip]

> blacklist vfb
> blacklist vga16fb
> 
> but even with un-blacklisting the FB doesn´t work (when i tested it)

Gerald's suggestion isn't to un-blacklist the driver, but to include it
in the initrd image.

If you use the vesa framebuffer driver you would do the following:

$ cd /lib/modules/`uname -r`/kernel/drivers/video
$ sudo cp vesafb.ko /lib/modules/`uname -r`/initrd
$ sudo update-initramfs -u 
$ sudo shutdown -r now

If all goes well, vesafb gets loaded when the initrd image does, and
fbcon (framebuffer console driver) has a framebuffer to work with. 

Interestingly enough, vesafb.ko is already present in the above
mentioned initrd directory with feisty kernels, but isn't with gutsy
kernels. Why the gutsy devs moved away from this workaround without
first solving the original problem with initramfs' framebuffer handling
is a mystery.

-- 
sktsee