Blank ttys when using vesafb (vga=xxx)

In case it's helpful, this is the terminal output of `dmesg | grep vesafb`:

$ dmesg | grep vesafb
[ 15.050294] vesafb: framebuffer at 0xd0000000, mapped to 0xe0880000, using 3072k, total 131008k
[ 15.050301] vesafb: mode is 1024x768x16, linelength=2048, pages=84
[ 15.050305] vesafb: protected mode interface info at c000:5a0d
[ 15.050310] vesafb: pmi: set display start = c00c5a7b, set palette = c00c5ab5
[ 15.050314] vesafb: pmi: ports = c010 c016 c054 c038 c03c c05c c000 c004 c0b0 c0b2 c0b4
[ 15.050324] vesafb: scrolling: redraw
[ 15.050328] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0

Note that my screen supports 1280x800, and that killing the vga=791 option doesn't help.

Forget what I said about vga=791. Actually, it is the culprit of the issue. If I delete that option, output at tty's will be visible. What package should be affected? Is is linux-source-2.6.22? It seems to be fault of the framebuffer.

I can confirm this. I have a nvidia card.

Confirmed here.
I can't login any tty with the option vga=792 in the grub entry.

Confirmed here as well.

I can also confirm.

Related bug:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/120747

Another confirmation here, this time with a Thinkpad r60e, intel 945GM

no tty with vga=791 or any vga setting above default

Have the same problem on a HP nx6125 with an ATI Radeon XPRESS 200M.
Both with vga=791 and vga=792.
Worked before on Breezy, Dapper, Edgy and Feisty.

Console works (i can log in and type commands in blind), its just completely black.

Confirmed also on Sony Vaio FE41Z, 32-bit Gutsy tribe-5.

Confirmed on two systems: Dell Inspiron 510m laptop with Intel 855gm, and Dell Dimension 1100 laptop with NVIDIA FX 5200.

Booting from Tribe 5 cd with "vga=773" allows usplash to function at 1024x768, but all tty's appear blank. Booting the Feisty live CD with same parameter works as expected.

A relevant discussion can be read here: http://ubuntuforums.org/showthread.php?t=454392

Confirmed here, running gutsy tribe 6 amd64, with a nvidia 7300 GT card and vga=792

I've posted a workaround/fix in the above thread(http://ubuntuforums.org/showthread.php?t=454392).

Confirming John Yate's fix with Gusty Tribe-5 64-bit:

1. Add fbcon to /etc/initramfs-tools/modules
2. Update initrd.img
3. Restart

$ sudo sh -c "echo 'fbcon' >>/etc/initramfs-tools/modules"
$ sudo update-initramfs -u

Fix confirmed here. I don't know if there's any negative repercussions to have fbcon included in the initramfs... The most obvious problem would be that it can affect DRI, but on my Dell Inspiron with Intel 855GM graphics, DRI still functions perfectly.

I highly recommend the fbcon module is included in the initramfs by default. My laptop can't display more than 640x480 without this module, leaving usplash non-centered.

I compared the initrd image of Feisty with Gutsy:

Feisty /conf/modules:

capability
vesafb
fbcon
dm_mod
unix

Feisty has the drivers:

/lib/modules/2.6.20-16-generic/kernel/drivers/video/vga16fb.ko
/lib/modules/2.6.20-16-generic/kernel/drivers/video/vesafb.ko
/lib/modules/2.6.20-16-generic/kernel/drivers/video/console/fbcon.ko

In Feisty vesafb and fbcon are modules:

CONFIG_FB_VESA=m
CONFIG_FRAMEBUFFER_CONSOLE=m

Gutsy /conf/modules:

apparmor
fuse
capability
fan
thermal
unix

Gutsy has the drivers:

/lib/modules/2.6.22-11-generic/kernel/drivers/video/vga16fb.ko
/lib/modules/2.6.22-11-generic/kernel/drivers/video/console/fbcon.ko

So far I've been unable to find any documentation on why the change was made, although I did notice some discussion relating to usplash.

In Gutsy vesafb is built into the kernel and fbcon is a module:

CONFIG_FB_VESA=y
CONFIG_FRAMEBUFFER_CONSOLE=m

To set VGA modes for vesafb the kernel command-line options differ from fbcon:

http://lxr.linux.no/source/Documentation/fb/vesafb.txt

so for 1024 x 768 x 24-bit colour: vga=0x318
and for 1280 x 1024 x 24-bit colour: vga=0x31B

Hello, this fbcon fix worked for me too ( Bug #138425 ). Thanks a lot

Adding fbcon to the initramfs works for me too (or just loading it manually).

Thanks!

According Ben collins comment in bug #120747 vesafb is now built into the kernel. But in the shell script /usr/share/initramfs-tools/hooks/kernelextras, there is :

for x in ${MODULESDIR}/initrd/*; do
 x=${x##*/}
 x=${x%.*}
 case ${x} in
 '*')
  break
  ;;
 *fb)
  fbcon=y
  ;;
 esac

 force_load ${x}
done

# And add vga16fb for usplash to use as well
manual_add_modules vga16fb

if [ ${fbcon} = "y" ]; then
 force_load fbcon
fi

Since there is no more *fb module in the ${MODULESDIR}/initrd/ directory, fbcon and its dependencies are not loaded.

I forgot to mention that when I remove the conditional loading of fbcon module and rebuild my initramfs with 'sudo update-initramfs -u', my framebuffer console works again and the device /dev/fb0 is actually created (with vga=791 in GRUB options). But it's probably a dirty hack... May be this should be done in the /usr/share/initramfs-tools/init-top/framebuffer script.

