Blank Screen on Reboot

Hi all,

Bit of a weird problem here. I’m running 12.3, and I’m having some trouble with the display. After install, the display was working normally. Then, after a reboot, I got a blank screen immediately after the grub screen selection (while opensuse booted). I could SSH into the machine, and everything seemed to be running normally; just nothing displayed on the screen. If I started X (via ssh), I didn’t get any error messages, just nothing would show up on the screen.

This was a few weeks ago, and I was able to - somehow - get it working. I do remember that I was getting an error about openbox, which made no sense, since I don’t use openbox. Anyway, uninstalling openbox seemed to do the trick, and after that everything worked OK. However, I had to reboot today, and the same problem has returned. I’ve rebooted a few times to no avail. Openbox remains uninstalled, and I haven’t done any updates or installed anything else major that I can think of.

A google search led me to try booting with nomodeset, but unfortunately that didn’t help at all (though I do get an error when I try to start X then, of course). Does anyone have any suggestions at all as to what I might try next, or even any log files I might check?

Would really appreciate any assistance at all.

Because yours is only the latest of many, many of the same thing and certainly will by far not be the last,
I am building a wiki page describing the/a correct troubleshooting procedure.

It won’t be ready until tomorrow, but if you would like a head start on the main troubleshooting fixes, try the following in order

  • Disable KMS (Recovery Mode or console > YAST > /etc/sysconfig editor> search kms > enable “no kms”
    See Release Notes for background info of this setting
  • “nomodeset” setting
  • Change drivers. Beware that some changes don’t blacklist or uninstall the previous driver, primary example is nVidia > proprietary. To be safe, just removexorg.conf if it exists
rm /etc/X11/xorg.conf

If you search all my most recent postings with keywords like nvidia, gpu you’ll see posts with some detailed steps to follow, but the wiki I’m preparing will consolidate all in a page or two. Although many of my posts are nVidia GPU specific, many like the KMS setting apply to any GPU.


Hi Tsu2,

Thanks for the reply, I really appreciate it. I tried disabling KMS and setting “nomodeset”, which unfortunately hasn’t helped. I could try changing my driver (currently using Intel i915), but I’m unsure whether that would do anything: My problem isn’t that the GUI isn’t showing up, it’s that nothing is showing up on the monitor - I’m not dropped into the command line, I can’t even see the boot process - just nothing shows up on the screen, after GRUB anyway. When I try to start X by SSHing in to the system (which normally works), I don’t get any error messages or anything - it’s as if the OS is outputting the display to a non-existent monitor.

I’m running off an HDMI port, if that makes any difference. I know that the conncetion is working because as I said above, BIOS and GRUB are both showing up OK on the monitor.

Does anyone else have any thoughts? Thanks!

A couple of speculative things to try (trying with and also with out the ‘nomodeset’ and with and without the ‘x11failsafe’ boot codes) …

  • try removing the vga=xxxxx (some value) boot code from the appropriate line in the grub menu to see if that helps
  • press the < escape > key during the boot, seconds after the grub menu disappears to see if that disabling plymouth helps

This sounds like kernel incorrectly detects active output port. If you can ssh into box, could you upload dmesg output to

If the GRUB Menu displays, and you select a kernel (and mode), what happens if you hit ESC approx 1 full second after making your selection (or timeout so boot resumes)?

If the GRUB menu does not display at all, then if your video driver is completely wrong then maybe editing grub.cfg to set to force VGA resolution (640x480) will work(or there is a BIOS output issue). If you do see the GRUB menu, the ESC click should enable you to see the continueing boot process and see where the system freezes. From what I’ve seen the display driver does not switch from GRUB to your Desktop driver until Plymouth which is the next graphical display which has your User login (unless of course you have auto-login enabled).


Thanks for the reply arvidjaar! This was my initial thought, but I’m unsure as to how to check or change that. Here’s the link to my dmesg output: SUSE Paste

To Tsu2 and oldcpu: the GRUB menu does display correctly. I’m not at home to try pressing ESC after the GRUB menu disappears, but I will try it and let you know what happens. Thanks!

I’ve posted an early draft which more or less contains the “meat and potatoes” for troubleshooting Display Boot issues for 12.3 at the following

Formatting the text and page layout is still in early stages, hope to improve readability with changes
Re-sizing and ading screenshots still need to be done.

This page is intended to focus on 12.3 issues (and possibly later, depending on future changes).
Have omitted everything I could think of that is irrelevant to 12.3 and later that’s contained in the SDB (Yes, I still put the SDB link at the bottom of my page).

This page is <open> for anyone to edit however they would like (just login and you can make changes). Don’t worry about making mistakes or saying crazy things, I’m keeping copies of the page code elsewhere and openSUSE wiki allows approx 4 rollbacks “undoing” recent changes. When making changes, pls include a comment describing changes (above the “save” button).


Will be interesting if you actually determine that display output somehow changes if you see the GRUB menu. I can’t think of why that might happen although <anything> is possible.


Looks like driver problem indeed:

Intel GMA3150 Chipset

It may be similar to this problem: Brightness of Lenovo S10-3 (GMA 3150 video) on Linux | Luis’ Blog If it works, it may be possible to add workaround to grub2 configuration. In any case I suggest to open bug report attaching dmesg output and explaining what happens.

I note a lot of EDD entries …

 6373.953733] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
 6373.953741] EDD information not available.
 6382.304062] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
 6382.304070] EDD information not available.
 6400.932548] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
 6400.932557] EDD information not available.
 6403.346135] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
 6403.346143] EDD information not available.
