openSUSE 11.3 Problem nach Kernel Update

Nureinnarr · 18 Okt. 2010

Hallo,

nach erfolgreicher Installation von openSUSE 11.3 mit Gnome Desktopumgebung sind mir u.a. zwei Kernel-Sicherheitsaktualisierungen angeboten worden.

Ich glaube es war das Update auf Kernel 2.6.34.4 (noarch 3038) und ein weiterer Fix (noarch 3315).
Yast ruft danach mkinitrd und SUSEconfig auf, die auch beide ohne Fehler durchlaufen.

Nun fangen die Schwierigkeiten an:
Nach einem normalen Reboot wird der Bildschirm nach der Ausgabe "starting firewall phase 1 of 2" (oder ähnlich) schwarz und das System hängt sich auf. Das heißt, ich kann auf keines der Terminals mittels Strg-Alt-F1 usw. wechseln. Es bleibt mir nur ein Hard-Reset.

Wenn ich das System über Failsafe starte, komme ich immerhin bis zum gdm Login. Nach Eingabe des Kennworts wird Bildschirm aber weiß und das System hängt sich nach einigen Minuten ebenfalls auf. Nach einem erneuten Hard-Reset und Failsafe-Start habe ich dann kurz nach Eingabe des Kennworts auf die erste Konsole gewechselt mich als root eingeloggt und versucht das Problem durch die Installation des neuesten Kernels zu lösen (2.6.34.7-4.x).

Leider ohne Erfolg.

Kann ich zypper von der Konsole aus nun irgendwie dazu bewegen, den "alten" Kernel (2.6.34-12) zu installieren? Ich werde aus der man Page nicht ganz schlau, was ich zypper dazu an Optionen mitgeben muss.
Meine Versuche endeten bisher immer mit der Meldung "kernel-desktop ist bereits die neueste Version und kann nicht aktualisiert werden".

Liegt das Problem vielleicht daran, dass ich eine ATi Grafikkarte verwende? Ich verwende jedoch nicht den proprietären Treiber sondern "radeon".

Lieben Gruß,
Alex

josef-wien · 18 Okt. 2010

Ich denke, daß Dir auch der Kernel-Rückstieg nicht helfen wird. Entferne im Boot-Menü die Angabe vga=xxx, bevor Du die Eingabe-Taste drückst.

Nureinnarr · 18 Okt. 2010

josef-wien schrieb:
Ich denke, daß Dir auch der Kernel-Rückstieg nicht helfen wird. Entferne im Boot-Menü die Angabe vga=xxx, bevor Du die Eingabe-Taste drückst.

Das entfernen der Angabe vga=xxx hat nichts gebracht, ausser natürlich, dass das Booten in einem anderen VGA Modus abläuft.

Ich hoffe dennoch darauf, dass ich den Dreh mit dem alten Kernel noch hinbekomme, denn mit dem hatte ich wenigstens ein laufendes System.

Rainer Juhser · 18 Okt. 2010

Man könnte ja auch mal versuchen, direkt in den Runlevel 3 zu booten und sich die ganze Sache in Ruhe von der Konsole aus anzusehen.

Nureinnarr · 18 Okt. 2010

Hallo,

ja das könnte man in der Tat.

In den Runlevel 3 habe ich schon mehrfach gebootet. Allerdings muß ich gestehen, dass ich einen Schubs in die richtige Richtung bräuchte, soll heissen, wo setze ich dann an, um der Sache in Ruhe auf den Grund zu gehen. Ich bin durchaus gewillt und geduldig genug, das so zu machen.

Ich hab nur den Nachteil, dass ich nur den einen Rechner hier vor mir habe. Um mich hier zu informieren, muß ich dann laufend in das andere OS booten.

Welche Werkzeuge muß ich da einsetzen, welche Dateien mir anschauen, um herausfinden wo es hakt?

josef-wien · 19 Okt. 2010

JestersTear schrieb:
Ich hoffe dennoch darauf, dass ich den Dreh mit dem alten Kernel noch hinbekomme

Im runlevel 3 entweder yast (im Textmodus) aufrufen oder direkt mit rpm den Kernel installieren:

Code:

rpm -Uhv kernel-default-2.6.34-12.3.i586.rpm   (bzw. kernel-default-2.6.34-12.3.x86_64.rpm)

