Feisty crashes after grub, before boot process, if usplash is enabled (amd64)

[Timo Jyrinki]

Filing this under libx86, since this broke when that package came in, and I'm just guessing it has something to do with it. Feel free to reassign to usplash if needed.

If starting up feisty with a normal boot line, ie. splash enabled, as soon as the splash screen should show up monitor just shuts down and a complete hang follows immediately - sysrq keys do not function either. Booting x86 version on the same machine works with splash screen, and booting with "splash" removed works okay.

I've been seeing this on this feisty installation since libx86 came, and also now tried to boot from the amd64 (and x86, which works) Herd 4 live-CD. Didn't found any existing bug repot about this, so I'd very much guess it has something to with my nice buggy ATI motherboard (with which pre-dapper clock ticked twice too much without special options, and 2.6.20 had a "cleanup" patch until rc5 that made it happen again).

[C de-Avillez (hggdh2)]

Can you please state the version of libx86 you are running?

Also, what is the content of /etc/usplash.conf?

[Timo Jyrinki (timo-jyrinki)]

Version 0.99-1.2, ie. the newest. Contents of the /etc/usplash.conf are what they are in the Herd-4 CD when booting from that, and as follows on the installed feisty:
# Usplash configuration file
xres=1024
yres=768

[Javier Martin (Habbit) (habbit)]

I don't think it has to be your motherboard failing: I have a perfectly healthy Gigabyte board and also suffer from this bug when booting in amd64 feisty. Haven't tried the x86 version though.

[C de-Avillez (hggdh2)]

Timo, I see you have an ATI video board, but I do not see any references to a framebuffer device, nor to extended VGA settings -- in fact, your VGA is set to 80x25.

Can you try with a lower usplash setting (xres=640, yres=480) and see if it works?

[Timo Jyrinki (timo-jyrinki)]

Habbit: My motherboard is not failing, it is known that all the ATI RS480/RS482 motherboards are buggy... people are basically being sold (partially) broken hardware, something that is quite common these days. Such hardware needs various workarounds to function properly, often done in eg. Windows drivers.

hggdh: I don't really understand - it's naturally in a text mode, since if I leave the "splash" parameter in the boot line, the computer hangs completely, monitor shuts down and I can't get any output. I now tried using lower usplash settings, but it didn't change naything.

[C de-Avillez (hggdh2)]

Yes, I understand that. What seems to be going on with your computer is you are getting hit by a hard crash during boot, as it seems as soon as usplash gets called -- and, most probably, the interrupt handler died (and, as a result, not even sysrq will work).

This is a hard one to crack. We do not have much data to go on, so pretty much all we can do is trying different options, on the hope of nailing the issue to one point.

usplash deals with the video; given that you are not using framebuffer, trying with a lower usplash resolution was worth a try.

It may be related to libx86; I do not know, and I do not know much on what it does, but it is is quite possible it has something to do with the video modes.

[Javier Martin (Habbit) (habbit)]

Did I mention that as soon as the monitor enters shutdown state, the caps lock key starts blinking? Maybe it's some kind of kernel "death message"

[C de-Avillez (hggdh2)]

indeed, this is a sign of a kernel hard crash -- your kernel died and, just before giving up the ghost, tried to give you an indication is was going down.

And... this, again, makes it much more difficult, since we do not know what happened. It would probably have been written to the console, but we do not seem to have access to it. Perhaps an option would be to send the console output to a serial -- and then we would know where it died.

Habbit -- can you add in here the lspci -vv, lspci -nvv, dmesg of a good startup and the boot log (whatever was saved) of a bad one? We can try to find out what is similar in your environment with Timo's one.

[Javier Martin (Habbit) (habbit)]

Maybe the problem is the video card itself? I didn't think that could bring down the whole kernel, but I've noticed we both have a R480-based ATI video card (I have an X850XT). I'll post the requested data ASA I boot into Feisty - I'm currently in windoze due to some... game :P

[Javier Martin (Habbit) (habbit)]

I have a laptop w/edgy and some serial cables... How can I send the console output to the serial port and capture it in my laptop?

[Timo Jyrinki (timo-jyrinki)]

I haven't done it myself, and information on the net is scarce. I found out that following could be added to /boot/grub/menu.lst:
# Setup serial (COM1) here with baudrate 9600
# use --unit=1 (for COM2) and so on
serial --unit=0 --speed=9600