As I don't see any answer from the kernel team, I'm setting the priority of this bug as critical.
This basically makes the framebuffer unusable for anyone using gutsy so I think it's worth this status. I can submit a patch if needed, but I'd like some guidance on the right thing to do. IMHO, as the vesafb driver is no longer compiled as a module, we should load the fbcon module unconditionally in /usr/share/initramfs-tools/hooks/kernelextras (as otherwise it won't ever load it). Thoughts ?

Cheers

i confirm this bug with my i810 chipset on my DELL Dimension 3000 and a related bug
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-driver-i810/+bug/146728

Could we possibly get an answer to this bug, even it's to tell us to stop complaining about that ? I asked for comments 10 days ago, but got no anwser...

Regards

Hi Albin
Please be patient, this bug has been triaged, assigned and set milestone to 7.10 rc, which means that about october 11, the fix should be included in gutsy, in the mean time, you could try the workaround mentioned here.

The vesafb kernel module is available with the 2.6.22-13 version of the kernel which may have already hit your local mirror. Please let us know if it resolves your issue.

On my Toshiba M40 with ATI X600 I have upgraded at 2.6.22-13 and still it doesn't work (black screen when switching to tty).
Furthermore the fbcon trick doesn't work anymore (on 2.6.22-12 it worked)

I can confirm motplux's situation:
With 2.6.22-13 the tty is garbaged again and fbcon trick does not work. It worked/works with 2.6.22-12.
This is T23 with S3 Inc. SuperSavage IX/C SDR (rev 05)

almost the same for me.

before the kernel update and without the workaround i got a complete black screen when switching to one of the tty's. now, after the kernel-update and without the workaround, i have a cursor blinking in the upper left screen, but its not the usual prompt.

the workaround doesn't work for me anymore too.

this is with a HP nx6125 and an ATI x200m

T23 with S3 Inc. SuperSavage IX/C SDR (rev 05)

2.6.22-12 with fbcon trick worked for vga=791 but after upgrade to 2.6.22-13 switching to one of the tty's brings up a black screen with a blinking cursor in the upper left corner of a 800x600px screen instead of a 1024x768px screen with a login prompt.

With kernel: 2.6.22-13
When loading the vesafb module the TTY's appear.
> modprobe vesafb

This is on a Dell 640m / intel 945GM graphics.

It couldn't work with kernel 2.6-22-13 since there's no vesafb module in /lib/modules/2.6.22-13-generic/initrd (just like in previous releases)

Brian, are you sure that veasfb is compiled as module in this new version?

T23 with S3 Inc. SuperSavage IX/C SDR (rev 05)

With kernel 2.6.22-13 and 'modprobe vesafb' even the blinking cursor in the upper left corner disappears.

In kernel 2.6.22-12 config says vesafb=y
               2.6.22-13 config says vesafb=m

Now for what ever reason, adding fbcon to initrd doesn't work.

modprobing vesafb gives me blinking spreadly green curson in the tty

i have both modules fbcon and vesafb in: /etc/initramfs-tools/modules
apparently the vesafb isn't loaded during boot.
when modprobing vesafb i get the TTY's.

That last workaround didn't work here..

the last workaround doesn't work for me either, i just get garbage in my screen.

any chance to get vesafb and fbcon built-in and not just as modules?

Hmmm...
Today I compiled last linux-source..

This is what I found. I was doing a "make modules", and it was on the stage 2 (building modules):

WARNING: drivers/video/vesafb.o(.exit.text+0x5b): Section mismatch: reference to .init.data:vesafb_fix (after 'vesafb_remove')
WARNING: drivers/video/vesafb.o(.exit.text+0x66): Section mismatch: reference to .init.data:vesafb_fix (after 'vesafb_remove')

Maybe this is related to this whole problem...

With kernel 2.6.22-13 I can get the tty's working again with:
sudo modprobe fbcon
sudo modprobe vga16fb

You may need to press enter to see the tty is really working again.
(Intel GM965, AMD64)

Same problem using vesafb.
I've commented blacklisted-framebuffer #vesafb (and #vga16fb) and loaded fbcon and vesafb modules in initramfs. I've tried various vga= options and the result was always the same: framebuffer seems to work but when I switch between ttys (ALT+right, ALT+left) all becomes black except the blinking cursor.

Kernel version: 2.6.24-3
videocard: ati radeon HD2400

On Tue, 18 Mar 2008 17:38:26 -0000
"mirko.quaglio" <email address hidden> wrote:

> Same problem using vesafb.
> I've commented blacklisted-framebuffer #vesafb (and #vga16fb) and loaded fbcon and vesafb modules in initramfs. I've tried various vga= options and the result was always the same: framebuffer seems to work but when I switch between ttys (ALT+right, ALT+left) all becomes black except the blinking cursor.

This is exactly what happens here with the most recent kernel. The frame
buffer appears to work for example on tty1, but switching to another tty
results in a blank screen. This is not recoverable.

In addition, even to get this much functionality the initramfs and modules
hacks are still required. This bug is *still not fixed*, and should be
so marked.

Update:

Using a debootstrap installed hardy I am able to run the frame buffer with
vga=788 in VirtualBox.

The console switching problem still exists, but typing

setupcon

blindly in a tty restores it. There appears to be a problem with the
console setup.

Hello,

  I tried setupcon blindly in a tty, and that did restore the tty
  indeed. But I need to do that every time I switch to the tty, even if
  I switch from one tty to the other then back I'll need to run
  'setupcon'.

--
 أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
  SySDSoft, Inc.
 GPG KeyID: 0x9DCA0B27 (@ subkeys.pgp.net)
 GPG Fingerprint: 087D 3767 8CAC 65B1 8F6C 156E D325 C3C8 9DCA 0B27

On Wed, 19 Mar 2008 13:25:26 -0000
أحمد المحمودي (Ahmed El-Mahmoudy) <email address hidden>
wrote:

> I tried setupcon blindly in a tty, and that did restore the tty
> indeed. But I need to do that every time I switch to the tty, even if
> I switch from one tty to the other then back I'll need to run
> 'setupcon'.

Correct. It is still broken, as I have said previously.

--
"INX Is Not X" Live CD based on Ubuntu 7.04 : http://inx.maincontent.net
Screenshots slideshow: http://inx.maincontent.net/album/1.png.html

Im running Ubuntu hardy on a Dell m1330.

Textmode boot works with vga=865 in grub.

However, after i login with gdm and Ctrl-Alt-F1-6 to a tty they only have a blinking cursor and nothing else.

I have commented the blacklisted vesafb in /etc/modprobe.d/blacklist-framebuffer and added the modules fbcon & vesafb into
 /etc/initramfs-tools/modules

any ideas?

This bug was confirmed here. I used Ubuntu 8.04 Beta (downloaded from http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-desktop-i386.iso), booted with vga=788, and used ctrl-alt-F* to switch the consoles, blank ttys.

fb modules are black listed becouse of wired issues on suspend/resume. So it should be blacklisted by default. Please do not report this bug anymore.

When kernel 2.6.24-11-generic was in Hardy development branch, no such problem.
This is a bug definitely.
When I am running an ubuntu server, fb is the one I need, while suspend/resume is not.
fb has been existed in the kernel for a long time, you can not just set it as blacklist for all the situations just because of suspend/resume problem. Since there are so many people they do not need suspend/resume function, but fb function is required.
Please, something did changed from 2.6.24-11 to 2.6.24-12, fix it, please.

Here tested it again with http://releases.ubuntu.com/releases/8.04/ubuntu-8.04-beta-server-i386.iso
This is a release for server, I did not touch anything, no "vga=xxx" in boot parameter, just booted it, when I saw the language to choose, I used ctrl-alt-fx to switch them. If I switched more than 2 ttys, it's blank.
See ?
This is in ubuntu server release, same problem. I did not put any vga=xxx as boot parameter. Just boot it, and got this problem.
Please, test it and you will see this is not a normal vesafb problem. I think I'd better to report this as another new bug report.

On Sun, 23 Mar 2008 07:12:09 -0000
fishor <email address hidden> wrote:

> fb modules are black listed becouse of wired issues on suspend/resume.
> So it should be blacklisted by default. Please do not report this bug
> anymore.

<consciously noisy rant>
fishor: You appear to think that this bug should just die quietly, without
being fixed. You also appear not to have read Ben Collins' comments, and
the fact that frame buffer modules *supposedly* can be loaded with vga=xxx
in the most recent hardy kernel.

I have reported a bug against console-setup, in the hope that the bug is no
longer kernel-related. See Bug #205484

People will continue to comment on this bug *until it is properly fixed* .
So far, it isn't fixed.

If the developers do not like the noise, I suggest that they try booting
with vga=791 for example, then attempt to switch to tty2-6 . Until the
behaviour is rectified to work as it has done without issues in every
Linux since way back in kernel 2.2 or so, it isn't fixed.

This bug is making a lot of people unhappy (see subscriber numbers), and
has been unfixed for over six months. A lot of sysadmins will stop using a
distribution that only gives them 80x25 without X, for example. Have fun
trying to use mc, jed, or any number of slang and ncurses console apps
without decent fb resolution and functionality...

</consciously noisy rant>

The chvt / blank tty on ALT+F[1-6] behaviour is apparently Bug #201591 (Thanks, Matthew Garrett)

I'm having this problem too with Hardy BETA/amd64/nvidia-glx-new. vga=791 is fine, but vga=792 is blank.

I have been using "un-blacklist-workaround" for some time now (both in Gutsy and Hardy) but after 2.6.24-12 kernel was installed, the workaround stopped working.

While booting to 2.6.24-12, system hangs just after usplash has been shown and power-cycling is required. When using nosplash, the system boots, X session is opened, but when I switch to console no text is displayed. I tried to log in and start mc and strange thing: background colors are more or less properly displayed, but not the text. Running setupcon makes the fonts visible, but after switching to another VT and back makes issue come again.

This appears to be somehow related to kernel 2.6.24-12. While I am booting to 2.6.24-11 virtual consoles are working just fine, the same is with usplash.

I first encountered the issue the same day 2.6.24-12 kernel was first released. Since then i updated system frequently

So I see two issues there somehow related to 2.6.24-12 kernel:
1) Usplash hanging boot process.
2) No text displayed on virtual terminals using vesafb driver.

