SDB:YaST Fehler berichten

Getestet mit openSUSE		Empfohlene Artikel		Verwandte Artikel
	13.2 13.1 12.3 12.2 12.1 11.4				Portal:YaST SDB:YaST-Starten

Hier wird beschrieben, wie Sie Fehler in YaST2 oder während der Installation auftretende Probleme melden.

Anhänge - y2logs, hwinfo usw.

Ich habe einen Fehler in YaST2 gemeldet und wurde nun aufgefordert, "y2logs" anzuhängen. Was ist damit gemeint und wie mache ich das?

YaST2 schreibt seine Protokolle während es läuft in Dateien unterhalb von /var/log/YaST2. Wir benötigen diese Informationen um zu rekonstruieren, was passiert ist.

Von SUSE Linux 9.3 an oder SLES 9 ab SP1 drücken Sie in der grafischen Qt-Oberfläche die Umschalttaste und F8. Sie werden dann aufgefordert, einen Dateinamen anzugeben, unter dem die Protokolle gespeichert werden sollen.

Wenn Sie die NCurses-Oberfläche (Textmodus) benutzen, beenden Sie diese und benutzen das Konsolenkommando

save_y2logs /tmp/y2logs.tgz

Unter SUSE Linux 9.2 (oder SLES 9) oder älter erstellen Sie ein (komprimiertes) tar-Archiv aller YaST2-Protokolldateien. Versuchen Sie bitte nicht, zu vermuten, welche wir eventuell benötigen könnten und welche nicht - das ist meist nicht so einfach möglich. Archivieren Sie einfach alle wie folgt:

cd /var/log

tar -czvf /tmp/y2logs.tgz YaST2

Ungeachtet dessen, welche Ausgabe Sie benutzen: Falls das während des ersten Teils einer Installation/Aktualisierung oder während einer Systemaktualisierung passiert, vergessen Sie bitte nicht, die sich daraus ergebenden Dateien von /tmp (welches dann auf einer RAM-Disk ist) an einen sicheren Ort zu kopieren - eine Diskette, einen USB-Stift, auf eine andere Festplattenpartition oder über das Netzwerk.

Zum guten Schluss hängen Sie die Datei /tmp/y2logs.tgz an einen existierenden Fehlerbericht oder erstellen einen neuen. Geben Sie bitte auch den Dateityp tar.gz archive (app/x-gunzip) in Bugzilla an, anstatt sich auf die Autoerkennung von Bugzilla zu verlassen.

Ich habe /var/log/YaST2/y2log an einen YaST2-Fehlerbericht gehängt und trotzdem werde ich noch aufgefordert, y2logs anzuhängen. Wieso?

Naja, y2log ist nur eine Datei von vielen in /var/log/YaST2 die wir benötigen, um zu rekonstruieren was geschehen ist. y2log wird ab einer bestimmten Größe rotiert, die älteren werden gesichert und y2log ist so immer die aktuellste - und meist enthalten dann ausgerechnet die älteren Instanzen die benötigten Informationen. Zusätzlich liegen in diesem Verzeichnis auch noch andere Dateien, deren Inhalt uns dabei hilft, dem Problem auf die Schliche zu kommen.

Versuchen Sie bitte nicht, zu vermuten, welche wir eventuell benötigen könnten und welche nicht - das ist meist nicht so einfach möglich. Packen Sie deshalb bitte immer das ganze Verzeichnis zusammen; wie, dass erfahren Sie in der vorhergehenden Antwort.

Es ist wichtig, dass Sie nach einer fehlgeschlagenen Installation immer den Inhalt von /var/log/YaST anhängen, der beste Weg ein angemessenes Protokoll zu erstellen wird in der folgenden Anleitung beschrieben.

Ich möchte einen Fehler im Zusammenhang mit Paketabhängigkeiten und deren Auflösung durch libzypp melden und nun werde ich aufgefordert, "einen Solver-Sestfall anzuhängen". Welche Protokolle soll ich anhängen?

