Bug 157027

Please use more descriptive summary lines - in most cases it's more interesting _what_ is buggy then _how old_ the bug is. I personally don't celebrate a bug's birthday ;-))

What hardware are you using, especially what graphics card and screen? Sometimes it is just necessary for the user to adjust the resolution for the framebuffer. Where does this strange mode come from and does the installation work fine after you chose the correct resolution?

>
> What hardware are you using, especially what graphics card and screen?

These are various graphic cards. I have this "bug/feature" since SLES9.

For example: (SLES9) it was a Radeon
Currently its a i915 on a Fujitsu Siemens with DVI. on a Samsung 940T
I have tested it with CRT and TFTs since years. Always the same.

On SuSE 9.x it was a X300 Ati on an IBM  laptop. During the SLES Time these were
the workarounds:

sles9x64hda_text: vga=0x0f00
sles9x64hdi: vga=788

In some cases it needs exactly these vga entries.

> Sometimes it is just necessary for the user to adjust the resolution for the
> framebuffer. Where does this strange mode come from and does the installation
> work fine after you chose the correct resolution?

When I use in the pxe Installation the paramater vga=0x314 it works.
vga=0x314 was the parameter I got with /proc/cmdline when using the CD.

(So I copied it into the pxe command line.)

When the vga= option is missing kernel starts in text mode 
write "starting udev"...
Sends DHCP request everything is fine.
Then it write using console 80x25 starts yast, and then you have the blank screnn.
You cannot switch to console with STRG+ALT 1
(At least you see nothing, system is running, samsung panel 940T "blinks")

Martin

For which product exactly are you reporting this problem for?

>For which product exactly are you reporting this problem for?

SuSE 10.1 beta6 but I have this Problem since SLES9.
It would be nice if its actually fixed in the final 10.1, this
is the reason why I report this.

Martin

> installer Hangs (black screen) if the paramter vga=0x314 is missing
> in cat /proc/cmdline.

Sorry but I cannot see the problem at the moment. Please state it more precise.

Hello,

its easy to reproduce.
My environment ist doing an autoinstallaion which starts with pxelinux.

If I omit the vga=xxxx line in the pxelinux append line I have the
problem which I describe.

I think people how do an autoinstallation which gets kernel/initrd 
over network are hit by the bug, but its actually a YAST problem/bug.

Martin

Please try to summarize these important issues in your initial comment, it's a totally different problem now. So, this does not happen if you boot normally into your installed system with GRUB?

What is the standard vga mode? Can't you choose the correct resolution for your display? I still don't see a problem here, at this stage it is impossible to predict which hardware is used and magically selecting the correct resolution (like for the installation itself).

>Please try to summarize these important issues in your initial comment, 

1. Use an automated installation
2. make it boot over PXELINUX:

PROMPT 1
DISPLAY info.txt

label itwm101-i386-sda
      kernel kernel_suse101b6_i386
      append initrd=initrd_suse101b6_i386  Insmod=e1000  
             install=http://10.136.16.223/itwm101/inst/CD1 
             autoyast=tftp://10.136.16.221/netinst/suse/autoyast-suse101-lvm.xml


This wont work. if you add
vga=0x314 to the append line it works. It should be reproducible
when omitting the vga=xxx entry in grub as well, but I have not tested
it. I dont think it has something to do with pxelinux, only
with the vga=xxxx append line, on which the YAST installer seem to 
depend somehow.

How was this configuration generated? I don't see the vga=... parameter there.

Hm,

yes. The parameter is missing, which means that it wont work.

If you change it to:

append initrd=initrd_suse101b6_i386  Insmod=e1000 vga=0x314
       install=http://10.136.16.223/itwm101/inst/CD1 
       autoyast=tftp://10.136.16.221/netinst/suse/autoyast-suse101-lvm.xml

it works. As said before: a simple test would be to remove the vga 
entry from the grub installation cd, but it only affects Yast in the
installation ramdisk, not the Yast which is installed.

So the bug is:

If you run an installation and you spawn from the install the X server
there goes something wrong.
Wihout vga the kernel boots over ascii 80x25 then as decribed earlier
when the installation begin you have the black screen and cannot switch the console.

Hello,

I just tried it with the suse cd.

