wishlist: Could initramfs detect vga=XXX and autoload vesafb?

[Alexis]

Fresh install of Dapper 20051214 + dist-upgrade 25dec2005 +
kernel-image-2.6.15-9-686 27dec2005

Attempting to boot with vga=791 ; screen remains blank until X session starts.
Switching (Alt-Fn) to console after X is up shows corrupted graphical display
(distorted root window background) instead of text login prompt. Same on all
virtual consoles. The system remains responsive and it is possible to go back to
the X session.

When booting without the vga= option, the system comes up normally in 80x25.

When booting with vga=ask, it is possible to boot with console up to 132x60
textmode.

Booting with *both* "vga=791 splash" options, the system comes up with
splashscreen (framebuffer mode switch briefly visible before splash comes up)
and the virtual consoles at 1024x768 are clean and behave normally.

Hoary comes up without problem with only vga=791 on same hardware.

Video card is a Matrox Millenium II, 4 MB RAM.

[Ben Collins (ben-collins)]

The likely reason is that with vga= and no splash argument, is that vesafb does
not get loaded and it is trying to use just vga text mode switching.

Try adding vesafb to /etc/modules and boot with vga=791 and no splash argument.

[Alexis (a-parseg)]

(In reply to comment #1)
> The likely reason is that with vga= and no splash argument, is that vesafb does
> not get loaded and it is trying to use just vga text mode switching.
>
> Try adding vesafb to /etc/modules and boot with vga=791 and no splash argument.

Edit: in first report, behavior is compared to Breezy, not Hoary (initial Hoary
install, dist-upgraded to Breezy later on ; Dapper on separate partition of its
own). The vga= option already worked as expected in Hoary anyway.

vesafb added to /etc/modules as the first line. Now the framebuffer behaves
normally : Alt+Fn works fine, no display corruption. However it only starts
displaying the boot lines partway through (when the vesafb module loads,
obviously).

Breezy on the same machine activates the framebuffer right at the beginning of
the boot process, without having vesafb in modules.

It would seem there's no in-kernel framebuffer support (only as module), whereas
previous versions had it ?

[Andreas Schildbach (schildbach)]

This is a duplicate of bug 26783.

[Ben Collins (ben-collins)]

> It would seem there's no in-kernel framebuffer support (only as module), whereas
> previous versions had it ?

Generally one does not need a framebuffer in order for the screen to work. If
nothing is loaded, then normal boot text mode should be what's operating.

When does your screen become blank? Do you see the grub loader? Do you see any
initial lines if you remove the "quiet" argument from the boot options? Please
send a full dmesg.

[Alexis (a-parseg)]

(In reply to comment #4)
> Generally one does not need a framebuffer in order for the screen to work. If
> nothing is loaded, then normal boot text mode should be what's operating.

Indeed, without framebuffer a normal 80x25 boot occurs. The vga= argument (with
a vesa code) forces the use of the framebuffer (not so long ago a kernel
recompile was needed to put it in...)

> When does your screen become blank? Do you see the grub loader? Do you see any
> initial lines if you remove the "quiet" argument from the boot options?

I am not using "quiet".
I always see the grub loader ; the screen blanks right after grub output (where
it summarizes where it starts from, what it loads etc), when the actual boot
messages would start.

> Please send a full dmesg.
Will be provided shortly, after rebooting under the appropriate conditions.

[Ben Collins (ben-collins)]

Ok, then I don't see the bug in all this. If you provide vga=, then you need
vesafb, which means you need to cause it to load. Our current default is to boot
with usplash, so normally this is not a problem. However, if you go changing the
defaults, you need to expect to compensate for your custom changes.

Maybe initramfs can help by detecting this at an earlier stage.

[Alexis (a-parseg)]

(In reply to comment #6)
> Ok, then I don't see the bug in all this.

I'll politely disagree... The bug is that it worked as expected before, and
doesn't anymore with Dapper.

> If you provide vga=, then you need vesafb, which means you need to cause it to
load.
> Our current default is to boot with usplash, so normally this is not a problem.

I've been using the vga= option since my early Debian days (3.0.0 when it came
out), when I had to recompile the kernel to enable it, and have carried it over
several system updates -- including going from Debian to Hoary (clean install)
then Breezy (dist-upgrade). Had I kept on this way, the problem would have
surfaced when dist-upgrading to Dapper when it's released.

In previous releases, the vga= option caused vesafb to automatically load ;
there is no apparent technical reason for that behavior to change, regardless of
whether usplash is used.

dmesg still available if required.

[Andreas Schildbach (schildbach)]

Could someone explain why the "vga=" option behaviour changed in Dapper?

[Martin Kreiner (languste)]

using pakages "initramfs-tools-0.40ubuntu16" and "usplash_0.1-30" you see the following implementation:

package initramfs-tools:
- includes a hook for copying extra kernel modules into the initramfs (hooks/kernelextras). If there are any framebuffer modules in your current kernel module dir ${MODULESDIR}/initrd/* these are copied into the initramfs (along whith fbcon and dependencies).
- includes *no* script to load any framebuffer related modules at boottime

package usplash:
- includes a hook to copy "fbcon" and "vga16fb" into the initramfs (hooks/usplash).
- includes a script to modprobe "fbcon" and "vga16fb" at boottime _if_ "splash" is appended to the kernel cmdline. if "splash" _and_ "vga=*" is appended "vesafb" is modprobed instead of "vga16fb"

so the kernel maintainer decides which framebuffer modules (apart from "vga16fb" in usplash) should be inside the initramfs but can not trigger a modprobe of these modules at boottime because initramfs-tools just copies them. usplash copies only "vga16fb" but modprobes "vesafb" as well at boottime if triggered.
as initramfs-tools has no dependencies on usplash you can end up in having "vesafb" included inside the initramfs but being unable to trigger loading it (when usplash is not installed). further on you will never be able to have a framebuffer driven console without an usplash loading.
all this seems to be more or less a problem of which package takes responsibilitiy of providing a framebuffer device and setting up.

here are my suggestions:

initramfs-tools:
- should initialise vesa framebuffer console when "vga=*" is set and "vesafb.ko" is present as it is indirect responsible for copying the modules into the initramfs. it does not make sense to copy them just to fill up space.

usplash:

- usplash should include a hook to add the module "vesafb" into the initramfs because it relies on it if "vga=*" is appended

- scripts/init-top/usplash should be changed to initialise the vesa framebuffer if "vga=*" is appended (regardless of whether "splash" is appended

[Henrik Nilsen Omma (henrik)]

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined.
According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .
The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). If the state of this bug should change such that it qualifies for the SRU process, please contact the person who originally declined it and ask them to re-evaluate it. To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage .

[Przemek K. (azrael)]

Given that now in Karmic we have KMS and all the related goodies, does this bug still apply to current Ubuntu release?

[Anzenketh (anzenketh)]

There have been many changes in Ubuntu since that time you reported the bug and your problem may have been fixed with some of the updates. It would help us a lot if you could test the current Ubuntu development version (10.10). If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue.

[dino99 (9d9)]

never got answered