[amd64 + nvidia 8xxx] usplash shows nothing

I have this problem to.

AMD X2 6000+
M2N-SLI Deluxe
MSI Geforce 8800GTS (oc) 640mb

Same for me. Also is the same for the live cd. (which make it useless as an installer)

I have a core2duo and a Geforce 8800GTS

As said in the comment above, it also happens in the LiveCD.
My hardware is the following one:
CPU: Core 2 Quad Q6600
Memory: 4GB RAM
VGA: 8800GTS 320MB
Motherboard: Asus Commando.
Monitor: Philips 200WS (TFT-LCD 20.1", 1680x1050, using DVI connector).

Hope it will get fixed before gutsy final. This bug has been present since feisty at least.

/rant on. I don't think they will, The developers doesn't care about bugs only about adding more stuff and bloating stuff up. We have had a flash issue in Ubuntu for several releases and they fixed it yet and now this. They haven't even looked at this report yet it seems. The developers might wanna rethink some stuff, why bloating stuff up with a unstable Compiz-Fusion when we have some nasty bugs that just keeps on living release through release? /rant off.

If they don't fix it for this release, they should do it for the next one, which is supposed to have Long Term Support.

Same problem here - Screen stays black, and won't even boot into X. Only solution to remove "splash" from menu.lst.

x64x2, 8800GTS

I tried modifying my initrd to include "fbcon" - same results.
I tried modifying CONSOLE_SCREEN="true" in /etc/init.d/usplash - same results.
I tried passing the vga= option in kernel paramater list - same results.

The only error in dmesg is: [ 21.000414] ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.

The other message (possibly related) I could find in syslog or kern:
Oct 7 11:27:05 morpheus kernel: [ 33.921595] Console: colour VGA+ 80x25
Oct 7 11:27:05 morpheus kernel: [ 33.921607] Checking aperture...
Oct 7 11:27:05 morpheus kernel: [ 33.921609] CPU 0: aperture @ 9aa0000000 size 32 MB
Oct 7 11:27:05 morpheus kernel: [ 33.921611] Aperture too small (32 MB)
Oct 7 11:27:05 morpheus kernel: [ 33.926056] No AGP bridge found

So, I guess it's back to old skool scrolling text for now.

Same bug, but in install CD its woking ok :/ . Workaround: change "splash" to "nosplash" in menu.lst. In Feisty was working fine :( My computer is a laptop with this hardware:

00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 02)
00:01.0 PCI bridge: Intel Corporation 82830 830 Chipset AGP Bridge (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 41)
00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY
02:04.0 Communication controller: Conexant HSF 56k HSFi Modem (rev 01)
02:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
02:06.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
02:08.0 Ethernet controller: Intel Corporation 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 41)
03:00.0 Network controller: RaLink RT2561/RT61 rev B 802.11g

I'm also experiencing this problem on Gutsy RC. I did not have this problem on Feisty, and nothing in my computer specs has changed.

Mobo: Asus Crosshair
CPU: AMD64x2 6000+
Video: EVGA GeForce 8800GTS (640MB)
RAM: 2GB XMS2 DDR2-800
Monitor: Dell Trinitron (Could not find model number)

Is it just me, or does it seem everyone here having this problem is running a 8800GTS? Possibly an nvidia driver incompatibility issue?

I really hope this is fixed before final release.

same for me on a Thinkpad T40 (mobility 7500)..
i can boot hitting Alt+F2 after grub or removing splash from menu.lst

I don't want to believe this issue will not be solved before the release! :)

If you want this bug to be more noticed, I suggest nominating it for release in gutsy. (Click the "Nominate for release" link in the side nav on this page)

I have doubts that it will be fixed in time for the final release next week, but I'm sure it will be fixed at some point before the next release cycle.

i've Nominated for feisty 'cos Gutsy option isn't avaible :)

Hi, greetings from Italy... unfortunately I'm experiencing the same issue.
I'm using Ubuntu 7.10 RC (AMD64 edition) on a:

AMD Athlon64 3000+
1 GB Dual Channel DDR RAM
Nvidia 7300GT

I tried changing into several VGA modes but it didn't help.
I experienced the same results as the other users.

Same issue on Q6600
4GB Ram
Nvidia 8500GT using DVI

With Gutsy 7.10 Release Candidate (64 Bit).

Unable to nominate anymore.... Hopefully this will be fixed soon.

It seems that the "nosplash" workaround fixes kernel 2.6.22-14 booting on ubuntu gutsy RC.

on Gutsy

1) edit the grub menu file:
sudo gedit /boot/grub/menu.lst

2) find the line that says
kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=289068d7-1370-4197-9c9c-0158604be66b ro quiet splash

3)change the splash to nosplash - afterwards the line looks like this
kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=289068d7-1370-4197-9c9c-0158604be66b ro quiet nosplash

This fixed my box - home it helps others.

The problem is that my Ubuntu 64 doesn't boot at all, so I can't "sudo gedit" :). You have to disable it directly from Grub.

Press Esc to bypass the Grub countdown, press 'e' to start editing, scroll down to "# defoptions" line, press e to start edit, delete the options 'quiet' and / or 'splash' with the delete key, press Esc again and then 'b' to boot.

Black screen here too. Here's my bootchart. Thinkpad T41 with Radeon Mobility 7500. Seems like usplash is using just a bit more CPU than it used to :-)

OBTW, the vga=normal was a wild gues - didn't work. It does the same with "quiet".

I solved the issue by changing the usplash resolution in /etc/usplash.conf.

I solved the issue by changing the usplash resolution in /etc/usplash.conf to 1024x768.

You need to update-initramfs.

