Hi there,
I’ve a sony vaio Y21S1E and I can’t install opensuse in graphic mode (I got a black screen just after the loading page…). So I installed it in text mode, but on reboot, I have exactly the same problem… I had a look in the logs but I found nothing … My Xorg.conf seems to be OK (intellegacy)…
Someone could help please ?
Thanks in advance,
It would have helped if you had specified your Intel device
Have you looked at this
openSUSE Graphic Card Practical Theory Guide for Users
Have you tried failsafe boot?
Try booting with the option nomodeset
caf4926: I can boot in failsafe mode, but I can’t startx (black screen again…), I’ll take a look at youir link, thanks.
A-D4M: OK, I’ll try this and I’ll come back to tell you …
both: Thanks for replying 
The Sony VAIO Y21-series has an Intel Pentium U5400 processor. Do not be mislead by the name, as it is a close cousin of the i3/i5 Arrandale line, built on a thin(ner) base for ultra-thin/ultra-lights. (Has very respectable power consumption and thermal dissipation!). However (there is always a “but” or “however”), …
The U5400 has the Intel Integrated Graphics. The problem you are experiencing is rather well-known. The circumvention(s) include booting in Failsafe mode, or specifying nomodeset on the boot options line. These techniques will give you a deprecated display, but everything else should work.
To get your display to function natively (1366 x 768), with full graphics, try the procedures found here - The “Black Screen” on Boot … a Surprise !, with attention to post #18.
Please post back here with your results !
If you could, please post the following:
uname -a
zypper lr -d
lspci -v
If possible, following a successful boot, please post the contents of /var/log/boot.msg. If you cannot get s successful boot, re-boot with either nomodeset or in Failsafe mode, and post the contents of /var/log/boot.omsg. Please carefully note the underlining.
Hi there,
so I tried with the nomodeset option, and I got the same problem after a brief text boot sequence… So I can only boot in failsafe mode.
SeanMc98, here is the result of the commands :
uname:
*Linux linux-29hz.site 2.6.34-12-desktop #1 SMP PREEMPT 2010-06-29 02:39:08 +0200 x86_64 x86_64 x86_64 GNU/Linux
*
zypper:
*
–±-------------±----------------------±-------±-----------±---------±-----±----------------------------------------------------------------±-------
1 | repo-debug | openSUSE-11.3-Debug | Non | Oui | 99 | NONE | Index of /debug/distribution/11.3/repo/oss |
2 | repo-non-oss | openSUSE-11.3-Non-Oss | Oui | Oui | 99 | NONE | Index of /distribution/11.3/repo/non-oss |
3 | repo-oss | openSUSE-11.3-Oss | Oui | Oui | 99 | NONE | Index of /distribution/11.3/repo/oss |
4 | repo-source | openSUSE-11.3-Source | Non | Oui | 99 | NONE | Index of /source/distribution/11.3/repo/oss |
5 | repo-update | openSUSE-11.3-Update | Oui | Oui | 99 | NONE | Index of /update/11.3 |
*
lspci:
00:00.0 Host bridge: Intel Corporation Core Proc
cat boot.omsg:
[klogd 1.4.1, log source = ksyslog started. <5>
Thanks again !
The boot.omsg posted indicated that the prior boot was performed with the nomodeset option. Can you re-run the sequence with:
2.6.34-12 is the openSUSE kernel straight from the liveCD. You really should run the updates (YAST –> Online Update). 2.6.34-12 OOTB (out-of-the-box, off-of-the-whatever) does not play well with the Intel Integrated graphics. Even in Failsafe mode, the borders of windows disappear, tasks hang, etc. Run the updates before re-doing the boot sequence above. The update sequence will bring your kernel to 2.6.34.7-07.1, along with (most likely) quite a few additional updates.
All good here, looks like the repositories should fresh from the install.
All good here. After you perform the updates, test your audio. (Yes, the Intel stuff spreads it around !).
See the notes at the top regarding the boot sequence. This showed that the prior boot was a nomodeset. This option disables KMS, so you get the fallback drivers.
One last question (I might have missed it): Are you running KDE or Gnome ?
I’m runnning KDE.
Thanks for your help !
Re,
I followed the procedure (upgrading distrib and reboot normally, I had a black screen and then, reboot in failsafe mode) and here are the results :
uname :
Linux linux-29hz.site 2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 x86_64 x86_64 x86_64 GNU/Linux
boot.omsg of the last boot sequence :
[klogd 1.4.1, log source = ksyslog started. <5>
Thanks again ^^
some news… I also tried the latest kernel (2.6.37 from repo HEAD:Kernel), but I have again the same result … black screen… Please help !
Your posted log shows the exact failure: the switch to “inteldrmfb” (Intel frame buffer) failure.
A couple of bits of information needed: did you install via liveCD or Network installer ? Did you receive the “black screen” during the instllation ? If so, when did it occur and wht did you do ?
Have you attempted the lid-closure workaround ? You would do :
Note: you may need to count 1,2,3 or 4. 
Hi,
again and again, thanks again, this problem is for me a nightmare, I DONT WANT TO USE ANY OTHER DISTRIB (sorry for caps but I really love Suse, you can understand that for sure ^^).
To answer your question, I had to install in text mode because graphical installation offered me the same black screen (with light under, when I say black screen, screen is lighted but shows nothing…) as soon loading progress bar ended before installation process really start, so I can only run a tty, so I installed from liveCD in text mode.
Last, I tried to close the lid, count, re-open it and then, I obtain… the same f***n (sorry for that… ) black lighted screen…
Thanks !
Let us try some alternate approaches. I assume that you get the GRUB screen at boot, to select the oS you wish to boot. Try booting openSUSE to “Runlevel 3”. At the GRUB screen, tab to the “Boot Options” and type “3” (without the quotation marks). Then select oS and boot. Report here what you see.
Next, reboot, tab to the “Boot Options”, and enter “vga=ask”. You should see a display of several video modes. Look for one that is 1366 x 768, failing that, look for 1024 x 768. Select that value, and continue the boot. As soon as you get the black/blank screen, close and reopen the lid.
When you installed the liveCD, did you get a “black”/blank screen during the install ?
Insert the liveCD, and run the media verification. (Just in case …).
Boot from the liveCD. You should see a “splash” screen first, with various welcomes, then a menu screen. Select the first option to run openSUSE (do not select “Installation”). Report back what you actually see at each step.
I see the same as always… black screen just after the “/boot/initrd-2.6.37-desktop @ 0x377… 0x89d49d bytes]”
I haven’t any 1366x768… I tried here to select almost all configuration proposed with/without lid opening/closing and all gave me the same res… black screen again !
Sure ! At install process, just after the loading page with the lizard, black screen !
No problem here !
Here, as see above, I only can see the loading page with lizard…
I tried to do echap during screen to see messages… and the last I can see is about NFS (line after starting rpcbind)
A precision, if I wait, I can hear the KDE start sound, so it’s must be only a graphical problem…
Thanks again !
I’ve been trying to follow this thread, but it is difficult due to the massive number of tests that have been attempted.
Has any effort been made to determine EXACTLY what boot code allows “failsafe” to boot where it does not boot properly without “failsafe”. Note “failsafe” is the same boot as a normal boot, except it has a large number of boot codes added.
One could simply do a series of reboots one after another in “failsafe”, each time removing an extra boot code, until the “failsafe” boot fails. Then take that boot code, apply it to a “normal” boot, and see if it makes a difference. If it does, it ‘might’ add some extra insight into the problem. Note sometimes it can be that more than one boot code is needed.
Actually, I can boot when adding ‘nomodeset x11failsafe’ to boot options, and then, it’s booting and open me a tty…
UPDATE: I also tried to add the Xorg repo (http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.3/) and update it … does not works… too bad !
When I began this analysis on my failing i5-430 Arrandale/“Ironlake” (Intel Integrated Graphics), a “normal” boot failed, and a “Failsafe” boot worked, albeit with degraded display.
/boot/grub/menu.lst :
# Modified by YaST2. Last modification on Tues Nov 28 21:41:20 EDT 2010
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader
default 0
timeout 15
##YaST - generic_mbr
gfxmenu (hd0,9)/boot/message
##YaST - activate
###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop --- openSUSE 11.3 - 2.6.37-34.1
root (hd0,9)
kernel /boot/vmlinuz-2.6.37-desktop root=/dev/disk/by-id/ata-ST9500325AS_6VE3ZHX6-part10 resume=/dev/disk/by-id/ata-ST9500325AS_6VE3ZHX6-part9 splash=silent quiet showopts vga=0x317
initrd /boot/initrd-2.6.37-desktop
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.3 - 2.6.37-34.1 (Desktop)
root (hd0,9)
kernel /boot/vmlinuz-2.6.37-desktop root=/dev/disk/by-id/ata-ST9500325AS_6VE3ZHX6-part10 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x317
initrd /boot/initrd-2.6.37-desktop
Starting with the germane options in the failsafe entry, each
apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1
nomodeset x11failsafe vga=0x317
was removed until a failing boot was achieved. In addition, “ACPI=off” was also tested, achieving a workable boot, with almost everything (wireless, sound, etc) disabled. The option that was the controlling factor was nomodeset.
Analysis of the logs (/var/log/boot.msg, /var/log/boot.omsg, the Xorg logs nd /var/log/messages) led to the entries in the boot.msg logs as the initial point of failure. I have SUSE Paste’ed four (4) boot.msg logs:
Runlevel 3 - SUSE Paste
Normal - SUSE Paste
nomodeset - SUSE Paste
Failsafe - SUSE Paste
Each of the nomodeset and Failsafe logs show the kernel using the VESA VGA frame buffer driver:
<6> 1.520895] vesafb: framebuffer at 0xc0000000, mapped to 0xffffc90011100000, using 1536k, total 1536k
<6> 1.520901] vesafb: mode is 1024x768x16, linelength=2048, pages=0
<6> 1.520905] vesafb: scrolling: redraw
<6> 1.520908] vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
<6> 1.521082] bootsplash 3.1.6-2004/03/31: looking for picture...
<6> 1.521084] bootsplash: silentjpeg size 157558 bytes
<6> 1.531472] bootsplash: ...found (1024x768, 80639 bytes, v3).
<4> 1.600395] Console: switching to colour frame buffer device 124x44
<6> 1.659369] **fb0: VESA VGA frame buffer device**
The Normal and runlevel 3 logs indicate the same initial driver, followed by
<6> 5.408095] [drm] MTRR allocation failed. Graphics performance may suffer.
<7> 5.434582] i915 0000:00:02.0: irq 41 for MSI/MSI-X
<6> 5.500387] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
<7> 5.572352] checking generic (c0000000 180000) vs hw (c0000000 10000000)
<3> 5.572356] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
<4> 5.599678] Console: switching to colour dummy device 80x25
<6> 5.664699] bootsplash: scaling image from 1024x768 to 1600x900
<4> 6.100330] Console: switching to colour frame buffer device 196x52
<6> 6.312290] **fb0: inteldrmfb frame buffer device**
<6> 6.313278] **drm: registered panic notifier**
showing the switch to the “inteldrmfb” (the Intel frame buffer) driver. The highlighted “fb0” indicate the choice of module, and its successful load. The message “bootsplash: scaling image from 1024x768 to 1600x900” indicates that the correct device mode and geometry have been detected and selected.
The “drm: registered panic notifier” appears to indicate the failure of that driver, yielding the “black screen”/blank screen/“white screen” display. In each case, kernel initialization continues, albeit unseen.
The subsequent application of the “workarounds” (lid closure/reopening, with or without workspace swap) appears to drive recovery procedures, which reinstates the screen display.
Summary:
The problem(s) with the Intel Integrated graphics occurs during kernel initialization. The failure appears to occur in module “inteldrmfb”, and, in most cases, appears recoverable.
Although subsequent problems may occur in Xorg, the ability to recover and use the display does not appear to require the advanced (aka “Factory”) Xorg, nor the associated Intel (2.13.+) drivers. While the advanced Xorg (Mesa 7.10+, Intel 2.13+) does seem to show performance enhancement, testing has shown it is not required. As a caveat, use of the advanced Xorg should be given careful consideration, as recovery can be problematic, requiring runlevel 3 maintenance and/or restoration/reinstallation.
Circumvention or temporary solution is (in most cases) to boot with nomodeset, which bypasses KMS (Kernel Mode Switching/Selection), without the broader impact of Failsafe boot, or the option “ACPI=off”.
Comment:
The solution is deeply involved in the Intel drivers and internals. Much developer activity is also involved in display power consumption and management. As of this writing, only circumventions can be offered, as the solution is in development hands.
OK, thanks for all ! I finally found a way to boot with graphical UI and KDE runnning… adding “xdriver=vesa nomodeset” boot options
Hi there, I’m coming back here to get you the last news about my problem…
Since few days, I’ve tried many linux distrib, and I can tell you that The VAIO Sony Y21S1E doesn’t work out-of-the-box… I tried latest release of gentoo, ubuntu and fedora, and I can tell that none of these distrib correctly detect my graphic card.
I sent a mail to the intel developer team… No answer … We’ll see…
I also tried OpenSUSE 11.4, and I can have a functionnal desktop with acpi=off boot option but my it is very slow (~2 sec to open konsole, I can see it being drawed…).
I really hope Xorg/intel developers will do a great work for Intel U5400 embeded graphic chipset…
Many thanks to you oldcpu, I’ve read your post about graphic configuration (sadly without the attended result^^), you do a great job for this forum (that’s not the first time you help me ;)) !
Particular thanks to you SeanMc98 for the time you given to me
A great continuation to OpenSUSE !
I also maintain a small Ubuntu install (on the same PC). Ubuntu 10.04.1 LTS (aka Lucid Lynx) worked OOTB with the Intel Graphics. This, I believe, was due to the 2.6.32- series kernel. Ubuntu 10.10 (aka Maverick Meerkat) experiences the “black screen” problem, and I have not bothered pursuing it further.
While working on this problem, I came across some circumventions and workarounds in the Fedora Forums, so I attempted to install Fedora 13, with problems in the install execution. I then installed Fedora 14, which works with the lid closure/workspace swtiching workarounds. I have not attempted anything with Gentoo, although there is much information concerning this problem on their forums.
I did install LinuxMint 9 (aka Isadora). This installed cleanly, and operates without problems. LinuxMint 10 (aka Julia) experienced some problems running the liveCD installer on my Gateway NV 79.
openSUSE is my preferred distro, and will remain so. I maintain a skeleton Ubuntu for printing (along with Windows), and for recovery editing if openSUSE has problems.
I would love to see their response (if you even get one).
My experience using “ACPI=off” has only been for testing a failing boot. This option cripples so many things (wireless, sound, etc) on my PC’s that it is basically a last-ditch test. Try nomodeset or a Failsafe boot: at least you will have wireless.
Your are welcome!