Maybe some vesafb bug was addressed in 2.6.24-12-21; but obviously another issue came out of it... some kind of regression...

The most recent issue was observed after 2.6.24-12 kernel upgrade.
The solution can be found by answering the question:
"WHAT HAS CHANGED BETWEEN 2.6.24-11 and 2.6.24-12?"

--
Hardy/x86; Nvidia 8600GT (fb:vesafb X:nvidia-glx-new);

The vt / tty switching blank screens problem is a different bug - it is not
this one.

Please read Bug #201591 "atyfb regression - screen blank except for
blinking cursor after fbcon vtswitch"

If you will help, really _can_ do it. No programming experience needed.

Best choice to begin is vanilla kernel, but you can do the same with
ubuntu kernel too..

1. download latest kernel and chack if bug still there.

sudo apt-get install git-core

git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

for vanilla kernel

or

git clone git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git

for ubuntu hardy.

2. install packages to build kernel
sudo apt-get build-dep linux
sudo apt-get install libncurses5-dev libncursesw5-dev

3. go to kernel, configure, compile and install it.
( you do not need to make kernel with initrd )

cd linux-2.6
make menuconfig ( to configure kernel )
make -j2 all && sudo make isnatll && sudo make modules_install

( -j2 option for dual core users )

4. edit grub to boot latest kernel