Wenn Du statt dem großen U ein kleines i eingibst, wird der Kernel zusätzlich installiert.

JestersTear schrieb:
Welche Werkzeuge muß ich da einsetzen, welche Dateien mir anschauen, um herausfinden wo es hakt?

/var/log/boot.msg (bzw. boot.omsg für den vorhergehenden Boot-Vorgang)
/var/log/Xorg.0.log (bzw. Xorg.0.log.old für den vorhergehenden X-Start)

P.S. Es ist zwar nicht sehr komfortabel, aber Internet geht auch im runlevel 3 (Hilfe = großes H):

Code:

w3m http://www.linux-club.de/

Nureinnarr · 19 Okt. 2010

Vielen Dank für die Hilfe!

auf die Idee in der Konsole mit yast zu arbeiten bin ich gar nicht gekommen.

Ich habe den alten Kernel parallel zum aktuellsten installiert. Suse läuft mit 2.6.34-12 wieder einwandfrei. Seltsam, dass das System mit allen anderen Kernels, die aktueller als dieser sind, nicht in die grafische Oberfläche kommen mag.

Mich hat nun schon der Ehrgeiz erfasst herauszufinden, was bei mir hier nicht schlüssig ist. Ich werde den neuen Kernel nochmal starten und dann die Logs vergleichen und nach Hinweisen darauf durchsuchen.

Rainer Juhser · 19 Okt. 2010

JestersTear schrieb:
Seltsam, dass das System mit allen anderen Kernels, die aktueller als dieser sind, nicht in die grafische Oberfläche kommen mag.

JestersTear schrieb:
einen Schubs in die richtige Richtung

Kann es sein, dass da noch irgendwelche Module (Grafiktreiber) neu kompiliert werden müssen? Ist aber jetzt eine reine Vermutung von mir. Ich kenne mich mit dem ATI-Zeug nicht aus.

josef-wien · 19 Okt. 2010

Rainer Juhser schrieb:
Kann es sein, dass da noch irgendwelche Module (Grafiktreiber) neu kompiliert werden müssen?

Nein, denn:

JestersTear schrieb:
Ich verwende jedoch nicht den proprietären Treiber sondern "radeon".

JestersTear schrieb:
Seltsam, dass das System mit allen anderen Kernels, die aktueller als dieser sind, nicht in die grafische Oberfläche kommen mag.

Da kann ich Dir nur zustimmen, und im Augenblick habe ich keine Idee, woran das liegen könnte. Ob es zur Fehlerfindung hilft, kann ich nicht sagen, aber deaktiviere im Runlevel-Editor die Dienste boot.startpreload und stoppreload (oder starte mit dem Parameter nopreload).

Nureinnarr · 19 Okt. 2010

Hallo,

die gute Nachricht: Kernel 2.6.34.7-0.4-default läuft! Allerdings muss ich ihm die Option nomodeset mitgeben.

Wenn ich die Suchergebnisse in Google überfliege, sehe ich dazu jede Menge Hinweise auf einen angeblich existierenden KMS-Bug. Ich werde mich dazu am Wochenende schlau machen, wenn ich bissel mehr Zeit habe.

Da mir Suse komischerweise* immernoch die beiden Updates anbietet (Aktualisierung auf 2.6.34.4), obwohl ein neuerer Kernel bereits läuft, werde ich die ganzen Update-Schritte zunächst durchtesten. Ich weiß ja nun, wie ich notfalls zum Ausgangspunkt zurückkomme.

Danke für die Unterstützung!

Nachtrag:
*Nein, nicht komisch sondern im Gegenteil sehr logisch, der alte Kernel ist ja noch installiert. Dafür die Updates angeboten zu bekommen ist nur konsequent.

spoensche · 21 Okt. 2010

Der Kernel hat einen KMS Bug. Direkt in RL 3 booten kannst du, in dem du im Feld Bootoptionen eine 3 einträgst.

Nureinnarr · 24 Okt. 2010

Ich habe mich wohl zu früh gefreut.

Mit dem aktuellsten Kernel läuft es nur scheinbar rund.
Wird das System mit dem Kernel Parameter nomodeset gestartet, tauchen folgende Einträge in boot.msg auf:

Code:

:/var/log> grep -i failed boot.omsg 
<7>[    0.732437] PM: Resume from disk failed.
<7>[    2.676032] PM: Resume from disk failed.
setfont: putfont: 256,8x16:  failed: -1
setfont: putfont: 256,8x16:  failed: -1
setfont: putfont: 256,8x16:  failed: -1
setfont: putfont: 256,8x16:  failed: -1
setfont: putfont: 256,8x16:  failed: -1
setfont: putfont: 256,8x16:  failed: -1
failedLoading keymap assuming iso-8859-15 euro
Failed services in runlevel 5: kbd

Ausserdem ist das Umschalten auf die virtuellen Textkonsolen z.B. tty1 sehr langsam. Der Bildschirm wird erst schwarz, dann dauert es ca. 3 Sekunden bis ich die Konsole sehe. Wenn ich nun zurück auf tty7 schalten möchte, hängt sich das System weg.

Muß ich bei nomodeset Xorg ganz klassisch über eine xorg.conf oder xorg.conf.d/50-device.conf konfigurieren?

spoensche · 24 Okt. 2010

Was für eine Keymap ist den in der Konfiguration des X- Servers angegeben? nomodeset hat nichts mit der Konfiguration des X- Servers zu tun, sondern deaktiviert KMS im Kernel. Die xorg.conf wird eigentlich nicht mehr verwendet, sondern auf die Dateien in /etc/X11/xorg.conf.d aufgeteilt.

Nureinnarr · 24 Okt. 2010

In etc/sysconfig/keyboard steht u.a:

Code:

## Path:        Hardware/Keyboard
## Description: Keyboard settings
## Type:        string
## Default:     ""
## ServiceRestart: kbd
#
# Keyboard settings for the text console
#
# Keyboard mapping
# (/usr/share/kbd/keymaps/)
# e.g. KEYTABLE="de-latin1-nodeadkeys", "us" or empty for US settings
#
KEYTABLE="de-latin1-nodeadkeys.map.gz"

## Type:        integer
## Default:
#
# Keyboard delay time in ms (250, 500, 750, 1000)
KBD_DELAY=""

## Type:	string(2.0,2.1,2.3,2.5,2.7,3.0,3.3,3.7,4.0,4.3,4.6,5.0,5.5,6.0,6.7,7.5,8.0,8.6,9.2,10.0,10.9,12.0,13.3,15.0,16.0,17.1,18.5,20.0,21.8,24.0,26.7,30.0)
## Default:
#
# Keyboard repeat rate (2.0 - 30.0)
KBD_RATE=""

## Type:        list(bios,yes,no)
## Default:     bios
#
# NumLock on? ("yes" or "no" or empty or "bios" for BIOS setting)
KBD_NUMLOCK="bios"

## Type:        yesno
## Default:     no
#
# ScrollLock on? ("yes" or "no")
KBD_SCRLOCK="no"

## Type:        yesno
## Default:     no
#
# CapsLock on? ("yes" or "no")
KBD_CAPSLOCK="no"

## Type:        yesno
## Default:     no
#
# Disable CAPS LOCK and make it a normal Shift key?
# (Ctrl Caps Lock will still toggle Caps Lock functionality)
# Note that you need to tweak the xkb maps or use xmodmap
# if you want to do the same under X-Windows. In ~/.Xmodmap:
# keycode 0x42 = Shift_L Shift_L
#
KBD_DISABLE_CAPS_LOCK="no"

## Type:        string
## Default:     "tty1 tty2 tty3 tty4 tty5 tty6"
#
# ttys for the above settings 
# Example: "tty1 tty2"
# "" for all tty's
#
KBD_TTY="tty1 tty2 tty3 tty4 tty5 tty6"

Wenn es das war, was Sie meinten.

spoensche · 30 Okt. 2010

Entferne mal das .map.gz bei bei deiner angegebenen Keymap.

openSUSE 11.3 Problem nach Kernel Update

Nureinnarr

Newbie

josef-wien

Ultimate Guru

Nureinnarr

Newbie

Rainer Juhser

Moderator

Nureinnarr

Newbie

josef-wien

Ultimate Guru

Nureinnarr

Newbie

Rainer Juhser

Moderator

josef-wien

Ultimate Guru

Nureinnarr

Newbie

spoensche

Moderator

Nureinnarr

Newbie

spoensche

Moderator

Nureinnarr

Newbie

spoensche

Moderator