I can also confirm this bug with geforce 8800 on amd64

Also confirming it is definately 64 bit specific, as 32 bit gutsy is fine. Would have jumped in earlier, but didnt start using 64 bit build till gutsy was released.

Importance: Undecided

Come on this is clearly a blocker. Think about when Jo Average want to check out ubuntu. He is a gamer and have therefor a 8800. Since he is not broke he also have a core2 or amd 64. So what happend when he tries out the new cool 64 ubuntu edition? Black screen. "Crappy linux" backu to window for him. No way he will edit grub to get it to work.

I am having this black screen problem from Edgy days...i couldnt boot from LiveCD/LiveUSB but i am able to upgrade without any issues.
I am using Dell Inspiron 5160 with XGI Trident Volari XP5 video card. Surprised that we still keep getting this issue with each new version!
To add, this black screen is not allowing to to do anything...ctrl+alt+F1 is not working nor is ctrl+alt+backspace.
Adding to boot options things like "noacpi" or "nosplash" or "noapic nolapic" etc is not working.
safe graphics mode doesnt work either.
No way to get to terminal, so cant reconfigure xserver-xorg.
And this is not just related to ATI.
This is one such issue needing resolution to help fix BUG#1.

This bug was nominated for several stable releases but does currently not qualify for a stable release update (SRU) and the nominations were therefore declined (the Hardy one remains). 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

It would help if those experiencing the bug could follow https://wiki.ubuntu.com/KernelTeamBugPolicies and provide the requested debugging files. Also please test with the Hardy kernels on the next few alpha releases. Thanks!

I added the files requested in https://wiki.ubuntu.com/KernelTeamBugPolicies . Note that these files are generated with nosplash kernel option, as the hardy alpha desktop cd (amd64) will not boot with default options.

Thanks for the log files. Targeting for Hardy.

I've added the log files using Gutsy Gibbon with the latest kernel released. Next I'll try with the latest alpha of Hardy.
I'm using the nosplash boot option because gutsy won't boot up (well, using nosplash you actually reproduce the bug).

And finally, the alpha2 log files of Ubuntu Hardy :)
Hope this helps.

Ok, I think I got what the problem is. And, unfortunately, I think the solution is out of reach, at least for me.
It seems we x86_64 are simply short of a usable working vesa module! That's right, because:

vesafb doesn't work with newer cards. The fact that with x86 it works, it's because it is, in reality, vesafb-tng, the newer release, which of course isn't availabe on x86_64.
nvidiafb or ati equivalent doesn't work because thay won't work with the proprietary driver.

There is an alternative: uvesafb (http://dev.gentoo.org/~spock/projects/uvesafb/), which is the evolution of vesafb-tng. It works on every architecture and it's completely userland. It needs a kernel patch, though, and offer also some new features, like VESA 3.0 compatibility.

If Ubuntu's folks can implement uvesafb, we should be set! ;)

Fabio,

I tend to agree with your synopsis. I haven't dived much into hunting down
the exact cause like you, but I did find this solution on the forums, which
relates to your post. Look at orange2k's solution.

http://ubuntuforums.org/showpost.php?p=3635667&postcount=9

On Dec 29, 2007 8:57 AM, Fabio Papa <email address hidden> wrote:

> Ok, I think I got what the problem is. And, unfortunately, I think the
> solution is out of reach, at least for me.
> It seems we x86_64 are simply short of a usable working vesa module!
> That's right, because:
>
> vesafb doesn't work with newer cards. The fact that with x86 it works,
> it's because it is, in reality, vesafb-tng, the newer release, which of
> course isn't availabe on x86_64.
> nvidiafb or ati equivalent doesn't work because thay won't work with the
> proprietary driver.
>
> There is an alternative: uvesafb
> (http://dev.gentoo.org/~spock/projects/uvesafb/<http://dev.gentoo.org/%7Espock/projects/uvesafb/>),
> which is the evolution
> of vesafb-tng. It works on every architecture and it's completely
> userland. It needs a kernel patch, though, and offer also some new
> features, like VESA 3.0 compatibility.
>
> If Ubuntu's folks can implement uvesafb, we should be set! ;)
>
> --
> [EM64T]When booting, screen stays black.
> https://bugs.launchpad.net/bugs/147623
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I think we must all be very very careful here. We have two very distinct problems which show themselves with similar behaviour.
But, they're separated and must remain that way.

32 bit Ubuntu, within a particular (unknown??) set of circumstances (hw config maybe) screwes up the usplash resolution, resulting in black screen and slow boot times.

But 64 bits Ubuntu, which we are discussing here, has a completely different matter. Still a black screen, but boot time is normal.

The first is caused by a problem whithin the installation (wrong res) followed by a problem in vesafb-tng, which when set to the wrong res, takes ages to boot. It shouldn't do that, IMHO. The second is caused, as I was saying before, by completely missing vesa driver in 64 bit linux that works with recent cards.

I really want to be precise, because I've seen many times the two problems blending together and generating much confusion.

Thanks anyway!

I'm using a Dell D830 and can't use the Live-CD because my screen is black after the boot menu. I can't use ALT+F1 to access TTY1 or any other terminal.

I have a Nvidia Quadro NVS 140M graphic adapter

Also reproduced on VGA compatible controller: nVidia Corporation GeForce 8600 GT (rev a1)

This bug seems to happen only with nvidia cards so most probably that it should be in linux-restricted-modules, Can someone reproduce it using a ATI or Intel or any other card?

Fabio Papa : If the informations that you provided concerning vesafb-tng really apply to ubuntu, I think that it could be great if you add a brief explanation about that in the bug description. Thanks for this information!

I just tried Kubuntu 64 Hardy Alpha 3 and got this bug again. Booting off of the live cd with any of the default boot options results in a black screen (with monitor entering sleep mode eventually) and the system refuses to boot. I can't get into the system at all off of the live cd unless I remove 'splash' from the kernel options.

This is very unsettling, if we can't get this fixed before the 8.04, then I fear we will lose a lot of potential users (most newbies will not spend the time to learn how to fix it - they will simply give up on (K/X)Ubuntu).

I have a NVidia 8800GTS 320mb with a 22inch widescreen monitor

Let me know if/how I can help (as someone without programing skillz :S)

Pat

I think this only happens on computers with the latest nVidia GPUs (Geforce 8 series). All the people which is reporting here the bug, has an nvidia Geforce 8.
Today, I popped in a LiveCD of Ubuntu 7.10 (64 bit) on a laptop with an ATI Radeon HD 2600, and it starts flawlessly. No "nosplash" hack. The laptop is a Toshiba Satellite Pro P200 18T (Serial Number: PSPB7E-00Q00HCE).

So I think that Saïvann Carignan is right, the problem should be in linux-restricted-modules.

Why should it be in linux restricted modules? This bug happens without using
any restricted modules at all.

Yep, you are right Tom, hehe.

I sended a mail to the ubuntu-devel mailing list and a ubuntu developers answered that we're not using vesafb and we have not for quite a while. So the Fabio Papa suggestion does not seem to be a solution. It also confirm the fact that this bug only happens with Geforce 8xxx because one developer has a Geforce 7600GS and doesn't have this problem with 64bit.

...has a Geforce 7600GS and doesn't have this problem with 64bit.

I can confirm this. I can also say that Usplash works with Nvidia, not perfect, but it works. I'm using Ubuntu Gutsy 64-bit here with a Nvidia 7600 GS graphics card. I tried the Ubuntu Desktop-CD. The boot process shows three different stages:

1) Usplash works right after booting the computer
http://pics.ubuntu-projekte.de/bild/297/1003378JPRYS.jpg

2) After a while Usplash get's a hickup
http://pics.ubuntu-projekte.de/bild/298/10033795PO2H.jpg

