Linux blank screen on boot

Blank screen, blinking cursor on boot

Occasionally my Ubuntu 10.04 PC won’t boot properly. It gets past Grub and then stops at a blank screen and blinking cursor. From what I’ve read, this blinking cursor screen is presented by Ubuntu itself and not Grub, so I assume the boot process gets halted for some reason. Has anyone any guidance on how to diagnose this issue or what the cause is likely to be? Normally I need to press the reset button to reboot the PC and often it will reboot fine. The fact that it is intermittent is what confuses me. Any pointers on diagnosing the problem would be much appreciated. It’s been a while, mainly because my server has been up for a long time. It looks like I’ve captured a recurrence of this issue, I copied the messages file and the dmesg file and had a look where processing seems to have stopped and found the messages below. I’m going to do some research on Google etc. but figured I’d put it up here in case anyone can help and wants to earn themselves some points. I should mention that the ondemand governor failed message happens on successful boots but the other two don’t appear to.

Oct 11 23:17:21 linux kernel: [ 98.905370] ondemand governor failed, too long transition latency of HW, fallback to performance governor Oct 11 23:21:48 linux kernel: Kernel logging (proc) stopped. Oct 11 23:21:48 linux rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="697" x-info="http://www.rsyslog.com"] exiting on signal 15. 

17 Answers 17

Hold shift during boot, then hit E to edit the GRUB entry. Remove the part that says quiet splash and replace it with text to see what’s happening during boot.

I encountered this issue and it turned out the problem was my hard drive being 100% full. Steps I took to troubleshoot and finally fix this were as follows:

1. Boot to blinking cursor
2. Press Ctrl + Alt + Fx to enter Ubuntu’s tty virtual console screen, where x is anything between 2 and 6. In my case I did Ctrl + Alt + F2
3. Log in using your username and password.
4. Type in df to check the storage and if indeed there is no more free space
5. If storage is the issue, clear some space by deleting unnecessary files.
6. To ensure kernel/grub settings are also not an issue, edit them settings by going to the grub settings file:

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset noresume" 

In my case, the blinking cursor was all I would ever get. No boot. It was upon installing a fresh Ubuntu Minimal. I figured out that during the GRUB installation step, it was installing GRUB onto the wrong drive, the «first» drive (/dev/sda).

My system has 3 drives. Two 500GB drives in RAID, that I didn’t want to touch during installation, and a 120GB SSD that I use for the OS. For whatever reason, the «first drive» (/dev/sda) is one of my 500GB drives. /dev/sdb is my 120GB drive and /dev/sdc is the other 500GB drive.

So, when formatting with a partition table of «mbr» on my 120GB drive, I did the normal 117GB of bootable ext4 and 3GB of swap. On the GRUB installation step, DO NOT choose Yes to put GRUB onto the «first» drive. Choose NO. This will bring up another screen that allows you to input /dev/sdX. In my case, I tried /dev/sdb and /dev/sdb1, but the installer would give me a fatal error every time, which still makes no sense.

Finally, I had to format my 120GB drive with a partition table of «gpt». With GPT, you have to manually create a GRUB partition. That’s the way things are done with GPT. So, the first partition I made for GRUB was 32.0 MB formatted for «boot or something (forget wording)». Second partition was my 3.0 GB formatted for «swap», at the «end». Third partition was the remaining space formatted as «ext4».

Now, when choosing NO during the GRUB installation step, manually input /dev/sdb, not /dev/sdb1 surprisingly, and it then works. GRUB installs into the 32MB boot partition on the correct drive and the system boots normally. YAY!

BTW, you have to choose Expert install from the menu at the beginning of the installation to do all this and format your HDD «manually» not «guided». Guided will always choose /dev/sda as the first drive and blinking cursor/no boot will result if /dev/sda isn’t your OS drive.

Источник

Ubuntu Wiki

A common class of kernel or video driver bug is a blank or black screen on boot.

Symptoms: The screen becomes 100% blank (no backlight or indication that the LEDs or CRT phosphors are lit up), or black (the monitor is on and displaying video, it’s just 100% pure black), at some point between the BIOS screen and the login page (GDM) being displayed. The black/blank screen never goes away. Aside from video, the system might still be working (e.g. playing the login sounds, responding to pings, etc.) or it could be completely locked up requiring a reboot. The issue can occur every time you boot, only irregularly, or only under certain circumstances (such as with a particular device plugged in).

Symptom Variation: The bug shows up the same way, yet can be worked around by attaching an external monitor or letting the system go into standby and resume the system. Another workaround that worked (for me) is to install a version of ubuntu parallel to the bugged version. Somehow, the installationprocess corrects the bootparameters and initializes the graphicsadapter correctly.

• If you never see your BIOS screen, then that points to perhaps some hardware issue.
• The screen displays but is far too time and/or the backlight can’t be adjusted. See Kernel/Debugging/Backlight
• If you see «Out of Scan Range» or similar, you don’t have this bug. See X/Troubleshooting/Resolution instead.
• If the blank/black screen occurs after resuming from suspend, you have a different class of bug. See DebuggingKernelSuspend or UnderstandingSuspend
• If it occurs when closing your laptop lid, see the PipeA Quirk as a better possibility.
• If the blank/black screen comes after your screen saver has been running, you may either have a screensaver-induced crash (see X/Backtracing) or a power management failure (See PowerManagement)
• If you see a screen of a different color (brown, white, multi-colored corruption, etc.) you are seeing a different class of graphics bug. Obtaining register dumps (see below) may still be of value however.
• If it occurs *after* entering your password on the login page, you have some different class of issue, such as an issue with 3D / DRM. Try disabling compiz (sudo chmod a-x /usr/bin/compiz), logging in as a different user, or turning off DRI.