# Now setup terminal as both Serial Line(/dev/ttyS0) and
# Monitor Console(/dev/tty0) depending upon where you press key
# with in timeout (15 sec) period. Otherwise first entry
# (console(Monitor)=>tty0) is selected here.
terminal --timeout=15 console serial

Then a boot line something like:
kernel /boot/vmlinuz-2.6.17-11-386 ro root=/dev/sda3 console=ttyS0 console=tty0

Found from Google cache with search terms 'serial console boot kernel', and the instructions were for the 2.4 kernel.

With the laptop connected to the feisty computer, you should run something like minicom to listen to the serial port (though if you haven't used it before, the user interface is quite terrible).

Here's some newer tutorial: http://www.howtoforge.com/setting_up_a_serial_console

[C de-Avillez (hggdh2)]

an additional comment here: usplash 0.4-43 (current level) has corrected some memory manipulation errors that, by the maintainer, would cause all sorts of unpredictable problems.

Please upgrade to this version (if not already done), and please try again.

[Timo Jyrinki (timo-jyrinki)]

0.4-43 doesn't help, and I've been using it for many weeks already. I now also downloaded the latest daily-live amd64, and the problem is still there.

[C de-Avillez (hggdh2)]

we have had other bugs on usplash failing, at varying places. Unfortunately, so far, none of the stack traces are not complete (i.e. no debugging information). Also, all of them are on a i386 architecture.

You two are the only I have seen so far with x86_64. The problems *might* be related -- I do not know --, so I am hoping we can grab a good backtrace from one of them and work on it.

I have been unable to reproduce it on my machines (all x86_64), so if one of you were able to get the console output... this would really help.

[Javier Martin (Habbit) (habbit)]

Since my last post I have been trying to obtain such a console output, and trying a "normal boot" everytime usplash gets updated -- with the same results: computer hangs and caps lock blinks. I can't post a boot log because nothing seems to be written to any file in /var/log/ when usplash crashes (not even the kernel log). Also, I have found that serial cables are not homosexual, so my I guess the only way out is a visit to my local computer shop u_u.

[Javier Martin (Habbit) (habbit)]

Just some thoughts: both Timo and I have a R480-based video card. How does usplash do all the rendering? Directly with its own VGA driver or through the kernel framebuffer? If it's through the kernel FB, how can I activate the it without running usplash? - to check which of them is defective. And last, wouldn't it be possible to force the kernel FB driver (if it indeed is the failing component, as I suspect) to use the most-compatible-and-basic VGA driver? How?

Cheers and BIG THX to everyone working to make Ubuntu possible!

[stuartmarsden (stuartmarsden)]

I am experiencing the exact same problem when booting with splash on my amd64 box.

If I remove splash no problem otherwise it freezes with blinking caps lock light.

Was working fine on edgy prior to upgrade.

[C de-Avillez (hggdh2)]

Unfortunately, until we can find out what goes wrong here, there is not much we can do.

This specific bug seems to affect only ADM64s with a kernel panic. I am hoping that bug # 88915 resolution will also solve this problem.

[C de-Avillez (hggdh2)]

A question for you three (Timo, Habbit, and stuartmarsden): Do you have framebuffer enabled with VGA extended resolution (thanks Habbit for remembering)?

Look at your Grub configuration (/boot/grub/menu.lst; see if there is a 'VGA=' in the definitions; the 'defoptions line is a good candidate, but please report the other places as well. For the record, this is what mine says:

# defoptions=splash pci=assign-busses vga=792, and on each bootable kernel:

kernel /vmlinuz-2.6.20-10-generic root=UUID=a152bcaa-2553-464e-b2c4-023fce8dc5ed ro splash pci=assign-busses vga=792

So I am using 1024x768 resolution for the console.

[Timo Jyrinki (timo-jyrinki)]

No, it's not enabled, I have "/boot/vmlinuz-2.6.20-10-generic root=UUID=008801fe-8fa8-47d2-ae6d-ffc30a509bc0 ro quiet splash locale=fi_FI". Also remember that I have also tried to boot from many daily-live CDs (http://cdimage.ubuntu.com/daily-live/), which always have the default configuration.

But now we are getting somewhere: if I _do_ specify the vga=792, it does not hang! Ie. I get a splash screen, though the logo itself is smaller than full screen and in the top left corner (don't know if that's unusual or not with the vga=792 setting).

So what is the default that is used, and why is it hanging our machines totally? I guess that's the question.

[C de-Avillez (hggdh2)]

YES! We are getting somewhere -- exactly where I do not know, but anyway... some other place looks better than being stuck where we were so far :-)

Timo, please verify /etc/usplash.cfg -- does it match the resolution you passed on the bootparm?

On my system, with vga=792 on bootparm *and* usplash.cfg set to 1024x768, the splash is full screen (but oh so very slightly skewed).

This still looks like a usplash thingie.

[Timo Jyrinki (timo-jyrinki)]

Also working vga=786 (640x480 / 24-bit, with the little fault this time that the progress bar is not correctly centered).

Now also tested 769 (640x480/8-bit), 775 (1280x1024/8-bit), 784 (640x480/15-bit), 791 (1024x768/16-bit), 789 (800x600/24-bit), 792 (1024x768/24-bit) and 795 (1280x1024/24-bit), and aside from the centerization issue of the progress bar, all work. So setting any of these vga=NNN settings seems to correct this for me.

I answered the usplash.conf issue earlier already, ie. it was set at the default xres=1024 / yres=768. Regardless of what I put there, the usplash hangs without setting some vga= -thing.

Are the developers sure this is not related to any of the hacks that were made during late Ubuntu 6.10 development on the amd64 platform that resulted with that low-resolution, grey thing from the past on the amd64 platform? Could it be by default eg. forcing 640x400 that was at some point discussed, is it the thing causing problems, or what?

(saved the text, booted one more time). Answering to myself: no, also vga=768 works, which is 640x400/8-bit. So using any vga=NNN parameter fixes the issue, but by default Feisty crashes hard each and every time.

[stuartmarsden (stuartmarsden)]

Adding vga=792 to my kernel stops the panic and I get the splash.

Unfortunately at the end of the boot when loading kdm it stuck but I believe
this has more to do with the fglrx driver that I am trying to get
configured. Strangely when I leave splash off and do not set vga X starts
fine. I will have to try a few more boots and look at the logs to determine
if they are linked.

Thanks for the info. Hope this can be fixed prior to final release.

On 13/03/07, Timo Jyrinki <email address hidden> wrote:
>
> Also working vga=786 (640x480 / 24-bit, with the little fault this time
> that the progress bar is not correctly centered).
>
> Now also tested 769 (640x480/8-bit), 775 (1280x1024/8-bit), 784
> (640x480/15-bit), 791 (1024x768/16-bit), 789 (800x600/24-bit), 792
> (1024x768/24-bit) and 795 (1280x1024/24-bit), and aside from the
> centerization issue of the progress bar, all work. So setting any of
> these vga=NNN settings seems to correct this for me.
>
> I answered the usplash.conf issue earlier already, ie. it was set at the
> default xres=1024 / yres=768. Regardless of what I put there, the
> usplash hangs without setting some vga= -thing.
>
> Are the developers sure this is not related to any of the hacks that
> were made during late Ubuntu 6.10 development on the amd64 platform that
> resulted with that low-resolution, grey thing from the past on the amd64
> platform? Could it be by default eg. forcing 640x400 that was at some
> point discussed, is it the thing causing problems, or what?
>
> (saved the text, booted one more time). Answering to myself: no, also
> vga=768 works, which is 640x400/8-bit. So using any vga=NNN parameter
> fixes the issue, but by default Feisty crashes hard each and every time.
>
> --
> Feisty crashes after grub if usplash enabled (amd64)
> https://launchpad.net/bugs/86666
>

[C de-Avillez (hggdh2)]

I will try it here as soon as I get home.

The problem with different resolutions was fixed a few ago (Herd2 time?) and should now work.

So. It seems we need a vga bootparm. I *think* I did test it on my laptop, but I may be confused -- looks like I have draw a prize in the form of a migrane, at least not strong so far.

Right now, no matter what, I am setting this as high importance, but I really would like to know what Habbit and stuartmarsden experience: I still cannot reproduce it here...

Questions:

(1) why didn't you get a vga setting on installing (neither did I, on the three AMD64 I set to feisty)?

(2) why is it that usplash seems to suffer if no vga bootsplash?

[C de-Avillez (hggdh2)]

usplash seems to misbehave on some AMD64, so I am upping importance

[Cesare Tirabassi (norsetto)]

I think this is the same issue as #90661?

[C de-Avillez (hggdh2)]

yes, it seems like its the same issue. BTW, I took out the vga bootparm from my grub setup, and still I booted OK. So... no matter what, I still cannot reproduce this one.

[C de-Avillez (hggdh2)]

still open questions:

1. why didn't any of us get a vga bootparm when we installed feisty?

2. would it still happen on Herd5 or the daily?

3. What is common between all of you?

Cesare has two cards:
01:00.0 VGA compatible controller: ATI Technologies Inc R420 JP [Radeon X800XT] (prog-if 00 [VGA])
01:00.1 Display controller: ATI Technologies Inc R420 [X800XT-PE] (Secondary)

Timo has two cards:
01:00.0 VGA compatible controller: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (prog-if 00 [VGA])
01:00.1 Display controller: ATI Technologies Inc R480 [Radeon X800 GTO (PCIE)] (Secondary)

On my side, its a single video card (also ATI):
01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon Mobility X600] (prog-if 00 [VGA])

