Ubuntu

Blank ttys when using vesafb (vga=xxx)

Reported by Miguel Martinez on 2007-08-02
438
This bug affects 5 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Medium
Unassigned
Declined for Gutsy by Henrik Nilsen Omma
Hardy
Medium
Unassigned
linux (Ubuntu)
Medium
Ben Collins
Declined for Gutsy by Henrik Nilsen Omma
Hardy
Medium
Ben Collins
linux-source-2.6.22 (Ubuntu)
Undecided
Unassigned
Declined for Gutsy by Henrik Nilsen Omma
Hardy
Undecided
Unassigned
xserver-xorg-video-ati (Debian)
Fix Released
Unknown
xserver-xorg-video-ati (Ubuntu)
Undecided
Unassigned
Declined for Gutsy by Henrik Nilsen Omma
Hardy
Undecided
Unassigned
xserver-xorg-video-intel (Ubuntu)
Undecided
Unassigned
Declined for Gutsy by Henrik Nilsen Omma
Hardy
Undecided
Unassigned

Bug Description

This is on a Dell Inspiron 8600 w/ ATi Mobility Radeon 9600, and might be related to bug #102712. Since a dist-upgrade to Gutsy, changing to tty[1-6] will result on a black screen. The tty's however, are showing in `ps aux`, and they will respond to input if I switch to any of those (i.e. I can reboot the computer from tty1 or play an ogg). Also, ssh logins are successful.

Boot options in grub are: nolapic splash locale=es_ES vga=791

I've updated the BIOS and the video BIOS, and also used the custom DSDT from acpi.sourceforge.net, but to no avail. Using nosplash option will result in an absolutely black screen until gdm loads. Booting into recovery mode, however, will give me a text terminal, and the text output during boot will be visible.

I have no /etc/inittab file, but feisty doesn't seem to have one either. There are three files named *inittab* in my system; a vim hilight file, a sample file at /usr/share/ubuntu-docs and a perl script for upstart named /usr/lib/ipstart/migrate-inittab.pl

Thank you very much for your attention.

Miguel Martinez (el-quark) wrote :

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.

Miguel Martinez (el-quark) wrote :

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.

John Yates (andyfranyates) wrote :

I can confirm this. I have a nvidia card.

hexion (hexium) wrote :

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

Steven Ketelsen (podfish) wrote :

Confirmed here as well.

Ryan Grieve (thegrieve) wrote :

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

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

Charon (markus-lobedann) wrote :

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.

TJ (tj) wrote :

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

Conn O Griofa (psyke83) wrote :

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.

Conn O Griofa (psyke83) wrote :

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

Albin Tonnerre (lutin) wrote :

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

John Yates (andyfranyates) wrote :

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

TJ (tj) wrote :

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

Conn O Griofa (psyke83) wrote :

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.

TJ (tj) wrote :

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

Charon (markus-lobedann) wrote :

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.

Albin Tonnerre (lutin) wrote :

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

Changed in initramfs-tools:
importance: Medium → Critical
Kyle M Weller (kylew) wrote :

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

Steve Langasek (vorlon) on 2007-09-29
Changed in initramfs-tools:
importance: Critical → High
Albin Tonnerre (lutin) wrote :

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

Basilio Kublik (sourcercito) wrote :

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.

Brian Murray (brian-murray) wrote :

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.

Luca Carrogu (motoplux) wrote :

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)

Jani Averbach (jaa-jaa-iki) wrote :

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)

Charon (markus-lobedann) wrote :

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

René Schmidt (r.schmidt) wrote :

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.

Thomas Sommer (flightsupport) wrote :

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?

René Schmidt (r.schmidt) wrote :

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.

John Yates (andyfranyates) wrote :

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.

Luca Carrogu (motoplux) wrote :

modprobing vesafb gives me blinking spreadly green curson in the tty

Thomas Sommer (flightsupport) wrote :

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.

hexion (hexium) wrote :

That last workaround didn't work here..

Basilio Kublik (sourcercito) wrote :

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?

hexion (hexium) wrote :

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

Albert Damen (albrt) wrote :

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)

René Schmidt (r.schmidt) wrote :

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

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

I can confirm this but the resolution is only 800x600px. I opted for vga=791 what should result in 1024x768px. But hey, at least there are some tty's! ;)

Aren Olson (reacocard) wrote :

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

I can confirm that this does bring back the terminals, but at only 800x600px.

MOM2007 (masterofmagic) wrote :

on my virtual pc installation i fixed the problem with the following steps:

1. sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb

so my /etc/initramfs-tools/modules looks like:

fbcon
vesafb

2. sudo update-initramfs -u

3. sudo vi /etc/modprobe.d/blacklist-framebuffer

change the line "blacklist vesafb" to "# blacklist vesafb"

4. reboot and everything is fine

HTH
MOM

On 10/6/07, MOM2007 <email address hidden> wrote:
>
> on my virtual pc installation i fixed the problem with the following
> steps:
>
> 1. sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
>
> so my /etc/initramfs-tools/modules looks like:
>
> fbcon
> vesafb
>
> 2. sudo update-initramfs -u
>
> 3. sudo vi /etc/modprobe.d/blacklist-framebuffer
>
> change the line "blacklist vesafb" to "# blacklist vesafb"
>
> 4. reboot and everything is fine
>
> HTH
> MOM
>
>
This works perfectly for me, thanks!

#43 Worked like a charm here
Thanks!

MOM2007 you rock! It works here too

TJ (tj) wrote :

In the latest Gutsy kernel images (looking at 2.6.22-13 here) vesafb is no longer compiled into the kernel image as it was when this bug was first reported. This is the reason the previous work-around no longer works.

As MOM has reported, it is now necessary to remove the vesafb module blacklist, and then have vesafb and fbcon loaded. Use module options to set resolution.

Miguel Martinez (el-quark) wrote :

What I find strange is that the kernel team has blacklisted vesafb. I mean, there has to be a reason why the modules that allow "high" resolutions and coulours in the tty's are no longer built into the kernel and one of these is even blacklisted. Anybody has a clue?

angel1127 (huxiaoping1127) wrote :

I test it under 2.6.22-13, it does not as MOM2007's description. when i pass vga=791
my notebook is thinkpad r50e with intel i801.

after startup, i modprode fbcon and vesafb
then there some green blocks in tty1,

angel1127 (huxiaoping1127) wrote :

today i updated ubuntu.
it has update to 2.6.22-14

i tested framebuffer. its ok....
Yeah.

when i startup, i see the grub list. non deve.... it is ubuntu 7.10
i cat /etc/issue
i found 7.10 released.

Kansei (clauretano) wrote :

Confirming that this is re-broken after the 2.6.22-14 update :(

mic.1.2.3 (launchpad-0123) wrote :

No change here. Problem remains on my pc with kernel 2.6.22-14 ...

For anyone who have this bug :

Please confirm that :

usplash run well (at boot and shutdown)
resolution in /etc/usplash.conf is good

Skeletonix (tomaskloucek) wrote :

confirmed ...

 in menu.list is set: vga=794
 in /etc/usplash:

   # Usplash configuration file
   #xres=1024
   #yres=768
   xres=1280
   yres=1024

and atherminal window is still black.

---
Linux Kosmik-1 2.6.22-14-generic #1 SMP Tue Oct 9 09:24:55 GMT 2007 x86_64 GNU/Linux

Skeletonix (tomaskloucek) wrote :

sorry:
atherminal == a terminal

confirmed no change here, alt ctrl F1-F6 are blank with a blinking
keyboard cursor, also when my chkfs scans my drive I dont see it,
also... text on boot up under the ubuntu logo is blue and not orange

I confirm the same: usplash is working well but no text in the terminal modes (ctrl F1-F6)

On Wednesday 10 October 2007 14:40:37 Patrice Vetsel wrote:
> /etc/usplash.conf

mine:
# Usplash configuration file
xres=1024
yres=768

grub:

title Xen 3.1 / Ubuntu 7.10, kernel 2.6.22-14-xen
root (hd0,6)
kernel /xen-3.1.gz
module /vmlinuz-2.6.22-14-xen root=UUID=d74052aa-50ed-4aea-9fbe-0a510b003684 ro console=tty0 vga=0x0360
module /initrd.img-2.6.22-14-xen
quiet

title Ubuntu 7.10, kernel 2.6.22-14-generic
root (hd0,6)
kernel /vmlinuz-2.6.22-14-generic root=UUID=d74052aa-50ed-4aea-9fbe-0a510b003684 ro usbcore.autosuspend=1 verbose splash vga=0x0360
initrd /initrd.img-2.6.22-14-generic
quiet

title Ubuntu 7.10, kernel 2.6.22-14-generic (recovery mode)
root (hd0,6)
kernel /vmlinuz-2.6.22-14-generic root=UUID=d74052aa-50ed-4aea-9fbe-0a510b003684 ro single vga=0x0360
initrd /initrd.img-2.6.22-14-generic

$ sudo hwinfo --framebuffer
02: None 00.0: 11001 VESA Framebuffer
  [Created at bios.447]
  Unique ID: rdCR.xnRagj3_2BF
  Hardware Class: framebuffer
  Model: "Intel(r)852GM/852GME/855GM/855GME Graphics Chip Accelerated VGA BIOS Intel(r)852GM/852GME/855GM/855GME Graphics Controller"
  Vendor: "Intel Corporation"
  Device: "Intel(r)852GM/852GME/855GM/855GME Graphics Controller"
  SubVendor: "Intel(r)852GM/852GME/855GM/855GME Graphics Chip Accelerated VGA BIOS"
  SubDevice:
  Revision: "Hardware Version 0.0"
  Memory Size: 15 MB + 832 kB
  Memory Range: 0xf0000000-0xf0fcffff (rw)
  Mode 0x0360: 1280x800 (+1280), 8 bits
  Mode 0x0361: 1280x800 (+2560), 16 bits
  Mode 0x0362: 1280x800 (+5120), 24 bits
  Mode 0x0363: 1280x800 (+1280), 8 bits
  Mode 0x0364: 1280x800 (+2560), 16 bits
  Mode 0x0365: 1280x800 (+5120), 24 bits
  Mode 0x033c: 1920x1440 (+1920), 8 bits
  Mode 0x034d: 1920x1440 (+3840), 16 bits
  Mode 0x035c: 1920x1440 (+7680), 24 bits
  Mode 0x033a: 1600x1200 (+1600), 8 bits
  Mode 0x034b: 1600x1200 (+3200), 16 bits
  Mode 0x035a: 1600x1200 (+6400), 24 bits
  Mode 0x0307: 1280x1024 (+1280), 8 bits
  Mode 0x031a: 1280x1024 (+2560), 16 bits
  Mode 0x031b: 1280x1024 (+5120), 24 bits
  Mode 0x0305: 1024x768 (+1024), 8 bits
  Mode 0x0317: 1024x768 (+2048), 16 bits
  Mode 0x0318: 1024x768 (+4096), 24 bits
  Mode 0x0312: 640x480 (+2560), 24 bits
  Mode 0x0314: 800x600 (+1600), 16 bits
  Mode 0x0315: 800x600 (+3200), 24 bits
  Mode 0x0301: 640x480 (+640), 8 bits
  Mode 0x0303: 800x600 (+800), 8 bits
  Mode 0x0311: 640x480 (+1280), 16 bits
  Config Status: cfg=new, avail=yes, need=no, active=unknown

and can anyone explain to me, why there are repeated resolutions for different modes?

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

On Wednesday 10 October 2007 16:53:09 Kyle Weller wrote:
> also... text on boot up under the ubuntu logo is blue and not orange

I also get that blue text. I rather have the old orange.

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

angel1127 (huxiaoping1127) wrote :

i update just now, and restart. it is ok on my computer with 22-14
i paste my configure steps as MOM2007 description above:

> on my virtual pc installation i fixed the problem with the following
> steps:
>
> 1. sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
>
> so my /etc/initramfs-tools/modules looks like:
>
> fbcon
> vesafb
>
> 2. sudo update-initramfs -u
>
> 3. sudo vi /etc/modprobe.d/blacklist-framebuffer
>
> change the line "blacklist vesafb" to "# blacklist vesafb"
>

On 10/11/07, Fabio Marzocca <email address hidden> wrote:
>
> I confirm the same: usplash is working well but no text in the terminal
> modes (ctrl F1-F6)
>
> --
> tty[1-6] are active but display nothing in Gutsy
> https://bugs.launchpad.net/bugs/129910
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
飘落的枫叶

I tried what MOM2007 recommended without success, and with my i845G with removed usplash wound up with:
/etc/initramfs-tools/modules:

fbcon
intelfb
vesafb

/etc/modprobe.d/blacklist-framebuffer
...
# blacklist i810fb
# blacklist intelfb
# blacklist vesafb
# blacklist vga16fb

No success, but I see in /lib/modules/2.6.22-14-generic/kernel/drivers/video/console only fbcon, no intelfb, no i810fb & no vga16fb, (but ../intelfb/intelfb.ko does exist - why there?) even though in /boot/config-23.6.22-14-generic:
...
CONFIG_FB=y
CONFIG_FB_VESA=m
CONFIG_FB_VGA16=m
CONFIG_FRAMEBUFFER_CONSOLE=m
CONFIG_FB_I810=m
CONFIG_FB_INTEL=m...

As expected after not finding those .ko files, lsmod finds neither vesafb nor i810fb, nor vga16fb, but only fbcon, and not even intelfb. Why didn't intelfb load? Why are there no .ko files for the rest?

I tried reducing /etc/initramfs-tools/modules to only intelfb, also without success. Even after update-initramfs -u that way intelfb fails to load on boot, and modprobe intelfb produces no apparent effect.

Albin Tonnerre (lutin) wrote :

Still no answer from the kernel team, re-setting as critical

Changed in initramfs-tools:
importance: High → Critical

good, it would be a shame to see Gutsy released with this problem, its
already a shame Ubuntu Gutsy is being released with ralink based
wireless cards not working properly:
https://bugs.launchpad.net/ubuntu/+bug/34902
Thank you
Kyle Weller

angel1127 (huxiaoping1127) wrote :

i use intel i810
i found

vesafb.ko
vga16fb.ko

under /lib/modules/2.6.22-14-generic/kernel/drivers/video.

i810fb.ko

under /lib/modules/2.6.22-14-generic/kernel/drivers/video/i810

fbcon.ko

under

under /lib/modules/2.6.22-14-generic/kernel/drivers/video/console

i think your configure may be have some error.
you just need to remove vesafb from blacklist.

you can you in blacklist-framebuffer , they say framebuffer driver is poorly
supported.
some add blacklist to make it no start when system startup.

i think you may need to just comment blacklist vesafb for a test.

best wish.

Driver is still a hard thing to Linux. we need to take time to learn write
it and contribute .

On 10/12/07, Felix Miata <email address hidden> wrote:
>
> I tried what MOM2007 recommended without success, and with my i845G with
> removed usplash wound up with:
> /etc/initramfs-tools/modules:
>
> fbcon
> intelfb
> vesafb
>
> /etc/modprobe.d/blacklist-framebuffer
> ...
> # blacklist i810fb
> # blacklist intelfb
> # blacklist vesafb
> # blacklist vga16fb
>
> No success, but I see in
> /lib/modules/2.6.22-14-generic/kernel/drivers/video/console only fbcon, no
> intelfb, no i810fb & no vga16fb, (but ../intelfb/intelfb.ko does exist - why
> there?) even though in /boot/config-23.6.22-14-generic:
> ...
> CONFIG_FB=y
> CONFIG_FB_VESA=m
> CONFIG_FB_VGA16=m
> CONFIG_FRAMEBUFFER_CONSOLE=m
> CONFIG_FB_I810=m
> CONFIG_FB_INTEL=m...
>
> As expected after not finding those .ko files, lsmod finds neither
> vesafb nor i810fb, nor vga16fb, but only fbcon, and not even intelfb.
> Why didn't intelfb load? Why are there no .ko files for the rest?
>
> I tried reducing /etc/initramfs-tools/modules to only intelfb, also
> without success. Even after update-initramfs -u that way intelfb fails
> to load on boot, and modprobe intelfb produces no apparent effect.
>
> --
> tty[1-6] are active but display nothing in Gutsy
> https://bugs.launchpad.net/bugs/129910
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
飘落的枫叶

You see that this *really* IS a problem since the Alternate Installer isn't even able to show up! Without altering any boot parameters!

People won't be able to install Gutsy if this bug remains.

regards

Synthaxx (synthaxx) wrote :

Bug confirmed in 2.6.22-14-generic on AMD 64 Ubuntu RC
22-12 works though.

What's really bugging me about this is that the kernel doesn't even start, just monitor out of sync and stays there.

I'd say this is SUPER CRITICAL!

pfaelzerchen (pfaelzerchen) wrote :

I can also confirm this bug with 2.6.22-14-generic on Intel Core Duo with ATI Mobility Radeon X1400.

ps shows running getty instances but switching to tty1-6 shows a blank screen with a white blinking text cursor.

Confirmed on Athlon XP 1800+ mit Nividia Geforce 6200

Martin-Éric Racine (q-funk) wrote :

Adding fbcon to initramfs modules had fixed it a while back, but this no longer is the case. I no longer have any fb console and, even worse, gdm also repeatedly fails to start. This all happened within the last couple of days and we are less than 4 days away from Gutsy release.

Confirmed here as well, shame on ubuntu, the problem is out there for a long time and is still not solved, all version after dapper are garbage...

Ati with fglrx driver , distro Gutsy RC , kernel 2.6.22-14-generic
The problem is the same and the update don't resolve nothing....

yes.
i update system today, i found it occurs again. so i think it is a
kernel error in 22-14 package.
i hope it is resolved when released in 10.18.

marco.proserpio writed:
> Ati with fglrx driver , distro Gutsy RC , kernel 2.6.22-14-generic
> The problem is the same and the update don't resolve nothing....
>
>
.

I can confirm that the fix by MOM2007 is working for me on HP compaq nx9105 with nvidia card.

uname -a:
Linux mars 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

> sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
> sudo update-initramfs -u
> sudo vi /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb"

In addition I changed the vga kernel parameter in /boot/grub/menu.lst from vga=791 to vga=0x0317 and did an "update-grub"

Everything is working now!

Fabio Marzocca (thesaltydog) wrote :

The fix doesn't work on GeForce 7300 SE

Can confirm this, too. System is an Asus V6V with Ati X600M. Why there is no comment from anyone from the launchpad Team? :( Would be nice to get some hard facts!

ac (ac-sonic) wrote :

I'd like to chime in that I'm seeing a hard system crash when I switch from X to tty1-6 on my Dell Precision M60 laptop with an nVidia Quadro FX Go 7000 (restricted drivers). When the crash happens not even the capslock key can be toggled and I have to power off completely.

I experienced this originally when doing an upgrade from Fiesty and got so frustrated that I did a wipe and reinstall to no avail. This really does strike me as something that must be fixed before it can be released.

A.C.
******

I use it as well.

2007/10/16, Fabio Marzocca <email address hidden>:
>
> The fix doesn't work on GeForce 7300 SE
>
> --
> tty[1-6] are active but display nothing in Gutsy
> https://bugs.launchpad.net/bugs/129910
> You received this bug notification because you are a direct subscriber
> of the bug.
>

confirmed on a geforce mx400
sometime i get also an hard crash
but i set up that if i press power it reboots so..
no keyboard signals are possible.

I also have a boot parameter vga=0x318 which worked on Feisty. Did my upgrade yesterday, kernel 2.6.22-24 came with the install and now I got a black screen as well. Due to the problems I isolated the parameters to just vga. For the record, I have an ATI radeon Mobility 9600

Tried the suggestion:
> sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
> sudo update-initramfs -u
> sudo vi /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb"

It ain't working. Only when vga=0x318 is removed, then I get my console output. Also, when started up in recovery mode, there is only one tty. When trying to switch I get a black screen with blinking cursor.

In my opinion, this bug is not critical though it should be fixed before the release. People who play with their boot parameters know how to recover. This is not noob stuff.

I'm not sure if my case is like Martin-Éric Racine with a crashing gdm but I'm experiencing what seems like a Xorg crash and might be related. X hangs, no ctrl-alt-backspace, no ctrl-alt-f2. Just a hard reboot works. From several Xorg logs I can see the output stops at different moments.

I got to fix it by changing vesafb into radeonfb in the above instructions. vesafb is not present on the system so it cannot be loaded. radeonfb does and it works even better than vesafb did. Much clearer font in the console. Unfortunately cpu scaling doesn't work *sigh* so I cannot use this latest kernel but that is another story.

confirmed here too
no fix found yet.
vesafb shows a crumpled screen

The problem also started appearing on my laptop on kernel 2.6.22-14. The posted fix works fine for me on a GeForce 8600M GT in 1024x768 (vga=0x317). I put vesafb first in the modules file, followed by fbcon. Not sure if that makes a difference.

> sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
 > sudo update-initramfs -u
 > sudo vi /etc/modprobe.d/blacklist-framebuffer
 > change the line "blacklist vesafb" to "# blacklist vesafb"

I can confirm this problem on my Thinkpad T60. I have an ATI Mobiliy Radeon X1400, and since updating to Gutsy (kernel 2.6.22-14-generic) I'm unable to use a vga=791 setting. I have to remove the vga= setting completely to have any output at all (and all I get then is the standard resolution which is horrible).

I hope we can find a fix for this issue, it is really annoying if you want to do work directly on a terminal.

I tried the workaround, but without success. I can't get my terminal to display a higher resolution, even if I add fbcon and vesafb to the initramfs modules file and disable the blacklist of vesafb

subtrnl (emailchase) wrote :

I can confirm, any vga= settings in the boot params in menu.1st will black screen the consoles.

The above fix didn't work

uname -r
2.6.22-14-generic

lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

C de-Avillez (hggdh2) wrote :

have you tried vga=<hex>?

Like vga=0x31a

NeverMind (agathe-durieux) wrote :

I've got a Nvidia FX 5200

> sudo nano /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb"
> sudo vi /etc/initramfs-tools/modules and add fbcon and --> nidiafb
> sudo update-initramfs -u -k all

It works for me ;)

NeverMind (agathe-durieux) wrote :

oops !

> sudo nano /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb"
> sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
> sudo modprobe nvidiafb
> sudo update-initramfs -u -k all

Sorry

Fabio Marzocca (thesaltydog) wrote :

Thank you, NeverMind. Your fix worked for me (GeForce 7300).

Felix Miata (mrmazda) wrote :

I just did updates again, and tried as NeverMind suggested in comment 89. As I have Intel 845GL, I did s/nvidiafb/intelfb/. With the default stanza and vga=788 I still have useless ttys, although there is some scrambled junk on the top few rows of each instead of entirely black.

This system also has Mandriva 2008 installed. Console framefuffer video works nicely as expected using it.

Radeon R250 [Mobility FireGL 9000] has problems with vesafb and splash screen. Without using splash screen you can use vga= by decimals or hex. Saving energy by save to disk there is no output from console.

So I did:
sudo mcedit /etc/initramfs-tools/modules
  fbcon
  radeonfb

sudo update-initramfs -u -k all -v

sudo mcedit /etc/modprobe.d/blacklist-framebuffer
  #blacklist radeonfb

sudo modprobe radeonfb

Now it's all right.

On Friday 19 October 2007 04:47:45 hggdh wrote:
> have you tried vga=<hex>?
>
> Like vga=0x31a
>

this is what I have:
title Ubuntu 7.10, kernel 2.6.22-14-generic
root (hd0,6)
kernel /vmlinuz-2.6.22-14-generic root=UUID=d74052aa-50ed-4aea-9fbe-0a510b003684 ro usbcore.autosuspend=1 verbose splash vga=0x0360
initrd /initrd.img-2.6.22-14-generic
quiet

I have just a blank TTY

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

I just tried Kai's fix on a Dell Inspiron 1501 Radeon Xpress 200M runnning Gutsy.

No luck though!

> uname -r
2.6.22-14-generic

Felix Miata (mrmazda) wrote :

I tried on another machine with 2.6.22-14-, both 386 & generic, and Matrox G400. More less the same problem, except that once KDM starts, trying to switch to tty[1-6] gives me the KDM background image instead of a black screen, but all during init it's all black.

vesafb does not show up in lsmod output. fbcon and matrox_w1 do.

When I do modprobe vesafb manually in Konsole, I get the ttys video working. Alternatively, I can switch to a tty, login blindly, and modprobe vesafb there for the same result.

Martin-Éric Racine (q-funk) wrote :

This bug really should be reassigned to package "udev" because it ships a blacklist-framebuffer file that prevents loading of all frame buffer drivers. This, in turn, affects the creation of ramdisk images, which can be handled by different tools, because the blacklist also prevents the inclusion of the driver in ramdisk images.

Anyhow, by the looks of it, the kernel that ships with Gutsy is back to where the Feisty kernel was, in terms of features: fbcon and vesafb copiled as modules. The only notable difference is the newer udev that includes the afore mentioned module blacklist, which is why this bug really ought to be reassigned to "udev".

Ian MacGregor (ardchoille42) wrote :

I just installed Kubuntu 7.10 (Gutsy Gibbon) a few hours ago on an AMD Sempron 2800+. Install went fine, then installed nvidia-glx-new (with the Restricted Manager) for my nvidia GeForce 6200 card. I tried to ctrl+alt+f1 and noticed the screen was black and none of my tty's work.

ps aux | grep tty reports:

root 4456 0.0 0.0 1696 488 tty4 Ss+ 12:32 0:00 /sbin/getty 38400 tty4
root 4457 0.0 0.0 1692 484 tty5 Ss+ 12:32 0:00 /sbin/getty 38400 tty5
root 4461 0.0 0.0 1696 484 tty2 Ss+ 12:32 0:00 /sbin/getty 38400 tty2
root 4462 0.0 0.0 1692 480 tty3 Ss+ 12:32 0:00 /sbin/getty 38400 tty3
root 4463 0.0 0.0 1696 488 tty1 Ss+ 12:32 0:00 /sbin/getty 38400 tty1
root 4464 0.0 0.0 1692 484 tty6 Ss+ 12:32 0:00 /sbin/getty 38400 tty6
root 4974 0.9 4.3 49480 44708 tty7 SLs+ 12:32 0:40 /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-rFJ4KA

and KDE 3.5.8 is running quite well on tty7.

Is there a fix that works for this problem yet? I'm kinda lost without my tty's.

Salva Ferrer (salva-ferrer) wrote :

I've just tried the solution provided by NeverMind:

> sudo nano /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb"
> change the line "blacklist nvidiafb" to "# blacklist nvidiafb" (---> I added this, it was not in the original post, I don't know if it is really needed but make sense to me to use the nvidia fb driver)
> sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
> sudo modprobe nvidiafb
> sudo update-initramfs -u -k all

and reboot.

My ttys are back in my AMD64 with GeForce 6600

Ian MacGregor (ardchoille42) wrote :

ardchoille here again. AMD Sempron 2800+ running Kubuntu7.10 with nvidia drivers installed for my GeForce 6200 card. uname -a returns:

Linux localhost 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

I tried this:

sudo vim /etc/modprobe.d/blacklist-framebuffer
changed the line "blacklist vesafb" to "# blacklist vesafb"
changed the line "blacklist nvidiafb" to "# blacklist nvidiafb"
sudo vim /etc/initramfs-tools/modules and added fbcon and vesafb
sudo modprobe nvidiafb
sudo update-initramfs -u -k all

Now I see the bootup sequence (which I didn't see before) but, as soon as kdm starts, tty's 1-6 are black screens.
So, this fix didn't work for me.

Thomas Sommer (flightsupport) wrote :

Why do you add vesafb to your /etc/initramfs-tools/modules instead of the nvidiafb?
As far as I know vesafb is for intel chips.

Try the following:

sudo vi /etc/initramfs-tools/modules and add fbcon and nvidiafb
sudo update-initramfs -u -k all

Ian MacGregor (ardchoille42) wrote :

Thank you for trying Thomas Sommer, but it didn't work.

I can't live without my tty's. If xorg breaks, I have no alternative but to reinstall Kubuntu. At least in Feisty, I was able to use screen + mutt + irssi + elinks + bash + mc in tty 1-6 and was able to continue work and not have to worry about xorg. This is seriously crippled.

My tty return back, i lost it after last update kernel. today i test
update-initramfs -u -k all.
then restart it, tty return.
so i think its because default kernel all black all framebuffer, so you
need to update by your configure files
/etc/modprobe.d/blacklist-framebuffer && /etc/initramfs-tools//modules.

In kernel 2.6.23 source document, i see module vesafb is used for intel
chips.
but fbcon is used to all.
so configure modules according to your chip.

ardchoille 写道:
> Thank you for trying Thomas Sommer, but it didn't work.
>
> I can't live without my tty's. If xorg breaks, I have no alternative but
> to reinstall Kubuntu. At least in Feisty, I was able to use screen +
> mutt + irssi + elinks + bash + mc in tty 1-6 and was able to continue
> work and not have to worry about xorg. This is seriously crippled.
>
>

I have fixed it on the following:
Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 03)

I followed satkata's instructions from https://bugs.launchpad.net/ubuntu/+bug/152089 1st comment:
> 1. sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
> so my /etc/initramfs-tools/modules looks like:
> fbcon
> vesafb
> 2. sudo update-initramfs -u
> 3. sudo vi /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb"
> 4. reboot and everything is fine

3-M (meyer30m) wrote :

I have an ATI Radeon 9600 card, and Kai's fix (

sudo mcedit /etc/initramfs-tools/modules
  fbcon
  radeonfb

sudo update-initramfs -u -k all -v

sudo mcedit /etc/modprobe.d/blacklist-framebuffer
  #blacklist radeonfb

sudo modprobe radeonfb

)

Lets me see the shutdown messages, but I still get the black screen on boot up.

3-M (meyer30m) wrote :

I got it!!! I also commented out "blacklist vesafb" in /etc/modprobe.d/blacklist-framebuffer, and now it works! I'm using the 2.6.22-14-generic kernal.

komputika (info-komputika) wrote :

Got no luck with the workaround here.
using vga=0x318

maddler@aubergine [4|~/thunderbird-maddler] $ uname -a
Linux aubergine 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce Go 7600] (rev a1)