Seit openSUSE 10.2/SLES10 SP1 können Sie zusätzliche Informationen erstellen, indem Sie in der Paketverwaltung von YaST den Menüeintrag Extras/Testfall für Abhängigkeitsauflösung generieren auswählen.

Diese Option gibt es in der GTK-Schnittstelle von YaST nicht. Nutzen Sie stattdessen die Qt-Schnittstelle, oder nutzen Sie zypper. (In openSUSE 11.0 Beta3 IST diese Option in GTK verfügbar.)

Sie werden dann gefragt, ob Sie die Protokolldateien erstellen wollen und es wird ihnen mitgeteilt, wo diese abgelegt werden. Sie sollten diese dann ihrem Bugzilla-Bericht anhängen, so wie es hier beschrieben wird.

Ein zweiter Weg (nur für den Fall, dass der erste nicht hilft. Der generierte Abhängigkeitstestfall 'reicht in 95& der Fälle aus!):

Unter SUSE Linux 10.1 oder älter hängen Sie bitte /var/log/YaST2/* an den Fehlerbericht in Bugzilla an, so wie es hier beschrieben wird. Zumeist ist es hilfreich, vorher den Protokollierungsgrad zu erhöhen:

Für die Paketinstallation:

export ZYPP_FULLLOG=1

export Y2MAXLOGSIZE=123456789

export Y2MAXLOGNUM=42

yast2 -i

Für YaST Online-Update (YOU)

export ZYPP_FULLLOG=1

export Y2MAXLOGSIZE=123456789

export Y2MAXLOGNUM=42

yast2 online_update

Für die grafische Oberfläche von YaST:

kdesu -u root -c env ZYPP_FULLLOG=1 Y2MAXLOGSIZE=123456789 Y2MAXLOGNUM=42 /sbin/yast2

Ich möchte einen Fehler im Zusammenhang mit Zypper (Zypper, openSUSE Updater mit ZYpp-Backend) melden. Welche Protokolle soll ich anhängen?

Fügen Sie dem Fehlerbericht bitte ihre /var/log/zypper.log bei. Weitere Informationen dazu finden Sie unter Zypper Problemlösungen.

Falls im KDE Updater Applet (ab openSUSE 11.4 wurde es durch KPackageKit ersetzt) das ZYpp-Backend ausgewählt ist, nutzt es intern Zypper, um seine Aufgaben (wie Prüfen auf Aktualisierungen, installieren der selbigen) durchzuführen. Fügen Sie ihrem Bericht bitte auch ihre /var/log/zypper.log bei, wenn Sie vermuten, dass die Probleme mit diesen Aufgaben zusammenhängen, und nicht mit der grafischen Darstellung oder etwas anderem.

Ich möchte einen Fehler im Zusammenhang mit ZENWorks (ZMD, rug, Software Updater) melden. Welche Protokolle soll ich anhängen?

Bitte hängen Sie /var/log/zmd-*.log an den Fehlerbericht an. Wir benötigen für gewöhnlich sowohl zmd-messages.log* als auch zmd-backend.log*.

Da diese Dateien recht groß werden können, sollten Sie sie vor dem Hochladen komprimieren, was auf beiden Seiten Bandbreite einspart.

Wenn bei ihnen SLES oder SLED 10 Service Pack 2 oder neuer läuft, können Sie selber einen Testfall erstellen.

/usr/lib/zmd/bin/zmd-solver-testcase /var/lib/zmd/zmd.db Ausgabeverzeichnis

Sie sollten ihn erstellen, wenn rug auf die Bestätigung der Transaktion wartet. An diesem Punkt sind die Transaktionsinformationen in zmd.db präsent.

Packen Sie das Ausgabeverzeichnis in ein Archiv und hängen Sie es ihrem Fehlerbericht an.

Wenn Sie einen Testfall in der Mitte einer Transaktionsbestätigung erstellen, bspw. wenn rug fragt, ob ein Paket installiert werden soll, wird der Testfall die gewählte Transaktion enthalten und dabei helfen, dass Problem zu finden.

Ich möchte einen Fehler bei der Registrierung melden. Muss ich da was bestimmtes machen?

Ja, hängen Sie bitte /root/.suse_register.log und /var/log/messages an den Fehlerbericht.

Ich habe einen Fehler in YaST2 gemeldet und werde nun nach "hwinfo" gefragt. Was heißt das und was soll ich tun?

hwinfo ist der Befehl mit dem Sie ihre Hardware erkennen lassen können. Wir benötigen die Ausgabe dieses Befehls, um feststellen zu können, welche Komponenten ihr Computer aufweist. Falls sie ein Problem im Zusammenhang mit Rechnerkomponenten gemeldet haben, ist es wichtig zu erfahren, ob diese überhaupt erkannt wurden, ob sie richtig erkannt wurden oder einfach nur um festzustellen, ob es sich um ein bekanntes Gerät mit Problemen handelt.

Leiten Sie die Ausgabe des Befehls in eine Datei um

hwinfo >/tmp/hwinfo.txt

und hängen Sie die dann entstandene Datei hwinfo.txt an ihren Fehlerbericht an.

Hängen Sie bitte nicht die Binärdatei /usr/sbin/hwinfo an (ja, dass kommt wirklich immer wieder vor) - wir brauchen die Ausgabe, nicht die Programmdatei.

Wie hänge ich ein Bildschirmfoto von YaST2 an?

Wenn Sie die grafische Qt- oder GTK+-Oberfläche benutzen, dann betätigen Sie einfach die Druck-Taste. Sie werden dann nach einem Dateinamen zum Speichern gefragt. Das funktioniert allerdings nicht mit der NCurses-Oberfläche (Textmodus).

(Fähigkeit von YaST, nicht von KDE)

Wenn der Fehler auch noch in einer X-Konsole auftritt, können Sie YaST in einer grafischen Konsole öffnen und beispielsweise mit KSnapshot ein Foto davon machen (oder mit jedem anderen Bildschirmfotoprogramm).

Wie kann ich während der Installation Konsolenbefehle ausführen?

Wenn Sie direkt an dem betroffenen System sitzen (also nicht über Netzwerk darauf zugreifen), können Sie mit Strg+Alt+F2 auf die zweite virtuelle Konsole wechseln. Dort befindet sich während der Installation eine root-Shell.

Wenn Sie grafisch über ein Netzwerk verbunden sind (bspw. mit VNC), dann erhalten Sie durch das Drücken von Strg+Alt+Umschalttaste+X ein X-Terminal-Fenster (siehe auch YaST Tipps & Tricks).

Die y2logs scheinen mein Problem nicht zu zeigen. Kann ich den Protokollierungsgrad erhöhen?

Ja, kann man: Sie können die Fehlerprotokollierung aktivieren (log level y2debug):

• Bei einem installierten System setzen Sie die Umgebungsvariable Y2DEBUG und starten YaST2 dann aus der gleichen Kommandozeile (!):

export Y2DEBUG=1
yast2

• Um die Fehlerprotokollierung während der Installation zu aktivieren fügen Sie den Startparametern y2debug hinzu (im Eingabefeld im unteren Bereich des Boot-Menüs)
• Wenn Sie vergessen haben vor der Installation y2debug als Kernel-Startparameter anzugeben, können Sie im grafischen Installationsmodus auch noch Umschalttaste+F7 drücken.

Beachten Sie bitte, dass die Fehlerprotokollierung in allen Fällen recht umfangreich ausfallen kann, wodurch die Protokolle ziemlich lang werden können, was während des ersten Abschnitts einer Installation ein Problem sein kann, da sich /var/log dann noch auf einer RAM-Disk befindet.

Reicht es nicht, wenn ich ihnen den Hostnamen oder die IP des Problemrechners sage und Sie sich dann alle Informationen selber holen?

Nein, dafür ist der Fehlerreporter zuständig.

SSH-Zugriff auf einen Rechner mit dem Problem zu haben ist eine nette Zugabe, nur ist das kein Ersatz dazu zur richtigen Zeit y2logs an den Fehlerbericht anzuhängen.

Zum einen hat ein großer Teil der Fehler die als YaST2- oder Installationsfehler gemeldet werden nichts mit beidem zu tun. Es handelt sich dann meist um Probleme mit Paketen (die zwar mit YaST2 installiert wurden, aber deshalb keine YaST2-Probleme sind), Kernel-Probleme, Hardware-Inkompatibilitäten oder Missverständnisse, weil der Nutzer nicht daran gedacht hat, die Dokumentation zu lesen. Wir wollen damit sagen, dass wir, die YaST2-Betreuer, schon reichlich Anfangsarbeit für viele andere machen; und wir wollen wirklich nicht noch mehr Zuträger Dienste (wie abholen von y2logs und hwinfo usw.) leisten.

Zum anderen kann sich bis dahin die Situation auf dem Rechner schon längst wieder geändert haben - neu installiert, Protokolle voll von irrelevanten Informationen usw. Und wir können auch nicht einfach Alles stehen und liegen lassen, um uns per SSH irgendwo einzuloggen, weil gerade mal wieder ein Fehlerbericht eingetroffen ist - vor allem, weil dann noch nicht einmal klar ist, wer überhaupt an diesem Fehler arbeiten wird.

Wie kann ich während der Installation YaST-Protokolle an einen entfernten Rechner umleiten?

Dies ist vor allem für weitergehende Tests/Fehlersuche nützlich. Sie können ihre Installationsprotokolle einfach auf einen entfernten NFS-Server (einfach ein anderer Computer) umleiten, bevor die Installation startet. Einen Artikel der die dafür nötige Konfiguration beschreibt finden Sie hier.

Wie kann ich während der Installation YaST-Protokolle auf einem USB-Stick speichern?

Dies läuft ähnlich ab wie bei der vorangegangen Frage. YaST-Protokolle können an jedes Gerät mit Schreibzugriff umgeleitet werden, bspw. auf einen USB-Stick oder eine andere Festplatte. Einen Artikel der die dafür nötige Konfiguration beschreibt finden Sie hier.

Wie kann ich YaST in einem Debugger (GDB) starten? Wie kann ich ein Backtrace erstellten?

In manchen Situationen wird man Sie dazu auffordern, YaST in einem Debugger zu starten (bspw. wenn YaST abstürzt), um detailliertere Informationen zu erhalten.

Um die kompletten Debugging-Informationen zu erhalten sollten Sie die zugehörigen *-debuginfo-Pakete installieren. Dies umfasst normalerweise die Pakete yast2-core-debuginfo, yast2-pkg-bindings-debuginfo und libzypp-debuginfo. Wenn der Absturz außerhalb von YaST auftritt (in einer externen Bibliothek) können noch weiter debuginfo-Pakete benötigt werden.

Debuginfo-Pakete befinden sich in zusätzlichen Paketdepots, bspw. enthält http://download.opensuse.org/factory/repo/debug/ die debuginfo-Pakete für das Factory-Paketdepot. Es ist zwar möglich, auch ohne debuginfo-Pakete zu debuggen, allerdings werden dann einige Informationen fehlen (bspw. Funktionsnamen, exakte Positionen im Quellcode...), was die Ergebnisse nutzlos macht.

Um den YaST-Interpreter im gdb-Debugger zu starten verwenden sie folgendes Kommando

gdb /usr/lib/YaST2/bin/y2base

Dann benutzen Sie

run <Modulname> qt

für die Qt-Oberfläche, oder

run <Modulname> gtk

für die GTK-Oberfläche, um das gewünschte YaST-Modul mit der bevorzugten Oberfläche zu starten (ncurses könnte ebenfalls genutzt werden, allerdings würde dann die Ausgabe von gdb mit der von YaST vermischt, der nächste Abschnitt behandelt dieses Problem). Sie können das Kommando 'yast -l' verwenden, um sich eine Liste der verfügbaren Module anzeigen zu lassen.

Die andere Möglichkeit besteht darin, gdb an einen schon laufenden YaST-Prozess anzuhängen. In diesem Fall nutzen Sie das Kommando

gdb /usr/lib/YaST2/bin/y2base <PID>

wobei PID die Prozess-ID des y2base-Prozesses angibt. Benutzen Sie bspw. den Befehl 'ps -aux' um die ID zu finden. Benutzen Sie im Debugger das Kommando 'cont' um YaST nach dem Anhängen des Debuggers fortzusetzen. Auf diesem Weg ist es möglich, sich an ein YaST-Modul zu hängen, welches in der ncurses-Benutzerschnittstelle läuft (von einer anderen Konsole aus).

Nun haben wir YaST im gdb laufen und können versuchen, dass Problem (Absturz) zu reproduzieren. Wenn das YaST-Modul abstürzt verwenden Sie das Kommando bt um den Programmstapel (backtrace) anzuzeigen. Kopieren Sie die Ausgabe und fügen Sie sie in eine Textdatei ein, falls Sie das Ergebnis einem Fehlerbericht anhängen müssen.

Allgemeine Probleme

Es erscheint ein Fenster mit folgendem roten Text: "Während der Installation trat ein Fehler auf". Kann ich die Protokolle irgendwie retten?

Ja! Solange die Fehlermeldung angezeigt wird, ist auf Konsole 2 auch die Root-Kommandozeile geöffnet. Sie wird jedoch beendet sobald Sie die Fehlermeldung schließen. Sie können die Kommandozeile auf Konsole 2 dazu benutzen, um Protokolldateien der gescheiterten Installation zu sichern.

Ich wurde gefragt, ob das Problem auch bei der manuellen Installation auftritt. Was ist mit manueller Installation gemeint?

Wählen Sie im Startmenü der Installations-CD "Installation" und geben Sie bei den Startoptionen "manual=1" an. Sie werden danach aufgefordert das Laden von Kernel-Modulen zu bestätigen. Sollte die Installation nach solch einer Bestätigung hängen bleiben ist das ein Hinweis auf mögliche Hardware-Inkompatibilitäten oder Kernel-Treiber Probleme.

Ich habe die Installation abgebrochen und sie von "linuxrc" aus neu gestartet und werde nun ständig gefragt ob ich Kernel-Module laden soll. Was läuft falsch?

Sie sind in die "manuelle Installation" zurückgefallen. Da ist das absolut normal.

Die Installation startet nur im Textmodus, ich weiß aber, dass ich eine geeignete Grafikkarte habe! Was ist los?

Die grafische Installation verlangt nach einer Mindestauflösung von 800x600 - im Frame-Buffer-Modus. Nicht alle Grafikkarten sind so kompatibel zu VESA, dass zu unterstützen, weshalb der X-Server während der Installation auf 640x480 zurückfällt, was aber zu niedrig ist, um alles anzuzeigen. Wir haben so viele Klagen über abgeschnittene Texte oder Dialoge erhalten, dass wir solch alte Grafikmodi nicht mehr unterstützen.

Lesen der YaST-Protokolle

Wenn Sie die YaST-Protokolldateien (/var/log/YaST2/y2log) selber lesen wollen werden Sie wahrscheinlich im Informationswust untergehen und die relevanten Teile übersehen.

Um nur wichtige Meldungen zu sehen können Sie mit grep in y2log nach Protokollierungsstufen filtern lassen:

grep '<[2345]>' /var/log/YaST2/y2log

wird nur Protokollzeilen der Stufe "warning" und höher anzeigen.

Existierende Protokollstufen sind:

• 0: debug
• 1: milestone
• 2: warning
• 3: error
• 4: security (selten genutzt - wenn überhaupt)
• 5: internal (wahrscheinlich nie genutzt)

Eine detaillierte Beschreibung der Protokollierungsstufen finden Sie in der YaST2-Dokumentation .