Booting Problems after 11.3 Install

Hi everyone,

I recently tried to upgrade my openSuSe 11.1 system using the instructions at:

SDB:System upgrade - openSUSE

I successfully got the system to 11.2, but the upgrade from 11.2->11.3 went awry. The installation froze during the update, and I had to start it over. The first issue I had to deal with was the fact that rpm had been upgraded and zypper hadn’t, so zypper wouldn’t function because older rpm files that it would search for had been deleted. After rolling back rpm to a previous version, I managed to complete the upgrade to 11.3 and everything looked good. However, when I rebooted the system, it hangs at a blank screen. More precisely, the system seems to get through all of the BIOS stuff and then hang while loading the OS (I assume). Although I’ve worked on Windows boxes for a long time, I’m a complete novice at OS installations/upgrades for Linux systems, so I’m not even quite sure where to begin to troubleshoot this. Ideally, I’d like to be able to fix the installation on the system to save the data on the hard drives, but I realize this might not be possible. My first thought was to use a recovery tool that I’d seen on some Linux installation CDs, but I see that for openSuSe 11.3 and on that utility has been dropped. I can, however, use the disk to get to the “Rescue” command prompt, so maybe there’s something I can do from there?

Thanks in advance for any advice, and for reading my essay of a post. Please let me know if there are any other details you require, and I hope to learn something from this whole mess, so feel free to scold me for any bone-headed mistakes I may have made :slight_smile:

-Matt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Can you tell what hardware do you have? and more important, exactly what
happen when you press the enter key on grub and start to boot the
system? it hang up on the splash screen? if so, the ESC key work? the
failsafe mode hang up?


VampirD

Microsoft Windows is like air conditioning
Stops working when you open a window.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk3v0rsACgkQJQ+0ABWtaVnuNgCfUEpMX4uEwyszuakNq0uHG8Rv
VxkAoJIQwvub/mWT5JXiz5kLZIBfqCBW
=W4Vd
-----END PGP SIGNATURE-----

The graphics system has been changing incrementally in every openSUSE version starting around openSUSE-11.2 or so. 11.3 had more changes. 11.4 had more changes. Coupled with these graphic changes were kernel changes with Kernel Mode-Setting (KMS) implemented where KMS is supposed to help in the automatic configuration of detected hardware graphic devices. Unfortunately that has not always worked well.

These is a possibility (and I am speculating) that KMS is a cause of your problem. So try to disable KMS when booting to see if that might be the problem. You can do that by typing the boot code ‘nomodeset’ (no quotes) in the options line of the grub boot menu.

Also, did you try booting to the Fail Safe Settings when this problem occurred ? That’s a very important thing to try.

Thank you both for the replies. This is a general use server for scientific computing that 99% of the time the members of my lab log into remotely. Here’s the hardware setup:

CPUs: 8 Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
Memory: 48 GB of RAM
Disk: 4.1 TB Harddrive

My apologies if I’ve left something out that you need from the hardware specs. I’ll hunt down other info if need be.

As to exactly what happens upon startup, with a boot CD in the computer, I make it all the way to the boot CDs menu. If I choose “Boot from harddrive”, I get to a menu that let’s me pick if I want to boot 11.3 or 11.3 Failsafe. After selecting either one of these options I get to a blank screen. I’ve also tried remotely logging in to see if maybe the server is running and the screen is out, but other servers can’t see it, so I’m not sure if it’s a graphics issue (although I’ll try the suggestion oldcpu). I double checked inittab to make sure the boot level supported networking btw and it does.

Video chip/card. This is the most likely place for a problem. Do you see the splash screen at all?

Don’t forget to try the mediacheck.

Wrt the boot CD, did you check the md5sum of the downloaded .iso file and compare that to the md5sum posted on the download website? Were they the same? When burning the .iso file to a CD, did you burn at the slowest speed your burner allows to a +R or -R media (not to an RW) to a high quality CD media (and not some bargain basement special ? ). Burning at slow speeds to high quality +R/-R reduces the risk of occurrence of remote obscure problems with the CD media.

I’m going to try the suggestions that were made about the video chip and mediacheck shortly. As to potential problems with the boot CD, I’ve only used the boot CD to try to get to the rescue terminal. All of the updating (from 11.1->11.2 and 11.2->11.3) I did via the web and based on the instructions in the link in my first post. I’ve also tried two different boot CDs (one that was in the machine from the 11.1 install and a new 11.3 CD I made today), so I’m not sure that they are causing any issues. However, if you have a suggestion as to the kind of problem it might cause based on the way I’m using it, please let me know. Thanks for all your help.

-Matt

Seems like booting with “nomodeset” did the trick. I suppose this kind of issue caused it not only to display a blank screen, but to hang the bootup since I wasn’t able to log in remotely before? In any case, things look ship shape now, and I will try updating to 11.4. Is there a way to make the “nomodeset” a permanent option for boot up? You guys have been great and saved me a lot of aggravation. Thanks again.

-Matt

Thats good to hear, but its also a bit surprising that failsafe did not work, as that also uses the ‘nomodeset’ boot code.

Yes. You can edit the /boot/grub/menu.lst file.

Post here the exact contents of that file and we can explain the exact edit needed. You will need root permissions to open and view that file. DO NOT change anything unless you know PRECISELY what you are doing, as changing the menu.lst file can break your openSUSE boot.

To also better understand WHY nomodeset works, can you please open a terminal and run the following command to list your VGA device(s).