3) Starting the Xserver fails
http://pics.ubuntu-projekte.de/bild/299/1003380XCG35.jpg

My situation fits in with the second description Fabio Papa gives above:
"But 64 bits Ubuntu, which we are discussing here, has a completely different matter. Still a black screen, but boot time is normal."

I am running AMD64 Gutsy (clean install) with an nvidia 8600GT. Booting time is normal (very short, in fact), but I do not get a splash screen after the kernel starts loading. The monitor simply goes into power saving mode until the login screen shows. None of the 'solutions' I have found on the web have solved the problem (e.g. loading the kernel with vga=) etc. -- these seem to be solutions to an unrelated problem, as Fabio suggests.

I should mention one thing that may help someone solve this problem:

After implementing the suggestions on the web, for example setting vga=795 in /boot/grub/menu.lst and updating the resolution in usplash.conf (and doing the associated rebuild), I see one change: when I shut down the computer, no longer do I see just a blank screen immediately (even before the computer has switched off), but now I see a screen with lots of random coloured 'noise' (lots of colours filling the entire screen).

Greetings, my 2 cents.

64 bit Gutsy; alternate install; Dell 1420; 1440x900 LCD; Nvidia 8400M GS (Regular 64 bit install never reaches GDM - LCD turns off; computer hangs; no shell) (32bit version worked fine.) Agree potential new users would be turned off if not fixed.

Tried every work around. The last one I tried, Orange2K's solution fixed usplash and faster boot time. Thanks Orange2K!

http://ubuntuforums.org/showpost.php?p=3635667&postcount=9

I have recreated this issue using the Edubuntu AMD64 daily build from 20080201.1. The system I tested on has a nVidia Corporation GeForce 8300 GS with PCI ID [10de:0423]. I was unable to see any usplash output when choosing "Start or Install" and "Check CD for defects" from the CD's boot menu.

My monitor was connected via DVI. Has anyone recreated this issue with a VGA connection using a Hardy Alpha CD?

01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce 8300 GS [10de:0423] (rev a1) (prog-if 00 [VGA])

Reproduced on Hardy Alpha 4 with a VGA connection

I have this problem on Gutsy (installed, both live and alternate) and Hardy Alpha 3 (live-cd, Gnome, not installed). I am on an Acer Aspire 5520G, Geforce 8600M GS, max res: 1280x800, AMD Turion 64.

I have this problem on 7.10 using 8600M GT.
I believe the importance might need to be upgraded; when the machine decides to fsck, or if there is an error, I am left looking at a black screen for an extremely long time sometimes with no idea of what's happening or what to do to fix it, with only my guessing that it's doing a fsck from the hard disk activity light. And if there's a critical error, I probably won't know it at all.

Due to quantity of ubuntu users which has this bug and according to Chris Lockfort comment, I raise the importance to High

I completely agree, this is a massive bug, due to not knowing what's going
on when the system boots. When the machine needs to fsck, people are just
going to assume nothing is happening and cut off the power to the PC in the
middle of the check. That can be dangerous.

On Feb 6, 2008 12:37 PM, Chris Lockfort <email address hidden> wrote:

> I have this problem on 7.10 using 8600M GT.
> I believe the importance might need to be upgraded; when the machine
> decides to fsck, or if there is an error, I am left looking at a black
> screen for an extremely long time sometimes with no idea of what's happening
> or what to do to fix it, with only my guessing that it's doing a fsck from
> the hard disk activity light. And if there's a critical error, I probably
> won't know it at all.
>
> --
> [amd64 + nvidia 8xxx] usplash shows nothing
> https://bugs.launchpad.net/bugs/147623
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Even worse, in some cases like mine X doesnt even come up due this problem
(which i assume is a clash between the dodgy fb driver and the nv driver),
the only reason i ever got around it was that i knew enough to try a
nosplash boot.