@ Thomas Sommer: nvidiafb is fine if you are using "nv" video driver, but it conflicts with the "nvidia-glx-new" proprietary driver. Since vesafb works well with nvidia video cards, that's the suggested choice to use.

Salva Ferrer (salva-ferrer) wrote :

Changing my previous comment, for my nvidia card the nvidiafb driver is not needed, a wrong testing procedure made me think that. Vesafb is more than enough as Jean has noted.

So the suggestions by NeverMind, satkata and Absorbed are basically the same and worked as is for me without needing additional modules for my nvidia card. Maybe other cards require other modules instead of the vesafb, maybe that is the reason why it is not working for evryone.

If this is the case this links can be useful to find which fb module needs each card:

http://www.linux-fbdev.org/
http://en.tldp.org/HOWTO/Framebuffer-HOWTO.html

On 10/21/07, Salva Ferrer <email address hidden> wrote:
> Changing my previous comment, for my nvidia card the nvidiafb driver is
> not needed, a wrong testing procedure made me think that. Vesafb is more
> than enough as Jean has noted.

My card (GeForcde 7300 LE) was not working with vesafb and it is
working with nvidiafb,

Kyle M Weller (kylew) wrote :

I had the same problem with no tty's, all I did to fix it was reinstall
gutsy and restore my packages with aptoncd and my /home partition took 20
minutes to fix this problem that way

1.) I edited my /etc/initramfs-tools to look like:
fbcon
vsafb
vga16fb

2.) I changed /etc/modprobe.d
blacklist vesafb -> #blacklist vesafb
blacklist vga16fb -> #blacklist vga16fb

3.) sudo update-initramfs -u

I have an Nvidia GeForce 7600 GS, and this worked for me.
Try enabling vga16fb if no other method works, as is the case with my computer.

Saul D Beniquez (saullawl) wrote :

I'm sorry, but the vsafb is supposed to be vesafb.

Aranel.Surion (aranelsurion) wrote :

My kernel is 2.6.22-14-386 , I tried removing vesafb from blacklisted modules and modprobe it / added it to initramfs modules , but this problem still persist. When I modprobe vesafb and fbcon, tty[1-6] gives black screen, When I boot my system without vesafb, It gives only flashing "_". It's very annoying.

Someone from Ubuntu Team can solve this ? Life is too hard without my sweet tty consoles :)

P.S : Sorry for my English :)

Saul D Beniquez (saullawl) wrote :

Try removing vga16fb from the blacklist,
and adding it along with vesafb and fbcon to the initramfs modules.

Felix Miata (mrmazda) wrote :

I've followed recommendations exactly, and variations thereof, with both Matrox and Intel chips. In no case has lsmod ever shown vesafb as having been loaded by the time init completes. Only when I modprobe vesafb manually do I get working framebuffer consoles.

I have tried all of the proposed fixes here and none of them have worked for me.

nVidia GeForce 6200 with the nvidia-glx-new driver in Kubuntu 7.10 (Gutsy) on AMD Sempron 2800+.

Felix Miata (mrmazda) wrote :

depmod -a didn't change anything for me.

have you play movie with mplayer when you use vga16fb.
i tested it before.
it can not... ...
if you hae some time, Pls take a test, and paste a test report, THX

El Chupacabras 写道:
> 1.) I edited my /etc/initramfs-tools to look like:
> fbcon
> vsafb
> vga16fb
>
> 2.) I changed /etc/modprobe.d
> blacklist vesafb -> #blacklist vesafb
> blacklist vga16fb -> #blacklist vga16fb
>
> 3.) sudo update-initramfs -u
>
> I have an Nvidia GeForce 7600 GS, and this worked for me.
> Try enabling vga16fb if no other method works, as is the case with my computer.
>
>

angel1127 (huxiaoping1127) wrote :

have you identify which video card you use?
if you are using intel serial card, use vesafb, if other cards.
Pls use suitable driver instead of vesafb.

after you edit your configure files,
Pls do "update-initramfs -u -k all" to update all kernel you installed.

Aranel.Surion 写道:
> My kernel is 2.6.22-14-386 , I tried removing vesafb from blacklisted
> modules and modprobe it / added it to initramfs modules , but this
> problem still persist. When I modprobe vesafb and fbcon, tty[1-6] gives
> black screen, When I boot my system without vesafb, It gives only
> flashing "_". It's very annoying.
>
> Someone from Ubuntu Team can solve this ? Life is too hard without my
> sweet tty consoles :)
>
>
> P.S : Sorry for my English :)
>
>

ardchoille here again. I wanted to post some new information in case it is helpful.

I just did a complete fresh install of Kubuntu 7.10 (Gutsy) on this machine. Here is what I found:

First reboot after the new install I found that all tty's (1-7) are functioning correctly.
I installed a lot of apps, made lots of tweaks and reconfigured xorg to get the resolution I wanted.
After rebooting, I noticed that all tty's are still working properly. The only thing different this time is I did not install nvidia drivers.

The normal way I installed nvidia drivers in Feisty was:

sudo apt-get install nvidia-glx
sudo nvidia-glx-config enable
sudo dpkg-reconfigure xserver-xorg
sudo /etc/init.d/kdm restart

The first time I installed nvidia drivers in Gutsy (which started this problem), I used the Restricted Manager - which I feared but did it anyway. The thing I disliked about that manager is that it didn't give me a choice between the nvidia-glx and nvidia-glx-new drivers - I dislike using "new" things because they're usually buggy. I'm wondering if I install nvidia-glx the old way if that will avoid this non-existent tty problem. I don't think it's the kernel because I have all tty's working now on the same machine and same kernel that had the problem earlier.. I think this has to do with the nvidia drivers.

Ian MacGregor (ardchoille42) wrote :

*** UPDATE: FIXED ***

ardchoille here. I fixed it. I have all tty's working properly now in Kubuntu 7.10 (Gutsy) with nVidia GeForce 6200 card (and nvidia-glx installed) on an AMD Sempron 2800+.

The problem started after using the Restricted Manager to install nvidia drivers - it automatically installed nvidia-glx-new without giving me any options. This somehow caused tty's 1-6 to stop working.

This time I installed the nvidia drivers manually with:

sudo apt-get install nvidia-glx && sudo nvidia-glx-config enable && sudo dpkg-reconfigure xserver-xorg

I did not alter /etc/initramfs-tools/modules or /etc/modprobe.d/blacklist-framebuffer in any way, nor did I run update-initramfs, and I didn't modprobe anything.

After rebooting, I have all tty's working properly as they were in Feisty. So, the problem is caused either by the nvidia-glx-new drivers or the Restricted Manager GUI/app. I probably wouldn't have figured this out had I not been doing this on the command line for over a year.

Score: command line 1, gui 0

Massimo Dal Zotto (dz) wrote :

The original problem (black screen on tty[1-6]) is not related to nvidia or other hardware and is caused by a change in /scripts/init-top/framebuffer from Feisty to Gutsy:

--- initrd.feisty/scripts/init-top/framebuffer 2007-02-07 10:52:34.000000000 +0100
+++ initrd/scripts/init-top/framebuffer 2007-10-22 10:10:22.000000000 +0200
@@ -82,8 +82,8 @@
 esac

 if [ -n "${FB}" ]; then
- modprobe -q fbcon
- modprobe -q ${FB} ${OPTS}
+ modprobe -Qb fbcon
+ modprobe -Qb ${FB} ${OPTS}
 fi

 if [ -e /proc/fb ]; then

With this change modprobe ignores all modules listed in blacklist-framebuffer, including vesafb and fbcon, while in Feisty those modules were loaded if required by the user in grub/menu.lst, even if blacklisted.

The change from Feisty to Gutsy in my opinion is wrong because if the user requires a particular vesa mode the modules should be loaded even if they could potentially crash the kernel.

This problem can be solved in two ways: either the -b option is removed from the framebuffer script, like in Feisty, or the vesafb and fbcon modules are removed from the blacklist-framebuffer file. In my opinion the first option should be preferred because it would work with any graphics driver,

BTW since the black console is still functional if you log-in and load the modules manually it becomes fully functional again.

Ian MacGregor (ardchoille42) wrote :

I'm no expert, but I have to disagree for the following reasons:

1) I cannot find "-b" anywhere in my /usr/share/initramfs-tools/scripts/init-top/framebuffer file

2) My /etc/modprobe.d/blacklist-framebuffer file still contain the lines "blacklist vesafb" and "blacklist vga16fb"

3) /etc/initramfs-tools/modules is empty except for some commented out text

and my nvidia driver and tty's 1-6 are working properly. I can see and use elinks, mutt, mc, irssi, etc in tty 1-6.

I feel that problem is caused by either by the Restricted Manager or the nvidia-glx-new driver, since I installed the nvidia-glx driver manually from the command line and all my tty's are working and I am able to see/use them.
It would further narrow it down to hear from someone who has installed the nvidia-glx-new driver without using the Restricted Manager.

Even if the problem is caused by the nvidia-glx-new driver, the Restricted Manager is somewhat to blame because it doesn't give the user a choice of drivers.. if it did, I wouldn't have had this problem at all because I would never have chosen a driver with "new" in the name - I'd be in the same postition I am now with all tty's working and viewable.

Felix Miata (mrmazda) wrote :

As Massimo Dal Zotto wrote, "the original problem (black screen on tty[1-6]) is not related to nvidia or other hardware". The problem exists for non-NVidia users as well, such as mga and intel.

gwi (george-willegers) wrote :

Thanks ardchoille, this:

sudo apt-get install nvidia-glx && sudo nvidia-glx-config enable && sudo dpkg-reconfigure xserver-xorg

really fucked up my system. Ended with a message that my config was corrupt and I should recheck the MD5sum?
Result: display adapter: no longer recognised, monitor: no longer recognised, carefully configured Wacom tablet settings: gone.
Thank God I had a backup xorg.conf.