Habbit & stuartmarsden: can you please attach here a 'sudo lspci -vv'?

[Timo Jyrinki (timo-jyrinki)]

> 1. why didn't any of us get a vga bootparm when we installed feisty?

I don't think vga bootparm is ever set for default installations, ie. people sometimes like to set that themselves.

> 2. would it still happen on Herd5 or the daily?

I've tested both herd5 and many dailies.

> Cesare has two cards:
> Timo has two cards:

No, we both have a single X800 card, it's usual that graphics cards report themselves that way, I think it was something done because of Windows 2000 dual head support or something.

[stuartmarsden (stuartmarsden)]

Ati seems to be common I have a single x800 PRO

lspci output is attached

On 14/03/07, hggdh <email address hidden> wrote:
>
> still open questions:
>
> 1. why didn't any of us get a vga bootparm when we installed feisty?
>
> 2. would it still happen on Herd5 or the daily?
>
> 3. What is common between all of you?
>
> Cesare has two cards:
> 01:00.0 VGA compatible controller: ATI Technologies Inc R420 JP [Radeon
> X800XT] (prog-if 00 [VGA])
> 01:00.1 Display controller: ATI Technologies Inc R420 [X800XT-PE]
> (Secondary)
>
> Timo has two cards:
> 01:00.0 VGA compatible controller: ATI Technologies Inc R480 [Radeon X800
> GTO (PCIE)] (prog-if 00 [VGA])
> 01:00.1 Display controller: ATI Technologies Inc R480 [Radeon X800 GTO
> (PCIE)] (Secondary)
>
> On my side, its a single video card (also ATI):
> 01:00.0 VGA compatible controller: ATI Technologies Inc M24 1P [Radeon
> Mobility X600] (prog-if 00 [VGA])
>
> Habbit & stuartmarsden: can you please attach here a 'sudo lspci -vv'?
>
> --
> Feisty crashes after grub if usplash enabled (amd64)
> https://launchpad.net/bugs/86666
>