sudo vi ( or ) nano /boot/grub/menu.lst

-----------------------------------------------------------
and change this parts:
timeout 5
#hiddenmenu

title Linux
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 acpi_sleep=s3_bios,s3_mode
libata.noacpi=1 ro
----------------------------------------------------------

normally you will have other kernel parameters

5. (MOST important part) If bug still exist and this is regression to
some kernel version:

man git-bisect

git bisect start ( will make extra branch for testing )
git bisect bad ( current version is bad )
git bisect good v2.6.23 ( version 2.6.23 is bad )

make menuconfig
make -j2 all && sudo make isnatll && sudo make modules_install

reboot test kernel if it's good, go to you git repository:

cd linux-2.6
git bisect goodmake -j2 all && sudo make isnatll && sudo make
modules_install
#if it's bad
git bisect bad

--------------------------------------------------------------------------

This testing will need some time bud you will find exact patch braced
your system. And believe me, such bug report will really accelerate bug
fixing and make you as part of solution and not part of noise.

There seems to be a fundamental difference in handling vesafb between 2.6.24-12 and the previous 2.6.24-11.

2.6.24-12:

Rebuilding the initramfs with vesafb, fbcon and vga16 results in a working framebuffer setup when started with video=vesafb vga=0X31A. However, one is left with a blinking cursor on an otherwise blank screen. A root login is possible and setupcon reveals a functional console at the desired resolution. Switching between ttys leaves one with a blank console again, setupcon brings it back.

2.6.24-11:
Rebuilding the initramfs with vesafb, fbcon and vga16 results in an 80x25 textconsole with working ttys, but vesafb is not initialized:

[ 14.919875] vga16fb: initializing
[ 14.919879] vga16fb: mapped to 0xc00a0000
[ 15.023979] fb0: VGA16 VGA frame buffer device

I found that 2.6.24-12 puts vesafb into /lib/modules/2.6.24-12-generic/initrd/ while 2.6.24-11 does not do that. Manually copying the module into /lib/modules/2.6.24-11-generic/initrd/ and rebuilding intramfs doesn't make a difference.

Go figure.

Hardware: Thinkpad T60, Intel 945, SXGA+ with broken Video BIOS (No 1400x1050)

An additional, maybe related culprit, which I am asking other users to verify; maybe it helps to track down what's really going on:

Two Different X-Sessions, the first one created by logging into KDM, second one created by "Switch User" with a different user from the KDE-Menu. The two sessions can be reached by Ctrl-Alt-F7 and Ctrl-Alt-F9.

Almost in 90% percent of the cases switching back from F9 to F7 results in a blank screen with the mouse pointer present and I can see its shape change when hovering over the KDE-Menu, Also, Input is possible by Alt-F2.

Since I have another distribution (Mandriva) sitting on a different partition, it simply works there, so this is definitely an /K)Ubuntu problem. Also, in Mandriva I can use a console with hi-res framebuffer and switch back and forth without problem.