I forgot to mention that the only way I was able to reach the live desktop in any 64 bit version was to use the OEM install. Otherwise screen turns off and computer hangs. (Not sure if this info. is useful or not.) I didn't realize I could try nosplash option for the live cd.

Dell 1420; 1440x900 LCD; Nvidia 8400M GS

thecure:

I have the same laptop. The easiest thing to do, until a permanent fix is made, is to simply hit F6 when the menu loads from the LiveCD, and then delete the 'splash' entry (and quiet too, if you want to see text scroll by).

The LiveCD will boot into the native screen resolution of the laptop (1440x900). You'll have to reconfigure screens and graphic cards on first boot though.

regards,

Harvey

I added a workaround in the description of the bug report that worked for me and a few persons. Can someone try that workaround and confirm if you can get usplash to work with it?

Saïvann:

Tested your workaround:

1. Modified /etc/usplash.conf (xres=1024; yres=768)
2. Modified /boot/grub/menu.lst (vga=795 and then 792)
3. Performed rest of steps

Results:

795 results in video error:

"Undefined video mode number: 31b"
"Press <ENTER> to see video modes ..."

792 results in expected usplash.

I've also successfully used vga=0x0365 and xres=1400, yres=900.

Adding fbcon to /etc/initramfs-tools/modules fixes the blank ttys bug (Bug 129910), and may confuse others trying to fix just this one.

Harvey

Harvey Muller : Thanks a lot for these informations.

Since the workaround I provided in description of the bug report can cause additional problems, I removed it and just mention vesafb. It's a better idea to keep usplash disabled than using the blacklisted vesafb framebuffer driver. However, this information is still good to know.

Harvey's workaround worked for my 1280x800 laptop (1024x768 in /boot/grub/menu.lst). His ttys workaround didn't work, though. I had to disable the splash to be able to login there.

Harvey Muller's solution worked for me as well. For the first time in months I actually saw usplash on boot!

Seems weird because I tried these exact same steps not too long ago and it didn't work. Perhaps in combination with driver updates? I did just upgrade to the latest nvidia drivers (171.05) last week, and have noticed a much more stable environment because of it. This could have had an effect on usplash.

Driver is available here; http://www.nvidia.com/object/linux_display_amd64_171.05.html

I have the same problem, and it makes my monitor to go to the power saving mode too.

I've got the same problem, infact i can't even boot of the livecd i had to install of the alternate cd. In all honesty this is a huge bug, i could imagine alot of people being put of ubuntu because the live cd not working.

here are my specs.

Samsung SpinPoint T 500GB SATA-II 16MB Cache - OEM (HD501LJ
Samsung SpinPoint T 320GB SATA-II 16MB Cache - OEM (HD321KJ)
Corsair HX 520W ATX2.2 Modular SLI Compliant PSU (CMPSU-520HXUK)
Corsair 4GB DDR2 XMS2 PC2-6400C5 TwinX (2x2GB)
Intel Core 2 Quad Pro Q6600 "Energy Efficient SLACR 95W Edition" 2.40GHz (1066FSB) - Retail
EVGA GeForce 8800 GTS "Crysis Edition" 512MB GDDR3 HDTV/Dual DVI (PCI-Express) - Retail (512-P3-E841-AE-CrysisUK)
Samsung SH-S203NRSMN 20x DVD±RW SATA Dual Layer Lightscribe ReWriter (Beige/Black/Silver) - Retail
Abit IP35 (Socket 775) PCI-Express DDR2 Motherboard
Logitech Wave Keyboard USB
Logitech MX518 Gaming mouse
Dell 22 inch Widescreen Flat Panel Display with built-in Webcam (SP2208WFP)

Me, too.

Dell Latitude D630, NVIDIA GPU Quadro NVS 135M, 1440x900 screen, amd64 Hardy Heron Alpha4 + updates to date.

The System > Administration > Screens and Graphics control currently has no nvidia driver listed as available (but it's the one that's running according to /var/log/Xorg.0.log) and doesn't list the correct screen resolution as available either (though the log has that, too).

-- rec --

Roger E Critchlow : Thanks for your comment. I see multiple bugs in your comment, I suggest that you isolate each of them and speaks of the symptoms in each appropriate bug report and (if the bug you are talking of does not exist yet) to create new bug reports. Speaking of one type of symptom for each bug report greatly helps developers to fix them. Thanks for your contribution!

Saïvann Carignan : Thank you for the mentoring.

I just checked this original problem out against the Hardy Alpha4 Livecd and discovered something even more disturbing.

As above, this is a Dell Latitude D630, NVIDIA Quadro NVS 135M (GeForce 8**** series), 1440x900 screen, amd64 Hardy Alpha4.

If I allow the default "Start or Install Ubuntu" entry to run, I get a blank screen followed by the "Ubuntu is running in low-graphics mode" dialog. This turns out to be a dead end on Alpha4 because gdm doesn't get restarted properly after the dialog finishes. So no matter how you reconfigure and test, you get no further.

If I choose the "Start in Safe Graphics Mode" option, I get a blank screen and then to the livecd desktop in 800x600 pixel resolution. This is a dead end for installing because the install windows are too tall, unresizable, and their controls are off the bottom of the screen.

If I use F4 to choose my screen's resolution, and then choose "Start or Install Ubuntu", I get a blank screen followed by the "Ubuntu is running is low-graphics mode" dialog again.

If I use F4 to choose my screen's resolution, and use F6 to erase "quiet" and "splash" from the boot options, then I get a less blank screen (it's a lighter grey than the one the splash causes) followed by a livecd desktop at 1440x900.