Why can't someone (at Canonical I presume?) come up with a real solution to this buggy product they call "Gutsy Gibbon"?
Workarounds by users that work for some, but don't for others can't be the way to go. Not if you want Ubuntu to become a serious operating system.
(Off-topic: this isn't the only problem: sound is gone since the upgrade from Feisty to Gutsy, and the random freezes of the SATA-controller are still there.)

gwl i had the same problem, had to reinstall gutsy and it fixed the problem,
try backing up your files and re-install

I have experienced this problem on a clean install of 7.10. Graphics are provided by an old nvidia gforce mx2 card. TTYs 1-6 showed up following the initial install and following the restricted drivers install using the new GUI module. They disappeared after I added vga=791 to my boot options.

Removing the vesafb blacklist from /etc/modprobe.d/blacklist-framebuffer and adding both that module and fbcon to the /etc/initramfs-tools/modules file and updating the initramfs has worked for me, so thanks to those that suggested this as it saved me time fiddling about testing these possibilities myself. I now have TTYs 1-6 working at the correct resolution.

I also had to manually correct the /etc/usplash.conf resolution to get the boot spash to work without my monitor complaining - it can only cope with 1024x768. As X.org works fine and correctly detects the limits of the monitor (although the refresh rate can go higher than the GUI wants to let me set it) I can't see why these settings can't be transferred to usplash.conf, but I digress.

I regard this as a serious bug, even if it's unlikely to be noticed by less technical users. I certainly noticed it almost immediately.

Ian MacGregor (ardchoille42) wrote :

> gwi wrote:
> Thanks ardchoille, this:
>
> sudo apt-get install nvidia-glx && sudo nvidia-glx-config enable ..

gwi,
 I'm sorry it made further problems with your system. However, in all fairness, what I suggested was the proper way to install nvidia drivers on a fresh install without using the Restricted Manager and this method has worked for me on 19 machines as well as the machines of family and friends - which is why I thought it would be safe to post.

I am still suspicious that the Restricted Manager is somehow causing all this mess.

Regards,
ardchoille

BigBoy_PDB (bigboy-pdb) wrote :

The same problem occurred for me with a RV280 [Radeon 9200 PRO] chip. Removing vga=791 from /boot/grub/menu.lst fixed the problem.

gwi (george-willegers) wrote :

ardchoille,
Sorry for the accusation. You're not to blaim, I overreacted in the heat of the moment.

Real problem here is that "just users" are the ones that respond here. Nothing from the official Ubuntu side. Why can't they at least inform us about the status of the bug?
Workarounds reported here sometimes contradict: some people say the problem is solved by adding vga=791 to the boot line, others say the problem is solved by removing it.

Ian MacGregor (ardchoille42) wrote :

gwi, no hard feeling.. and you have a very good point. There should be a standard process to this, since this is a critical bug. Someone from the dev team should be assigned as "PR" for the bug to come in and say something to the effect of

"we're working on the bug at the moment and will get back to you with information as soon as possible. Meanwhile, do not perform 'foo' or 'blah blah' as that is not recommended".

There are times when something seems to be related to the bug, but in reality is not. I'm no dev and I thought either the nvidia driver or the Restricted Manager were to blame but, as many here have pointed out, there are folks being affected who don't even use nvidia hardware.

I feel sorry for the people who just learn about Linux today and download/burn the ISO only to be confronted with this the very first time they try Linux. This kind of bug sheds a bad light on all of Linux, not just Kubuntu, where the Linux newbie is concerned.

When this is fixed, there should really be a 7.10.1 release so the live cd's are no longer affected.

Ian MacGregor (ardchoille42) wrote :

I just noticed the date when this bug was first reported:
Bug #129910, first reported on 2007-08-02 by Miguel Martinez

That's over two months ago. Maybe this is one of those situations where the dev team isn't interested in fixing the bug.

fanatic (fanatic666) wrote :

        Hi, i have AMD Athlon 2000+ and Nvidia 6200 graphic card. I have installed Gutsy and have the same problem with tty. I have nvidia-glx-new drivers installed and with that drivers it is impossible to make tty work in gutsy, nvidia-glx drivers work fine but then you can't enable your visual effects or 3D becouse you need to enable restricted drivers. I think that restricted drivers are problem here. If anyone could solve this problem please share it ;)

gwi (george-willegers) wrote :

I am experiencing the problem on two different systems: one (AMD Athlon64 X2) with nVidia restricted drivers, and one (Intel Pentium IV) with the i810 non-restricted drivers. So the restricted drivers are not the (only) cause of this bug.

fanatic (fanatic666) wrote :

gwi have you tried to remove vesafb from blacklist-framebuffer on that system with i810. Maybe that will work, and if you are using nvidia-glx-new restricted drivers try nvidia-glx non-restricted. That worked on my system, but nvidia-glx does not support visual effects or 3D.

Antoine Amarilli (a3nm) wrote :

I can reproduce this on one system using an NVIDIA card and nvidia-glx drivers, one system using an NVIDIA card and nvidia-glx-new drivers, and one laptop (Acer Travelmate 4000) with an ATI card and no proprietary drivers.

Jason Wigg (jw5801) wrote :

I can reproduce this bug on an ATi card (Radeon Xpress 1100) using fglrx. I can also fix the bug by adding vesafb and fbcon to /etc/initramfs-tools/modules, and commenting out the relevant lines in /etc/modprobe.d/blacklist-framebuffer. As a result of this the splash image does not display correctly however (it appears to be at far too low a resolution).

gwi (george-willegers) wrote :

I did a fresh install of Gutsy on my AMD/nVidia system. I can access tty1-6 now, but the font is huge. I am using the nvidia-glx-new restricted drivers, which were installed via the Restricted Manager.
I will try to change the resolution to get a smaller font in the tty's, and see if that causes the problem.
The fresh install did solve another problem: swat is working again (as it was under Dapper and Edgy, but never under Feisty), and so is hddtemp (but that also worked after the upgrade). So Gutsy has its good points ;-)

komputika (info-komputika) wrote :

*** solved here ***
using El Chupacabras instructions.
vga=791 is working fine.
Thank you!

Sridhar Dhanapalan (sridhar) wrote :

No luck here. I've tried all the suggestions made above. I've got a Dell Inspiron 9400 laptop with Nvidia GeForce Go 7900GS graphics.

fanatic (fanatic666) wrote :

-------solved here too--------
I used El Chupacabras instructions as well. I have added a vga=791 in my menu.lst and I edited my /etc/initramfs-tools/modules to look like:
 fbcon
 vsafb
 vga16fb
I changed /etc/modprobe.d/blacklist-framebuffer
blacklist vesafb -> #blacklist vesafb
blacklist vga16fb -> #blacklist vga16fb

After that you have to do sudo update-initramfs -u
and that's it.
I have AMD/nVidia 6200 with nvidia-glx-new restricted drivers and this worked for me.

Alpha4 (colligia) wrote :

I confirm the problem here on my Acer Aspire 5680 Laptop.
I've installed Ubuntu Gutsy and set up the boot with startup-manager.
My tty consoles on f1-6 are invisible, with the flashing cursor on top-left corner, but working. If I log in, it logs me in (I verified from X just after).

gwi (george-willegers) wrote :

Tried to change the resolution to 1280x1024 by editing usplash.conf and adding vga=794 to the kernel boot parameters, and generating a new initrd image.
During boot the Ubuntu logo screen disappeared, and was replaced by a black screen with a flashing cursor in the upper left corner. After a while the login screen appeared. The tty1-6 failed to show text.
Restored the initrd image, and all is working again, at low resolution that is...

Wiktor Wandachowicz (siryes) wrote :

ASUS F3SC-AS218E here, with GeForce 8400M. I was testing all Tribes
and RC of Ubuntu Gutsy and recently I installed it from official ISO.
I have nvidia-glx-new driver installed by Restricted Drivers Manager
and I have obviously noticed problems with black virtual terminals.

Since this notebook has 1440x900 screen I tried at first to enable
this or similarly high resolution. However, my attempts proved I was
able to turn on only 1024x768.

The following applies only to this kernel (it works as I type):
$ uname -a
Linux ghost 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

Here's the procedure I've used to enable high resolution on consoles:

1. Select font used in framebuffer mode:
$ sudo dpkg-reconfigure console-setup

* select "Fixed" font or any other you like/prefer

2. Modify kernel parameters:
$ sudo nano /boot/grub/menu.lst

* change:
# defoptions=quiet splash locale=pl_PL

* to:
# defoptions=vga=791 quiet splash locale=pl_PL

3. Make sure the changes are applied:
$ sudo update-grub

4. Modify usplash configuration:
$ sudo nano /etc/usplash.conf

* change:
xres=
yres=

* to:
xres=1024
yres=768

5. Enable modules autoloading:
$ sudo nano /etc/initramfs-tools/modules

* at the end of file add:
fbcon
vesafb
vga16fb

6. Remove modules from blacklist:
$ sudo nano /etc/modprobe.d/blacklist-framebuffer

* change:
blacklist vesafb
blacklist vga16fb

* to:
# blacklist vesafb
# blacklist vga16fb

7. Just in case:
$ sudo depmod -a

8. Apply all changes in one go, including initrd generation:
$ sudo dpkg-reconfigure usplash

After restart all is right, just like it was in Feisty.

interbird (rdepantalon) wrote :

For me this worked :

sudo echo "fbcon" >> /etc/modules
sudo echo "vesafb" >> /etc/modules
sudo update-initramfs -v -u -k $(uname -r)

The screen will remain blank for some time until the drivers are loaded.
To have them loaded earlier-on initrd has to be modified.

Some info of my machine:
grub menu.list (out-of-auto-kernel-update-section):
title Ubuntu 7.10
root (hd0,6)
kernel /vmlinuz root=/dev/sda7 quiet vga=791
initrd /initrd.img

kernel: Linux troffice 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

video: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

Sridhar Dhanapalan (sridhar) wrote :

The solution outlined in fanatic's last post has made my console visible. I didn't have to use any vga settings in grub.

Sridhar Dhanapalan (sridhar) wrote :

I should add that this has seemingly messed up my bootsplash. It is now of a lower resolution, and is offset to the right to the point where half of it is on the right edge of the screen and the rest is wrapped around onto the left. I've experimented with a few different resolutions in /etc/usplash.conf but there's been no change.

use vga=791 will effect your gnome UI.
you take care look at UI color and other. you will find.
interbird 写道:
> For me this worked :
>
> sudo echo "fbcon" >> /etc/modules
> sudo echo "vesafb" >> /etc/modules
> sudo update-initramfs -v -u -k $(uname -r)
>
> The screen will remain blank for some time until the drivers are loaded.
> To have them loaded earlier-on initrd has to be modified.
>
> Some info of my machine:
> grub menu.list (out-of-auto-kernel-update-section):
> title Ubuntu 7.10
> root (hd0,6)
> kernel /vmlinuz root=/dev/sda7 quiet vga=791
> initrd /initrd.img
>
> kernel: Linux troffice 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT
> 2007 i686 GNU/Linux
>
> video: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM
> Integrated Graphics Device (rev 02)
>
>

> interbird wrote ..
>
> For me this worked :
>
> sudo echo "fbcon" >> /etc/modules
> sudo echo "vesafb" >> /etc/modules

interbird, you might want to "cat /etc/modules" and see if the expected text was actually written to that file because those two commands shouldn't have worked as you expected them to. The sudo echo "blah" bit no doubt worked, but the redirection should have failed.

Try:
echo "fbcon" | sudo tee -a /etc/modules
echo "vesafb" | sudo tee -a /etc/modules

aletheianalex (aletheianalex) wrote :

This bug almost made Xubuntu uninstallable on my machine (reformat and clean install) since the installer did not recognize my hardware properly, and not all of the options that I passed to the installer were honored by it. And since Xfce-terminal has a bug too (crashes GDM) and I could not bring up Xterm at first, I was left with NO command line interface at all to fix it!! I had to fish around my apartment for a *known* compatible network card to download a few different terminals until I fould one that would work (most just said "task completed... exiting" and closed down) and "menu" for a Debian system menu and then get it running by:

Deleted my vga= argument in /boot/grub/menu.lst

Ran update-grub

Corrected resolution in /etc/usplash.conf

Enabled fbcon and vesafb in /etc/initramfs-tools/modules

Commented out fbcon and vesafb in /etc/modprobe.d/blacklist-framebuffer

Desperately enabled every possible repository in hopes of a fix in the works

Ran upgrade

Ran depmod -a

Ran dpkg-reconfigure usplash

My TTY's are back! but they look funky, and my power-down splash screen is horribly garbled... but it is functional at least. My hardware for this machine is older VESA 2.0 compliant Intel.

(Not to get off topic, but in case it helps and/or is related, Gusty did not recognize my touchpad, network card, and APM, ACPI, LAPIC are not functioning properly even though I had them working in Debian sarge, Etch, Lenny and Sid.)

Frodon (frodon) wrote :

Bug also confirmed on final gutsy upgrade on my computer.

The following commands solve the problem (i added the 2 modules in my /etc/modules file).
sudo modprobe vga16fb
sudo modprobe fbcon

Antoine Amarilli (a3nm) wrote :

Loading the vga16fb and fbcon modules gets the ttys working again for me, although their display isn't perfectely centered on screen plus no "Login:" prompt appears when switching to them (entering the login works nevertheless).

Kernel version is 2.6.22-14-generic.

Ralph Wabel (rwabel) wrote :

the commands below also solved the issue, however resolution isn't perfect
sudo modprobe vga16fb
sudo modprobe fbcon

just waiting for the bug fix and so far working with the temp fix. many thanks to all pointing that out. It drove me crazy many days ago.

gwi (george-willegers) wrote :

Best results I got so far:
- used startupmanager to set resolution to 1280x1024 (could do this manually, but wanted to try this way);
- manually removed vga=794 setting from boot parameters in /boot/grub/menu.lst;
- no changes to the default modules list or blacklists.

I now have a proper startup and shutdown screen with progress bar (and with text if I select that option in startupmanager).
tty1-6 have the proper font, but an incorrect resolution (probably 640x480, it's 80x30 characters). I think I will leave it like this, until the Ubuntu guys come up with a real solution.

Loading modules fbcon and vesafb lead to a bunch of green blocks on a black and unresponsive tty1.
Loading modules fbcon and vga16fb lead to a low resolution tty1, with an ugly font, and a fucked up shutdown screen, also at 640x480, with colors so bad that you can hardly see what's there.

In the mean time I have seen some very strange things happening, like the X screen getting blank while loading the desktop. The monitor power light starts blinking. After pressing a key or moving the mouse the screen returns (and the monitor shows "digital" for a few seconds, so there really was no signal).

interbird (rdepantalon) wrote :

@ardchoille

I actually used mc as root to add the module-names and then posted the append-commands without checking if they worked.
And you are right, they don't work; shame on me.
Your comment reminds me again to always double-check before posting.
Thanks !

Graelb (cody-croslow) wrote :

So... I know i'm rather new to this whole scene, but the issue i'm having is related, though slightly different. Instead of just plain black tty's, my screen cycles through colors. And only when i'm using nvidia-glx-new drivers. When i use the nvidia-glx ones (after i get them working,) I get to keep my tty's, but every time i reboot, the system defaults back to the vesa drivers. Obviously i'd rather get the tty's working on the new drivers. But i do cycle through colors on tty1-6, it goes red-green-blue-white-grey(which is kind of like a bunch of criss-crossed lines,) a darker grey, an even darker grey, then back to black for a while, then goes back through them... i would think this is the same issue, but it is slightly different.

Sridhar Dhanapalan (sridhar) wrote :

Sridhar Dhanapalan wrote:
> The solution outlined in fanatic's last post has made my console visible.
> I didn't have to use any vga settings in grub.

> I should add that this has seemingly messed up my bootsplash. It is
> now of a lower resolution, and is offset to the right to the point where
> half of it is on the right edge of the screen and the rest is wrapped
> around onto the left. I've experimented with a few different resolutions
> in /etc/usplash.conf but there's been no change.

Correcting these comments, I _was_ using a vga= parameter in grub (I didn't notice it before), and the usplash problem was fixed by setting usplash.conf to 1024x768.

So the solution for me was to load the fbcon, vesafb and vga16fb modules into the initramfs and remove their blacklisting.

I have had this bug for a long time in Feisty and now in Gutsy....instead of a black screen I received verticle colored lines filling the whole screen.

I have HP dv8000 with AMD with ATI X200M

The bug only exists when I use fglrx drivers.

I employed the solution of Kai (way above: radeonfb, etc) and also added vga=791 to kernel line in menu.list, then restart system. This resulted in a fix of a long standing issue for me, but did not make the system unusable. I am only a step or two above noob. I cannot speak for others, only myself, this has not been a critical issue. However, I know that others rely on this working than what I do. Thanx for the fix....I now have a way out if KDE or x crashes.

schnollk (schnollk) wrote :

Bug confirmed on fresh 7.10 final installation

$ uname -sr
Linux 2.6.22-14-generic
$ lspci | grep 'VGA'
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

but can neither confirme John Yate's fix nor loading it manually.

Black ttys untill gdm comes up on tty7.
~$ lsmod | grep fbcon
~$
~$ sudo modprobe fbcon
~$ lsmod | grep fbcon
fbcon 41760 0
tileblit 3584 1 fbcon
font 9344 1 fbcon
bitblit 6912 1 fbcon

still no change. kernel boot options in menu.lst:
root=UUID=... ro splash vga=791

Only work around is removing vga= option gives back ttys as desired. But vga= is needed to show usplash from right after grub passes control.

Note: Had issues with initramfs not showing usplash (see Bug #157620). Solutions involves update-usplash-theme (i.e. update-initramfs) if that helps.

Download full text (4.4 KiB)

Hi folks.

Bug confirmed on Gutsy amd64/nvidia (Asus V1S-AS004E laptop)

Solution *confirmed*, even went a tiny bit further: now got all 6 tty working and visible in 180x60 characters mode -- 1440x900/24bit. Outstanding :)

Please also note I have met no conflit, whatsoever, between nvidiafb and nvidia-glx-new (as installed by restricted manager). Running Gutsy's default Xorg and Compiz, nVidia's TwinView with two cubes, and all sorts of effects enabled. Besides loosing Emerald decorations sometimes (I assume it's unrelated), I can switch between X and ttys as expected.

$uname -a
Linux venus 2.6.22-14-generic #1 SMP Sun Oct 14 21:45:15 GMT 2007 x86_64 GNU/Linux)
$lspci | grep VGA
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GT (rev a1)
$ apt-cache showpkg nvidia-glx-new
Versions: 100.14.19+2.6.22.4-14.9 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_gutsy_restricted_binary-amd64_Packages)
Provides: 100.14.19+2.6.22.4-14.9 - xserver-xorg-video nvidia-gl

Not sure if all I did was necessary, but since it took me a long time with quite a few reboots, and that it now works with no limit so far, I'll give up testing and just write it all down here.

I started from these comments above (thanks very much, chaps):
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/129910/comments/145
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/129910/comments/89

Finding the solution was hard because:
- I was blind, since I first got no output from hwinfo --framebuffer
- reading the following refs, I tried vga=791 then 868 and 869 respectively, but none of them worked. Later I tried 877, which did not work either
  http://gentoo-wiki.com/HARDWARE_Lenovo_Thinkpad_T61#1440x900:_vga.3D869_kernel_parameter
  http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers
- in facts the kernel does not seem to accept any vga=[decimals] equivalent as parameter, only the [hexa] form
- I finally obtained some output from hwinfo --framebuffer, once I did modprobing fbcon, nvidiafb and vga16fb (only after I realized I had to sudo the command, therefore I am not sure if I needed them all)

Anyway, to paraphrase Wiktor, here's the procedure I've used to enable MAXIMUM resolution on consoles:

1. loaded modules
$ sudo modprobe fbcon
$ sudo modprobe nvidiafb
$ sudo modprobe vga16fb

* note that I did not need vesafb here, as I expected
* if anyone had the time to try without vga16fb, that would be great

2. get the list of supported modes from the graphic card
$ sudo apt-get install hwinfo
$ sudo hwinfo --framebuffer

* that did show me a lot of modes, the one that most interested me was:
Mode 0x0365: 1440x900 (+5760), 24 bits

3. was happy to read that, so did just in case:
$ sudo depmod -a

4. went to discover the console setup program
$ sudo dpkg-reconfigure console-setup

* I also selected "Fixed" font in framebuffer mode
* WARNING: almost every default option came fine, except the Alt-Gr key
* (I have one, selected Right-Alt. That works, and surprisingly almost
* all keys output something with this modifier, nice discovery)

5. therefore, specified 0x365 as kernel parameters:
$ sudo nano /boot/grub/menu.ls...

Read more...

Just correcting myself:

9. to allow module loading, I commented two blacklist lines in this file:
$ sudo nano /etc/modprobe.d/blacklist-framebuffer
# blacklist nvidiafb
# blacklist vesafb

* if anyone had the time to try without vesafb, that would be great

Cheers

gwi (george-willegers) wrote :

Sounds nice. Will try it when I get home tonight.

But what about non-nVidia systems? I am having the same problems on an Intel system (with a 82915G video chip).

Harvey Muller (hlmuller) wrote :

This is in response to caravel's comments:

My hardware is similar. Nvidia GeForce 8400M GS, Intel Core 2 Duo. I also have Gutsy amd64 desktop installed.

I was intrigued that you were able to get a console with native 1440x900, and gave your method a try. It was not successful.

But I was able to get consoles at 1440x900 with usplash working using:

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

modified /boot/grub/menu.lst
added vga=0x0365 to defoptions
ran sudo update-grub

Modified /etc/initramfs-tools/modules:
fbcon
vesafb

Commented out in /etc/modprobe.d/blacklist-framebuffer is:
blacklist-vesafb
ran sudo update-initramfs -u

Your instructions are inconsistent, early you state vga=0x0365, then later vga=0x365. hwinfo showed 0x0365 to be correct. I haven't been able to make the nvidiafb module work. But at least I now have consoles at the native 1440x900 resolution of my laptop monitor.

gwi (george-willegers) wrote :

@caravel

Just tried your solution on the nVidia system. It works. Not without the vesafb. In that case the monitor and video card are not recognised, and I get the Gnome window at 800x600 in the center of my 1280x1024 monitor. tty1-6 looked ok, but could not switch back to tty7 (just a flashing cursor in the upper left corner of a black screen). And the shutdown splash was awful (resolution and colours).
With vesafb included, all seems fine. tty1-6 are about 140x64 characters. Just like they were in Feisty. Until there is an official solution I keep it the way it is now.
One down (nVidia), one to go (Intel).

gwi (george-willegers) wrote :

@caravel

Did the same on the Intel system, with intelfb instead of nvidiafb. Everything seemed to be ok, until I tried to switch back from tty1 to tty7. tty7 was just black. It did work however, because the key sequence alt-F1, S, A, alt-H restarted the system (keys are for the Dutch locale). Returned to the previous state, but changed vga=794 to vga=0x31a. Now it seems to work.

Hello,

  I got an nVidia GeForce Go 7200 on an AMD64 X2 laptop.

  1. My tty's problem was solved using instructions in MOM2007's post.
     But I was using vesafb & fbcon modules only, ie. I didn't use
     nvidiafb module.
  2. A while ago I did tried to use nvidiafb instead of vesafb, but I
     got problems similar to what 'gwi' has mentioned. So I just
     disabled 'nvidiafb'
  3. For X, I use nvidia-glx driver and NOT the nvidia-glx-new, as the
     nvidia-glx-new caused hangups on my laptop even if I disable compiz
     stuff.
  4. With the nvidia-glx, I was not able to use compiz, because with
     compiz enabled, if I switch to a tty then back to X, I would just
     get a mouse pointer over a black screen and that's it, sometimes I
     even can't switch back to the tty, and even if I can, after few
     moments the laptop would hangup.
  5. Anyways, I gave it a try to add nvidiafb to the fbcon & vesafb
     modules, and it was fine, I was even now able to get compiz
     working ! Now, I am thinking to test nvidia-glx-new again with
     nvidiafb module loaded.

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

Hello,

i have a problem, i can not load "vesafb" with modified /etc/initramfs-tools/modules.

I modified /etc/initramfs-tools/modules:
fbcon
vesafb

and commented out in /etc/modprobe.d/blacklist-framebuffer is:
blacklist-vesafb

sudo update-initramfs -u

When i start the system comes a black bootscreen, if i modified the /etc/modules to with "vesafb" comes at the half boottime the infos from the booting system like feisty.

Why load intiramfs not vesafb?

My Hardware ist a IBM Lenovo T60 Laptop with ATI X1400

interbird (rdepantalon) wrote :

@Goodness

Maybe this script fixes it for you.

its just can used to fix chip of intel which use vesafb.
for a fresh to linux, they may use this to all ubuntu.
so i think, if you write script to fix, Pls give a error or warning when
non intel chip.
or write a script to fix common chips.

THX.
interbird 写道:
> @Goodness
>
> Maybe this script fixes it for you.
>
>
> ** Attachment added: "Fix gutsy initrd.img to load vesafb unconditionally"
> http://launchpadlibrarian.net/10292550/fix-gutsy-initramfs
>
>

@ interbird
thanks for your help, but there is a problem with the skript:

./fix-gutsy-initramfs: 29: pushd: not found
cp: Aufruf von stat für „initrd.img-2.6.22-14-generic“ nicht möglich: No such file or directory
gzip: initrd.img-2.6.22-14-generic.gz: No such file or directory
./fix-gutsy-initramfs: 53: pushd: not found
./fix-gutsy-initramfs: 56: cannot open initrd.img-2.6.22-14-generic: No such file
rm: Entfernen von „initrd.img-2.6.22-14-generic“ nicht möglich: No such file or directory
./fix-gutsy-initramfs: 62: pushd: not found
./fix-gutsy-initramfs: 71: popd: not found
./fix-gutsy-initramfs: 77: pushd: not found
./fix-gutsy-initramfs: 93: popd: not found
...............................................................................................................................................................................................................................
2640 blocks
./fix-gutsy-initramfs: 100: popd: not found
./fix-gutsy-initramfs: 106: popd: not found

interbird (rdepantalon) wrote :

@Goodness

The pushd and popd commands could not be found on your system.
I did not realize they are not installed by default, sorry for that.
Here is a fixed script.
Hope this one works for you.

@angel1127
The vesafb should work with any vesa 2.0 compliant videocard.
It is only used for the console as X loads it's own (accelerated) driver for the GUI.

Shriramana Sharma (jamadagni) wrote :

interbird, please change:

#!/bin/sh

to

#!/bin/bash

in the script. That's the problem. You are telling the system to interpret the script using sh which on Ubuntu is a symlink to dash which does not support all of bash's features. (I learnt that the hard way.) pushd and popd are bash built-ins. They are not separate commands to be installed on the system.

BTW what do you need tcl for?

BBTW: even with changing sh to bash, I am getting a running display of:

cpio: Malformed number
cpio: Malformed number
cpio: Malformed number
cpio: Malformed number

which I have to manually terminate. Did you check this on your own system before uploading?

interbird (rdepantalon) wrote :

@Shriramana Sharma

You are right, I was wondering why pushd and popd were not found.
I changed the symlink from dash to bash on my system months ago due to more strange behaviour from dash.
(I upgraded feisty to gutsy which left my symlink to bash untouched)
I too quickly tried to determine which package pushd was in and came to tclx.
Which is incorrect as you state. It's a bash feature.
Thanks for pointing that out.

Yes, I did try the script on my system before uploading.

I cannot reproduce your cpio error however.
I'm using version 2.8.
Maybe it has to do with the locale settings or translation.
Try to unset LANG and LC_ALL before running the script.

@Goodness
The first line of the script should read: #!/bin/bash
This version (20071107 #3) has that fix.

NeverMind (agathe-durieux) wrote :

Goodness wrote on 2007-11-0

>i have a problem, i can not load "vesafb" with modified /etc/initramfs-tools/modules.

>i modified /etc/initramfs-tools/modules:
>fbcon
>vesafb

>and commented out in /etc/modprobe.d/blacklist-framebuffer is:
>blacklist-vesafb

>sudo update-initramfs -u

>When i start the system comes a black bootscreen, if i modified the /etc/modules to with "vesafb" comes at the half boottime the infos from the >booting system like feisty.

>Why load intiramfs not vesafb?

You're forget

sudo modprobe fbcon
sudo modprobe vesafb

sudo update-initramfs -u -k all

Shriramana Sharma (jamadagni) wrote :

@interbird:

I'm on en_IN so by doing export LANG="en_US" prior to running the script the script worked, and I even got the vga=792 screen until X started. After X started, however, Ctrl+Alt+F1 etc give me a junk display.

So:

1) you may consider temporarily storing the LANG environment value into a temporary variable, set it to en_US for the script and restore it at the end, but that may be a problem for users that don't have that locale

2) the problem is not properly solved. I have an Intel 915GAV motherboard. Do I have to select another driver?

interbird (rdepantalon) wrote :

@Shriramana Sharma

vga=791 (0x318) uses 24-bpp which could be the problem.
Try vga=791 (0x317) which uses 16-bpp.
Here is some info (look at the table under section 5.3):
http://tldp.org/HOWTO/Framebuffer-HOWTO-5.html

If that doesn't work, I'm currently on IRC and willing to help you.
Server: kubrick.freenode.net
Channel: #ubuntu
Nick: interbird

interbird (rdepantalon) wrote :

@Shriramana Sharma

In my former post I meant: vga=792 uses 24-bpp.
So try vga=791 and please see if this new script fixes the cpio error you had.

@interbird
I view vesafb readme under kernel 2.6.23 source. it seems to used to
intel boxs.
i do know about what chips support vesa 2.0. is where any list?
Thank you.
interbird 写道:
> @Goodness
>
> The pushd and popd commands could not be found on your system.
> I did not realize they are not installed by default, sorry for that.
> Here is a fixed script.
> Hope this one works for you.
>
> @angel1127
> The vesafb should work with any vesa 2.0 compliant videocard.
> It is only used for the console as X loads it's own (accelerated) driver for the GUI.
>
>
> ** Attachment added: "Script to fix gutsy initrd.img to load vesafb unconditionally #2"
> http://launchpadlibrarian.net/10299725/fix-gutsy-initramfs
>
>

@angel1127

Vesa is a videocard independant standard to access higher resolutions than standard vga (640x480x16).
Almost any recent videocard supports this.
You can read what vesa is here:
http://en.wikipedia.org/wiki/VESA_BIOS_Extensions

$kernel-source/Documentation/fb/vesafb.txt is correct in that Intel chipsets can use it.
But it is not intel-specific-- it's generic.
It's also loaded on my nVidia MX440 machine.

The problem with Gutsy is that vesafb does not load even if you unblacklist it in /etc/modules.d/blacklist.framebuffer in the initramfs.
That's why my script makes it load unconditionally by patching the script in /scripts/top.../framebuffer
(ugly hack, i know)

An other problem is that many people mistake the loading of vesafb for the console (tty) with the loading of the driver X uses for the GUI.
Yet another problem is that there can be interference between vesafb and the (accelerated) driver loaded by X.
Regarding color-depth.

Using vga=792 uses a 24bpp color-depth for the console which could be problematic with X.
But, why use such a color-depth for a console? It only makes it slower.
And the GUI uses the driver specified in /etc/X11/xorg.conf.

Anyway,

This problem has been in the beta-versions of gutsy and it has not been fixed for the general release.
That's not good.
I can imagine people to bark at upgrading to gutsy, or new people installing it freshly, to get "pissed off" by not having Ctrl-Alt-Fn working.

I wrote this script as a one-run solution to this problem and I know it's not a pretty one.
But my aim is to provide an answer that works for people having this problem.
I've got some valuable feedback on this script which I incorporated in it.

What I would like is a script that solves this issue for anyone installing gutsy or upgrading to it.
For as long as it's needed. (until a kernel-upgrade finally fixes this quirk)

Thank you for reply angel1127, and please keep me sharp :-)