etc ...

Did you have any success with ‘x11failsafe’ or removing the ‘vga=xxxx’ and/or pressing “escape” immediately after the grub menu disappears. Does the ‘failsafe’ boot work ?

Another possibility would to try the boot code (?) “edd=off” … (speculation on my part based on that error message - I note “edd=off” is one of many additional boot codes in a “failsafe” boot).

EDD does not work with default GRUB2 loader. EDD requires real mode (16 bit) and GRUB2 by default is using protected mode (32 bit) when starting Linux. In protected mode Linux expects bootloader to supply EDD information.

Hmm … ok if one ignores the EDD messages, and ignores the firewall messages, what strikes me next is this:

 9149.571879] python[5656]: segfault at c ip b6995d1e sp bfab88d0 error 4 in[b6924000+ae000]
 9154.264968] python[5663]: segfault at c ip b694fd1e sp bf8bb4b0 error 4 in[b68de000+ae000]
 9154.555754] python[5669]: segfault at c ip b68dbd1e sp bff36b70 error 4 in[b686a000+ae000]
 9154.849846] python[5675]: segfault at c ip b68d6d1e sp bfe01a80 error 4 in[b6865000+ae000]

with lots of segfaults in (ie if it were me I would assume libgdk-x11 crashed).

I tried the solution suggested in your link, but unfortunately it still didn’t work.

I have submitted a new bug:

Thanks all for the assistance!

Thanks for the reply. If libgdk-x11 were crashing, shouldn’t I still be able to see the command line?

Referring back to the original post,
I assume that immediately after initial install, your video resolution was high (at least not VGA).

This leads me to believe this is <not> an unfixable problem, not likely a BIOS/EFI problem and is more than likely an OS-installed video driver problem.

Part of the troubleshooting issue might be relying so heavily on logging in remotely to the machine. That utilizes graphics in a way that is very different than logging in locally to the machine.

In fact, although I can’t say it’s exactly the same, the “display fails with first boot after finished install” is exactly what the “old” nouveau driver problem looked like (before it seems to have been fixed with 12.3). If you didn’t fix by replacing the nouveau driver (installed by default) with the nVidia proprietary driver, you’d be stuck troubleshooting in Recovery or curses mode.

Also, I’m not sure that the BIOS attempting to load 16-bit drivers should be that surprising… AFAIK that’d be typical of “older” BIOS until the introduction of EFI. If no subsequent working display ever happened, I’d be more concerned about that, but since it sounds like <something> was successfully installed eventually (before reboot), I don’t know that it’s a major obstacle to getting something to work.

IMO and admittedly guessing,

… hmm … where does the OP note nVidia hardware? Am I missing something ?

I had assumed based on the dmesg that their computer had Intel graphic hardware. I note this from the dmesg:

    1.508982] Linux agpgart interface v0.103
    1.509152] agpgart-intel 0000:00:00.0: Intel GMA3150 Chipset
    1.509244] agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, 262144K mappable
    1.509435] agpgart-intel 0000:00:00.0: detected 8192K stolen memory
    1.509662] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xd0000000
   15.076847] i915 0000:00:02.0: setting latency timer to 64
   15.077474] i915 0000:00:02.0: irq 44 for MSI/MSI-X
   15.077500] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
   15.077506] [drm] Driver supports precise vblank timestamp query.
   15.077596] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
   15.086109] [drm] initialized overlay support
   15.380900] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
   15.384352] i915: render error detected, EIR: 0x00000010
   15.384358] i915: page table error
   15.384362] i915:   PGTBL_ER: 0x00000002
   15.384368] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
   15.384384] i915: render error detected, EIR: 0x00000010
   15.384389] i915: page table error
   15.384393] i915:   PGTBL_ER: 0x00000002
   15.402953] fbcon: inteldrmfb (fb0) is primary device
   15.403354] Console: switching to colour frame buffer device 160x45
   15.403373] fb0: inteldrmfb frame buffer device
   15.403378] drm: registered panic notifier
   15.403414] i915: No ACPI video bus found
   15.403512] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

I can find no reference in the dmesg to nvidia nor to nouveau.

hmmm both intel and NVIDIA maybe. Is the machine a laptop seems like a lot of them these days have the frankenvideo setup.

It’s a Zotac Zbox “Mini-PC”. The spec sheet says it has Intel GMA graphics. Not sure if that includes the “frankenvideo” setup, but I don’t see any reference to nvidia hardware on the spec sheet.

Thanks for your comments, tsu2 - I agree that my reliance on logging in remotely probably hasn’t helped things. I’m out of town for a few days and my wife wants to watch some movies on the computer, so I was hoping to be able to fix it from afar. I’ll just have to tell her she might have to wait until I get back!

Probably not then. Was just a thought having seen a lot of problems with machines with 2 different brand Video cards