/sbin/lspci -nnk | grep VGA -A2

and then post the output of that command here.

Always the potential for user error, so maybe I did something differently this time around then I did when trying to boot with failsafe before? I can give rebooting a couple more tries to be sure that this solved the problem if it doesn’t seem a reasonable fix given the symptoms I’ve described.

CONTENTS OF MENU.LST

Modified by YaST2. Last modification on Mon Jun 6 18:09:33 PDT 2011

THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader

Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don’t change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.3 - 2.6.34.8-0.2
root (hd0,1)
kernel /boot/vmlinuz-2.6.34.8-0.2-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 resume=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part1 splash=silent showopts vga=0x314
initrd /boot/initrd-2.6.34.8-0.2-default

###Don’t change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe – openSUSE 11.3 - 2.6.34.8-0.2
root (hd0,1)
kernel /boot/vmlinuz-2.6.34.8-0.2-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x314
initrd /boot/initrd-2.6.34.8-0.2-default

###Don’t change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.2 - 2.6.31.5-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.31.5-0.1-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 resume=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part1 splash=silent showopts vga=0x314
initrd /boot/initrd-2.6.31.5-0.1-default

###Don’t change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe – openSUSE 11.2 - 2.6.31.5-0.1
root (hd0,1)
kernel /boot/vmlinuz-2.6.31.5-0.1-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x314
initrd /boot/initrd-2.6.31.5-0.1-default

OUTPUT OF /sbin/lspci -nnk | grep VGA -A2

0e:0d.0 VGA compatible controller [0300]: ATI Technologies Inc ES1000 [1002:515e] (rev 02)
Subsystem: Dell Device [1028:01b1]

Ok to make ‘nomodeset’ permanent, you need to add it to the precise location noted below. (I highlighted it in red to make it easier to find):


# Modified by YaST2. Last modification on Mon Jun  6 18:09:33 PDT 2011
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,1)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.3 - 2.6.34.8-0.2
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.34.8-0.2-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 resume=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part1 splash=silent showopts vga=0x314 **nomodeset**
    initrd /boot/initrd-2.6.34.8-0.2-default

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.3 - 2.6.34.8-0.2
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.34.8-0.2-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x314
    initrd /boot/initrd-2.6.34.8-0.2-default


###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.2 - 2.6.31.5-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.31.5-0.1-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 resume=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part1 splash=silent showopts vga=0x314
    initrd /boot/initrd-2.6.31.5-0.1-default


###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.2 - 2.6.31.5-0.1
    root (hd0,1)
    kernel /boot/vmlinuz-2.6.31.5-0.1-default root=/dev/disk/by-id/scsi-36001e4f02f0bf4001127e87e5787b8f2-part2 showopts ide=nodma apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x314
    initrd /boot/initrd-2.6.31.5-0.1-default

Save the change. Note thou that a kernel update could remove that ‘nomodeset’ entry, so after every kernel update, BEFORE rebooting, check to see that ‘nomodeset’ is still in place.

I can also see I am getting openSUSE-11.3 mixed up with openSUSE-11.4. It appears openSUSE-11.3’s menu.lst for failsafe does NOT have ‘nomodeset’ as a boot code, but openSUSE-11.4’s does. That would explain why failsafe did not work for you (as nomodeset was not one of the boot codes).

Hmmm … I’m not familiar with the ES1000, although some research suggests its an RV100 series and it should be supported by the ‘radeon’ open source driver. Unfortunately that command did not tell me the driver (typically it does tell the driver).

By specifying ‘nomodeset’ , openSUSE-11.4 (and I think 11.3) will boot X using the ‘radeonhd’ opensource graphic driver, instead of the ‘radeon’ opensource graphic driver. Now the ‘radeon’ open source graphic driver is better supported and typically has superior performance to the ‘radeonhd’.

Check your /var/log/Xorg.0.log file to see what video driver you are using (radeon or radeonhd)

If you are using the radeonhd, then I recommend you try this, … edit the /etc/X11/xorg.conf.d/50-device.conf file, removing the ’ # ’ sign in front of the line with ‘radeon’ in it such that that file looks like:


Section "Device"
  Identifier "Default Device"

  Driver "radeon"

  ## Required magic for radeon/radeonhd drivers; output name
  ## (here: "DVI-0") can be figured out via 'xrandr -q'
  #Option "monitor-DVI-0" "Default Monitor"

EndSection

and then reboot using the boot code ‘nomodeset’ as before. I think that should work and you should have superior graphics performance. And if it fails, then reapply the " # " to comment out the line in the 50-device.conf file.

Even with nomodeset, when I grep for “radeon” in the /var/log/Xorg.0.log file I get:

21.215] (II) LoadModule: "radeon"
21.216] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so
21.222] (II) Module radeon: vendor="X.Org Foundation"

Nothing when I grep for “radeonhd”. Does this mean I’m still using the radeon driver? In the end, it might be moot because we almost never use this computer for graphical things. Usually just computation and occasionally plotting things in R/Python.

The 11.4 install went smoothly and everything seems to be running great. Thanks for all the advice and especially oldcpu for taking the time to spell things out very clearly. I learned quite a bit.

Its unlikely that one can draw a conclusion from that, as one should have many more ‘hits’. Note Linux is case sensitive and if you did not use the " -i " option in grep, then you likely missed many upper case “RADEON” hits.

Thats great news !