DF5JT --

> Rebuilding the initramfs with vesafb, fbcon and vga16

My experience has been that I get better results using vesafb OR vga16fb,
but not both. With your hardware setup, my initial guess would be that
vesafb is better for your hardware.

Does dropping vga16fb make a difference in the outcome in your case?

This is unrelated:

>Rebuilding the initramfs with vesafb, fbcon and vga16 results in a working framebuffer setup when started with video=vesafb vga=0X31A. However, one is left with a blinking cursor on an otherwise blank screen.
>A root login is possible and setupcon reveals a functional console at the desired resolution. Switching between ttys leaves one with a blank console again, setupcon brings it back.

I belive this is bug #201591 which is fixed and patches should go soon to repos.

When will this fix really appear in repositories? (if there's a fix at all).

The 2.6.24-13.23 kernel seems to fix the framebuffer issue, but my Creative Audigy soundcard doesn't work with this kernel. As the following linux-restricted-drivers package was not put in the repos, closed-source NVIDIA video driver doesn't work either. Another machine here doesn't get its MCP51 High Definition Audio recognized.

I'd like to thank all people involved in fixing this bug and 201591. Seeing things being sorted out is wonderful, and I hope the final fix without regression cases will appear soon.

Bug #201591 is now fixed.

Saïvann, are you on x86? I'm still having the problem on amd64, where 2.6.24-12.23 doesn't seem to be available yet...

ski : The 2.6.24-13 kernel is available for AMD64 too, I just looked, but the restricted-modules are not yet. It's normal that you still have the problem if you did not install the update. Just wait for update-manager to install the packages once they will be all ready. After this, if you still have problems, it is appropriate to look at this deeper.

search for screen in the repositories, install it, boom, you have vt's.

I believe both my sound cards not being recognized is not related at all to the -restricted modules, as ALSA is free and included by default in Kernel.
The released fix introduced a grave regression. It manifests with linux-2.6.24-13.23 (amd64) ,but not with 2.6.24-12.
Not being able to play sound is imo a showstopper, so please don't consider this bug closed yet.
Thanks for the ongoing effort on this yet-to-be-fixed bug. ;)

Taupter : restricted modules and ubuntu modules are two packages which add drivers and modules to ubuntu. Most of laptops won't have sound working without these packages for your kernel, opening a new bug report for this is really not appropriate because you don't have necessary packages installed, this is not a bug. Alsa is the linux sound system, but this system won't use your sound card if the linux kernel does not have any drivers (modules) for it. Also, problem with sound cards is not a part of this bug which is about blank tty, this bug is closed. It would make more sense that you wait for the ubuntu-modules and restricted-modules to come for your kernel before opening a bug for this if the problem really persist.

Issue is result of perceived conflict between framebuffer kernel driver and X video driver. See extended discussion in the thread

Why is that bug still open in xserver-xorg-video-ati? Does the framebuffer problem persist with ATI cards with latest ubuntu kernel? If not, we should close that bug and open new bugs if new issues appears.

As far as I can tell, this fixes my problem with an NVidia Geforce Go 7300. If there is a seperate ATI issue, it should be broken into a seperate bug imo.

Cheers...

Setting back to fix released. This bug is fixed and similar issues should be posted as different bugs. Thanks.

Trying the latest Intrepid kernel with the following packages:

linux_2.6.27.2.2_i386.deb
linux-generic_2.6.27.2.2_i386.deb
linux-image_2.6.27.2.2_i386.deb
linux-image-2.6.27-2-generic_2.6.27-2.3_i386.deb
linux-image-generic_2.6.27.2.2_i386.deb
linux-restricted-modules_2.6.27.2.2_i386.deb
linux-restricted-modules-2.6.27-2-generic_2.6.27-2.2_i386.deb
linux-restricted-modules-common_2.6.27-2.2_all.deb
linux-restricted-modules-generic_2.6.27.2.2_i386.deb

and I am not getting my tty-s when using vesafb. Is there a regression and should this bug be reopened?