IB

Shriramana Sharma (jamadagni) wrote :

Are the kernel maintainers still actively looking at this? A kernel update is in order, methinks.

@interbird:
I tried changing 792 to 791 but to no avail. Even changing the xorg.conf depth setting did not help. I still get the junk display when I do Ctrl+Alt+Fn.

Goodness (1-goodness) wrote :

Hello,

first, i make a backup of my complete installation before i start the test with the skript

now i test the skript, at last the version #4.

i think my sytem like not to load vesafb at booting.

i do following:
back to standardfiles /etc/modules, /etc/modprobe.d/blacklist-framebuffer and /etc/initramfs-tools/modules, also without any changes
rename the skript without *.txt
chmod +X the skript, the right's now 755
run the skript in a terminal without any error's
check the folders - OK
reboot
the system start, after the grub window the screen is black
the next screen is the logon-window
i to log on
now i start a terminal with Strg+Alt F1, this screen is also black
back to kdm
open a terminal an run sudo modprobe vesafb
back to with Strg+Alt F1, now it works

why does my system not load vesafb at the booting?

interbird (rdepantalon) wrote :

@Goodness

Can you send your initrd image to the email-address in the script?
I'll try it on my system to see what's wrong with it.
Please also include the out put of the lspci -v and lmod commands.
*Before you modprobe vesafb; thus when your Ctrl-Alt-Fn terminals are blank*
You can use: lspci -v > lspci.output to capture the output.
Also: lsmod > lsmod.output.

huiii (a00ps) wrote :

hi, i have the same,
since gutsy, switching to vt by pressing ctrl+alt+F1-6 results in black screen.
removing vga=791 does not change a thing.
nvidia go6600

huiii (a00ps) wrote :

thanks 1000 times to John Yates!!and all of you!!!

this worked for me perfectly:

ubuntu gutsy framebufer fix for switching to VT:

1. sudo gedit /etc/initramfs-tools/modules

add following lines:

fbcon
vesafb

2. sudo update-initramfs -u

3. sudo gedit /etc/modprobe.d/blacklist-framebuffer

change the line "blacklist vesafb" to "# blacklist vesafb"

4. sudo sh -c "echo 'fbcon' >>/etc/initramfs-tools/modules"

5. sudo gedit /boot/grub/menu.lst

this line should look like this (for 1280x800 resolution screen)

# defoptions=quiet vga=773 splash

gwi (george-willegers) wrote :

I don't know who John Yates is (I don't see a posting with that name here), but what's the use of step 4? You already added fbcon to /etc/initramfs-tools/modules in step 1.

huiii (a00ps) wrote :

wright,

than do it without 4.:

1. sudo gedit /etc/initramfs-tools/modules

add following lines:

fbcon
vesafb

2. sudo update-initramfs -u

3. sudo gedit /etc/modprobe.d/blacklist-framebuffer

change the line "blacklist vesafb" to "# blacklist vesafb"

5. sudo gedit /boot/grub/menu.lst

this line should look like this (for 1280x800 resolution screen)

# defoptions=quiet vga=773 splash

and about john yates:
http://www.imdb.com/find?s=all&q=John+Yates&x=13&y=12

darthanubis (darthanubis) wrote :

Never Mind said...

"I've got a Nvidia FX 5200

> sudo nano /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb"
> sudo vi /etc/initramfs-tools/modules and add fbcon and --> nidiafb
> sudo update-initramfs -u -k all

It works for me ;)"

Before I saw your correction right below this post I followed this....with a slight change.

I've got a Nvidia FX 6200

> sudo nano /etc/modprobe.d/blacklist-framebuffer
> change the line "blacklist vesafb" to "# blacklist vesafb" and I uncommented nvidiafb
> sudo nano /etc/initramfs-tools/modules and add fbcon and --> nvidiafb and vesafb
> sudo update-initramfs -u -k all

Although I may not need both vesafb and nvidiafb.
It works for me ;)

p.s. vga=791 grub menu.

Gutsy should not have released with this bug.

Thanks Dude!!!

are you test Nvidia chip with just add vesafb but not nvidiafb to /etc/initramfs-tools/modules
if you have time, PLs take a test, Thank you.
wait for your report. :)

On Mon, Nov 12, 2007 at 04:00:26PM -0000, darthanubis wrote:
<Authentication-Results: mx.google.com; spf=pass (google.com: best guess record
< for domain of <email address hidden> designates 91.189.90.139 as permitted
< sender) <email address hidden>
<From: darthanubis <email address hidden>
<To: <email address hidden>
<Reply-To: Bug 129910 <email address hidden>
<Subject: [Bug 129910] Re: tty[1-6] are active but display nothing in Gutsy
<X-Launchpad-Bug: distribution=ubuntu; sourcepackage=initramfs-tools;
< component=main; milestone=ubuntu-7.10-rc; status=Triaged;
< importance=Critical; assignee=ubuntu-kernel-team;
<X-Launchpad-Bug: distribution=ubuntu; sourcepackage=linux-source-2.6.22;
< component=main; status=New; importance=Undecided; assignee=None;
<X-Launchpad-Message-Rationale: Subscriber
<X-Generated-By: Launchpad (canonical.com)
<
<Never Mind said...
<
<"I've got a Nvidia FX 5200
<
<> sudo nano /etc/modprobe.d/blacklist-framebuffer
<> change the line "blacklist vesafb" to "# blacklist vesafb"
<> sudo vi /etc/initramfs-tools/modules and add fbcon and --> nidiafb
<> sudo update-initramfs -u -k all
<
<It works for me ;)"
<
<Before I saw your correction right below this post I followed
<this....with a slight change.
<
<
<I've got a Nvidia FX 6200
<
<> sudo nano /etc/modprobe.d/blacklist-framebuffer
<> change the line "blacklist vesafb" to "# blacklist vesafb" and I uncommented nvidiafb
<> sudo nano /etc/initramfs-tools/modules and add fbcon and --> nvidiafb and vesafb
<> sudo update-initramfs -u -k all
<
<Although I may not need both vesafb and nvidiafb.
<It works for me ;)
<
<p.s. vga=791 grub menu.
<
<Gutsy should not have released with this bug.
<
<Thanks Dude!!!
<
<--
<tty[1-6] are active but display nothing in Gutsy
<https://bugs.launchpad.net/bugs/129910
<You received this bug notification because you are a direct subscriber
<of the bug.

1. sudo nano /etc/modprobe.d/blacklist-framebuffer
   * change the line "blacklist vesafb" to "# blacklist vesafb" and I uncommented nvidiafb (if somebody has another card just choose your's)
2. sudo nano /etc/initramfs-tools/modules and add fbcon and vesafb and nvidiafb (the same as above, if other choose your's)
3. sudo update-initramfs -u -k all

And that's it :)

Thanks to all :)

Regards.

Gurubie (gurubie) wrote :

Should I take that to mean, comment out (with #) "blacklist nvidiafb" (I have an old nvidia Geforce card) so that it is NOT blacklisted?

I took this to say that vesafb and nvidiafb are the only ones in my file WITH a "#" so as not blacklisted. Right?

huiii (a00ps) wrote :

i would recommend not to comment out nvidiafb.
there are issues known and what you really want is vesafb.
leaving nvidiafb in the blacklist is goood.

Sannindan (sannindan) wrote :

Hmm. With only vesafb it is not working,
at least with me.

Regards.

gwi (george-willegers) wrote :

Same here, I needed to include nvidiafb (with a PCX5300 card).

murf76 (peter-murfy) wrote :

thinkpad Z60m (intel vga) framebuffer working with:

kernel: 2.6.22-14-generic
grub options: # defoptions=nosplash vga=791

sudo nano /etc/modprobe.d/blacklist-framebuffer
change the line "blacklist vesafb" to "# blacklist vesafb"
sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
sudo update-initramfs -u

thinkpad R50 (ati radeon vga) framebuffer working with:

radeonfb module

Thanks.

This is how I got my Dell Inspiron E1705/9400 with ATI Mobility Radeon X1400 working:

Undo all the other things you did with vesafb. The /etc/initramfs-tools/modules and /etc/modprobe.d/blacklist-framebuffer files should be their defaults (vesafb should be commented out again.)

sudo nano /etc/initramfs-tools/modules
Add fbcon and vga16fb

So my /etc/initramfs-tools/modules looks like:
fbcon
vga16fb

sudo update-initramfs -u
sudo nano /etc/modprobe.d/blacklist-framebuffer
Change the line "blacklist vga16fb" to "#blacklist vga16fb"

The only kernel parameters I have in menu.lst are "quiet splash" (the default)

Reboot and all the virtual terminals work. I'm still having a little issue with the usplash that appears on shutdown though.

interbird (rdepantalon) wrote :

@strabes

At boot-time the splash-screen takes it's resolution from /etc/usplash.conf, *which is in the initramfs image* !
At boot the root-filesystem is changed from the initramfs to the real-root.
Your system is on the real-root.
On shutdown, the splash-screen takes it's resolution, again, from /etc/usplash.conf.
But this is now the /etc/usplash on the real-root... Which is a different file from the one in the initramfs...

Make sure they are both the same; /etc/usplash.conf in your initramfs and the /etc/usplash.conf on your root.fs.
This link from "caravel" points to a table of resolutions,modes and numbers for more info.

interbird (rdepantalon) wrote :

errata:

#1
s/Which is different/Which could be different/

#2
What's a link to a link without a link...
http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers

(thx, caravel)

Damian (misc-daminator) wrote :

I've tried both:

1. sudo vi /etc/initramfs-tools/modules and add fbcon and vesafb
fbcon
vesafb

2. sudo update-initramfs -u

3. sudo vi /etc/modprobe.d/blacklist-framebuffer

change the line "blacklist vesafb" to "# blacklist vesafb"

4. reboot and everything is fine

and:

1. sudo nano /etc/modprobe.d/blacklist-framebuffer
   * change the line "blacklist vesafb" to "# blacklist vesafb" and "blacklist nvidiafb" to "# blacklist nvidiafb"
2. sudo nano /etc/initramfs-tools/modules and add fbcon and vesafb and nvidiafb
3. sudo update-initramfs -u -k all

and neither worked.

The 1st seemed to have no effect at all.

The second messed up X so that I only had a very low res gui

I've put everything back to how it was but it's very frustrating not to be able to use tty. uspalsh shows on boot up and shut down, but I can only see the white text on black back ground bits on boot up. I get an out of range error (same as for tty) on powering down when it gets to those bits.

Is this likely to be fixed any time soon with an update any time soon?

Paul Dufresne (paulduf) wrote :

I do have a VERY different workaround, that let me suggest the real bug is with xserver-xorg-video-intel.

Everytime I set my /etc/X11/xorg.conf file to use 'i810' driver, my TTY[1-6] works fine.
And when I set Xorg to use 'intel' driver, my TTY[1-6] goes away.
As I reported in duplicate of this bug #162400.

@interbird:

May I ask how to edit the /etc/usplash which is used for shut down? I have apparently edited the one used for bootup by simply running sudo nano /etc/usplash. I don't exactly understand the difference between the two. If you could point me to a website with this kind of information that would be very useful.

Thanks for your help.

interbird (rdepantalon) wrote :

@strabes

To extract the usplash.conf file from the initramfs, follow these steps:
1. open a terminal
2. run this command: mkdir tmp; cd tmp; gzip -cd /boot/initrd.img-$(uname -r) | cpio -im; cp -a etc/usplash.conf ..; cd ..; rm -rf tmp
(best is to paste this line in your terminal, if you retype it, type it exactly as shown above and don't forget the double dot's near the end)

This will leave a file usplash.conf in the current dir.

Now check it's contents with: cat usplash.conf
Now check the contents of the one on the root-fs: cat /etc/usplash.conf

If they show different resolutions, then copy the one you just extracted with the command: sudo cp -a usplash.conf /etc/usplash.conf
Now the usplash resolution used at shutdown is the same with the one used to boot.

To understand more about initrd and initramfs:
http://en.wikipedia.org/wiki/Initramfs

Paul Dufresne (paulduf) wrote :

In Debian bug number 445100, it is said:
You nailed that one, Brice. The problem goes away with
xserver-xorg-video-ati/experimental 1:6.7.194-1.

Paul Dufresne (paulduf) wrote :

Confirming on xserver-xorg-video-ati, based on the fact that debbugs #445100 suggest that some Debian ATI driver version fix this problem.

Changed in xserver-xorg-video-ati:
status: New → Confirmed

@interbird:

Thanks for your reply. I ran the commands and both files are identical, but my shutdown usplash is still a small, very dark greyscale version of the normal usplash image. Is there any other information you know that might apply to this problem? Thanks again.

Paul Dufresne (paulduf) wrote :

I am removing my bug #162400 as a duplicate of this one, because I don't use vga=xxx and I am affected by almost identical symptoms, except that modprobe of the different proposed modules did not help me.
If you don't use vga=xxx in your /boot/grub/menu.lst on the kernel lines, then maybe you should mark your bug as a duplicate of mine (bug #162400) rather than this one.

Changed in xserver-xorg-video-ati:
status: Unknown → Fix Released

I believe this issue still exists in the recently released Hardy kernel, but if someone else can confrim that would be great. Unfortunately, the Hardy Heron Alpha1 LiveCD was released with the older 2.6.22 kernel. You'll have to manually install the newer Hardy Heron kernel in order to test. This should not be the case for Alpha2. However, here are the instructions to install (if you choose to do so):

1) edit the file /etc/apt/sources.list and add the following line:

deb http://archive.ubuntu.com/ubuntu hardy main restricted

2) sudo apt-get update
3) sudo apt-get install linux-image-2.6.24-1-generic
4) reboot and select the new kernel from the grub menu