[Cesare Tirabassi (norsetto)]

Could this be a VESA probing issue? Perhaps some ATI cards do not implement the VESA 2.0 spec. correctly......

Re. the bootparm, I noted that in edgy vga=normal was used. This doesn't work in feisty. I have not yet tried vga=ask.

[stuartmarsden (stuartmarsden)]

sorry thought I could send attachments by reply on email

[C de-Avillez (hggdh2)]

@Timo -- thanks for the clarification.

Still, they are reported as two cards... and what we are looking for here is commonality: something (well, perhaps somethingS) among all of you is causing the hard crash.

And, so far, all I can find is this. BTW, Cesare also has his video card reported as two:
01:00.0 VGA compatible controller: ATI Technologies Inc R420 JI [Radeon X800PRO] (prog-if 00 [VGA])
01:00.1 Display controller: ATI Technologies Inc R420 [Radeon X800 PRO/GTO] (Secondary)

I think it is high time a developer/maintainer looks at this bug. Setting importance high, and confirming the bug.

[C de-Avillez (hggdh2)]

@Timo -- perhaps we should propose this one for Feisty?

[Cesare Tirabassi (norsetto)]

It seems we all also have and AMD-64.
I tried vga=ask, and no matter what I choose (with or without scan) there is a kernel panic.
I suspect it is not a problem from video.S but with vesafb.c (I see some changes have been made in 2.6.20).
I'll keep investigating .....

[Matthew Garrett (mjg59)]

Ok. Could you all please confirm that this doesn't happen on i386 live CDs?

[Matthew Garrett (mjg59)]