Same for me, Intrepid uses the new uvesafb for the same function so vesafb
can be blacklisted again. I disabled my vesafb and let uvesafb do the job
and everything went fine.
Just make sure that v86d package is installed, in my case it was not and had
to do it manually.

On Fri, Sep 5, 2008 at 12:39 PM, Shriramana Sharma <email address hidden>wrote:

> Trying the latest Intrepid kernel with the following packages:
>
> linux_2.6.27.2.2_i386.deb
> linux-generic_2.6.27.2.2_i386.deb
> linux-image_2.6.27.2.2_i386.deb
> linux-image-2.6.27-2-generic_2.6.27-2.3_i386.deb
> linux-image-generic_2.6.27.2.2_i386.deb
> linux-restricted-modules_2.6.27.2.2_i386.deb
> linux-restricted-modules-2.6.27-2-generic_2.6.27-2.2_i386.deb
> linux-restricted-modules-common_2.6.27-2.2_all.deb
> linux-restricted-modules-generic_2.6.27.2.2_i386.deb
>
> and I am not getting my tty-s when using vesafb. Is there a regression
> and should this bug be reopened?
>
> --
> Blank ttys when using vesafb (vga=xxx)
> https://bugs.launchpad.net/bugs/129910
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I am attaching another bug with uvesafb that may apear for those switching
to intrepid, just a reference:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246269

On Fri, Sep 5, 2008 at 3:35 PM, Salva Ferrer <email address hidden> wrote:

> Same for me, Intrepid uses the new uvesafb for the same function so vesafb
> can be blacklisted again. I disabled my vesafb and let uvesafb do the job
> and everything went fine.
> Just make sure that v86d package is installed, in my case it was not and
> had to do it manually.
>
>
> On Fri, Sep 5, 2008 at 12:39 PM, Shriramana Sharma <email address hidden>wrote:
>
>> Trying the latest Intrepid kernel with the following packages:
>>
>> linux_2.6.27.2.2_i386.deb
>> linux-generic_2.6.27.2.2_i386.deb
>> linux-image_2.6.27.2.2_i386.deb
>> linux-image-2.6.27-2-generic_2.6.27-2.3_i386.deb
>> linux-image-generic_2.6.27.2.2_i386.deb
>> linux-restricted-modules_2.6.27.2.2_i386.deb
>> linux-restricted-modules-2.6.27-2-generic_2.6.27-2.2_i386.deb
>> linux-restricted-modules-common_2.6.27-2.2_all.deb
>> linux-restricted-modules-generic_2.6.27.2.2_i386.deb
>>
>> and I am not getting my tty-s when using vesafb. Is there a regression
>> and should this bug be reopened?
>>
>> --
>> Blank ttys when using vesafb (vga=xxx)
>> https://bugs.launchpad.net/bugs/129910
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>

In Interpid I've installed v86d and blacklisted vesafb, but still see blank consoles. They worked fine in hardy with vesafb.

One year later and this problem still isn't fixed. http://ardchoille.nfshost.com/Blog/20081029

ardchoille

I sympathize with your frustrations. I did a clean install to Intrepid after release date. This issue has returned to my laptop. I will be working for net couple hours to see what hack must be done to resolve it.

My solution under Intrepid:

modified /boot/grub/menu.lst
added vga=0x0323 to defoptions

modified /etc/usplash.conf:
xres=1024 was: 1440
yres=768 was: 900

Note: vga=0x0365 did not work even though my default display is 1440x900. During reboot this produced a screen of vga mode options for me to choose from, and an option to scan. I selected "scan" and the result did not offer any modes in the 1440x900 resolution. I ended up selecting the best 1024x768 mode available.

I did not need to mess with modules vga16fb and vesafb in any manner.

I am wondering if during the installation of Intrepid, the system was unable to properly detect my resolution and so excluded the vga line from the menu.lst file? Just a guess...probably wrong though. Based off of what I observed today, I can't help but think that this bug has a hook into the default display resolution and the ATI fglrx driver.

For the moment my TTYs are working.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.