After you've tested, please feel free to revert back - ie boot into the old kernel, sudo apt-get remove linux-image-2.6.24-1-generic, and remove the line from /etc/apt/sources.list . Please update this report with your results. Thanks in advance!

Changed in linux:
importance: Undecided → Medium
status: New → Incomplete
sinewalker (sinewalker) wrote :

Confirmed: still getting the blank ttys with 2.6.24-1 kernel.

However, I also couldn't start X, and do not seem to have any evidence of my attempt in system or X logs to bring some light to the problem, sorry.

System started up fine without the vga=794 in my boot options (selected 2.6.24-1 in Recovery mode).

Hardware is a Radeon 9200 on AGP, driving a Philips 190B LCD over a VGA analogue cable.

Bryce Harrington (bryce) wrote :

Dropping -intel as subscriber as it looks like Paul determined the -intel issue is separate (bug 162400), so will focus there.

Changed in xserver-xorg-video-intel:
status: New → Invalid
Changed in linux:
assignee: nobody → ubuntu-kernel-team
status: Incomplete → Triaged
LeGreffier (ylamouroux) wrote :

I think it's not good to mix the framebuffer drivers, my tty work great in gutsy, and it's not related to nvidia (should work with any CGU)

1. comment the "blacklist vesafb" (but leave uncommented every others) line in /etc/modprobe.d/blacklist-framebuffer
2. add "fbcon" and "vesafb" in /etc/initramfs-tools/modules
3. add the vga=xxx in your boot list, and i find the font prettier than in the nvidiafb (looks like debian Oo )

Finally "sudo update-initramfs -k all -u" to apply ...

This should work , and mplayer runs smooth in this (works for me :) )

using hardy with all updates, and I still dont have TTYs if i set vga=0x0360
both regular and recovery modes fail. I have to edit the grub parameter to see anything.

Using intel 855 GPU

Henrik Nilsen Omma (henrik) wrote :

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). To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage and https://wiki.ubuntu.com/DebuggingProcedures .

Albin Tonnerre (lutin) wrote :

The causes of this bug have been cristal-clear for a long time. The only reason it's still open if that the kernel team just doesn't care (or if it does, it apparently enjoys not telling us)

Cheers

just updated hardy kernel to 2.6.24.1.1 and using vga=0x0360 still leaves me with a blank screen

DavidS (david-aeolia) wrote :

Just tried LeGreffi3R's fix for Gutsy, and it works fine for me with NVidia GeForce 2 MX200, except that the tty displays are offset a little from the position of the X display - this problem first appeared in the later Feisty kernels.

I must say I'm a bit miffed at being expected to wait 6 months (until Hardy is released) for a "proper" fix.

---

LeGreffi3R wrote on 2007-12-06: (permalink)

I think it's not good to mix the framebuffer drivers, my tty work great in gutsy, and it's not related to nvidia (should work with any CGU)

1. comment the "blacklist vesafb" (but leave uncommented every others) line in /etc/modprobe.d/blacklist-framebuffer
2. add "fbcon" and "vesafb" in /etc/initramfs-tools/modules
3. add the vga=xxx in your boot list, and i find the font prettier than in the nvidiafb (looks like debian Oo )

Finally "sudo update-initramfs -k all -u" to apply ...

This should work , and mplayer runs smooth in this (works for me :) )

Dave Steinberg (dmsteinberg) wrote :

MOM's fix worked for me, too. Thanks!

I'm running 7.10 with Linux 2.6.22-14-generic on AMD64, using an Intel 945GM graphics adapter.

For me it's been enough to remove the vga=xxx option to restore the full
functionality of the ttys.

I've got an Acer Aspire 5680 laptop, with NVIDIA GeForce Go 7600SE graphics
card and Ubuntu Gutsy Desktop x86.

BTW, the vga=xxx option is set easily by the StartUp-Manager, who I think
was the first to set the vga option. It was not preinstalled by default in
Ubuntu, I installed it a little after the installation from the
repositories: that's why at the beginning my ttys worked, and then no more.

2007/12/11, Dave Steinberg <email address hidden>:
>
> MOM's fix worked for me, too. Thanks!
>
> I'm running 7.10 with Linux 2.6.22-14-generic on AMD64, using an Intel
> 945GM graphics adapter.
>
> --
> 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.
>

--
Elio "Killer Behind You" Alpha4

Dave Steinberg (dmsteinberg) wrote :

2007/12/11, Alpha4:
>
> For me it's been enough to remove the vga=xxx option to restore the
> full functionality of the ttys.

That doesn't work for me because of bug 175475. The framebuffer goes into an ugly, low-res graphics mode (instead of staying in text mode) and for some reason X won't run at full resolution (1280x1024).

linux-source-2.6.22 won't be in Hardy, flipping status to Invalid.

Changed in linux-source-2.6.22:
status: New → Invalid
Jonas Bygdén (jbygden) wrote :

What is this?

Is this the way to solve problems now?

First the responsible teams just ignores the bug long enough, then the QA team says that since Gutsy is now released it's too late to fix it and sends it to the next release which will not include the same source (which I'm pretty sure was known) and hence can be set to invalid.

Problem solved!

Yeah, right!

What's probably most frustrating is the complete and utter silence from the responsible teams.

Kyle M Weller (kylew) wrote :

Invalid is an approach or example that is flawed and does not lead to the
correct solution of the problem. An invalid approach would be to simplify
the expression from left to right, disregarding the order of operations. A
valid approach would be to simplify the expression using the order of
operations....
Why is this marked invalid? This obviously effects Ubuntu Gutsy so marking
it invalid is an invalid decision

On Dec 12, 2007 6:46 PM, Leann Ogasawara <email address hidden> wrote:

> linux-source-2.6.22 won't be in Hardy, flipping status to Invalid.
>
> ** Changed in: linux-source-2.6.22 (Ubuntu Hardy)
> Status: New => Invalid
>
> --
> 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.
>

Felix Miata (mrmazda) wrote :

FWIW, this bug does not apply to OpenSUSE 10.3, Mandriva 2008, or Feisty, and I highly doubt it applies to Fedora 8 or any other recent distro. Apparently the devs think those who rightly expect their fb consoles to work correctly should use something other than Gutsy or Hardy, or write their own script to load the necessary module(s), or install some gfxcard other than Intel.

Timo Aaltonen (tjaalton) wrote :

Not a driver issue.

Changed in xserver-xorg-video-ati:
status: Confirmed → Invalid
gwi (george-willegers) wrote :

@Jonas Bygdén
> What's probably most frustrating is the complete and utter silence from the responsible teams.

I completely agree with that (and not only for this bug, but for others as well).

@Felix Miata
> or install some gfxcard other than Intel.

If you do, don't install an nVidia card. I have one, and have the same problems, so it's not Intel specific.

Miguel Martinez (el-quark) wrote :

Calm down, guys. At least as far as we have our standard 80x24 terminals
working.

This issue is not an xorg driver issue, as Timo already noted. This issue
is caused because the kernel devs have blacklisted all the framebuffer modules.

As the modules have been knowingly blacklisted, this can be deemed as a
feature, not a bug. Let's see what we gain:

$ head -3 /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.

OK, so all framebuffer modules are blacklisted for a reason. The questions
I ask are:

1) Are all the fb modules of such a low quality?
2) Can we afford putting the best supported modules back in, so that some
users will still be able to use nice high-res ttys?
3) Is suspend/hibernate working better in gutsy because of the general
blacklisting?
4) If one blacklists fb drivers due to suspend/resume woes, should we take
the next step and blacklist fglrx because it doesn's support SLUB allocator?

Ok, ok, forgive my sarcasm on my last question.

Kyle M Weller escribió:
> Why is this marked invalid? This obviously effects Ubuntu Gutsy so marking
> it invalid is an invalid decision

--
----------------------------------------
Miguel Martínez Canales
    Dto. Física de la Materia Condensada
    UPV/EHU
    Facultad de Ciencia y Tecnología
    Apdo. 644
    48080 Bilbao (Spain)
Fax: +34 94 601 3500
Tlf: +34 94 601 5326
----------------------------------------

  "If you have an apple and I have an apple and
  we exchange these apples then you and I will
  still each have one apple. But if you have an
  idea and I have an idea and we exchange these
  ideas, then each of us will have two ideas."

  George Bernard Shaw

"4) If one blacklists fb drivers due to suspend/resume woes, should we take
the next step and blacklist fglrx because it doesn's support SLUB allocator?"

That's exactly what I did! I get massive artifacts and no suspend/resume at all w/ fglrx.

Goodness (1-goodness) wrote :

So, today a new kernel-image has installed and dthe same problem again, no output at the booting system.

What can i do?

LeGreffier (ylamouroux) wrote :

Your menu.lst has been updated, put vga=xxx on the line of your kernel should get things back working.

Goodness (1-goodness) wrote :

No, it is writen in the settings

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=quiet vga=0x0307

I have the Boot-Information back, i modified the Skript from Interbird with a hold command before the Skript will creat a new Image. I added the Information was diffrent from my old kernel-image to the new on. It was no "fbcon and vesafb" in the modules file, the vesafb.ko and the driver for the console failed. So this new Image with my modifikation works now perfekt for me.

Without this Changes at the skript, the Boot-Information are no avaible on the Screen.

LeGreffier (ylamouroux) wrote :

Le jeudi 20 décembre 2007 à 11:49 +0000, Goodness a écrit :
> No, it is writen in the settings
>
> ## additional options to use with the default boot option, but not with the
> ## alternatives
> ## e.g. defoptions=vga=791 resume=/dev/hda5
> # defoptions=quiet vga=0x0307

The lines that begin with a "#" are comments.

Guillaume Martres (smarter) wrote :

Yes, but update-grub interpret them and use them to update the kernels boot options.

angel1127 (huxiaoping1127) wrote :

i also updated to new kernel yesterday. i add vga=792 to new kernel
setting.
it works,

but under new kernel. my sound card does not works, oh. God.

i now do not have time to fix it. so i go back to .13 kernel

so i want to recommend, backup your older kernels. may be one day you
will need it.
;)

Goodness 写道:
> So, today a new kernel-image has installed and dthe same problem again,
> no output at the booting system.
>
> What can i do?
>
>

Felix Miata (mrmazda) wrote :

Upgrading to the latest kernel didn't help my mga system at all. My /etc/modprobe.d/blacklist-framebuffer file has no content. No matter what combination of modules I do or don't include in /etc/initramfs-tools/modules before doing 'update-initramfs -u -k all', I get entirely black screen between Grub menu and KDM login screen, and unless I first 'modprobe vesafb', also on reboot after X closes, until POST begins.

Loye Young (loyeyoung) wrote :

<rant>
The statement in /etc/modprobe.d/blacklist-framebuffers to the effect that all framebuffer drivers suck is extremely bizarre, because GFXBOOT that the install CD uses loads the framebuffer to install the system and does it damn near flawlessly.

As a sanity check, when I boot from the install disk, press F4, select the best resolution that works for my card/monitor, I get great resolution in the consoles. If it works during installation (which often must use lowest common denominator), it damn sure should work when the system is fully installed.

If the kernel framebuffer is so bad, somebody needs to change the install script for xserver-xorg, because it recommends the framebuffer ("Enabling this option is the safe bet . . . ."). If you don't believe me, try "dpkg-reconfigure xserver-xorg". (Now that I think of it, I've wasted a lot of time trying to get X to work correctly by enabling the framebuffer when it's blacklisted.) If the framebuffer works for the GUI, I for the life of me can't see why it won't work in text mode.

By the way, it's pretty damn arrogant to blacklist every driver out of hand and leave a flame in the configuration file about how bad they are. The framebuffer has been around for at least 8 years that I know of, and it works great for the rest of the world. The guys upstream writing the fb drivers for the kernel are some of the best software engineers in the world, with many years of experience, and these days they get their information straight from the manufacturers. Whoever wrote the flame in the blacklist file should consider that perhaps the problem is NOT in the framebuffer driver but instead somwhere between the keyboard and the chair.
</rant>

Happy trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

Loye Young (loyeyoung) wrote :
Download full text (3.8 KiB)

The following isn't a cut-and-paste "how to" solution. Rather, in an effort to get resolution (the pun was too good to pass up) on this bug, my comments are intended as a starting place for how to get the framebuffer working. If this were a real "how to", I'd make it more friendly for newbies, but if you even know what the console and the framebuffer are, you are not a newbie. My hope is that the following will be of assistance to the community in making headway. I'm NOT confident that the following is entirely or even mostly accurate. Following the instructions below is at your own risk and may cause some or all of your descendants to be born naked. You have been warned. If anyone has anything to add or correct, please post a message.

WHERE TO GET INFO. Install the package "linux-doc", which depends on the latest kernel documentation. Once installed, you can navigate to /usr/share/docs/linux-docs-2.6.[latest greatest]/Documentation/fb and find a number of surprisingly detailed documents about the framebuffer. The best starting place is framebuffer.txt.gz, which can be viewed in a terminal using "less" without having to decompress the file first (which is kinda slick, don't you think?). I also recommend that you read fbcon.txt.gz, vesafb.txt.gz, modedb.txt.gz, and the document for the native driver for your video card, if it exists. The "Framebuffer HOWTO" by Alex Buell is already 8 years old, so it doesn't have the latest, greatest information, but it is a helpful read.

GOTCHAS
1. Misconfiguration. My sense is that misconfiguration accounts for 75% of the problems people are having with the framebuffer. For the framebuffer to work on the console, one must load TWO modules: (1) the video card framebuffer driver; and (2) "fbcon", the framebuffer's console driver.
2. Splash screen. The splash screen itself causes problems if the monitor does not have a 4x3 aspect ratio. That is to say, if you have a wide screen monitor, the splash screen won't work correctly because it's a graphic. My workaround solution is simply to delete "splash" from the boot loader line in /boot/grub/menu.lst. A better solution would probably be to create a splash graphic that has the right resolution and aspect ratio. Someday, I'll learn how to do that, but I'm not up to it today.

LOAD THE FRAMEBUFFER KERNEL MODULES
You should probably do a little testing to see which driver works best for you. For most cards, one of the drivers listed in /etc/modprobe.d/blacklist-framebuffers will be appropriate. The "vesafb" driver is a generic framebuffer driver that works very well with many video cards. Sometimes it works better than the card-specific driver. In either event, you'll have to edit /etc/modprobe.d/blacklist-framebuffers to get your favorite driver working. Comment out the fbcon line and the line referring to the driver you want to use (i.e., add a # to the beginning of the line). To have the modules load at boot time, add to the beginning of /etc/modules: "fbcon" (without quotes) and EITHER "vesafb" (ditto) OR the name of the native fb driver for your card.

FIGURE OUT THE RIGHT VIDEO MODE
From modedb.txt.gz:
   "To specify a video mode at bootup, use the followi...

Read more...

in response to Loye Young "the keyboard and the chair problem":
"video= ... " boot option will do nothing in ubuntu - I believe this is vesafb-tng/gentoo specific ... sigh ...

Loye Young (loyeyoung) wrote :

klerfayt wrote:
>"video= ... " boot option will do nothing in ubuntu

There's nothing proprietary about Ubuntu's implementation of the
kernel or the video stack. "video=..." is a feature of the vesafb (and
similar) framebuffer driver. If the driver is loaded at boot time, as
I described, it should work. I've been experimenting with it and found
that it does more than nothing. :-)

On a slightly different tack, I haven't taken a look at the specifics
of how the kernel is compiled to see what effect that has on the
framebuffer. If someone knows or has the opportunity to look, it would
be helpful.

Happy Trails,

Loye Young

Wiktor Wandachowicz (siryes) wrote :

@Loye Young

I have already written an Ubuntu-specific tutorial concerning this issue and K/Ubuntu usplash as well, using only "hwinfo" program and traditional "vga=" instead of "video=" parameter. I haven't posted here earlier, because this bug already has had lots of comments. But since you've mentioned it...

To can find my post in the forums:
* GeForce 1440x900 resolution, virtual terminals and wide usplash-theme-ubuntu
  http://ubuntuforums.org/showthread.php?t=622018

Though I would rather prefer things to work out of the box, so my howto would not be needed at all.

This seems fixed to me with latest updates. Can you confirm this happens also to you?

Changed in initramfs-tools:
importance: Critical → Medium
angel1127 (huxiaoping1127) wrote :

i update day and day.
i fixed in each version.
my note book is Thinkpad r50e with intel i810 card

Andrea Corbellini 写道:
> This seems fixed to me with latest updates. Can you confirm this happens
> also to you?
>
> ** Changed in: initramfs-tools (Ubuntu Hardy)
> Importance: Critical => Medium
>
>

Loye Young (loyeyoung) wrote :

I'm not sure what you mean by "fixed . . . with latest updates," because the console is still broken unless the user has the inclination and ability to do some hacking.

With latest updates the default installation still doesn't allow better than 80x25 on the console, because the framebuffer is blacklisted and nothing takes its place.

It is possible to re-engineer the box to get the console working again, but that's not a fix, just a workaround for us in the geek-speak-enlightened club.

<rant>
The SVGA standard for 1024 × 768 resolution at 256 colors was released in 1990. Here we are 18 years later running the most advanced, cutting edge kernel on the planet, but we're back to hacking the kernel to get the humble, text-mode tty console working properly. WTF?
</rant>

Bottom line: this bug ain't fixed.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

Andrew Conkling (andrewski) wrote :

So you tried on Hardy then?

-----Original Message-----
From: Loye Young <email address hidden>

Date: Thu, 10 Jan 2008 04:25:41
To:<email address hidden>
Subject: [Bug 129910] Re: Blank ttys when using vesafb (vga=xxx)

I'm not sure what you mean by "fixed . . . with latest updates," because
the console is still broken unless the user has the inclination and
ability to do some hacking.

With latest updates the default installation still doesn't allow better
than 80x25 on the console, because the framebuffer is blacklisted and
nothing takes its place.

It is possible to re-engineer the box to get the console working again,
but that's not a fix, just a workaround for us in the geek-speak-
enlightened club.

<rant>
The SVGA standard for 1024 × 768 resolution at 256 colors was released in 1990. Here we are 18 years later running the most advanced, cutting edge kernel on the planet, but we're back to hacking the kernel to get the humble, text-mode tty console working properly. WTF?
</rant>

Bottom line: this bug ain't fixed.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

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

mozdevil (mozdevil) wrote :

Using kernel 2.6.22-14-386
VGA controller: Intel 82945G/GZ rev 02

Solution does not work for me:
1. comment the "blacklist vesafb" (but leave uncommented every others) line in /etc/modprobe.d/blacklist-framebuffer
2. add "fbcon" and "vesafb" in /etc/initramfs-tools/modules
3. add the vga=xxx in your boot list, and i find the font prettier than in the nvidiafb

What works though is manually modprobing vesafb and fbcon

LeGreffier (ylamouroux) wrote :

Le jeudi 10 janvier 2008 à 16:20 +0000, mozdevil a écrit :
> Using kernel 2.6.22-14-386
> VGA controller: Intel 82945G/GZ rev 02
>
> Solution does not work for me:
> 1. comment the "blacklist vesafb" (but leave uncommented every others) line in /etc/modprobe.d/blacklist-framebuffer
> 2. add "fbcon" and "vesafb" in /etc/initramfs-tools/modules
> 3. add the vga=xxx in your boot list, and i find the font prettier than in the nvidiafb
>
> What works though is manually modprobing vesafb and fbcon
>
Did you update your initramfs?
"sudo update-initramfs -u -k all"

This should work

mozdevil (mozdevil) wrote :

Yes i did:

update-initramfs -u

Loye Young (loyeyoung) wrote :

@ Andrew
>So you tried on Hardy then?

No. This bug was filed against Gutsy, and it's still a bug against Gutsy. I don't know what would possess anyone to mark it "declined for Gutsy". The EOL date for Gutsy isn't until April 2009. Until then, basic functionality of the OS that's broken should be fixed, especially when how to fix the problem is widely known.