This is troubling because it shows that usplash doesn't just fail, its failure is causing other things to fail as well.

Roger E Critchlow Jr : That's really strange, I have to admit. Thanks for the clear informations you provided. I don't have any idea but wait for this problem to get fixed, and then see if your card still has some problems. I also suggest that you look for similar bugs with the same nvidia card on launchpad, perhaps that you can contribute to these bugs as well and group them by finding duplicates, the case of your graphic card seems to be specific so I suggest that if you find people that have the same issues, you open a separate bug report concerning the blank screen issue.

Saïvann Carignan - I experienced the same problems as Roger. Actually looks like just about everyone with a GeForce 8**** series card experienced this as evidence by all the posts in this bug.

Please ignore my last comment, I misunderstood Roger comment. Sorry.

This bug is still present for me in Hardy Alpha5.

I avoid the problems at the Live CD boot prompt by:

  Typing F6 to access the boot options,
  Typing a space to make the options visible,
  Erasing the "splash" option,
  Typing a return to launch the boot.

I confirmed Roger's observation, this bug is still present in Hardy Alpha 5. With the number of 64bit nvidia 8xxx users out there we really should fix this before the full release of Hardy, because although there are workarounds many newbies won't be bothered to go to the time, trouble, and effort to find/implement them (especially since the rival distros - suse, fedora, etc.. - don't have this problem).

If Fabio Papa is right - and it sounds like he probably is - then is there any chance of getting uvesafb into the Hardy in time to fix this problem?

If there is any way that a not-overly-technical user like myself can help, then please let me know (Unfortunately I'm underskilled and over-worked so I can't directly implement the fix myself :S)

Good luck and keep up the good work,

Pat

This problem still needs fixing in Gutsy also.

Pat_Primate wrote:
> I confirmed Roger's observation, this bug is still present in Hardy
> Alpha 5. With the number of 64bit nvidia 8xxx users out there we really
> should fix this before the full release of Hardy, because although there
> are workarounds many newbies won't be bothered to go to the time,
> trouble, and effort to find/implement them (especially since the rival
> distros - suse, fedora, etc.. - don't have this problem).
>
> If Fabio Papa is right - and it sounds like he probably is - then is
> there any chance of getting uvesafb into the Hardy in time to fix this
> problem?
>
> If there is any way that a not-overly-technical user like myself can
> help, then please let me know (Unfortunately I'm underskilled and over-
> worked so I can't directly implement the fix myself :S)
>
> Good luck and keep up the good work,
>
> Pat
>
>

This bug is actually a high bug in the qa-hardy list so I think that developers will really work hard on it, we don't need to ask for more priority, it will be better for developers if this bug contains only relevant informations about the bug itself. uvesa will probably not fix this problem since ubuntu does not use framebuffers like uvesa and vesafb/vesafb-tng. A ubuntu developer thinks that it has to do with ia32-libs.

Thanks for your feedback Saivann, I didn't know that we didn't use framebuffers (being not-too-technical and all :P). Please let us know if there is something us well-wishing non-techies can do to help :)

Keep up the good work,

Pat

In attempt to provide useful information, I downloaded both daily-live versions (amd64 and i386) 2008-02-24 of Hardy desktop and ran the following commands to obtain the information in this attachment and the next:

# sudo strace -o usplash-strace.i386 usplash -c
# sudo strace -o usplash-strace.amd64 usplash -c

I used tty1. the i386 version works, amd64 doesn't (as you already know). There are interesting differences in the output for each version, but I have a bit more learning to do before I can understand it in full.

The hardware platform this was produced on is a core2 duo with nVidia 8400M GS.

HTH,

Harvey

Output for amd64.

I did a strace on my 7.10 box. Harveys and mine are almost the same.

jake@quad:~$ diff usplash-strace_jake.amd64 usplash-strace_harvey_muller.amd64

1295c1291
< rt_sigreturn(0x2b5404320a20) = -1 EINTR (Interrupted system call)
---
> rt_sigreturn(0x7f6e801568e0) = -1 EINTR (Interrupted system call)
(repeated 380 times)

1302c1298,1299
< ioctl(0, VIDIOC_ENUM_FMT or VT_SETMODE, 0x2b5403703840) = 0
---
> ioctl(0, VIDIOC_ENUM_FMT or VT_SETMODE, 0x7f6e80b70a00) = 0
> ioctl(4, KDFONTOP, 0x7fff88d8d500) = 0

I just bought a Geforce 8600 GT card and big surprise - I ran into this bug ;-) (on Gutsy)

On my system I had only a blank screen during the boot process, after GDM startet, everythings seemed to work as usual. The following procedure gave me back the nice splash screen again (a combination of hints in this report):

- adding vga16fb, fbcon and vesafb to /etc/initramfs-tools/modules
- outcommenting the blacklistet vesafb and vga16fb in /etc/modprobe.d/blacklist-framebuffer
- adding vga=795 (1280x1024) to the kernel options in /boot/grub/menu.lst (while setting usplash resolution to the same value in /etc/usplash.conf
- sudo update-initramfs -u

Kind regards,
Jan

Uh, I have to say that I can't get to GDM. Some people here seems to get GDM started, but me not. My screen stays black forever and ever.
And in Ubuntu Hardy Heron Alpha 5 the bug is there too.

Filiprino : Thanks for this information. Can you confirm that this issue is really caused by usplash? You can know this by starting you computer with usplash disabled and look if the problem still happens. If you can reproduce the problem even when usplash is disabled, you probably have another bug. To boot with usplash disabled :

   1. Press Esc during Grub boot delay to access the boot menu.
   2.Select your actual Ubuntu boot line and press "e" to edit it.
   3.Select the "kernel" line and press "e" to edit it.
   4.At the end of the line, remove "splash" and "quiet" and press "enter".
   5.Type "b" to boot the custom boot line.

If you can reproduce the bug with usplash disabled, searching for a already posted bug or opening a new bug is a good idea.

I can also confirm the issue for Hardy, exactly the same as with Gutsy.
The solution to get the splash back I described in my previous comment does also work in Hardy.

Kind regards,
Jan

The workaround worked for me as well.

Saïvann Carignan, I can not reproduce this bug editing the "kernel" line (disabling usplash). The system starts normally. Note: I am the original reporter of usplash bug :-)
Attached to this message is a strace of usplash, amd64, on Ubuntu 7.10 (Gutsy Gibbon).

IT WORKS!!! IT WORKS!!!

The solution of Jan Rathmann works on Hardy 64bit with nVidia 8500!

1) added vga16fb, fbcon and vesafb to /etc/initramfs-tools/modules
2) outcommented the blacklisted vesafb and vga16fb in /etc/modprobe.d/blacklist-framebuffer
3) added "vga=795" (1280x1024) to the kernel options in /boot/grub/menu.lst (and "splash" option if not present)
4) modified setting usplash resolution to the same value in /etc/usplash.conf (xres=1280 and Yres=1024)
5) sudo update-initramfs -u

