Hwinfo output should be a good start.
http://en.opensuse.org/Bug_Reporting_FAQ#YaST

When exactly does the screen go blank? What is the last thing you see before?

I experienced the same problem. The last thing I saw was 
 Starting Yast.
 Found console at ... lines.
It will be hard to get y2logs without display. 
I have nvidia graphics card.

(In reply to comment #1)
> Hwinfo output should be a good start.
> http://en.opensuse.org/Bug_Reporting_FAQ#YaST

I will attach it.

> When exactly does the screen go blank? What is the last thing you see before?

Same as what Ladislav said in comment #2. It is essentially right before it switches over to the first graphics creen of the install, right after everything is loaded into ram. I also have the nvidia graphics card. This is a Dell precision 530, and there are a lot of these here in Provo.

Created attachment 71564 [details]
hwinfo

It blanked my monitor again in text mode installation in 2nd phase in HW configuration. (Cobe it.)

Created attachment 71586 [details]
hwinfo output

Stefan, is it for you (xorg-x11)?

*** Bug 155059 has been marked as a duplicate of this bug. ***

What kind of graphics hardware is this? Install with "vesa" option and try to configure X11 with "sax2 -r -m 0=fbdev". Describe the results.

I have some info in the bug that was marked a duplicate of this one, 155059. I have tried several vesa options, 791, 773, 788, etc. 791 (1024x768x16) just kills everything when X attempts to load. 788 (800x600x16) gets further, but has a large black bar across the top of the screen, on all consoles. This makes navigating the install difficult.

I have attached and explained several hwinfo logs, yast2 logs, and serial console output in Bug 155059.

I'm still missing the information by the reporter. Your comment sounds like the fbdev driver no longer work with TNT2 boards. I need to check this later.

(In reply to comment #9)
> What kind of graphics hardware is this? Install with "vesa" option and try to
> configure X11 with "sax2 -r -m 0=fbdev". Describe the results.

The graphics hardware is nvidia. I attached an hwinfo file in comment #4. Do you need more than what that will give you?

As far as the install goes, I will give it a try and post back here.

Model: "nVidia Quadro2 MXR/EX/Go"
Vendor: pci 0x10de "nVidia Corporation"
Device: pci 0x0113 "Quadro2 MXR/EX/Go"

I can't test on Quadro 2, but I will test on TNT2 later.

I can somewhat reproduce this (the picture is shifted to the bottom, I can only see the top of the window, the remaining screen is black), but this might be related to the broken TNT2 board.

acceleratedx=1 on the boot prompt works (uses the native nv driver). framebuffer console is broken. This looks like a broken kernel framebuffer. Seriously ...

I will try the acceleratedx=1 and see if that works for me as well. However, I don't see the same issue as you with the picture shifted to the bottom. Mine is blank.

The acceleratedx=1 option worked for my issue as well.

Works here as well! Excellent. Will this make it into Beta 8?

(In reply to comment #9)
> Install with "vesa" option and try to
> configure X11 with "sax2 -r -m 0=fbdev". Describe the results.

Same results as during the install. Screen goes blank.

This smells like a major bug. :-(

(In reply to comment #19)
> (In reply to comment #9)
> > Install with "vesa" option and try to
> > configure X11 with "sax2 -r -m 0=fbdev". Describe the results.
> 
> Same results as during the install. Screen goes blank.
> 
Does the screen restore properly when the Xserver is killed (for example with ctrl-alt-backspace)?
Also could you please attach a log of this Xserver?

*** Bug 154101 has been marked as a duplicate of this bug. ***

*** Bug 155522 has been marked as a duplicate of this bug. ***

The list is getting longer and longer:

- TNT2
- GeForce2 MX
- GeForce2

And it sounds that this new bug has been introduced with Beta5 (maybe already with Beta4, if I understand Karsten correctly in Bug #154101).

It starts with Beta4 for me, but unfortunatly beta2/beta3 did not boot on this machine, so it maybe already the case with beta2/beta3 too. I will try to boot beta2/beta3 CD2 to verify again.
And yes, <ctrl>-<alt>-<bs> dosn't help, seems the kernel freeze hard.
I can try adding a serial console log.

Thanks for verifying, Karsten. I can't reproduce the hard freeze. The display is just shifted to the bottom so you can only see the top of the picture. The rest remains black. Henne is another victim:

- TNT2 Model 64

(In reply to comment #25)
> The list is getting longer and longer:
> 
> - TNT2
> - GeForce2 MX
> - GeForce2
> 
> And it sounds that this new bug has been introduced with Beta5 (maybe already
> with Beta4, if I understand Karsten correctly in  Bug #154101).

I have had this eith beta 4 as well. I don't know about earlier betas, but I know that I didn have it for beta 4.

> So I tried to boot old betas to find out when this starts:
> Beta1 - worked
> Beta2 - do not show bootscreen (black) but after timeout it boots from HD
> Beta3 - same as Beta2
> Beta4 - same as Beta5
> Beta5.2 - same as Beta5

I only tried Beta3 and Beta4, but I can see exactly the same problems with
my TNT board. These problems don't occur at all e.g. with a GeForce 4 MX
with the same machine.

OK, I verified, that the problems start with Beta2. CD2 is not longer a boot disk, but fortunately I only do not see the boot menu with B2/CD1 on the screen and so cursor down <return> start installation and I see the splash screen and after <ESC> I see the kernel/installation messages and it freeze again after starting yast.
Hmm, with a simple serial console (console=ttyS0,115200n8) I do not enter graphic install, but text install on the serial line, do I need some special console= setting to get both, serial log and graphical install ?

(In reply to comment #21)
> Does the screen restore properly when the Xserver is killed (for example with
> ctrl-alt-backspace)?

That worked for me to get it back. So it doesn't appear to hard lock for me.

Well, I experienced this problem only on SL 10.1 Beta 6. Beta 4 was O.K. I skipped Beta 5. 
And ctrl+alt+bs didn't helped. I had no signal to the monitor all the time.

(In reply to comment #21)

> Also could you please attach a log of this Xserver?

Are you wanting the xorg.0.log or the sax.log or some other log.

> Hmm, with a simple serial console (console=ttyS0,115200n8) I do not enter
> graphic install, but text install on the serial line, do I need some special
> console= setting to get both, serial log and graphical install ?
I ran into the same problem. What you can do is:

boot prompt: instshell=1 (--> shell)
setup network/ssh/password in shell, e.g. 
  modprobe tulip
  dhcpd eth0
  inst_setup_ssh
  passwd
login via ssh  

> Are you wanting the xorg.0.log or the sax.log or some other log.

Both at best.

*** Bug 156393 has been marked as a duplicate of this bug. ***

Created attachment 72021 [details]
xorg.0.log from Joes machine

Created attachment 72022 [details]
sax.log from Joes machine.

JOe, we need the files for "sax2 -r -m 0=fbdev" ...

Created attachment 72041 [details]
another sax.log

I thought that I did, but I guess that when I did the CNTL ALT backspace that it renamed them. Anyway, it doesn't appear to be writing to the xorg.0.log file, but it does appear to be writing to the SaX.log. The interesting thing is that when I did a sax2 -r -m 0=fbdev and the screen went to no signal, I decided to switch over to CNTL ALT F2 so that I could rename the current SaX.log file so that I wouldn't loose it if I restarted X (assuming that restarting X would rename it). I then switched back to CNTL ALT F7 expecting to need to do a CNTL ALT backspace and I had my screen back with the sax2 window having been launched. If I don't switch over then it stays blank with "no signal", but the simple act of switching displays seems to have an affect on my system. Hope this helps.

Better try "sax2 -r -m 0=fbdev -a" instead. This creates the configuration without any user input.

Created attachment 72052 [details]
yet another sax.log

Same result as before, except when I switch between CNTL ALT F2 and CNTL ALT F7 I see the following in the terminal. I assume this is what you expected.

jharmon@linuxjoe:~> sax2 -r -m 0=fbdev -a
SaX: root Password:
SaX: initializing please wait...
SaX: your current configuration will not be read in

SaX: access to your display has been granted

SaX: startup

SaX: creating config file please wait...

SaX: Automatic configuration is done
SaX: The file /etc/X11/xorg.conf has been written

And now attach /var/log/Xorg.0.log etc /etc/X11/xorg.conf again. Hopefully this is the fbdev configuration this time.

Created attachment 72057 [details]
xorg.conf

It is not creating an xorg.0.log file. I deleted it before running the tests the second time and it has never created it again.

I forgot to mention to start an Xserver to create the logfile.

Created attachment 72060 [details]
xorg.0.log from 0=fbdev

Here you go.

Created attachment 72063 [details]
config created with sax2 -r -m 0=fbdev -a

Created attachment 72064 [details]
logfile kernel beta7

Created attachment 72066 [details]
logfile kernel beta1

If I boot the Beta1 kernel, it works, with Beta7 kernel it hang.

Hmm ...

@@ -583,7 +583,3 @@
 Could not init font path element /usr/X11R6/lib/X11/fonts/local, removing from list!
 Could not init font path element /usr/X11R6/lib/X11/fonts/CID, removing from list!
 (EE) FBDEV(0): FBIOBLANK: Invalid argument
-(II) Open ACPI successful (/var/run/acpid.socket)
-(EE) FBDEV(0): FBIOBLANK: Invalid argument
-(II) Mouse[1]: ps2EnableDataReporting: succeeded
-FreeFontPath: FPE "/usr/X11R6/lib/X11/fonts/misc:unscaled" refcount is 2, should be 1; fixing.

Karsten, could you also check Beta2 kernel? so we can see if it really has got broken between Beta1 and Beta2 kernel.

The 
(EE) FBDEV(0): FBIOBLANK: Invalid argument
lines are irrelevant.
We did fix ACPID support. You may want to try with the -noacpi command line option.
If I understand correctly this happens during installation before the first reboot. I was not able to reproduce this on Beta3. 

Starting X works with all kernels (Beta1-Beta7) with the xorg.conf from comment #47.
But it always crash graphics (tested with Beta1,Beta6,Beta7 kernels on a Beta7 installation) if I start 'sax2 -r -m 0=fbdev -a'.

Created attachment 72099 [details]
strace -f -o sax2.trace sax2 -r -m 0=fbdev -a

This is a strace from sax2 with all forked processes
after this graphic is dead.

Egbert, I only wanted to summarize the relevant diff between the use of kernel for Beta1 and Beta7. I don't think it's related at all to ACPI.

And as Karsten writes in comment #52 it no longer seems to be related to the kernel at all.

I don't want to investigate SaX2 related problems here. During installation
(this problem already occurs when Xserver starts at the beginning of the installaion!) a pregenerated config file for fbdev is used.

Egbert, which graphics board did you try?

Excuse me. But I have a question. I experienced something like freeze at the beginning of instalation, which should be a blocker bug. It wasn't a freeze of the kernel, the numlock was reacting. But the monitor was without signal and nothing helped (ctrl+alt+bs, ctrl+alt+F1, etc.)
 Are you solving the freeze or the shift of the display in this bug?

I think it's the same problem. On my TNT2 e.g. I get a shift in 800x600 and a signal lost in 1280x1024 resolution. Meanwhile I found a GeForce2 MX, which is not affected by this problem. Which means that not every NVIDIA board <= GeForce 2 seems to be affected. 

It's interesteing that I didn't hear from this problem before Beta6 (although it probably exists since Beta2). Sound like people with such old graphics boards didn't begin testing before or at least did not report this problem. :-(

*** Bug 155956 has been marked as a duplicate of this bug. ***

I agree it is related. But my videocard is GF 2 MX-400 which is newer then 2MX, 2Ti and is yet supported by the nVidia binary driver. So there could be more people having this graphics card, than older GF 2MX or GF 2Ti. 
It is suspiciously that I didn't experienced this problem when installing SL Beta4 or 3. I didn't try NLD installation. 

The same problem also happens when starting a 10.0 Xserver/modules during 10.1 Beta7 installation (I managed to copy a 10.0 Xserver+modules during installation on the machine and started a second fbdev Xserver with the same fbdev config). The logfile shows only minor differences.

--- 10.1 Beta7 X.Org
+++ 10.0 X.Org 
[...]
-(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
-(II) No APM support in BIOS or kernel
+(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
[...]
 (EE) FBDEV(0): FBIOBLANK: Invalid argument
+(EE) FBDEV(0): FBIOPAN_DISPLAY: Invalid argument
[...]
-(**) Mouse[1]: ZAxisMapping: buttons 4, 5, 6 and 7
-(**) Mouse[1]: Buttons: 11
+(==) Mouse[1]: Buttons: 3

Karsten, could you provide the iso image of Beta1 CD1? This would be very interesting for me.

> Karsten, could you provide the iso image of Beta1 CD1? This would be very
> interesting for me.
Since it's no longer available via /mounts/dist/install ... :-(

I finally managed to find a Beta1 CD1 (by accident of course). Installation works fine and starting a Beta2 Xserver (including the modules) works fine as well. I no longer this this is a X.Org related issue.

Created attachment 72351 [details]
Kernel RPM changelog diff

In case it's kernel related. Here is the diff between the changelog of Beta1 and Beta2 kernel.

> I finally managed to find a Beta1 CD1 (by accident of course). Installation
> works fine and starting a Beta2 Xserver (including the modules) works fine
> as well.
The same for X.Org of Beta7.

Oddly, I cannot reproduce this here with beta7 and a TNT2.

I had it happen on beta 7.

I've tested this with different cards on different systems (both x86 and x86-64) and still cannot see this problem.

Egbert, looks like I need to send you the TNT2 board, with which I can reproduce this problem. Unfortuntately I can only reproduce this problem
during installation and not afterwards. :-(

*** Bug 154638 has been marked as a duplicate of this bug. ***

An important one.

Just for the record. With Beta3 I even cannot get a boot screen with my TNT2, which works fine with a different gfx board. This is more than strange.

> Stefan, I found a card/machine combo with which I can reproduce this.
Great to hear this, Egbert!

> Would you please be so kind and add information how I can prevent the
> Xserver to start during installation
Good question. Currently I don't know the answer. Fortunately I was still able to switch to a only partly broken console. I will investigate.

> Also I would like to know how to log into the install system remotely. I
> know you've posted this on IRC - but IRC is rather volatile.
boot prompt: instshell=1 (--> shell)
setup network/ssh/password in shell, e.g. 
  modprobe tulip
  dhcpd eth0
  inst_setup_ssh
  passwd
login via ssh  

boot prompt: startshell=1
Setup ssh in the shell as mentioned above. After terminating the shell YaST2 would start regularly.

Hmm. Starting a plain Xserver (using a generated config file by YaST2) *before* yast runs *does* work. What's going on here?

After starting yast2 starting a plain Xserver is broken in the same way it is when yast2 is starting. Something in yast makes the Xserver unusable.

> After starting yast2 starting a plain Xserver is broken in the same way it
> is when yast2 is starting. Something in yast makes the Xserver unusable.
Probably some hardware probing.

Steffen finally figured out that the changes for "hwinfo --monitor" is the culprit. Probably it triggers a BIOS bug. Steffen, could you add a new statically linked hwinfo for testing? Thanks.

Created attachment 72793 [details]
hwinfo checking only 3 ports

Statically linked hwinfo checking only 3 monitor ports.

Created attachment 72794 [details]
hwinfo checking only 2 ports

dto, 2 ports

Ok, here is the story that comes with it: hwinfo looks at up to 4 ports
for monitors. It is not possible to know in advance how many connectors the
gfx card has, so it just goes for 4. Apparently some BIOSes have problems
with this approach. You can use the above hwinfo-variants for testing.

At least on Stefan's machine hwinfo3 did work. So, presently I will
change it to look at at most 3 ports unless some test results indicate that
hwinfo2 is required.

Bryan, Karsten, Katarina, Keith, Stanislav, Henne and all the others, who are affected by this problem. Could you boot your installed system in runlevel 3 with kernel framebuffer enabled and report the results of executing:

1) hwinfo2 --monitor
2) hwinfo3 --monitor
3) hwinfo --monitor

(in this order)? Thanks. hwinfo2/hwinfo3 has been attached by Steffen (comments right above) and hwinfo is the one of the installed system.
Hopefully hwinfo2/hwinfo3 won't break your console. hwinfo will likely do 
it!

(In reply to comment #84)
> Could you boot your installed system in runlevel 3
> with kernel framebuffer enabled and report the results of executing:

So I would assume that you mean pass in the following parameters right?
init 3 x11i=fvdev

or would I replace the x11i=fbdev with something else?

No, I assumed that you already have done an installation with vesa. The you only need to add "3" as boot option.

hwinfo2 --monitor  -  Worked fine
hwinfo3 --monitor  -  Immediately killed the video
hwinfo --monitor   -  Also killed the video

These are on Compaq Deskpro EN machines.

No, I assumed that you already have done an installation with vesa. The you only need to add "3" as boot option.

(In reply to comment #86)
> No, I assumed that you already have done an installation with vesa. The you
> only need to add "3" as boot option.

No, I reinstalled with the acceleratedx=1 when beta 7 came out.
 

> No, I reinstalled with the acceleratedx=1 when beta 7 came out.
Should not matter. kernel framebuffer should still be available nevertheless.

Steffen, it looks like the cards that have problems with this are older ones.
Would it make sense to restrict the test for additional ports to cards that have a VBE version 3.0 or above?

IIRC nvidia uses vbe 3 for years now, even the old TNT boards have it.

> hwinfo2 --monitor  -  Worked fine
> hwinfo3 --monitor  -  Immediately killed the video
> hwinfo --monitor   -  Also killed the video

I can reproduce this on

- TNT2 PCI    10de:002d
- GeForce2    10de:0150
- GeForce2 MX 10de:0110

I found a TNT2 (also 10de:002d), on which hwinfo3 works and a GeForce 2 MX (also 10de:0110) on which all hwinfo versions work.

Egbert, the board on which hwinfo3/hwinfo(4) does *not* work has a VBE version 3.0. :-( It's the GeForce2 MX (10de:0110) mentioned above. BTW, when calling
"hwinfo --vbe" the monitor gets black. :-(

#hwinfo --vbe
[...]
  VESA BIOS Version: 3.0
[...]

I'm afraid we need to revert the changes in the monitor detection. :-(
According to Ralf via chipsets are affected as well. :-(

Steffen, please submit the hwinfo2 (2-port) version for STABLE. Thanks.

in hwinfo 12.14

This is really unfortunate. A lot of functions that are specified in the VBE but not commonly used seem to be broken on numerous cards.
It makes these features useless for all other cards where they do work.

  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x0113 "Quadro2 MXR/EX/Go"
  SubVendor: pci 0x10de "nVidia Corporation"

hwinfo2 --monitor worked
hwinfo3 --monitor worked
hwinfo --monitor didn't work

Is it possible to switch to init 3 typing the command init 3 in console?
I did this and all hwinfo worked. This is queer. 

Well, init 3 and boot to runlevel 3 has different results.
hwinfo2 --monitor - no problem
hwinfo3 --monitor - killed the graphics card output
hwinfo --monitor - killed the graphics card output

Well the hwinfo2/3 trick did not work for me:
hwinfo2 --monitor  -  Illegal instruction
hwinfo3 --monitor  -  Illegal instruction
hwinfo --monitor   -  Gives hwinfo output (with 640x480@73Hz output)

My system is a SUSE Linux 10.1 Beta7 on a VIA EPIA ME600 motherboard.
But as I tried many things yesterday (including vga=0x311 and several
sax2 calls) I will reinstall from scratch now (over night) in VESA
mode and try again tomorrow morning. If I still see the same results
I will bring this system into the office tomorrow.

Without any vga parameter (snwint said this is equal to choosing VESA mode)
and with 640x480 video setting in BIOS I can not install because it assumes (or falsely detecs) somehow a 800x600 display and so I only get a subset of the info/dialog on the screen. Same problem exists if I choose 600x800 in
BIOS as mode. With 1024x768 it works and displays all info. I have started
a fresh install with this now.

> Well the hwinfo2/3 trick did not work for me:
> hwinfo2 --monitor  -  Illegal instruction
> hwinfo3 --monitor  -  Illegal instruction
Ralf, this looks like a different problem. Probably because Steffen linked
these hwinfo binaries statically against glibc i686 and you have a i586 CPU
(VIA).

OK for completeness:
hwinfo2 --monitor  -  OK
hwinfo3 --monitor  -  no video
hwinfo --monitor   -  no video

hwinfo --vbe identification:
  Model: "NVidia NV10 Reference Board"
  Vendor: "NVidia Corporation"
  Device: "NV10 Reference Board"
  SubVendor: "NVidia"
  SubDevice:
  Revision: "Chip Rev A1"
  Memory Size: 64 MB

hwinfo --gfxcard identification
  Model: "nVidia GeForce2 MX/MX 400"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x0110 "GeForce2 MX/MX 400"
  Revision: 0xb2

(In reply to comment #102)
> Without any vga parameter (snwint said this is equal to choosing VESA mode)
> and with 640x480 video setting in BIOS I can not install because it assumes (or
> falsely detecs) somehow a 800x600 display and so I only get a subset of the
> info/dialog on the screen. 

Can you please check the Xserver log file for the driver used and the size that is reported there?
There are different possibilities: 
1. It may be that YaST cannot deal with anything smaller than 800x600.
2. The BIOS may indeed have set up a 800x600 framebuffer stride and expects you to pan thru a virtual screen. This sometimes happens on older chipsets for panels in panel only or panel + external mode when the panel size is lower than 1024x768.

yast requires at least 800x600 and will not even start with anything lower.

*** Bug 156954 has been marked as a duplicate of this bug. ***

*** Bug 158622 has been marked as a duplicate of this bug. ***

*** Bug 158224 has been marked as a duplicate of this bug. ***

Did the fix of this problem make it to beta8 ?

no, was too late

It did make SLED/NLD beta 8.

The bug is still in SUSE-Linux-10.1-beta8

see comment 111

*** Bug 157376 has been marked as a duplicate of this bug. ***

adjust product so more people can view this bug

*** Bug 159731 has been marked as a duplicate of this bug. ***