And just for some explanation - usplash accesses your video card directly through calls to the video BIOS. On x86, it can run the code directly in vm86 mode. Since amd64 systems running in 64 bit mode can't use the vm86 instruction, the code is run through an emulator instead.

If you're getting a flashing caps lock light, that indicates that the kernel has crashed. This is obviously slightly confusing, since usplash on amd64 doesn't use the kernel for anything. It's quite possible that a bug in the x86 emulator used is causing it to write over kernel memory, but this would be quite odd behaviour.

In any case, I'll see if I can determine a test case for this that will give us some more feedback. For further clarification - is there anybody with this bug who does not have an ATI graphics card? Given the lspci output, it's clearly not related to the motherboard chipset.

Finally, if you could let me know precisely which manufacturer and model of graphics card you have, that would be helpful. This could be linked to a specific vendor BIOS.

[mattegeniet (mattegeniet)]

The same thing occurs to me. After selecting what I want to start in GRUB, i get a sign on my screen saying "No signal detected". I don't get any LED's on my keyboard blinking though...

Starting in recovery mode and then startx works fine. Just adding a vga=791 or vga=794 gets me a splsh screen, but then it hangs when it's done and is supposed to show the login-screen. If I remove the splash setting and the VGA setting, then it works fine, but if remove splash from the command line but keeps the VGA= setting, then it will hang again after when it's done loading and is about to show the login screen.

The problem seems to be in usplash, because it works for everyone when the splash command is removed from the bootup-line. And at least for some other people it still hangs with the vga=-setting. But for me it also hangs when not using splash, but using the VGA=-setting (the text get's smaller but hangs when loading is done, and screen shows no signal message), so maybe it isn't a bug in usplash after all?

Notable is also that, when I inactivate the splash setting, I get the same kind of error when trying to log out from my account ( as mentioned by some people earlier)...

As almost everybody else I use an AMD 64 with the amd64-version of ubuntu, a x850XT from ATI (using fglrx driver) and version 7.04 BTW.

Tell me if you'd like some log of any kind from me.

[mattegeniet (mattegeniet)]

Tried to install from the i386 live-CD today, and it seems to work flawlessly! The splash screen works perfectly, no hangups, and I can even log out, thus using the fglrx driver. So it's pretty obvious it has something to do with the amd64 version. Worth a note is that it didn't work for me in edgy either, thus using the i386 version.

[fergatron (aaronandshag)]

Hello there, I am having the same issues with the same specs.

As almost everybody else I use an AMD 64 with the amd64-version of ubuntu, a x850XT from ATI (using fglrx driver) and version 7.04 BTW.

Tell me if you'd like some log of any kind from me.

I try to boot from grub generic boot and I get the system hang as well. If there's any fix for this anytime soon let us all know! or at least what I need to do to bypass it so I can turn on my system and not need to do recovery mode every time.

[esion (esion99)]

You can start your system in standard mode with usplash disabled :

$ sudo gedit /boot/grub/menu.lst

#remove "splash" from the line you want to start, for example :

title Festy Fawn
root (hd1,1)
kernel /boot/vmlinuz root=/dev/hdd2 ro

[Sitsofe Wheeler (sitsofe)]

What is this bug about? Is this bug about starting up an AMD64 system with an ATI card and then being unable to ever get to X (even vesa X) because the kernel crashed? Or is it about the previous problem AND starting up an AMD64 system with an ATI/NVIDIA card and not seeing usplash/progress output but after waiting the appropriate amount of time X starts as normal (i.e. no kernel crash)?

[Timo Jyrinki (timo-jyrinki)]

Like the title says, this is about "Feisty crashes after grub if usplash enabled (amd64)". This has nothing to do with X.org, or problems with X.org drivers, or non-amd64 machines. It seems it's limited to ATI's R420/R423 cards (X800-series), though there was a mention about nvidia GeForce Go 6100 + 32-bit but indeed it might good to have a different bug for it.

The known workarounds include removing the "splash" parameter from the kernel boot line, or adding, for example, "vga=792" parameter with which you don't need to be without splash screen either.

Please do not add further comments unless you have eg. a patch which fixes the problem, or some new information about this specific problem that is not covered in the tens of earlier messages.

[H_Plow (brtdth)]

Hi there!

Some news:

I've also tried "splashy" on my PC but it doesn't work too...wehn trying to set a "splash" it says me [FAIL]....

As suggested by a friend, I've tried to start from a "vanilla kernel" (2.6.21) and applied the patch for bootsplash (www.bootsplash.org).

Very important before to compile the kernel is to set in .config file the VESA framebuffer support for the console.

Result was:

Bootsplash not working too...but now I can visualize the original Usplash from Ubuntu....the only problem is that now I've some "run-level" problem...
When booting I can see the Usplash for a few seconds (progress bar not completing the forwarding..) and after that a message saying cannot find /etc/inittab, and only the CTRL+ALT+F7 console works... (CTRL+ALT+F1...F6 doesn't work....such as CTRL+ALT+DEL...)

Looking all around on the net I've read that Ubuntu (starting from 6.10) doesn't use "/etc/inittab" any longer.....but now "/etc/init.d" folder.....
I still didn't managed how to fix that, but I hope what happened to me can be usefull to someone.....

[C de-Avillez (hggdh2)]

setting to Triaged per new rules. We now need maintainer input to go further.

[Timo Jyrinki (timo-jyrinki)]

Is Matthew Garret or someone else potentially understanding the issue trying to get a look at this for gutsy? Btw, I found out that you can get the ROM file from the /sys, so attached is the rom file for Sapphire X800 GTO.

[Timo Jyrinki (timo-jyrinki)]

Tested with http://cdimage.ubuntu.com/daily-live/20070818/gutsy-desktop-amd64.iso , still totally crashes right after boot menu as usual. Pressing any key blinks Numlock light on my keyboard, nothing else works.

[Matthew Garrett (mjg59)]

Ok. Could someone with one of the affected X800s please do the following:

1) Boot without splash and without vga=
2) Switch to a text console
3) run vbetool vbemode set 0x118

