Occasional Blank Black Screen at Boot

Architecture: i386
DistroRelease: Ubuntu 9.04
Lsusb:
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Dell Computer Corporation Inspiron 1100
Package: linux-image-2.6.28-11-generic 2.6.28-11.42
PackageArchitecture: i386
ProcCmdLine: root=UUID=d2b192bb-3978-4e0d-b0d3-711366b6824e ro quiet splash nopat
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-11.42-generic
Uname: Linux 2.6.28-11-generic i686
UserGroups:

I followed the instructions for the "safe" option in the following thread, and it appears to have served as a workaround for the problem. For the first time in Jaunty, I was immediately able to boot properly without using the "nopat" kernel option:

http://ubuntuforums.org/showthread.php?t=1130582

Scratch my last comment. I haven't been able to get the system to boot properly without the "nopat" option since I posted that message. I am starting to wonder if I subconsciously automatically put in the "nopat" option after following those instructions. It has become rather routine! :)

Karmic will target the 2.6.31 kernel so this should hopefully be resolved for the upcoming release. Moving this to Triaged so the kernel team will track this. I'll leave it to their discretion if this will qualify for a Stable Release Update for Jaunty.

If you wanted, you could also run the latest Karmic kernel or take a look at https://wiki.ubuntu.com/KernelMainlineBuilds for builds of the upstream stable releases or the latest upstream kernel builds. Thanks.

In pursuit of a solution to this problem, I updated the video driver am now running the following:

xserver-xorg-video-intel (2:2.7.1-0ubuntu1~xup~1)

This does not appear to have solved the problem.

I have noticed, however, that it may NOT be the "nopat" option that is actually resolving the issue--strangely, pressing ESC and simply entering the GRUB boot menu, without actually editing any of the commands, appears to also sometimes resolve the problem. I thought it was the "nopat" option because, in order to enter the "nopat" option, I needed to first enter the GRUB boot menu at startup.

I can't imagine what might be causing this, or how these two things might be related; but my best guess is that maybe it has something to do with the newer kernel modesetting feature in the driver.

Can you just test and confirm if this issue remains with the latest Karmic 9.10 Alpha release? It contains a 2.6.31 based kernel. ISO images are available for testing at http://cdimage.ubuntu.com/releases/karmic/ . Please let us know your results. Thanks.

I downloaded today's ISO, burned it, and attempted to boot from the CD.

It appears that the issue remains in Karmic; however, because I do not have access to the text-based GRUB boot menu, using ESC, when booting from the CD, I have been unable to get xorg to start properly at all in Karmic. It does appear to go into graphical mode, sometimes the LCD appears lit, and other times it does not; but either way it never seems to make it past the mouse cursor (which is similar behavior to what happens in Jaunty when I do not first at least enter the GRUB menu.) The only difference I notice is that the mouse cursor eventually locks up, which isn't something that I noticed in Jaunty.

I have further tested since the last time I posted, and I now am even more certain that the difference between getting xorg to start properly is hitting ESC and simply entering the GRUB boot menu. I have tried booting dozens of times without doing this, with no success; but the first time I hit escape and just take the first kernel option by hitting enter, the system usually boots without incident. Again, this leads me to believe the problem may not actually be the PAT issue mentioned above; but I don't know what relationship GRUB and xorg might have or how simply ENTERING the GRUB boot menu can make a difference in xorg starting or not.

This is quite odd. Are you positive that when you _don't_ hit escape to enter the Grub boot menu that Grub is indeed defaulting to the most recent kernel (ie the one you are manually selecting)? A quick way to tell would be is that when you do hit ESC the kernel is highlighted by default.

If that isn't the issue, how about manually editing your grub's menu.lst to remove the ''quiet" and "splash" options. Then let it boot up without entering the Grub menu. That will let us see how far into the boot the system is able to get.

I am positive that when I don't press escape that GRUB is defaulting to the most recent kernel, as I have removed all old kernels from my system and currently have only one installed.

I have GRUB 2 installed, which no longer has a menu.lst file. I manually removed the "quiet" and added the "nosplash" boot options from/to the GRUB command line. This did not resolve the problem.

I still wonder if this problem could be related to kernel mode setting in the Intel driver. I believe the Linux kernel framebuffer is used to show some of the splash screens prior to X.Org start; and the framebuffer has its own driver(s), but I don't know if they share any code with parts of the Intel driver in the kernel.

I used to occasionally have the same problem when switching between virtual terminals; however, I just tried to replicate that problem, and I can't seem to make this happen, at least at the moment. (In fact, this is what originally made me suspect it was a mode setting problem--I believe that not only is mode setting normally done when booting but also when switching between GUI and virtual terminal.)

For purposes of disclosure, I am affected by the following bug; and I don't know if this is related:
https://bugs.edge.launchpad.net/linux/+bug/404064

In addition, I see several instances of the following messages in dmesg; and I don't know if they are related:
"i2c-adapter i2c-1: unable to read EDID block."
"i915 0000:00:02.0: LVDS-1: no EDID data"

I just experienced this problem again, this time with the 2.6.31-19-generic kernel.

I booted, saw the Dell BIOS splash screen, saw a little piece of text that said GRUB, and then a blank black screen (backlight did not appear lit, but this is not always the case) and nothing else. I had to hold down the power button to cut the power, turn the laptop back on; and this second time I saw Dell BIOS splash screen, the text that says GRUB, and then the GRUB boot menu (because I interrupted the boot process the previous time by holding down the power button.) I selected the 2.6.31-19-generic kernel, briefly saw a cursor blink in the upper left of the screen, and then saw a splash screen with a plain white Ubuntu logo (no wording and no progress bar.) After a few seconds, that transitioned to the splash screen with the word Ubuntu and a progress bar, followed by the login screen.

Again, notice that the difference here was that things seem to work properly when I go through the GRUB boot menu?

I would also like to ask what generates those two splash screens? Are they both generated by xsplash? Is the first (without the progress bar) generated by xsplash and the second (with the progress bar) generated by gdm?

Because I experienced the problem immediately prior to the first splash screen, knowing that may help troubleshoot, as if that splash screen is drawn using the Linux kernel framebuffer, we know to look there, rather than in the xorg Intel userland driver.

I am having the same problem with Ubuntu 10.04 LTS.

I am also having this problem with Ubuntu 10.04 LTS. My machine is a Samsung V25 laptop with a 82845G chipset.

Very odd, but going into a root command prompt using GRUB and typing "gdm start" usually makes it boot properly.

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.