Having a console with better than 80x25 resolution isn't some new, cutting-edge technological feature to be introduced in the future. The framebuffer has been part of Unix systems since the 1970's. (For a description of the state of the Linux framebuffer as it was 10 years ago, see http://www.xfree86.org/3.3.6/fbdev.html.). As I said in an earlier post, SVGA has been around since 1990. It was even working in Ubuntu until Feisty was released.

This bug ain't fixed.

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

Andrew Conkling (andrewski) wrote :

On Jan 10, 2008 3:21 PM, Loye Young <email address hidden> wrote:

> @ Andrew
> >So you tried on Hardy then?
>
> No. This bug was filed against Gutsy, and it's still a bug against
> Gutsy. I don't know what would possess anyone to mark it "declined for
> Gutsy". The EOL date for Gutsy isn't until April 2009. Until then, basic
> functionality of the OS that's broken should be fixed, especially when
> how to fix the problem is widely known.

I get that. I asked because Andrea Corbellini had mentioned the latest
updates while changing the importance of Hardy, so, I'm not sure, I thought
he was talking about the latest Hardy updates. If (he could confirm and) you
could test it on Hardy, and it works there, then maybe we could see about a
possible backport to fix this?

Also, maybe it was declined because we'd need to release a new kernel
package and that wouldn't be possible for this? Again, I'm not sure, just
thinking out loud.

On Thursday 10 January 2008 12:26:42 Andrew Conkling wrote:
> So you tried on Hardy then?

Been using Hardy ever since Alpha 1, and I still have this prob, with may onboard Intel i855.
actually, it even worse now, because hibernation also cause the screen to get all those "nice" color squares, and a gray char filling my screen instead of the
shutdown splash.

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by...

mozdevil (mozdevil) wrote :

Adding the modules to /etc/initramfs-tools/modules and executing update-initramfs -u did not work for me.

What helped me a bit was this comment:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/129910/comments/236

After adding the modules to the start of /etc/modules it worked fine.

Thanks...

mozdevil (mozdevil) wrote :

Another try after a fresh install of Feisty.

1. comment the "blacklist vesafb" (but leave uncommented every others) line in /etc/modprobe.d/blacklist-framebuffer
2. add "fbcon" and "vesafb" in /etc/initramfs-tools/modules
3. add the vga=xxx in your boot list
4. update-initramfs -v -u -k $(uname -r)

Worked for me, finally.

On Thu, 2008-01-10 at 20:42 +0000, Andrew Conkling wrote:
> I get that. I asked because Andrea Corbellini had mentioned the latest
> updates while changing the importance of Hardy, so, I'm not sure, I thought
> he was talking about the latest Hardy updates. If (he could confirm and) you
> could test it on Hardy, and it works there, then maybe we could see about a
> possible backport to fix this?
I was speaking about latest Hardy updates but it seems the fix was
"unwilling" because this bug still open.
I've changed the importance because this bug is not critical at all.

Loye Young (loyeyoung) wrote :

To Andrea Corbellini,
> I've changed the importance because this bug is not critical at all.

It may not be important to you, but I am not keen on my company
selling computers with a broken console.

Remember that you aren't the only fish in this pond, Andrea. You might
not care about this bug or the people it affects, but the many people
who have commented on it and its many duplicates DO care.

Happy Trails,

Loye Young

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

I know this is not the best place to ask question, but - is there a wiki or
something that explains all this
"console/framebuffer/what_ever_is_this_tty_really_called" stuff in layman's
terms?

On Jan 11, 2008 9:39 PM, Loye Young <email address hidden> wrote:

> To Andrea Corbellini,
> > I've changed the importance because this bug is not critical at all.
>
> It may not be important to you, but I am not keen on my company
> selling computers with a broken console.
>
> Remember that you aren't the only fish in this pond, Andrea. You might
> not care about this bug or the people it affects, but the many people
> who have commented on it and its many duplicates DO care.
>
> Happy Trails,
>
> Loye Young
>
> --
> Loye Young
> Isaac & Young Computer Company
> Laredo, Texas
> http://www.iycc.biz
>
> --
> 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.
>

@Loye Young: I'm sorry for your company, but I have to set the importance "critical" to bugs which are really critical.

Loye Young (loyeyoung) wrote :

On Jan 11, 2008 1:54 PM, klerfayt <email address hidden> wrote:
> I know this is not the best place to ask question, but - is there a wiki or
> something that explains all this
> "console/framebuffer/what_ever_is_this_tty_really_called" stuff in layman's
> terms?

Yes, there are, though it's a bit more complicated than it appears on
the surface. I mentioned a few in an earlier post, but you might also
want to look at:

http://homer.iycc.biz/cgi-bin/dwww?type=runman&location=console/4
http://homer.iycc.biz/cgi-bin/dwww/usr/share/doc/HOWTO/en-html/Keyboard-and-Console-HOWTO.html
http://homer.iycc.biz/cgi-bin/dwww/usr/share/doc/HOWTO/en-html/Text-Terminal-HOWTO.html

Happy Trails,

Loye

Loye Young (loyeyoung) wrote :

Andrea,

>I have to set the importance

Did someone die and made you BDFL?

>"critical" to bugs which are really critical.

It's one thing to mark something as less than critical; it's another
to mark it as declined altogether.

Loye

Albin Tonnerre (lutin) wrote :

On Fri, Jan 11, 2008 at 08:02:33PM -0000, Andrea Corbellini wrote :
> @Loye Young: I'm sorry for your company, but I have to set the
> importance "critical" to bugs which are really critical.
>
> --
> 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.

The very nature of this bug, its activity and the number of duplicates
it has clearly show that this is not a trivial bug. It sure deserves a status
higher the 'Medium'
Please remembert that the kernel team hasn't been able to provide a single
answer, even though this bug has gotten the highest priority for SEVERAL months.

If you want the bug never to get fixed, just go ahead, and have fun. But it's
plain silly

--
Albin Tonnerre, aka Lutin
 - Search a little longer, travel a little further

I set the importance "critical" also for linux so. Sorry for the mistake.

Changed in initramfs-tools:
importance: Medium → Critical
Changed in linux:
importance: Medium → Critical
Paul Dufresne (paulduf) wrote :

You have to understand that we normally don't fix bugs in a version that was released.
Only in exceptional case this is done, and the conditions for doing so are described at:
https://wiki.ubuntu.com/StableReleaseUpdates

Among the conditions, the following:
An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix; generally, SRUs will not be accepted if the bug has not been fixed in the development branch.

Almost no one have reported this problem on Hardy (I have checked all duplicates, and they are all about Gutsy, except mine: bug #162400, which I am
not sure is a duplicate, because I have no screen, even without VGA=xxx option, which I seems to be alone in that situation).

Bug importance are described at:
https://wiki.ubuntu.com/Bugs/Importance

One could argue that it should be low because it has many easy workarounds:
  -don't use vga=xxx
  -use the terminal in graphics mode rather than real virtual terminals
  -and the one consisting at modifying initramfs modules to load fbcon and vesa
But as it affects many people, well yes, medium seems fair.

A new alpha version of Hardy have just come out: Alpha 3.
Please consult http://www.ubuntu.com/testing/ , download alpha 3 CD and test how it works for you with it,
and report results here.

Andrew Conkling (andrewski) wrote :

On Jan 11, 2008 4:23 PM, Paul Dufresne <email address hidden> wrote:

> You have to understand that we normally don't fix bugs in a version that
> was released.
> Only in exceptional case this is done, and the conditions for doing so are
> described at:
> https://wiki.ubuntu.com/StableReleaseUpdates
>
> Bug importance are described at:
> https://wiki.ubuntu.com/Bugs/Importance
>
> One could argue that it should be low because it has many easy
> workarounds:
> -don't use vga=xxx
> -use the terminal in graphics mode rather than real virtual terminals
> -and the one consisting at modifying initramfs modules to load fbcon and
> vesa
> But as it affects many people, well yes, medium seems fair.

Agreed. Also, questions about this can be addressed on the bugsquad list:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad.

And let's keep in mind the Ubuntu Code of Conduct:
http://www.ubuntu.com/community/conduct.

Albin Tonnerre (lutin) wrote :

On Fri, Jan 11, 2008 at 09:23:54PM -0000, Paul Dufresne wrote :
> You have to understand that we normally don't fix bugs in a version that was released.

You have to understand that I'm part of MOTU and thus do know what a SRU is,
thanks.

> Only in exceptional case this is done, and the conditions for doing so are described at:
> https://wiki.ubuntu.com/StableReleaseUpdates
>

I see. A non-usable framebuffer for basically evey ubuntu user is actually a
very, very common bug. My mistake

> Among the conditions, the following:
> An explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix; generally, SRUs will not be accepted if the bug has not been fixed in the development branch.
>
> Almost no one have reported this problem on Hardy (I have checked all duplicates, and they are all about Gutsy, except mine: bug #162400, which I am
> not sure is a duplicate, because I have no screen, even without VGA=xxx option, which I seems to be alone in that situation).
>
> Bug importance are described at:
> https://wiki.ubuntu.com/Bugs/Importance
>
> One could argue that it should be low because it has many easy workarounds:
> -don't use vga=xxx

This is for people who are too lazy to apply the fix. Until someone tells
me why I shouldn't use the framebuffer, which is, let's be honest, quite handy
if you want to work properly with your consoles, I see no reason why this would
be a proper fix

> -use the terminal in graphics mode rather than real virtual terminals

Btw, it prevents you from seeing usplash. Just use usplash at the lower res
then, with svgalib. woot.

> -and the one consisting at modifying initramfs modules to load fbcon and vesa
> But as it affects many people, well yes, medium seems fair.
>

Why in hell is that so hard for the kernel team to just comment on the solution,
and possibly tell us why this should or should not be done, and eventually fix
the thing or definitely mark it as a won't fix ?. Oh, wait. I was dreaming.
Nevermind.

> A new alpha version of Hardy have just come out: Alpha 3.
> Please consult http://www.ubuntu.com/testing/ , download alpha 3 CD and test how it works for you with it,
> and report results here.
>
> --
> 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.

--
Albin Tonnerre, aka Lutin
 - Search a little longer, travel a little further

Lionel Le Folgoc (mrpouit) wrote :

Andrew Conkling a écrit :
>
> And let's keep in mind the Ubuntu Code of Conduct:
> http://www.ubuntu.com/community/conduct.
>
And let's stop invoking the CoC each time someone doesn't agree, please...
Btw, where are the offending words?

--
Lionel Le Folgoc - https://launchpad.net/~mrpouit
EEBA 555E 0CDE 92BB 3AF4 4AB3 45A0 357B 5179 5910

Timo Aaltonen (tjaalton) wrote :

Andrea, you were right the first time, medium is the right importance:

https://wiki.ubuntu.com/Bugs/Importance

Lacking a framebuffer console is not an issue that makes your machine explode.

Changed in initramfs-tools:
importance: Critical → Medium
Changed in linux:
importance: Critical → Medium

@Timo: I strongly disagree. This bug does not affect "an application" or "non-essential hardware component", as medium bugs do. It "has a severe impact on a small portion of Ubuntu", those who want to use terminal can't. Moreover, you can't use the tty to solve X server problems. It is also "a problem with an essential hardware component" - video, since framebuffer is video card depended. So, the importance of this bug is *high*.

@Paul: Please, after reading all these comments here you should be aware that, first, there is no single workaround for all cards, second, it is not so hard for unexperienced user to miss a step and turn the whole system unusable. I wouldn't say then that the workaround is easy.

Timo Aaltonen (tjaalton) wrote :

"Those who have changed the default configuration and thus cannot use the console". There.

On Sat, Jan 12, 2008 at 08:02:43AM -0000, Timo Aaltonen wrote :
> "Those who have changed the default configuration and thus cannot use
> the console". There.
>

*Cough* . You must be joking. This is not $whatever_random_modification that is
likely to make the part of your system you are configuring actually not working.
It's nothing more than expecting a piece of software that has been working for
ages to do its work properly. One sometimes calls that a regression. And a
severe one as as the activity on this bug shows, it's 1/ widely used and
2/ affects every single ubuntu user.
Please don't try to make it look as if users were doing some evil setup that is
perfectly known as harmful.

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

--
Albin Tonnerre, aka Lutin
 - Search a little longer, travel a little further

Timo Aaltonen (tjaalton) wrote :

> Please don't try to make it look as if users were doing some evil setup that is
> perfectly known as harmful.

But I am. Framebuffer consoles can break lots of things, like power management. The ultimate solution is coming though; kernel modesetting. Hardy+1 material, hopefully.

If you haven't noticed, this bug has been assigned to the kernel team by a team member. So either contribute patches or just wait.

On Fri, 2008-01-11 at 23:24 +0000, Timo Aaltonen wrote:
> Andrea, you were right the first time, medium is the right importance:
>
> https://wiki.ubuntu.com/Bugs/Importance
>
> Lacking a framebuffer console is not an issue that makes your machine
> explode.
Yes, I know but it was going to become a difficult situation :)
Thanks for your assistance.

da1l6 (da1l6) wrote :

