Installing on IBM NetVista - video goes dead

I got my hands on an IBM NetVista 2257 machine and since the other PC I had OpenSUSE11 on was flaky(bad HD, bad power supply, frequent system lockups and every now andf then HD corruption) I figured I’d migrate to this other PC. The problem is that during the initial set up when, after the 1st reboot, OpenSUSE tries to autodetect the video card the video goes dead and that’s it, I can’t get any further beyond that. If I shut down then restart I get the option to retry the setup, but it always gives the same behaviour, it gets to the “Don’t panic, X11 needs to switch to console to detect video…” screen, then there’s briefly some graphical garbage displayed and the video signal goes dead and monitor goes into power-save mode. I also notice the keyboard stops responding, at least I think so since the caps lock and numlock keys no longer seem to function, obviously without video it’s hard to tell whether anything else is working.
Is there some way to skip the video autodetection, or some trick to preloading whatever IBM-peculiar video driver I may need?
It works fine in the VESA mode for all the steps prior to the automatic configuration of the hardware.
I thought by switching to this machine I could leave my hardware problems in the dust, the old system was faster, especially with the GeForce card in it, but just way too unstable and this IBM machine was proven stable when it still had XP running on it.

No ideas so far? I’m getting a little discouraged with OpenSUSE. I had so many problems installing on my other system, then the flaky hard drive issue came up, when I got my hands on this IBM machine I thought I would have an easier time of it, but this has stopped me in my tracks. With the video dead I can’t follow through with the installation, and if I try to boot up normally afterwards it seems the admin account isn’t set up properly because I get a username/password prompt but it won’t accept the combo I selected during the installation. I think if I want to get Linux working on this PC I really need to sort out this video detection issue, or find a way to skip it and set up video manually after installation.

Did you try installing in “Text” mode (under F3)? Choose “Automatic Configuration”, too. That may get you past the point where the installation choked. Be careful using this mode, it’s ncurses (like the DOS gui); be sure you are doing what you intend to do (e.g., in the partitioning) what with the different gui.

I did some googling on your machine, and at least a few years ago there were issues with the graphics device. I saw a couple of X server workarounds, but can’t be sure which are applicable now as since there is a newer driver. But first let’s see if we can just get you fully installed, then deal with that.

EDIT: Possibly something to try first: In the Boot Options below on the DVD menu, enter “x11failsafe” (without the quotes), and then install as you tried before.

The problem is with the integrated 810 video or rather the default driver that opensuse uses for it. You might be able to install using vesa and definitely using text. Once installed change to the intel driver from i810 with ‘sax2 -r -m 0=intel’.

I think you may be right, although the i810 is still available. The challenge is that the installation, even in text mode, will still run sax under the hood and try to configure the server. Hopefully that will not kill the installation.

@grosporina - if the suggestions above do not work, another approach would be to install without the X server (a “server” install). Thereafter, from the command line we can install X and the Desktop Environment, and from there configure the driver.

Do the regular install, mount the hard drive and modify xorg.conf to use the ‘intel’ driver directly. Just remember to do that before reboot. In fact, if you use the KDE4 livecd and use sax2 from the command line to change drivers then the installed system should be using that driver.

OP’s install is failing at the video device detection and configuration step. Where during the installation process can OP break out and manually modify the driver to circumvent this?

If using text mode, set sax2 from the console, if vesa works there will be a gui.

I don’t follow. Neither the gui nor text mode installations give the user the opportunity to get at sax2. Your suggestions are fine, once openSUSE is installed. But the OP’s install is failing about 75% in, at the step when the framebuffer is dropped and sax runs its internal server to probe the graphics device and create the X configuration.

Thanks both of you for the help. Mingus, I’ll try what you suggest after work today. I’m not sure about the server install you refer to but hopefully your first suggestion will do the trick.
The other thing I’m pondering is whether it would be practical to swap hard drives with my flaky machine, install on there (after probably many false starts with the PC flaking out along the way, but eventually I would probably get to the end) then make sure it’s using a plain old VESA video driver and swap the drive back into the IBM machine. If it’s clever enough it would probably just try to redetect the video card on boot up and I’d be in the same mess I suppose.