Does that cause the same crash?

[Timo Jyrinki (timo-jyrinki)]

Yep, vbetool vbemode set 0x118 does the same crash, nothing works after that, not even Magic SysRq key combinations. Apparently setting any vga=xxx parameter does things differently and does not use that, then.

[Matthew Garrett (mjg59)]

Ok. So the next bit is going to be slightly awkward, I'm afraid. First of all, download

http://www.codon.org.uk/~mjg59/tmp/x86_debug/libx86-1_0.99-1.2debug1_amd64.deb

and install it. Switch to a console and mount your filesystem synchronously (I'm going to assume you have a single filesystem here - if you have a separate home directory, use /home rather than /):

mount -o sync,remount /

and then do

sudo vbetool vbemode set 0x118 >vbetrace

Once the machine has hung, try doing alt+sysrq+s (just to be on the safe side) and then reboot. gzip the vbetrace file and attach it here.

[Timo Jyrinki (timo-jyrinki)]

The machine does not seem to hang with the libx86 debug version, but it does with the normal version. Vbetrace continues to ever increase, I let it ran for about half an hour to get the current 4MB log file.

[Matthew Garrett (mjg59)]

Hm. I'm not entirely convinced this is looping - I think it may just be very slow. Could you possibly leave it running overnight?

[Timo Jyrinki (timo-jyrinki)]

Yep, did and it had finally crashed. Noticed that it first (after ca. 10 hours) had a blank screen but with monitor on, and after the night the hdd had stopped writing new information and monitor was off. Compressed with 7-zip (1.7MB against bzip2's 4.4MB).

Oh, and the command was naturally: sudo vbetool vbemode set 0x118 2>vbetrace, if someone else is trying it out. Otherwise the information is just printed on the screen.

[Tor Håkon Haugen (torh)]

Can confirm this bug on x86_64 with Asus P5B Delux motherboard and NVIDIA 8800GTS graphics.

[Tor Håkon Haugen (torh)]

This is a dmesg output from where it hangs. Although it doesn't seems to be anything useful information in it.

[Giedrius (plintusas)]

I also experience this bug. My mother card is Intel D915GAV and my video card is Sapphire X700 PRO 256MB. The 32 bit version of ubuntu boots fine, and the 64 bit version boots fine when I change "splash" option to "nosplash" in grub menu.lst. Though it is annoying that after some of the ubuntu updates, the "nosplash" option reverts back to "splash".

[Miłosz Kosobucki (mikom)]

I have something very similar on Pavilion (dv6510) notebook with amd64 processor (Turion) and GeForce 8400 GS card.

[Timo Jyrinki (timo-jyrinki)]

Anyone with the Radeon X800 cards trying current gutsy? I seem to have the hang both with and without vga=791 now. I'm going to go all-Intel in the future (now that I got my 2xDVI ADD2 card for my GMA X3000), so I may not be able to debug this much later on.

[H_Plow (brtdth)]

So? Is all this at a dead end??

[Cesare Tirabassi (norsetto)]

Yes, there is Oops no matter what vga you specify, I just had to delete splash.

[vladf (vlad-chel)]

I have same bug with ATI X800GTO: https://bugs.launchpad.net/bugs/155391 (sorry, can't find this case in that moment).

"vga=..." option is not help. Then kernel panic leds Caps Lock and Scroll Lock are flashing. In different posts was described various combination of blinking. Only Lorenzo Ciuciat write about Caps Lock + Scroll Lock too.

[Lorenzo Ciuciat (lorenzociuciat)]

Just tested again (7.04): Caps Lock + Scroll Lock blinking together (not try
with 7.10 yet, but I think same problem as you wrote in bug 155391).

See you,

    Lorenzo Ciuciat

[shon (kosmici-atakuja)]

I can sort of confirm this bug on amd64 - E6750 cpu on GA-P35-DS3 mobo with Gigabyte NVidia 8600GT. Tried a couple of VGA= options as well as different /etc/usplash.conf resolutions (from 800x600 to 1280x1024, max for my display), usually with VGA and usplash.conf synced to the same resolution.
I'm saying 'sort of' because the system does not hang. After GRUB I just get blank screen, no signal, monitor shuts off, but the system is loading under that and X with gdm comes up.
Without 'splash' kernel option everything of course works and I get normal boot messages.

Piotr

[shon (kosmici-atakuja)]

Sorry, this is me again, forgot to add I'm using Gutsy!

Piotr

[Dara Adib (daradib)]

Shon, that seems like a different bug. The hang in this bug is important, because it appears to crash the kernel. Not even the Magic SysRq key combinations work.

[shon (kosmici-atakuja)]

Ok, thanks, I'll search for the right one then!

Dnia 28-11-2007 o godz. 21:07 Cyrus Jones napisał(a):
> Shon, that seems like a different bug. The hang in this bug is
> important, because it appears to crash the kernel. Not even the Magic
> SysRq key combinations work.
>
> --
> Feisty crashes after grub, before boot process, if usplash is enabled
> (amd64)
> https://bugs.launchpad.net/bugs/86666
> You received this bug notification because you are a direct subscriber
> of the bug.

----------------------------------------------------
Tych emocji nie możesz przegapić!
Dawid CYGAN Kostecki w walce wieczoru podczas
Senator Night of The Champions! Zobacz wielką Galę Boksu
kliknij -> http://klik.wp.pl/?adr=http%3A%2F%2Fcorto.www.wp.pl%2Fas%2Fcygan-w-rzeszowie.html&sid=116

[M. Thomas Frederiksen (mahasamoot)]

I had the same problem on Kubuntu alt amd64 w/ nVidia 8600. But I was able to fix it. It seems the vesafb module is needed--but it is blacklisted. Here's what I did:

add "vesafb" to /etc/initramfs-tools/modules
comment out "blacklist vesafb" in /etc/modprobe.d/blacklist-framebuffer
generate modules.dep: sudo depmod -a
try loading it: sudo modprobe vesafb
sudo update-initramfs -u
reboot

These instructions are based on http://ubuntuforums.org/showthread.php?t=622018 however he was also trying to set up fbcon which I don't think is need to fix the problem. In my case I used hwinfo --framebuffer and edited /boot/grub/menu.lst to run usplash at 1920x1200x24. The posts above talk about these grub and hwinfo, which is nice, but doesn't fix the problem.

PS: I'm guessing that vesafb was blacklisted for a reason, so this may not work for everyone... if not you may need to remove splash from the default options in /boot/grub/menu.lst... text boot messages are better then a black screen.

Cheers,
~Thomas

[Joachim Frieben (jfrieben)]

Current Hardy/AMD64 live CDs [e.g. of 2007-12-31] crash my system, too. Directly after validating the boot options, the screen goes blank, and after a few seconds, the system simply starts over again.
The mainboard is a Tyan S2865AG2NRF [chipset NForce4 Ultra] equipped with an ATI X800 GT PCIe graphics card. Removing "splash" from the boot options allows the system to boot regularly albeit without any intermediate text output until GDM takes over. The same live CDs of i386 flavour work without any problem.

[slaguth (elliottslaughter)]

Thomas Frederiksen's fix (vesafb module) worked for me. I am on Ubuntu Gutsy AMD64 with an NVIDIA 8800 GTS card (using the proprietary driver). I was finally able to see the bootsplash for the first time since using the install cd six months ago!

Previously when I tried to start up the monitor would go blank and report not getting input. I believe the computer just crashed because it wouldn't start up, even if left for interminable periods of time. I tried the vga=xxx settings, and I was able to get some output, but it was mostly just black and white noise on the screen. (Under 24bit color I was able to get red noise before the screen when blank, but I don't think that means anything.) I was forced to simply remove "splash" from the parameters in menu.lst in order to make my system boot. However, allowing vesafb seems to have fixed the problem. My system now boots normally with usplash enabled.

Thanks!

[J. Thomas Shaw (v-admin-jtsnetworks-net)]

Install and ran Gutsy 32-bit i386 without any problems, however Gutsy 64 bit/amd64 freezes on a black screen at boot unless the splash option is removed from the boot options.

[Joachim Frieben (jfrieben)]

System still crashes shortly after booting the AMD64 live CD as of 2008-03-19. Adding vga=792 to the boot line cures the problem.

[SireeBob (sireebob)]

Affects: x86-64 versions of Feisty, Gutsy, Hardy
Motherboard: EVGA 680i SLI
CPU: Intel Core 2 Duo E6600
GPU: NVIDIA GeForce 8800GTS 640MB
Currently using: Kubuntu 8.04 Beta, KDE4 Remix
 ^ This is a fresh installation, and I haven't installed the proprietary NVIDIA drivers.

I experience a persistent black screen at early system startup, including when trying to load the live CD or installation process. Despite this, when messing with the installed Kubuntu, it became clear that the computer does not freeze or hang - it continues to load everything as normal: it can be pinged, and after installing openssh-server I see that it can be ssh'd to as well. For me, the magic SysRq keys also work. So, the computer is responsive, but the screen stays black.

Removing the "splash" option has always worked around the problem just fine, but unfortunately Thomas' "vesafb" approach has no effect for me in Kubuntu 8.04 Beta KDE4 Remix.

I've had this problem since Feisty (the first Ubuntu release I've used), and it has carried on into Gutsy and now Hardy beta as well, and like other users, it has only occurred in x86-64 versions.