Use a normal beta6 (installed).
Copy boot/loader/linux and initrd to your local harddrive
edit the menu.lst for grub. (remove the vga=xxx entry.
Boot the installation from harddisk..

And it works.
Strange did not expected that.

I will check whats wrong here.

pxelinux over serial line works too.

Uwe: Please provide some help here.

I can't help. It looks like yast in ncurses mode does not work on that machine but that is far beyond my business.
Gaby, I think you yast2-ncurses now?

No, yast ncurses works,
I have tested that with the console=ttyS0,115200 parameter on 
a linuxbios machine (beta6). That works.
Only if I omit the vga entry the pxe variant of booting
make problems.

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

It's not a ncurses problem and sorry, I can't help here.
Reassigning bug to Michael.

Martin, can you propose a valid fix for that problem? What exactly should be changed and were?

Im not sure anymore where the problem is. 
(Because I could not reproduce it with grub.)

Maybe that grub makes some magic initialization
which do not work with autoinstall and pxelinux?

Nevertheless I think that when the Yast2 graphice based installer
starts X11 it makes somewhere checks which VGA mode to use, then it chooses
something which is always wrong and as a result you dont see anything
on the screen. No switching of consoles etc...

Somewhere in the grahics initilisation of the X Server which is started
when using pxelinux is buggy. 
The machine is pingable, but I cannot login over ssh to check which
x.org configuration is used.
Should it be possible to login into the installer with ssh?
Then I may provide some additional information.

Taking Stefan and Ruediger into CC. Can either of you help here?

I don't think I can help here, but I don't see a problem specifying vga=0x0314
as default. 800x600@16bit shouldn't be that exotic nowadays. :-)

I think its a bug somewhere, probably the X11 server
who ist missing some "hint" or something.
If I could loggin over ssh this would be fine.

console=ttyS0,115200 is not an option, because that works
and starts yast over serial line.

> I think its a bug somewhere, probably the X11 server
> who ist missing some "hint" or something.
> If I could loggin over ssh this would be fine.

boot prompt: startshell=1
setup network/ssh/password in shell, e.g. 
  modprobe tulip
  dhcpd eth0
  inst_setup_ssh
  passwd
After terminating the shell (graphical) YaST2 will start regularly.

login via ssh ...

Hello,

checked with b8, beta9 still downloading.
New findings:

- remove vga=0x... and put the panel at analog VGA
  and it works.
- remove vga=0x... and put it on DVI it does not work
- add vga=0x.. on the DVI output and it works.

So the new finding is:

VGA works when vga=0x.. is missing
DVI does not work when vga=0x... is missing.

strange. Dont know if this qualifies as a software bug anymore.
Havent checked if this is the same with grub loading only pxe

Using vga=0x... is default and connecting the monitor to DVI output works according to your research. So where is the problem?

Hello

attached is the difference in the xorg.conf.
between working(+) non working(-)

It seems that the DVI adapter does not work over vesa mode.
I think more and more that this bug is related to hardware
and or special chipsets.


--- /tmp/geht_nicht.xorg.conf   2006-04-03 14:30:20.000000000 +0200
+++ /tmp/get.xorg.conf  2006-04-03 14:36:58.000000000 +0200
@@ -227,6 +227,6 @@
   InputDevice  "Keyboard[0]"   "CoreKeyboard"
   InputDevice  "Mouse[1]" "CorePointer"
   Option               "Xinerama"              "off"
-  Screen   "Screen[vesa]"
+  Screen   "Screen[fbdev]"
 EndSection
 

Ok. But I still don't see the problem, when it works connecting the monitor to DVI. Can you explain?

Well, its an automated installation with autoyast,
where you need to know which command line parameters
you pass during booting.

I live with this bug this SLES9 and my idea was to 
check whats really going on.
I never debugged the problem this far.

I think that the vesa mode does not work with DVI and vesa
is the fallback when no vga=0x... is given on the commandline.

Its not that I dont know a workaround, of course, its only 
a bug or a feature.

Ok. I understand. As mentioned earlier it wouldn't be that exotic to use vga=0x314 as default (800x600@16bit) for a autoyast installation. Can you
live with that?

Well it should be documented somewhere, and maybe Uwe Gansert

http://www.suse.com/~ug/

should be involved. I think its today very common to have
a DVI Monitor and setting up an autoinstallation with
pxelinux is the way to use autoyast.
And not setting a command line parameter would be the first
start to use pxelinux/autoyast2.

I really think that many people will ran into this 
feature. 

Is this bug report in the google searchspace ?

> Well it should be documented somewhere, and maybe Uwe Gansert should be 
> involved.
Now in Cc.

> I think its today very common to have a DVI Monitor and setting up an 
> autoinstallation with pxelinux is the way to use autoyast. And not setting
> a command line parameter would be the first start to use pxelinux/autoyast2.
Why? I still think vga=0x0314 would be a good default.

Reassigning to Uwe for a comment.

Yes, I think it's enough to add something to the autoyast documentation. Just that it's recommended to use the vga=... kernel boot option for a graphical
installation. vga=0x0314 (800x600@16bpp) should be a good default, which always work.

okay, I'll add something to the autoyast documentation, that it's recommended to add the vga=... parameter with PXE installations.
Can I close this then? I mean, somehow this got my bug now.

documentation updated
Fixed.