That would work if the two machines had similar or compatible hardware. The main problem with that approach is the loading of incompatible modules. Certain combinations are very likely to cause a system lockup.

The server install is one of the desktop environment options under “Other”. In this approach, the X server is not installed. After installation, at the command line, you can use zypper to install X and the DE.

I did a Text mode regular install including a DE and, and while it did configure the X server under the hood, it did not attempt to run the server. So this route may dodge the problem you experienced.

As far as installing to the drive in the other machine and then moving it, actually that could work, too. openSUSE by default now identifies drives by their unique device-id rather than device name (e.g., /dev/sda) as in the past. Consequently, the files which control the boot and the partition mount, will work in another system.

Great! Progress.
I installed in text mode as suggested and now I have it running, in fact I’m posting this from the very PC in question. While detecting video it again showed garbage, but this time it kept working at it (hard drive going like crazy) and eventually the thing came back to life and booted to the KDE in glorious 800x600.
Definitely the video driver does not like this card though, I tried switching to 1024*768 (after verifying I had a means of reverting of course) and again it showed just garbage. Still, low-res is better than no-res for now.
I’ll just see what happens upon reboot (maybe this is just the computer building me up for a punchline).

Right, progress indeed. So, boot into runlevel 3 (just type a 3 in the Boot Options below on the menu), login as user, and then do “su” (without quotes) to switch to root. Then try this:

sax2 -r -m 0=intel

If sax comes up, configure the device and monitor if necessary, exit, and then do:

exit
startx

If sax did not come up, try instead


sax2 -r -m 0=i810

If again that does not work, repeat and try this:


sax2 -r -m 0=vesa

Report back.

Even better. The first option gave graphical garbage like before but “sax2 -r -m 0=i810” worked, it’s now working in 1024*768 using the i810 driver.
On boot up it still momentarily shows a garbled screen, same on shutdown, luckily I don’t know enough about Linux yet to act on what’s being shown on the console at those times anyway :D.

Hi
At the grub menu (Boot menu) there is an option line enter the
following;


vga=0x317

If that doesn’t work, then try the lower resolution ones from here;
VESA BIOS
Extensions

If it all works, then post back with the option that worked and will
tell you how to add to your boot options.


Cheers Malcolm °¿° (Linux Counter #276890)
openSUSE 11.0 x86 Kernel 2.6.25.18-0.2-default
up 23:33, 3 users, load average: 1.14, 0.82, 0.41
GPU GeForce 6600 TE/6200 TE - Driver Version: 177.80

This might help too, in a command window as root, post back output from:

hwinfo --framebuffer

Hmm… odd results this time. hwinfo --framebuffer spits a few things out to screen but they’re gone by the time it’s done and it’s too fast to tell what it’s printing. I tried redirecting the output to a file but just ended up with an empty file. As for the vga code at the grub menu when I entered something in the range I thought was reasonable (ex: 0x317 or 0x314) it told me that was outside the valid range and provided me a list of options that all looked like text modes (ex: 130x40).
Still, it’s working at the moment, and after watching a few more boots and shutdowns I see that I am catching most of the console action, the garbled screen is just momentarily when the GUI first starts up and finally shuts down. I can see sometimes the “X” cursor trying to show itself among the mess.
You’ve helped me get this mostly happy now I’m inclined to not try to fix it any further for the moment and start doing what I planned to do with this. Start bashing on it getting familiar with Linux and maybe eventually I’ll try my hand at getting this thing the last bit of the way to 100% without having to take up gurus’ time.

Try adding this to the Boot Options below on the grub menu:

edd=off

The bios on that machine is probably too old to support edd, and that can disrupt the video framebuffer. Then run hwinfo --framebuffer again, this type you’ll probably see the supported fb resolutions. Then try


edd=off vga=0x317

If this works, add it to the kernel line in the boot stanza in /boot/grub/menu.lst (using an editor as root).

Unfortunately it’s the same story, nothing to see when I type hwinfo --framebuffer. Next time I boot up I will do it in safe mode and try again. The system is behaving well though so it’s all good and with all these reboots it’s had a lot of chances to mess up.