Now usplash wors perfectly!

Thanks Jan!

I can confirm this with current Hardy and Geforce 8800 GTS/512. Very annoying especially with the LiveCD since it takes very long to boot. Btw. the CD check doesn't work under this circumstances. It seems to have no output without splash.

The solution of Jan Rathmann almost works on Gutsy 64bit with nVidia 8600 GT.
Now, I have shell boot, it's smart ! ;)

Like Filiprino, I can confirm that I never get to GDM on the liveCD without the work around. Once I used the work around and installed to HD, GDM does come up.

I'm using a GeForce 8400 GS

Confirming this. This happens with the 64-bit version only; with 32-bit the boot splash works normally.
This happens to me on Gutsy and Hardy Alpha 6.

I fixed it in Hardy Alpha 6 by doing the following:

Edit /etc/initramfs-tools/modules, add a line: vesafb
Edit /etc/modules, add a line: vesafb
Edit /etc/modprobe.d/blacklist-framebuffer, put a # in front of the line: blacklist vesafb
Edit /etc/usplash.conf. change to: x=1024, y=768
In /boot/grub/menu.lst, add vga=773 to the kernel boot line (for 1024x768, 8 bit per pixel)

Run: sudo update-initramfs -u -k all

Forgot to mention my hardware: Intel Core 2 Duo E6600, nVidia 8600 GTS.

Has anyone run into a "stability" problem with un-commenting vesafb? I don't believe I have since I started using it early in Feb. Apparently that's what's keeping the hack from being implemented. 64 bit Hardy, 8400 card

http://ubuntuforums.org/showpost.php?p=3635667&postcount=9

No problems here, i can switch between xorg running nvidia binary driver,
and my terminals without problem. Never had any problemswith usplash booting
up/shutting down either. The only thing that i havent tried would be
suspend, as this is on a big honking workstation rather than a laptop.

After two weeks with this workaround I also did not run into any problem so far (on Gutsy). TTYs and suspend to disk are working as usual (the TTYs have a higher resolution now of course).
On Hardy I could not test suspend to disk so far but I quickly checked that TTYs seem to work as expected.

Kind regards,
Jan

Forget my last comment. I see the problems with vesafb, especially with TV out. It seems as though uvesafb corrects the problems inherent in vesafb. On a side note I have no problem with TV out except small text is unreadable with such low resolution.

In Hardy with all current updates the mentioned workaround doesn't work flawless anymore. At the first stage of the boot process where the progress bar of the splash screen goes back and forth between left and right everything seems as usual. But when the progress bar normally would change to the "report boot progress mode" (I don't know how to describe it better ;) ) the entire splash screen disappears and only a blinking text cursor is shown which changes it's screen position wildly during the continueing boot process. The start of the X-server works but all TTYs show likewise only a blinking cursor but nothing else (allthough they seem to work, if I do a "blind" login, the cursor changes it's position as it would do when text would be displayed). I have not found a way to get the splash working properly so far.

Kind regards,
Jan

Just want to change my statement earlier about the vesafb workaround, as of
the latest kernel my ttys are all blank except for the blinking cursor.

There was a regression introduced in the initramfs-tools package regarding vesafb introduced some time in the past week, this should be fixed in initramfs-tools 0.85eubuntu34. You should be able to get ttys working again using the update-initramfs command and rebooting.

On my side nothing has changed yet.

On Wed, Mar 19, 2008 at 5:27 AM, Steve Langasek <
<email address hidden>> wrote:

> There was a regression introduced in the initramfs-tools package
> regarding vesafb introduced some time in the past week, this should be
> fixed in initramfs-tools 0.85eubuntu34. You should be able to get ttys
> working again using the update-initramfs command and rebooting.
>
> --
> [amd64 + nvidia 8xxx] usplash shows nothing
> https://bugs.launchpad.net/bugs/147623
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Same for me, I still haven't found any way in Hardy to get the splash screen working properly again.

TTYs are working when I don't change the default setup which means no splash at all is shown. If I apply the workaround described above that worked in Gutsy, TTYs are still blank and still only the first stage of the splash screen is working.