[M. Thomas Frederiksen (mahasamoot)]

Hi SireeBob,

Removing the "splash" option has always worked around the problem just
> fine, but unfortunately Thomas' "vesafb" approach has no effect for me
> in Kubuntu 8.04 Beta KDE4 Remix.
>

I've also just installed Kubuntu 8.04 Beta 4 alt amd 64--but the KDE3
version. I had the same problem again at install, but after I upgraded and
installed the nvidia-glx-new (version 169.12) drivers, the problem went
away. I didn't do anything else.

--
Cheers,
~Thomas

"The mystery of government is not how Washington works but how to make it
stop."
~PJ O'Rourke

[Dara Adib (daradib)]

The problem went away for me completely sometime after I upgraded to hardy alpha 6 (last alpha). It is completely fixed, I have usplash running fine without any extra arguments (i.e. vga=something). I have a ATI Radeon X800 and am running the default free radeon driver.

[Timo Jyrinki (timo-jyrinki)]

Cyrus: Cool! You were one of us with a configuration actually matching the bug report, ie. amd64, Radeon X800, 64-bit Ubuntu. I also saw some libx86 fixes which possibly finally fixed this, but I don't currently have the X800 installed. Maybe I'll take some time to see it also myself, but marking as Fix Released anyway.

All others with any other configuration besides Radeon X800 and 64-bit Ubuntu, or a crash somewhere else besides the very beginning of boot, please file a new bug if you still experience problems. Also note that this is not just a "black screen" bug, but a complete crash bug.

[Javier Martin (Habbit) (habbit)]

I can also confirm that Hardy, updated today, works for me (Radeon X850 XT PCI-E), with the splash argument and without vga=whatever. Nice work, whoever fixed it!
By the way, is there any way to avoid boot splash screen stretching in my widescreen display?

[Lorenzo Ciuciat (lorenzociuciat)]

I will wait the official 8.04 LTS release to test.
I will report my experience as before

HW: Asus A8N-E, Athlon64 3000+ 90nm (socket 939), Radeon X800 XT

See you soon (18 days left to 8.04 official release date)