How It Works

Blank or black screens generally indicate a failure feeding data to the Graphics Processing Unit (GPU) in your video card. This can happen for a bunch of different reasons as different processes run as your system boots up. You may notice flickers during boot — these are indications that different processes are starting up and interacting with the GPU.

1. bios screen
2. Black with blinking cursor (short). Disk activity LEDs blink and flicker.
3. Purple without cursor (long)
4. Boot splash graphic (via plymouth)
5. Black screen (short). Backlight may go off at this point.
6. Maybe more plymouth
7. Login screen. Sound (e.g. drums) plays

1. BIOS detects hard drive with a bootloader (grub) present and starts it
2. grub selects a kernel and loads it
3. If the kernel supports Mode Setting (KMS), it puts the video card into its preferred resolution using a frame buffer (vesafb). The framebuffer is initialized with a purple background.
4. plymouth displays a bootsplash image.
5. gdm is started, which instantiates a new X session for the login screen to replace the framebuffer’s graphics
6. X attempts to put the card into one of its higher resolutions, such as the preferred resolution
7. The login screen is drawn on the screen

Workaround A: Non-graphical Boot

See X/NonGraphicalBoot for additional ideas.

Workaround B: Disable Plymouth

If Plymouth crashes during boot, X *should* still boot up, just that you’ll be left looking at a black screen a lot longer than you’d like. However, if plymouth dies at just the right time it can leave the system stuck on a blank vt, and can’t recover. This is because with plymouth in initrd, it’s a bit racy.

To check this, in the grub menu edit the kernel line and remove ‘splash’ from the end of the line, and boot. If that solves the issue, you can remove it from your /boot/grub/menu.lst as a workaround.

Workaround C: Disable the VESA framebuffer from grub

The linux kernel uses the framebuffer for doing graphics prior to X starting up. For systems that support Kernel Mode Setting (KMS), this includes using the higher resolutions of the video card. The kernel uses a framebuffer driver for this, such as -vesafb. However this can misbehave sometimes (e.g. hardware-specific bugs).

Analysis Techniques

Before you start, think back to when you first started noticing the behavior. Did it start right after a fresh install? Or only after an upgrade? Or only after you installed something? If you can recall a rough timeframe for when it started, you may be able to correlate that with your upgrade logs (see /var/log/dpkg.log).

Start by studying your boot, writing down exactly what you see. If you can record a video using a camera or phone, do it. Count how many screen blanking flickers you see. Do you see a blinking underscore cursor? Do you see the boot splash graphic? Does it look correct? Does it show weird colors or scrambling or appear stretched or squished? Does it resize during the boot? Do you see any text on the screen at any point during the boot (these can be useful in isolating how far into the boot process the error occurred.)

Run through your boot cycle several times, taking notes for each run. Does it always behave the same way? If it fails only intermittently, determine the % frequency of failure. Does the blank screen failure always occur the same way, or does it sometimes occur earlier or later? Or does it sometimes fail in other ways (such as with scrambled colors, a kernel panic message, or sudden hardware reboot)? Does the boot splash graphic always display the same way or does it appear corrupted (or text) on some boots?

Also, remove «splash» and «quiet», so you can see more info.

This will cause a log to be written to /var/log/plymouth-debug.log (which you should definitely include in bug reports).

If you have any other kernel parameters set in your grub configuration (such as gfxpayload), one by one remove them to see if their presence affects the issue.

Problem: System is Completely Unresponsive, with Blank/Black Screen

The screen blanks after BIOS, flickers a few times, and then plymouth dies, leaving the system in an inconsistent state. You may or may not see the Plymouth boot splash graphics.

See X/Troubleshooting/Freeze for troubleshooting a completely locked up system. Register dumps are usually needed.

Problem: Black screen after resume

Typical scenario is «use a laptop docked with lid closed, only the external screen is active, suspend, take the laptop, open it somewhere». which leads to «no screen active».

To debug this problem, check if gnome-settings-daemons is getting a signal that the display configuration has changed, by running xtrace against it, and look for a RRScreenChangeNotify event when resuming the machine. If that signal is being sent, then it indicates a possible bug in g-s-d. Otherwise, it suggests a bug in either X or (more likely) the kernel which is not causing the signal to be emitted to begin with.

Problem: Lockup When Closing Lid with Intel Graphics

There is a long known issue with the -intel driver where pipe A/B mixups can cause hangs at the point where the lid is closed. The good news is that it is easily quirkable. In general this is most often seen with newer hardware, because older hardware either has already gotten a quirk or doesn’t need one.

X/Troubleshooting/BlankScreen (последним исправлял пользователь 95-91-227-239-dynip 2013-10-21 21:37:33)

The material on this wiki is available under a free license, see Copyright / License for details.

Источник