Kind regards,
Jan

I have the same problem here on the latest hardy-desktop-amd64 image. I have a 8800GT and Core2 Duo E8400. The systems loads just fine, but usplash just makes the screen say no signal and go into power saving mode (it goes back to normal once I wait long enough for the system to load).

There's a lot of noise in the bug from the metoos, so this will probably get lost in the noise, but I'd like point out one way in which this bug has a very negative impact on user experience. If a user sets up drive encryption through the installer, they are asked for a password on bootup. If you are using usplash, and usplash fails to display, then the user has no indication that they should type in their password. I verified that I can just wait a few seconds and type my password even though I can't see the screen, but that's not the ideal experience, nor the obvious response. I can get around it by running a 32 bit OS or by disabling usplash.

Hopefully the fact that this bug is high priority will mean that it gets fixed, but just in case, I wanted to make sure the developers were aware of this additional negative impact and encourage that this get fixed in some manner, even disabling usplash if encryption is selected, before the hardy release. Given the increase in popularity of disk encryption and 64 bit, I think this is likely to pop up a great deal if it isn't fixed.

It seems to me that this is not usplash bug. When I add change splash option to nosplash I get text output, but when I add "vga=795" it shows nothing. It could be framebuffer bug.

I can also confirm this with Hardy Beta on my T61 (Nvidia Quadro NVS 140m).
This happens with the 64-bit version only; with 32-bit the boot splash works normally.

Confirmed, Hardy Beta x64, clean install, nvidia 8600gt, with open source driver and propietary driver alike.

Me too. Ubuntu 8.04 (Hardy Heron) Beta Release LiveCD session AMD64. The bug is still present...

My hardware (stated at the first posts of this bug report):
CPU: Core 2 Quad Q6600
Memory: 4GB RAM
VGA: 8800GTS 320MB
Motherboard: Asus Commando.
Monitor: Philips 200WS (TFT-LCD 20.1", 1680x1050, using DVI connector).

Core2duo T7500
4gB RAM
Nvidia 8400gs

and the bug too with AMD64

Thanks everyone for keeping active on this bug report. Since this bug is confirmed with recent nvidia cards since a while, please don't add additional comments unless you can provide new technical informations that can help the bug getting fixed. Reducing noise in this bug report will probably help developers to find relevant informations inside it and fix this bug faster.

libx86 (0.99-1.2ubuntu3) hardy; urgency=low

  * Add xorg upstream fixes for cpuid, rdtsc, bsr, bsf opcodes, from upstream
    http://gitweb.freedesktop.org/?p=xorg/xserver.git (LP: #147623).
    - 66fa87292ef26bd0f464481287f3af992cd5741c
    - c4b7e9d1c16797c3e4b1200b40aceab5696a7fb8
    - 2fe74ef339c3a4902ae8214f5a0454662895422c
    - 66f8001b61d12eaf4905ac71ccbb3f304914d00d

This was a bug in x86emu code (amd64) in libx86, which is what usplash uses to do video BIOS calls. Many thanks to mjg59 for explaining to me how everything hangs together. :)

Kees Cook : MANY thanks to you and Matthew Garrett! Great work!

Now writing from the latest daily build. The fix works. Good job.
Nice to see free software development model works great =)

Kees, mjg59, and the rest,

Thanks for your efforts in resolving this. It improves the Core2Duo amd64 experience.

Harvey

On my system this seems to be not completely fixed. I have done a fresh installation with daily-live image 20080322, booting the live CD works fine, but when I boot the installed system, I get the splash screen only during the first boot stage (when the progress bar goes from left to right and vice versa), at the second stage of the boot process only text output is shown, same as if I would boot without the 'splash'-option in /boot/grub/menu.lst . TTYs are working fine. I could try to make a video of my system during boot if that would help.

Nevertheless I would also like to say huge thanks to all people fixing this issue!

Kind regards,
Jan

Thanks ! Where can we get the fix :D ?

When a bug is set to fix released, it means that a update has been released that fix this problem. All you have to do is to update your computer. This bug is fixed in Hardy with libx86 (0.99-1.2ubuntu3). It will probably don't get fixed in Gutsy

I updated my system completely, and I get usplash ONLY when shutting down, not when booting up. I don't get TTY's, nothing, just a blank screen when starting up.

Also, I'm confused why this won't be fixed in Gutsy, by not fixing it in Gutsy you'd be ending the eighteen month support cycle VERY early.

I also verified that I do have the package that you mentioned installed.

On Sat, Mar 22, 2008 at 07:05:33PM -0000, Jeremy LaCroix wrote:
> I also verified that I do have the package that you mentioned installed.

You may need to run "sudo update-initramfs -u" to see the changes happen
during boot-time.

As for Gutsy, this may not be valid for a Stable Release Update. (Also
note that it never worked in Gutsy.)

I just made a fresh install of the daily build 20080322 and it works without any problems. No black screens, no text scrolling on it, just the progress bar, as it should be.

confirmed-fixed Dell 1420; 1440x900 LCD; Nvidia 8400M GS

Great Job!

I ran "sudo update-initramfs -u" and it's fixed now. :)

Kees Cook wrote:
> On Sat, Mar 22, 2008 at 07:05:33PM -0000, Jeremy LaCroix wrote:
>
>> I also verified that I do have the package that you mentioned installed.
>>
>
> You may need to run "sudo update-initramfs -u" to see the changes happen
> during boot-time.
>
> As for Gutsy, this may not be valid for a Stable Release Update. (Also
> note that it never worked in Gutsy.)
>
>

wooooo!

that's the first time i've seen that screen on this PC - and i've had it for almost a year.....