Just tested in Hardy Alpha 3: Bug is still present there :(

Graphics Card: Nvidia Geforce 2MX
Kernel: 2.6.24-3-generic

Loye Young (loyeyoung) wrote :
Download full text (4.8 KiB)

@ andrew
> You have to understand that we normally don't fix bugs in a version that
> was released.

Then why do we claim that we "support" any release? I really hope that
you were speaking off-the-cuff. Deciding not to fix bugs (even with
the exception of security fixes) means that we DON'T support the
release, and every release is at the end of life the day it's
released.

The wiki page on Time Based Releases
(https://wiki.ubuntu.com/TimeBasedReleases) describes a policy that
is, fortunately, somewhat more flexible:

"What kind of changes are appropriate to make in a released version of Ubuntu?

"We only update packages for specific types of changes:
    * Fixes for security vulnerabilities
    * Other high-impact bug fixes, for example those which cause data loss
    * Very conservative, unintrusive bug fixes with substantial
benefit and very low risk"

This bug clearly falls into the second category, and I would argue it
falls into the third category as well.

I can't think of many more high-impact bugs than a broken console.
Despite our best efforts to making it more "user friendly", Ubuntu and
every other GNU/Linux system, needs the command line. This is
especially true when dealing with problems with graphics cards and
monitors, because the command line is all you have if you can't get X
to operate correctly.

My users run into this relatively frequently. Example:
Example 1: Pancho buys a slick new IYCC "Laredo Cuadrado" desktop
computer with 19" widescreen, preinstalled with Ubuntu and
preconfigured for the graphics card and monitor. He gives it to Dario,
his 15 year old son, who sets it up in his room. The family decides
they want to play an online game in the living room, so Dario
disconnects the monitor and carries it by the integrated front panel
handle to the living room and hooks it up to the 30" LCD
monitor/television in the living room. When he fires it up, everything
boots up, but when X starts, the monitor gives and "Out of Range"
error, meaning not even displayconfig-gtk is visible. He wants to use
the console to run "dpkg-reconfigure xserver-xorg", but alas, the
console doesn't show anything, just a black screen staring at him.

Example 2: Laredo Trucking Co. buys three Laredo Cuadrado desktops for
their offices, again with the 19" screens. The cleaning guy knocks
over the monitor one night, leaving it in a dozen pieces on the floor.
After cleaning it up, the boss sends his secretary out to Best Buy to
buy a monitor. She picks up another LCD monitor, but they were out of
19" wide screens, so she gets a 17" regular 4x3 LCD monitor. They fire
it up, but X won't start. The IT guy wants to configure the xserver,
but can't because the console doesn't work.

Example 3: Ubuntu ships an updated version of a driver, xserver-xorg,
displayconfig-gtk, or any of a number of packages needed to make X
work. Unfortunately, the update overwrites a configuration file or has
some other bug that prevents X from starting. Again, the console is
broken, so there's not much he can do.

Example 4: The upgrade script from Gutsy to Hardy breaks the computer
(like the script for Kubuntu broke many computers upgrading from
Feisty to Gut...

Read more...

Jonas Bygdén (jbygden) wrote :

On 11/01/2008, Paul Dufresne <email address hidden> wrote:
>
> You have to understand that we normally don't fix bugs in a version that
> was released.
> Only in exceptional case this is done, and the conditions for doing so are
> described at:
> https://wiki.ubuntu.com/StableReleaseUpdates

I would be more inclined to understand that if this bug had been reported
AFTER Gutsy was released. But this bug was reported on August 2nd, and as
far as I know Gutsy is also known as 7.10, which indicates that it was
released in October. That gives 2 months to do something (or at lease post a
comment, which is yet to happen) about it BEFORE the release.

> Among the conditions, the following:
> An explanation of how the bug has been addressed in the development
> branch, including the relevant version numbers of packages modified in order
> to implement the fix; generally, SRUs will not be accepted if the bug has
> not been fixed in the development branch.

Again, when the bug was reported Gutsy WAS the development branch.

> Almost no one have reported this problem on Hardy (I have checked all
> duplicates, and they are all about Gutsy, except mine: bug #162400, which I
> am
> not sure is a duplicate, because I have no screen, even without VGA=xxx
> option, which I seems to be alone in that situation).
>
> Bug importance are described at:
> https://wiki.ubuntu.com/Bugs/Importance
>
> One could argue that it should be low because it has many easy
> workarounds:

Easy for whom? For me? Yes - if I had a different graphics card. I'm yet to
try a solution that works with my Intel 945GM/GMS. I'm living with 80x25,
which is a "working" solution but, as someone said earlier, seem rather
silly this long after the standard came out.

For someone trying out linux as an alternative to Windows for the first time
and runs into some trouble needing to login without X? Not so much!

> -don't use vga=xxx
> -use the terminal in graphics mode rather than real virtual terminals
> -and the one consisting at modifying initramfs modules to load fbcon and
> vesa
> But as it affects many people, well yes, medium seems fair.
>
> A new alpha version of Hardy have just come out: Alpha 3.
> Please consult http://www.ubuntu.com/testing/ , download alpha 3 CD and
> test how it works for you with it,
> and report results here.

Someone earlier tried that, with the same results.

/Jonas

On Friday 11 January 2008 21:23:54 Paul Dufresne wrote:
> Almost no one have reported this problem on Hardy (I have checked all duplicates, and they are all about Gutsy

I'm on Hardy, ever since Alpha 1, and I had this prob the all time up until last week, when I MANUALLY fixed it with the step provided in the bug reports.

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by...

On Sunday 13 January 2008 00:27:28 Jonas Bygdén wrote:
> I would be more inclined to understand that if this bug had been reported
> AFTER Gutsy was released. But this bug was reported on August 2nd, and as
> far as I know Gutsy is also known as 7.10, which indicates that it was
> released in October. That gives 2 months to do something (or at lease post a
> comment, which is yet to happen) about it BEFORE the release.

I first detected it while trying to install Gutsy alpha via Network Install

> Easy for whom? For me? Yes - if I had a different graphics card. I'm yet to
> try a solution that works with my Intel 945GM/GMS. I'm living with 80x25,
> which is a "working" solution but, as someone said earlier, seem rather
> silly this long after the standard came out.

I manage to make my Intel 855GM work with the steps mention, on my hardy laptop.

> For someone trying out linux as an alternative to Windows for the first time
> and runs into some trouble needing to login without X? Not so much!

I already had to explain this a few 1st timers on Ubuntu..... not good.

> /Jonas

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

Felix Miata (mrmazda) wrote :

I upgraded from Gutsy to Hardy and observed no improvement. Then I added vesafb to /etc/modules. This proved a partial solution. I no longer need to manually modprobe vesafb, but there's a much too long 25 second delay between Grub menu selection and observing anything but black on the screen again. The boot process is far along before any startup messages can be observed. mga gfxcard. 1.13 GHz CPU.

Miguel Martinez (el-quark) wrote :

Hello everybody,

I've got a little question regarding this bug. When I'm on tty[1-6] before
modprobing radeonfb and fbcon, my 80x25 tty works without any kind of
colour. Well, I have different shades of grey, but nothing else. No blue
folders, no green exes, no red tarballs nor purple images. And of course
syntax highlighting in vim is not really usefull. Is anybody else
experiencing the same?

I'd also like to ask Timo or anybody with the knowledge what I should
expect to be broken when I modprobe radeonfb (which btw direclty uses a
1280x800 console in my laptop)

Hi,

i am running ubuntu 7.10. last week i did a kernel update to 2.6.22-4-generic.
after that i lost my system's framebuffer capability.

i did following to re-enable it:

content of /etc/initramfs-tools/modules:

fbcon
vesafb

---------( eof )-------------

change the end of /usr/share/initramfs-tools/hooks/kernelextras:

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

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

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

my /etc/modules contains the 3 lines:

fbcon
vesafb
vga16fb

remove the vesafb and fbcon from /etc/modprobe.d/blacklist-framebuffer
do a: update-initramfs -u -k all
and make sure grub's menu.lst file is setup correctly
dont forget grub-update if you need it.

good luck, stefan

----------------------------------
http://www.polybytes.de

sinewalker (sinewalker) wrote :

It seems to me that this bug (or regression of a long-existing feature, which ever way you want to look at it) was introduced in order to fix issues with suspend-to-RAM or hibernate features on computers with frame buffer LCDs (as pointed out to us by Miguel Martinez on Dec 13). It also seems that this was perhaps a heavy-handed, or quick fix for that problem (the correct fix would be to file bugs with the upstream maintainers of the frame buffer drivers, though I concede this is probably not a workable solution in short term given the stated lack of support).

The best outcome for all concerned would be to reverse this blacklist measure that was introduced in Gutsy, and instead only blacklist if you are installing on a notebook computer that would make use of suspend/hibernate features.

Presence of a notebook could either be detected (look for a PCMCIA bus + ACPI BIOS, for instance; there may be more reliable indications too), or failing that, you could just ask the user ("are you installing to a laptop/notebook computer?") during install. You could even ask directly: "do you wish to use suspend/hibernate power saving features?" though this is probably too complex a question to face during install.

I would also place a warning in /etc/modules that the fbcon/vesafb drivers (and others?) have known issues with suspend/hibernate and that they should be disabled _if_ you are experiencing problems with that feature.

This way, people with notebooks have working power save, and people with desktops (who presumeably don't care about power saving) will have working high-res frame buffer vttys.

I propose that this should be the course of action the ubuntu dev's take on this bug, rather than endless arguments about whether or not it's a bug (of course it's a valid bug).

FliPsTaR (flipstar) wrote :

thanks to Stefan Ollinger,
your bugfix describtion finally worked for me.
just wanted to say thank you :)

running hardy@2.6.24-3-generic

Taupter (taupter) wrote :

Well, this bug drives me crazy, not because it's hard to fix (it isn't or it shouldn't), but because no kernel dev seems to be interested in fixing it.
I was able to fix it in my desktops, but not in my notebook, no matter what I did. Installed openSUSE 10.3 on it and now the nb runs fine.
I'm generally disappointed with Gutsy as a whole, a lot of instability problems in my notebook (the machine freezing from time to time, not being able to wake-up and this absurdly stupid bug - let's call a lemon a lemon).
Telling me I'm free to choose to run another distro or even MS-Windows doesn't count, as I already know that and I'm already using another distro in my notebook, thank you, and telling me I can't complain cause I got it for free doesn't count either, cause I spent (and still spend) countless hours coding stuff present in almost every Linux distro (KDE), and this idiotic bug is in my way.
What I'm doing here is making an wake-up call. I, as a F/OSS developer, am pretty aware people will complain and even use a program other than ours if it doesn't meet their needs, simple as that. People will give up.
Please be responsive to your users' needs, or, given so many options floating around, you'll have no users anymore.

kaer (kaerb) wrote :

I did what Kai (message 92 above: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/129910/comments/92 ) explained:

sudo mcedit /etc/initramfs-tools/modules
  fbcon
  radeonfb

sudo update-initramfs -u -k all -v

sudo mcedit /etc/modprobe.d/blacklist-framebuffer
  #blacklist radeonfb

sudo modprobe radeonfb

I am under Linux 2.6.22-14-generic with Radeon R250 [Mobility FireGL 9000] and IT WORKED !!!
My problem was that tty's where unusables : big letters and quickly pink screen with jammed letters :-)

Taupter (taupter) wrote :

My desktops have Nvidia 5700LE and 5200, my notebook has a 6150go, and I followed the same procedure in all of them, didn't work in the notebook.
My point is this bug, caused by a decision from a brainy boffin, shouldn't be there at all. That rare intelligence thought it would be mean to blank every (k/x/edu)ubuntu framebuffer terminal around the globe because it didn't break his workflow. As far as I can see it's a complete disregard about users other than him, and even if it was done to supposedly fix a broken suspend (it was broken to me so hard I had to reinstall my system after a failed suspend) it only demonstrates this dev doesn't know a simple engineering lesson: Fix what is broken, where it's broken, and don't mess wirth anywhere else while you're at it.

Buzz (buzz-piersol) wrote :

I did not realize this was a bug. I always had my virtual consoles at VGA quality, not realizing that higher resolutions were possible, until I experimented with different distros. When I started messing with vga=XXX I got the blank screens.

The process below, similar to others, gets 1024x768 in the virtual consoles, though I get the native 1440x900 when running X.

edited /etc/initramfs-tools/modules to include:
  fbcon
  vesafb

commenting in blacklist file, /etc/modprobe.d/blacklist-framebuffer as such:
# blacklist vesafb

followed by
sudo update-initramfs -u -k all -v

and then edit /boot/grub/menu.lst, using boot option:
vga=0x0318

For the boot option above, I chose the best vga mode from output of "hwinfo --framebuffer" (had to apt-get), which was 1024x768.

I've nvidia Geforce 6150 Go, which gives 1440x900 in the GUI, so I will try the nvidia fb modules next.

Thomas Orlowski (th-orlowski) wrote :

Hallo,

I tried the workaround for this bug too, but always ended with a console screen containing some spread green squares, partly blinking.
I have an older Toshiba notebook with a NVidia GeForce4 620Go. Because I need the Xinerama function (for beamer presentations), I use the restricted nvidia driver. I never got a working high resolution framebuffer console (with vesafb -- I know that only this works with the nvidia drivers) since I upgraded from Feisty (where everything worked fine) to Gutsy (which is IMHO on older hardware _very_ slow, even when I disable most of the eyecandy).
 I was just one step before switching back to Debian (that I used before Feisty) the necessary backup was already done. Then I found, that the framebuffer console came back, when I disabled the Ubuntu splash screen.
So the combination of the splash screen with the restricted nvidia driver (#9636, not the "new" one) seems to break the vesafb framebuffer.

Thomas.

James Cuzella (trinitronx) wrote :

Hello, running a Gateway C-140x convertible tablet that includes an "ATI Mobility™ Radeon® X2300 HD" card. I initially had problems with the usplash not displaying on boot as well as the no terminal problem.
I changed around the display settings in /etc/usplash.conf to be:
xres=1024
yres=768
Then installed the proprietary fglrx drivers (in the process of this I had need of a terminal when X would not start, only to find that those would not work either! Only booting recovery console would get a working terminal thankfully.)

Fixed it with the following steps:
sudo apt-get install hwinfo
sudo hwinfo --framebuffer
looked through supported vga modes and found one I liked:
Mode 0x0323: 1024x768 (+4096), 32 bits

sudo vim /boot/grub/menu.lst
found my kernel line and added vga=0x0323
Add fb modules to initramfs:
sudo vim /etc/initramfs-tools/modules
inserted:
fbcon
radeonfb

sudo vim /etc/modprobe.d/blacklist-framebuffer
un-blacklist the module by commenting out line:
#blacklist radeonfb
update the initramfs:
sudo update-initramfs -u -k all -v

Fixed with acceptable resolution and working usplash :D.

Seriously though, how'd this bug even get into Gutsy? There's no need to break previously working framebuffer modules for the sake of power management. I'd think having a working set of ttys is more important. This is most certainly a case of: "If it ain't broke, don't fix it". I'd like to see this back to normal in Hardy.

Buzz (buzz-piersol) wrote :

This is a sort of update.

In my /etc/initramfs-tools/modules
    fbcon
    vesafb
    nvidiafb

And in /etc/modprobe.d/blacklist-framebuffer
   # blacklist nvidiafb
   # blacklist vesafb

Now this is interesting. If my boot line DOES NOT include vga=XXX, I get virtual terms which are very crisp clean, very small beautiful font, probably 1440x900. However, my X is broke from this--I am using the nvidia-glx driver (not nvidia-glx-new). Jean Levasseur mentioned the incompatibility with the nvidiafb and nvidia-glx-new. Of course I can't get the full 1440x900 natively in X with the nv driver.

To sum it up, using the above modules, I have a double-edged sword:
   * GUI is 1440x768 using nvidia-glx, and virtual terminals at 1024x768 when I specify vga=0x318 as a boot option.
   * GUI is 1024x768 using nv, and virtual terminals are 1440x900 (I think), when I don't specify vga=xxx as a boot option.

Buzz

Loye Young (loyeyoung) wrote :

Buzz --

>* GUI is 1440x768 using nvidia-glx, and virtual terminals at 1024x768 when
I specify vga=0x318 as a boot option.
>* GUI is 1024x768 using nv, and virtual terminals are 1440x900 (I think),
when I don't specify vga=xxx as a boot option.
I've found a similar reaction with the radeonfb driver.

1. Have you tried running dpkg-reconfigure xserver-xorg from a terminal when
vga=xxx is not specified?
2. I haven't had good luck when running a vesafb AND the card-specific fb
driver. Have you tried using only the nvidiafb without vesafb and vice
versa?

--
Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

MiKRO (miro-kropacek) wrote :

I've tried all tricks with adding/commenting vesafb, vga16fb and fbcon modules with no success. however, Wiktor Wandachowicz's hint worked. my machine is thinkpad r60, intel graphics card. i use 1024x768/32 with no problem now!

Fabio Marzocca (thesaltydog) wrote :

I tried everything in this thread, with no success.

I am running Gutsy and nVidia GeForce 7300LE.

If I switch to tty, I only have one line stating: "Loading, please wait...". Then when I come back to tty-7 I have a black screen and nothing working. Computer freezes and I have to hard switch off.

Loye Young (loyeyoung) wrote :

To my fellow framebuffer-deprived penguins:

   I feel your pain, and agree that this needs to be fixed. However,
if you are trying to figure out how to troubleshoot to get your
framebuffer working, it's probably best to submit a question to the
forums. This should venue should really be reserved for reporting or
helping to fix bugs.

To Fabio,

You'll need to provide more information for the community to be able
to help. Some relevant information would be:

1. Which video driver are you running under X, and which version?
2. Which framebuffer drivers are you running on the console? Open up
a virtual terminal (while running X), and type:
   [code]
   $ lsmod | grep fb
   [/code]
3. Are you loading the agpgart module?
   [code]
   $ lsmod | grep agp
   [/code]
4. When you "switch to tty", how are you switching? (It turns out
that there are several ways to do it, and they have different effects
on switching back and forth.) Is the result the same on each of tty1
through tty6?
5. What does your boot command say? (The line towards the end of
/boot/grub/menu.lst that starts with "kernel" for your default boot
option)
6. What do the files /etc/modules and /etc/initramfs-tools/modules say?
7. What does your log file say? (Don't send the whole thing, just
look for any relevant messages.)
8. Which of the blacklist items did you blacklist?
9. Are you running more than one nvidia video driver?
   [code]
   $ lsmod | grep nv
   [/code]

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

Fabio Marzocca (thesaltydog) wrote :

You're right, Loye, I should have provided more informations.

Here they are:

1. nvidia-glx 1:1.0.9639+2.6.22.4-14.10

2. fabio@Plato:~ $ lsmod | grep fb
vga16fb 15500 0
vgastate 11008 1 vga16fb
vesafb 9092 1
fbcon 41760 72
tileblit 3584 1 fbcon
font 9344 1 fbcon
bitblit 6912 1 fbcon

3. fabio@Plato:~ $ lsmod | grep agp
agpgart 35016 1 nvidia

4. I switch to tty-1 with Ctrl-Alt-1. Only on that tty I see the line "Loading. Please wait...". On other tty's there is a blank screen
    If I go to single-mode user (with telinit 1) the tty screen is good.

5. kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=ead6c453-7721-49c0-ad26-1287c8486460 ro quiet splash vga=791 quiet splash

6. /etc/modules:
psmouse
mousedev
lp

/etc/initramfs-tools/modules
fbcon
vesafb
vga16fb

7. Relevant log messages:
vesafb: framebuffer at 0xe0000000, mapped to 0xf8880000, using 3072k, total 131072k
[ 24.264190] vesafb: mode is 1024x768x16, linelength=2048, pages=1
[ 24.264193] vesafb: protected mode interface ino at c000:d5a0
[ 24.264196] vesafb: pmi: set display start = c00cd5d6, set palette = c00cd640
[ 24.264198] vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
[ 24.264214] vesafb: scrolling: redraw
[ 24.264217] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
[ 24.264339] Console: switching to colour frame buffer device 128x48
[ 24.293986] fb0: VESA VGA frame buffer device
[ 25.452768] vga16fb: initializing
[ 25.452773] vga16fb: mapped to 0xc00a0000
[ 25.452832] fb1: VGA16 VGA frame buffer device

8. I blacklisted vesafb and vga16fb

9. fabio@Plato:~ $ lsmod | grep nv
nvidia 4716468 32
agpgart 35016 1 nvidia
i2c_core 26112 2 nvidia,i2c_nforce2
sata_nv 20612 1
libata 125168 3 ata_generic,sata_nv,ahci

Thank you.

Fabio

Thomas Orlowski (th-orlowski) wrote :

Hello,

@Fabio:

1. try to use only one framebuffer driver.

2. Maybe if helps to disable the Ubuntu-splash during boot (Remove "splash" "quiet" from the kernel command line in /boot/grub/menu.lst)

I have an older nvidia graphic in my notebook (GeForce4 420 Go) and use the nvidia-glx (9639) too . When I boot with ubuntu-splash enabled, I get on tty1..6 black screens with randomly spread green squares. Just before the splash appears I can see for a very short time the kernel-output on the screen, so I think the console works before the splash comes up.
When I disable the splash I get a blank screen for the first, hm. say 15 seconds, until the kernel loads the vesafb module. It's output is the first appearing on the screen. But then the console works in 1024x768 (which is the native resolution of my LCD).

Best regards,
Thomas.

Loye Young (loyeyoung) wrote :
Download full text (3.7 KiB)

IF YOU HAVE SOMETHING THAT WILL HELP THE DEVELOPERS FIX THE BUG, THIS
IS THE APPROPRIATE VENUE.

IF YOU NEED HELP TROUBLESHOOTING YOUR PARTICULAR SITUATION, GO TO THE FORUMS.

That said, Fabio's situation is likely instructive for others, so I'll
write up a general how-to here even though this thread should be about
the bug and not about troubleshooting.

Fabio has four video drivers loaded:
-- vesafb
-- vga16fb
-- fbcon
-- nvidia

The correct number is at most THREE. You should not use vga16fb and
vesafb at the same time. In Fabio's case, vesafb will probably be the
best choice.
1. Go back to /etc/modprobe.d/blacklist-framebuffer and remove the
"#" before the vga16fb line.
2. Remove "vga16fb" from /etc/initramfs-tools/modules.
3. Add "vesafb" and "fbcon" to /etc/modules.

The framebuffer mode is probably incorrect on your boot kernel command
in /boot/grub/menu.lst.
4. Remove "splash vga=791" everywhere it appears in /boot/grub/menu.lst.
5. Run "depmod".
6. Run "update-initramfs -u"
7. Reboot.

You should now have your consoles back, but in 640x480 mode.
(Sometimes, the graphics card figures out the right thing to do and
"just works". If it does, don't fix what ain't broke.)

Now you want to figure out which framebuffers are best for your
card/monitor combination. Run the rest of the commands below from a
console, NOT a terminal in X. The following two commands will give you
a great deal of information:
8. Run "get-edid | parse-edid" to get the possible modes for your monitor.
9. Run "hwinfo --vbe | less" and find the stanzas for the framebuffer
and monitor. (For me, they are at the end of the file, so I just press
the END key.)

ALTERNATIVE 1 --
hwinfo should give you the list of framebuffer modes to put in your
boot kernel command and the native resolution of your monitor. Note
that not all monitors do such a good job of reporting, so you might
have to pull out the documentation and read it to find the best
resolution. Usually, a digital LCD should run at 60 Htz (long story
that's not worth telling now). Pick the best framebuffer mode for your
monitor. If you have a digital LCD, use a resolution that equals the
native resolution of your monitor.
10. Edit /boot/grub/menu.lst and insert your chosen vga mode.
(You may have to do some trial and error to figure out which is best.)
11. Reboot and see how it comes out.

ALTERNATIVE 2 --
"get-edid | parse-edid" should give you the possible modes for your
monitor, if your monitor has a decent implementation of EDID. (My LG
19" Flatron does not work with this, but my Acer 19" widescreen does.
YMMV)
10. Run "less /etc/fb.modes". Study it and find which stanzas match
your monitor as reported by the EDID command.
11. From the console, run "fbset [vert]x[horiz]@[refresh]",
substituting the correct arguments that match fb.modes. Trial and
error may be necessary. If your console blanks out and you can't see
anything, use Alt-Right or Alt-Left (i.e., the Alt key and the
appropriate arrow key pressed simultaneously) to go to another console
and try again.

If you almost always use the console, Alternative 1 is probably more
convenient. If you only occasionally use the console, Alternative 2 is
p...

Read more...

Fabio Marzocca (thesaltydog) wrote :

Thanks Loye,

I had both vesafb and vga16fb because I have read a post here saying to put them both, and them I forgot to remove. Anyway I will try your suggestions, even thou I remember I have tried in the past the same configuration you are correctly describing.

Concerning the last comment on your post: of, I am not paying any support and I know what I am getting. This is a community-driven service and sometimes you can find in the community people much more professional than those on the paid support.

Fabio Marzocca (thesaltydog) wrote :

Loye,

this is my feedback report.

I have run points 1 to 7. Now, when I switch to tty-1 (Ctrl-Alt-F1), I got a 640x480 screen on which is displayed the boot sequence until "running local boot scripts..", then the cursor is blinking and I cannot enter anything . The other ttys are completely blank. If I try to go back to tty-7, the computer freezes and I have to hard reset.

Concerning your suggestion to go to the forums, I will do it for sure (as I always did in the past), but I believe this is a BUG and not a misuse of the OS. Since warty I always had my ttys and I was used to use them very often (before Gutsy...).

Loye Young (loyeyoung) wrote :

Fabio,

>I believe this is a BUG
I am sensing that I perhaps have inadvertently put you on the
defensive, which was not my intent.

I agree with you wholeheartedly that this is a bug, and I'm not
singling you out. It's just that this is already a long thread, and
more "me too" could actually make it harder on the developers to
figure out how to solve the problem.

In your particular situation, it comes down to a judgment call whether
to post here or the forums. If you believe you have something to
contribute that will help the developers fix this bug, you are in the
right place. If you're merely troubleshooting your own issues, the
forum is the right place. As is true in the rest of life, wisdom is a
better guide than knowledge.

>I have run points 1 to 7. Now, when I switch to tty-1 (Ctrl-Alt-F1), I
>got a 640x480 screen on which is displayed the boot sequence until
>"running local boot scripts..", then the cursor is blinking and I cannot
>enter anything . The other ttys are completely blank. If I try to go
>back to tty-7, the computer freezes and I have to hard reset.

Here are a few suggestions to isolate the problem. Work them
sequentially. Between each, review your log files to see if you get a
clue about what's going on.

* I've seen behavior you are describing when the BIOS was buggy
(sometimes the video card BIOS, sometimes the system BIOS). (Yet
another reason to pressure Intel and AMD to open up the BIOS.) Try
turning off all power management in X and in your BIOS and see if you
get the same results. You might also check with the manufacturer of
your computer and see if later BIOS upgrades refer to any issues with
suspend to RAM, hibernation, or other power management issues. Leave
the power management off while you troubleshoot.

* The nvidia-glx driver may be the culprit. Back up
/etc/X11/xorg.conf. Disable the proprietary video driver using the
Restricted Driver Manager. Reboot to see if the results are the same.

* Boot into recovery mode, and run "dpkg-reconfigure xserver-xorg",
specifying the "nv" driver instead (the open source driver for nvidia
cards). Then reboot as normal to see if the results are the same.
Continue to use the nv driver while you troubleshoot.

* Perhaps your console configuration is out of whack. Run, as root,
"dpkg-reconfigure console-setup". Reboot.

* [Advanced troubleshooting technique; do only if you are comfortable
doing it.] Rename the appropriate files to prevent gdm, xdm, or kdm
(as the case may be) from starting. The instructions are in
/etc/rc2.d/README. Reboot.

* Boot into recovery mode. Run "lsmod | grep fb" to see what
framebuffer drivers you are running. If vesafb and fbcon are not
loaded, use modprobe to load them. Use the instructions for fbset to
see if you can get a working framebuffer. If you can, something about
the modules and drivers loaded with runlevel 2 are interfering with
the framebuffer.

If you are able to get your framebuffer loaded, undo (one at a time)
each of the prior steps to get your machine to where it should be.
Report back on results.

Loye Young

Wiktor Wandachowicz (siryes) wrote :

@ Fabio Marzocca <email address hidden>:

> --
> 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 have already written an Ubuntu-specific tutorial concerning this
issue and K/Ubuntu usplash as well. It works great for me and it has
been reported by several folks that it works for them too :)

To can find my post in the forums:
 * GeForce 1440x900 resolution, virtual terminals and wide usplash-theme-ubuntu
   http://ubuntuforums.org/showthread.php?t=622018

Though personally I would rather prefer things to work out of the box,
so my howto would not be needed at all.

If you have more questions, feel free to comment on the aforementioned thread.

Friendly,
Wiktor

--
Registered Linux user #390131 (http://counter.li.org)

Fabio Marzocca (thesaltydog) wrote :

 @developers: maybe this can help in fixing the bug.

I have found the cause of my bug: nvidia-glx driver. By removing this driver and using the free "nv" driver, I have back my tty's (with the workaround suggested by Loye). But in such a case, I havo no compiz effects. If I reinstall nvidia-glx, I have the effects, but no more the ttys...

:-(
Is this the world we created?

Marhahs (shahram) wrote :

Hello,

I have had a similar problem. I use "ati radeon x1300 pro", "dell 2007wfp" with 1680x1050@60. I installed the ati driver by amd (the free driver does not work for me). I have compiz installed and works almost fine (except the image quality in cube is not good enough).

using radeonfb, vesafb and fbcon with default /boot/grub/menu.lst, i get virtual terminals and xserver is on tty7. but if i use the boot-up manager to change the dafault to "show bootloader", "show boot splash", and "show text during boot" (note:all the three), then i get no virtual terminal and gdm moves to tty9!

is this a different bug?

honestly, i do not see this as a major problem, but however wondered if there is a solution to this.

i appreciate your response in advance. thanks. shahram.

Marhahs (shahram) wrote :

Hello,

I have had a similar problem. I use "ati radeon x1300 pro", "dell 2007wfp" with 1680x1050@60. I installed the ati driver by amd (the free driver does not work for me). I have compiz installed and works almost fine (except the image quality in cube is not good enough).

using radeonfb, vesafb and fbcon with default /boot/grub/menu.lst, i get virtual terminals and xserver is on tty7. but if i use the boot-up manager to change the dafault to "show bootloader", "show boot splash", and "show text during boot" (note:all the three), then i get no virtual terminal and gdm moves to tty9!

is this a different bug?

honestly, i do not see this as a major problem, but however wondered if there is a solution to this.

i appreciate your response in advance. thanks. marhahs

Ben Collins (ben-collins) wrote :

This bug report is so convoluted, it can not be made sense of. Over 300 comments, various "me too"'s and more tangents than a geometry lesson.

I'm marking this as "Invalid" against the kernel until someone can summarize a single bug for us to look at, and directly relate that bug to the kernel.

Thanks

Changed in linux:
status: Triaged → Invalid
Taupter (taupter) wrote :

Ben Collins,

It's a really poor excuse for closing this bug.
The problem exists, people complained, people even posted fixes in this bug report, and here comes you to say this bug is invalid.
Be honest and say you're closing this bug because you don't want to fix it or are too lazy to parse these comments.
Let's bring it to perspective: if there are so many comments on this bug it's because this bug bites a lot of people. If you close this bug with such a lame half-baked excuse you pass the idea you don't give a d@#* to all these people, and you and (*)Ubuntu don't care to look beyond your own noses.
Very good example of how bad Ubuntu us becoming.

Richard Bailey (rmjb) wrote :

Please keep in mind the Ubuntu Code of Conduct:
http://www.ubuntu.com/community/conduct

Ben Collins (ben-collins) wrote :

FYI, committing a change that will get vesafb.ko back into the initramfs, which should resolve the generic problems of vga=

Changed in initramfs-tools:
status: Triaged → Invalid
Peter Garrett (peter-garrett) wrote :

On Mon, 25 Feb 2008 16:10:53 -0000
Ben Collins <email address hidden> wrote:

> I'm marking this as "Invalid" against the kernel until someone can
> summarize a single bug for us to look at, and directly relate that bug
> to the kernel.

Have you actually tried running a framebuffer in a tty on your own
hardware ?

Have you perhaps noticed that most of the comments relate to this?

Did you happen to notice that this bug has been around since at least
August last year?

Do you care?
--
"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

Andrew Conkling (andrewski) wrote :

On Mon, Feb 25, 2008 at 12:13 PM, Richard Bailey <email address hidden> wrote:

> Please keep in mind the Ubuntu Code of Conduct:
> http://www.ubuntu.com/community/conduct
>

Taupter (taupter) wrote :
Download full text (7.2 KiB)

About Ubuntu's Code of Conduct,

Disregarding so many people for so much time is, imo, a disrespectful act.
Getting upset with the aforementioned lack of consideration to its users and to all the people who cared about reporting, confirming, investigating and posting workarounds/fixes to this bug is, imo, a completely natural reaction.
Closing a bug as invalid doesn't magically fix the problem.
Closing a bug as invalid in such circumstances makes people question the seriousness, commitment and capability of the maintainer and his employer.
Complaining != being disrespectful.
Following Ubuntu's Code of Conduct doesn't make everything pink, happy, right and good.
The CoC is a guideline, not the 10 Commandments.
The CoC shouldn't be used as a cloaking device to avoid criticism.

The CoC's link (http://www.ubuntu.com/community/conduct) has a beautiful word in it: "community". If we can't give opinions, question people or express ourselves, including our dismal about other community members, it may well not be a community worth of taking part.
'Humanity towards others', Ubuntu's motto, expresses fully this concept of interaction between humans (sharing ideas, feelings) for a greater good. I believe nobody here complained or suggested fixes to this bug just to piss off the Ubuntu's kernel team, but because fixing it was seen by all these people as being an improvement to Ubuntu and another step in direction to a greater good.

Before another Law's Guardian comes up here to trump the CoC card again, let's take a look at it:

"Be considerate. Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and we expect you to take those consequences into account when making decisions. For example, when we are in a feature freeze, please don't upload dramatically new versions of critical system software, as other people will be testing the frozen system and not be expecting big changes."
When the unknown-to-me Kernel maintainer added this regression in august 2007, almost 7 months ago, before gutsy's stable release, he/she disregarded the very CoC, as this bug affects a lot of people, and framebuffer consoles are used mostly by developers, sysadmins and other knowledgeable people who have a good deal of influence, either as local gurus or IT professionals.

"Be respectful. The Ubuntu community and its members treat one another with respect. Everyone can make a valuable contribution to Ubuntu. We may not always agree, but disagreement is no excuse for poor behaviour and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It's important to remember that a community where people feel uncomfortable or threatened is not a productive one. We expect members of the Ubuntu community to be respectful when dealing with other contributors as well as with people outside the Ubuntu project, and with users of Ubuntu."
Ignoring so many people for 7 months _is_ disrespectful. Asking if the maintainer cares is mostly a rethorical question, as his actions speak for him. 7 months is a way too large span ...

Read more...

sinewalker (sinewalker) wrote :

one wonders whether the people closing this bug as "invalid" are the same arrogant individuals who caused it in the first place, wrt the comment in the blacklist file...

In any case, this bug, and especially the opportunity to witness how this ubuntu developer community "includes" all in their process, has been enough to encourage me to return to openSUSE, despite Novell's ties with Microsoft. At least the SUSE guys are good engineers.

c u. Was fun while it lasted.

Gurubie (gurubie) wrote :

Come on guys. Please fix this with the fine and automatic upgrade system. It's been way too long.

LeGreffier (ylamouroux) wrote :

Le jeudi 28 février 2008 à 14:21 +0000, PMan a écrit :
> Come on guys. Please fix this with the fine and automatic upgrade
> system. It's been way too long.
>

No. In ubuntu, there are only security upgrade by default, this problem
(not even a bug to me) is not a critical bug, so no upgrade.

Peter Garrett (peter-garrett) wrote :

On Thu, 28 Feb 2008 16:47:28 -0000
LeGreffi3R <email address hidden> wrote:

>
> Le jeudi 28 février 2008 à 14:21 +0000, PMan a écrit :
> > Come on guys. Please fix this with the fine and automatic upgrade
> > system. It's been way too long.
> >
>
> No. In ubuntu, there are only security upgrade by default, this problem
> (not even a bug to me) is not a critical bug, so no upgrade.

The fact that it isn't a bug for *you* does not mean that it is not a bug.

Among other things, it breaks apps that use the frame buffer without X -
for example, the fbi and fbgs programs, links2 -g called from a tty and
probably a number of others.

In addition, it is still present in Hardy (the development version of
Ubuntu), so your argument regarding "security only" falls flat on its face.

The frame buffer has worked on every version of Linux that I have used
since I started in 2002. This is a regression, whether you like it or not.

I notice that Ben Collins is committing a change with vesafb, so perhaps
this absurd situation will be rectified after all. We live in hope.

lee (lovergeek) wrote :

Would just like to say that Caravel's solution worked for me, followed exactly, with no side effects as of yet.
Gutsy
Dell Inspiron 1720
Nvidia GT8600M
*New to Ubuntu and Linux, so if I can add any other useful info please let me know.

Stevie (stevie1) wrote :

what if my hwinfo --framebuffer doesnt show me my native resolution of 1440*900?
im lost then or is there still a solution?

3-M (meyer30m) wrote :

Caravel's solution sort of worked for me - I can get the ttys to show up at 1024x768, but I have the same problem as Stevie, where hwinfo --framebuffer doesn't show anything higher than 1024x786.

Gusty, nVidia 7600 GT.

Stevie (stevie1) wrote :

yep ! i got a geforce 7600 go!

Didier L (l-farquaad) wrote :

Hi,

I have the same problem as Stevie, with the same card. The only difference is that I see 2 modes at 1440x1050, but only at 8 or 16 bits. It is still lower than my native 1680x1050 resolution and I see no wide resolution in the list…

fig_wright (fig-wright) wrote :

I have totally blank consoles (tty 1-6). My boot screen works OK. I do need the consoles in cases of rare crashes. I have tried all the possible solutions here with no success.

I have tried editing in /etc/modules and /etc/initramfs-tools/modules and /etc/modprobe.d/blacklist-framebuffer the modules fbcon and all of vesafb nvidiafb vga16fb by themselves and sometimes with each other. None have ever produced anything other than a blank tty screen.

My Kit:
GeForce3 Ti 200 with latest restricted drivers
LCD DVI flat panel 1280x1024

Here is an excerpt from the latest ATI Catalyst driver released today, note point 3.

The following section provides a brief description of known issues associated with the latest version of ATI Catalyst™ Linux software suite. These issues include:

    * There is no support for video playback on the second head in dual head mode. Further details can be found in topic number 737-26985
    * Desktop corruption may be noticed when dragging the overlay/video when using dual-display mode. Further details can be found in topic number 737-29578
    * A black screen may be observed on some hardware when switching to the console or leaving the X window system when a Vesa framebuffer console driver is used. Further details can be found in topic number 737-30687
    * Video Playback may display wrong colors and additional shadow images when cropping or expanding a video file using a video player that utilizes the XVideo extension

Apparently ATI considers this a bug worthy of their attention, although from what I know the issue is not an exclusively ATI issue.

Larry

Loye Young (loyeyoung) wrote :

> * A black screen may be observed on some hardware when switching to the
> console or leaving the X window system when a Vesa framebuffer console driver
> is used. Further details can be found in topic number 737-30687
<snip>
> Apparently ATI considers this a bug worthy of their attention, although
> from what I know the issue is not an exclusively ATI issue.

The problem with ATI's driver is distinct from the bug described in
this thread, and
the two should not be confused.

The bug described in this thread is really a misconfiguration of the
kernel and of
the boot-up routine in Ubuntu, to wit: Use of the console framebuffer
is blacklisted
altogether by default in Ubuntu Gutsy et seq.

The ATI driver has a separate problem of corruption of video when moving between
the framebuffer and X. The "solution" by the Ubuntu kernel team was to
blacklist the
framebuffer, effectively making the console unusable, instead of
fixing the problem
with ATI's X video driver.

The kernel team's current position towards the console is akin to
throwing away all
four tires when the car gets a flat. You have to drive the car on the
rims, but at least
you don't have to fix flats anymore. Besides, the rims are prettier
than the tires, so
who cares?

Happy Trails,

Loye Young
Isaac & Young Computer Company
Laredo, Texas
http://www.iycc.biz

The default behavior using the vga=... parameter on Gusty is to break the virtual consoles while producing no error message to the user.

I understand that it makes sense to start the booting process with the lowest common denominator driver for reliability reasons,

however I think if the system finds itself booting with a vga=.... and all framebuffer modules blacklisted, which default configuration, the system should produce a meaningful error message and gracefully ignore the vga=... option, rather than the current behavior which is to display a black screen without offering any explanation to the user as to what's going on. Maybe that's not practical to implement, but the current system is not intuitive.

Bug still exists in Hardy Alpha 6.

Saivann Carignan (oxmosys) wrote :

Setting back to confirmed because it makes no sense that a so high volume bug in invalid everywhere. However, please don't post additional comments here unless a developers is asking for some information. Thank you for your contribution and for your understanding.

Changed in linux:
status: Invalid → Confirmed
Colin Watson (cjwatson) wrote :

Loye: the reason we don't use vesafb by default is that it breaks suspend/resume.

Colin Watson (cjwatson) wrote :

FWIW, the CD boot menu in Hardy no longer incites people to use vga= (that F4 menu has been removed and replaced with something different), which was probably why quite so many people were running into this bug.

Ben Collins (ben-collins) wrote :

Uploaded an initramfs-tools that doesn't call modprobe with -b (which honors blacklists, when it shouldn't). Need to fix the kernel build so that vesafb.ko gets copied to /lib/modules/`uname -r`/initrd/ in order for it to be included in the initramfs. Bug is only partially fixed right now.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.85eubuntu29

---------------
initramfs-tools (0.85eubuntu29) hardy; urgency=low

  * Do not honor blacklists for vga=/video= parsing. We should always load the
    fb drivers in this case (since this is a manual operation on the part of
    the user)
    LP: #129910

 -- Ben Collins <email address hidden> Tue, 11 Mar 2008 11:46:08 -0400

Changed in initramfs-tools:
status: Invalid → Fix Released
Changed in linux:
status: Confirmed → Invalid
Changed in linux:
assignee: ubuntu-kernel-team → ben-collins
status: Invalid → Fix Committed
Loye Young (loyeyoung) wrote :

Colin:

> it breaks suspend/resume

The suspend/remove issue is a bug in the proprietary X video drivers, not in vesafb. I'm sure that blacklisting the framebuffer seemed like the thing to do at the time.

> CD boot menu in Hardy no longer incites people . . . , which was probably why quite so many people were running into this bug.

That's a plausible explanation, but it's not what I'm seeing with my customers. I like the F4 feature very much because it's much easier to see what you're doing when setting up several machines a day. However, my sense is that few people ever use the F4. I have taught around 50 people how to install Ubuntu, and I tell them about F4 when I do. However, when they actually do the install themselves, they ignore it.

The reason people use the console is because it is useful for so many tasks, especially when fixing problems with video in X. They are accustomed to modern video resolutions, even in text mode, so they naturally expect the CLI to work with a decent resolution.

> Uploaded an initramfs-tools . . . . Bug is only partially fixed right now.

I think the solution Ben is driving towards is a reasonable compromise. It will get the framebuffer working for those who need or want it, but works around the suspend/remove problem in the X video driver.

I think I can speak for many on this thread: THANKS!!

Happy Trails,

Loye Young

Ben Collins (ben-collins) wrote :

Just a quick comment, my solution is not a "compromise", it restores the original functionality that we've always had. Framebuffer drivers for the console should never be loaded by default, and we've never done this to my knowledge. It's way to unstable, even ignoring the suspend/resume issues.

Felix Miata (mrmazda) wrote :

Ben Collins wrote "It's way to [sic] unstable,"

That's utter nonsense. In all the years I've been using Linux since sometime last century, my kernel lines have not had vga= parameters only briefly when necessary to overcome brokenness such as this. With the exception of this bug, such periods without have always been very brief, days or at most two weeks. Six months of a choice between being stuck with the exclusively Ubuntu only 80x25 possible on the ttys, or using any of the many major distros not suffering this ridiculous bug instead is inexcusable. Fedora 8 doesn't have this. Etch doesn't have this. SUSE 10.3 doesn't have this. Mandriva 2008 doesn't have this. Knoppix doesn't have this. OTOH, every release of Ubuntu since my first exposure to it over 3 years ago has given me consoles that are different from what just works elsewhere. Whatever it is that Ubuntu does differently with framebuffer from what other distros do is simply broken, and should be changed to conform to what seems to be bulletproof everywhere else.

Miguel Martinez (el-quark) wrote :

Ben,

Thanks for your fixes and comments. I've got just one question. Are all
framebuffer drivers unstable? If so, should bugs be filled upstream about
this functionality?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.24-12.21

---------------
linux (2.6.24-12.21) hardy; urgency=low

  [Ben Collins]

  * build: Fix vesafb module inclusion into initrd subdir
    - LP: #129910
  * net/bluetooth: POWERBOOK => APPLE, fix for apple keyboard patch
  * custom/xen: Remove asix portion of xen patch, breaks driver
    - LP: #199296

  [Colin Ian King]

  * SAUCE: fix Udma not fully available in Acer 1694 Wlmi
    - LP: #187121
  * SAUCE: Update toshiba_acpi.c to version 0.19a
    - LP: #77026

  [Stefan Bader]

  * x86: Clear DF before calling signal handler
  * Enable FN key on Apple aluminum bluetooth keyboard
    - LP: #162083

 -- Ben Collins <email address hidden> Tue, 11 Mar 2008 13:20:49 -0400

Changed in linux:
status: Fix Committed → Fix Released
Saivann Carignan (oxmosys) wrote :

As said earlier, please don't use launchpad for argumentation or it become very difficult to work on these bug reports. This bug was close to stay unfixed because it has too much comments.

If you still disagree and when to ask for this idea, please debate of the idea with developers in mailing lists or ubuntu brainstorm http://brainstorm.ubuntu.com/

Thanks for your participation and for your understanding.

Hello,

  Since I upgraded the kernel to 2.6.24-12, the tty is blank, I use vga=0x318. I have been using this workaround:
Commented those lines in /etc/modprobe.d/blacklist-framebuffer :
#blacklist nvidiafb
#blacklist vesafb

Added those lines to /etc/initramfs-tools/modules:
fbcon
vesafb

Then running update-initramfs.

This workaround was working in Gutsy and Hardy, but when I upgraded to kernel 2.6.24-12, it stopped working.

I'm another sufferer. This evening I tried to add vga=865 to my menu.lst to get full resolution, and, splam, blank virtual ttys. Nvidia card, proprietary driver.

Hello,

  I just found out, that I get the blank ttys even if without the vga= option

Just from the blacklist workaround?

On Sat, Mar 15, 2008 at 12:03 PM, أحمد المحمودي (Ahmed El-Mahmoudy) <
<email address hidden>> wrote:

> Hello,
>
> I just found out, that I get the blank ttys even if without the vga=
> option
>
> --
> 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.
>

Felix Miata (mrmazda) wrote :

Since my last update, the problem returned, except that the background color I set in .bashrc is not ignored.

On Mon, Mar 17, 2008 at 12:33:45PM -0000, Benson Margulies wrote:
> Just from the blacklist workaround?
>
>
> On Sat, Mar 15, 2008 at 12:03 PM, أحمد المحمودي (Ahmed El-Mahmoudy) <
> <email address hidden>> wrote:
>
> > Hello,
> >
> > I just found out, that I get the blank ttys even if without the vga=
> > option
> >
---end quoted text---

I don't understand your question.

--
 أحمد المحمودي (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

Liken Otsoa (liken) wrote :

Same problem.
In update from kernel 2.6.24-11 to 2.6.24-12 tty is missing.
I have fbcon and vesafb in initrams modules and commented in blacklist-framebuffer.

IBM Thinkpad X41.
intel driver.

mirko.quaglio (erlic) 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.

Kernel version: 2.6.24-3
videocard: ati radeon HD2400

Peter Garrett (peter-garrett) wrote :

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.

Peter Garrett (peter-garrett) wrote :

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

Peter Garrett (peter-garrett) wrote :

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?

Steven Shiau (stevenshiau) wrote :

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.

Oleksij Rempel (olerem) 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.

Steven Shiau (stevenshiau) wrote :

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.

Steven Shiau (stevenshiau) wrote :

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.

Peter Garrett (peter-garrett) wrote :

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>

Peter Garrett (peter-garrett) wrote :

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

ski (skibrianski) wrote :

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

pan Proteus (bartjablo) wrote :

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

Peter Garrett (peter-garrett) wrote :

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"

Oleksij Rempel (olerem) wrote :

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.

DF5JT (df5jt) wrote :

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)

DF5JT (df5jt) wrote :

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.

Loye Young (loyeyoung) wrote :

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?

Baronek (baronek1) wrote :

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.

Taupter (taupter) wrote :

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

Taupter (taupter) wrote :

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.

Saivann Carignan (oxmosys) wrote :

Bug #201591 is now fixed.

ski (skibrianski) wrote :

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

Saivann Carignan (oxmosys) wrote :

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.

kindofabuzz (kindofabuzz) wrote :

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

Taupter (taupter) wrote :

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

Saivann Carignan (oxmosys) wrote :

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.

Loye Young (loyeyoung) wrote :

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

Changed in xserver-xorg-video-ati:
status: Invalid → Confirmed
Saivann Carignan (oxmosys) wrote :

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.

ski (skibrianski) wrote :

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

Saivann Carignan (oxmosys) wrote :

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

Changed in xserver-xorg-video-ati:
status: Confirmed → Fix Released
Shriramana Sharma (jamadagni) 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?

Salva Ferrer (salva-ferrer) 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.
>

Salva Ferrer (salva-ferrer) wrote :

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

arty (me-arty) wrote :

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

Ian MacGregor (ardchoille42) wrote :

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.

To post a comment you must log in.