Thanks!!!

Forget my last comment, the cause for the abnormal boot behaviour of my system was that I had messed up boot options in /boot/grub/menu.lst.

To boot my system I am using grub from my Gutsy installation and thus the menu.lst doesn't get rewritten if I install Hardy. Some time ago I had added 'resume=/var/cache/swapfile' to the kernel line of the Hardy entry and it just remained there allthough I had never recreated the swap file in later installations. I never thought this was a problem, but if I remove this option, Hardy is booting just fine.

So everything is working now for me, sorry for the noise.

Kind regards,
Jan

Hello,

I still have the same problem at boot, but the exact message is :

Undefined video mode number: 312

I have Ubuntu Hardy beta with all the updates done, an AMD dual Core X2 6400+ and as graphic card ATI Radeon X1950 Pro

I "just" have to click on space button to continue booting, I did not try the solutions listed above as I do not have a Nvidia, I do not know if bug should be fixed or not...

Best regards,

Xavier

On Fri, Mar 28, 2008 at 10:00:11PM -0000, Valeryan_24 wrote:
> I still have the same problem at boot, but the exact message is :
> Undefined video mode number: 312

Please open a new bug report for the problem you're seeing. The
original libx86 missing-opcodes bug (this one) is already fixed.
Thanks!

Hello,

In my case it was not a bug, thanks to Saïvann I could correct the problem :

I had the comment "vga=786" in my file /boot/grub/menu.lst

I removed it and there is no more message at boot.

So no report needed for this.

Best regards.

HOWTO: end user fix in Gutsy without upgrading to Hardy

---8<---
sudo apt-get install fakeroot build-essential
sudo apt-get build-dep libx86-1
wget http://archive.ubuntu.com/ubuntu/pool/main/libx/libx86/libx86_0.99-1.2ubuntu3.dsc
wget http://archive.ubuntu.com/ubuntu/pool/main/libx/libx86/libx86_0.99-1.2ubuntu3.tar.gz
tar xzvf libx86_0.99-1.2ubuntu3.tar.gz
cd libx86-0.99
fakeroot deb-buildpackage
cd ..
sudo dpkg -i libx86-1_0.99-1.2ubuntu3_amd64.deb
sudo update-initramfs -u
---8<---

I know Hardy is less than a month away, but the same source code for it works in Gutsy without modification, so I can not understand why the bug has got "status: declined". It is an actual bug, not a new feature, and it was reported in Gutsy beta six months ago.

This happens also on 32 bit intel.

I have two graphic cards.
One is nVidia 6600
Other is nVidia 8600GT

The 6600 works with usplash
THe 8600 does not work with usplash. It does work with X though.

THis is on a 7.10 xubuntu install.

Also, I noticed I don't have my text consoles when using the 8600.
When removing the 8600, and using the 6600, my text consoles and usplash work.

  Bram

I recently upgraded to the Hardy Beta. I still had this trouble at first. But I then installed the proprietary drivers as well as all the other updates available and now my usplash is working great! This is now solved for me!!!

Does also work the text terminals (tty1-6)?

I didn't have this issue with 8.04.1 at all on my 8800GTS

I have same problems with ASUS MSN-MX SE PLUS motherboard.
Same hardware on 2 pc's, on one is Ubuntu 7.10 Hardy, on another Ubuntu 8.04
Several times problems with a Nvidia GeForce 6150 SE , blank screen, manual changing of resolution did help.
Apparently, there is a release of new Nvidia VGA driver, maybe life will get better.

Now, Nvidia nforce Network card controller isn't working on the both machines (Ubuntu 7.10 and Ubuntu 8.04).
Tip with nosplash, or removing quite option during the boot didn't help.

Seems that this hardware is of trash quality.
I don't know any list of recommended hardware by Ubuntu, this would help, because, I'll need several more PC's for company that I'm working for.

Ubuntu 7.10 is Gutsy, not Hardy and Gutsy isn't supported anymore for as
far as I know.
It is also not the fault of the graphics card but a combination of all
sorts of issues on quite a few sides, I did some kind of workaround to
fix this but I don't remember it (I'm on hardy now and planning to
migrate to jaunty soon).

The nvidia nforce chipset has nothing to do with the bug, it's just the
graphics card. Also, my nforce ethernet works just fine, no special
configuration required, it works fine with the forcedeth drivers that
are builtin. I guess upgrading might be a good idea.

Also, I'm not sure whether the 6000series need the new or the legacy
nvidia drivers from the repo.

I clearly want to state that nvidia hardware is not trash, I personally
consider it as very good hardware.
On linux drivers it's usually something like this if we're talking just
about graphics:
intel > nvidia > ati (not talking about Via and other, smaller players).

About the recommended hardware: https://wiki.ubuntu.com/HardwareSupport/

Frank schreef:
> I have same problems with ASUS MSN-MX SE PLUS motherboard.
> Same hardware on 2 pc's, on one is Ubuntu 7.10 Hardy, on another Ubuntu 8.04
> Several times problems with a Nvidia GeForce 6150 SE , blank screen, manual changing of resolution did help.
> Apparently, there is a release of new Nvidia VGA driver, maybe life will get better.
>
> Now, Nvidia nforce Network card controller isn't working on the both machines (Ubuntu 7.10 and Ubuntu 8.04).
> Tip with nosplash, or removing quite option during the boot didn't help.
>
> Seems that this hardware is of trash quality.
> I don't know any list of recommended hardware by Ubuntu, this would help, because, I'll need several more PC's for company that I'm working for.
>
>

--
Bert Van de Poel
webdeveloper and administrator
bhack.net and rpgfamilie.net