[gelöst] 13.2 bootet nicht richtig

[revealed]

....
[    19.207] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.16.7-29-default root=UUID=cea68159-d9fe-4f4b-a9f3-b040748be581 resume=/dev/disk/by-id/ata-MAXTOR_STM380815AS_5QZ30BAL-part1 splash=silent quiet showopts nomodeset
..
[    19.253] (EE) [drm] KMS not enabled

...
..

Du bootest auch mit nomodeset. Deswegen ist das Log fraglich. Nomodeset deaktiviert genau die Funktionionen zu denen (ich zumindest) die Meldungen sehen wollen würde. Deswegen hast du auch nur 640x480. Weil eben genau das modesetting nicht stattfindet. Freilig hast du das drinstehen, da dir zuvor für den Versuch mit nvidia binary dazu geraten wurde. Das verstehe ich.

Ohne nomodeset sollte dann gewohnt "nouveau" wieder werkeln.

Die weitere Frage:
Was tun, wenn Nouveau dann wieder werkelt? Nochmal binary blob?

Gruß,

R

 

[per pedes]

@revealed:

Ich habe das System ohne nomoset gebootet, mit folgendem Ergebnis:
> Beim Booten mit der neuesten Kernelversion 3.16.7-29 blieb das System vor dem (bunten) Hintergrund der Arbeitsfläche stehen, es zeigten sich zwei bunten Streifen im oberen Bildschirmdrittel, der Vorgang ließ sich nur durch harten Reset beenden
> Das Booten mit der Kernelversion 3.11.10-29 verlief normal; am Ende zeigte sich die KDE-Arbeitsfläche mit der Auflösung 1280 x 1024

Ich habe jetzt noch einmal die von josef-wien erbetenen Angaben abgefragt, mit folgendem Ergebnis:

linux-auj4:/ #                                                                                                                                                                      
linux-auj4:/ # grep nouveau /etc/modprobe.d/*
linux-auj4:/ # egrep -w "EE|WW|command|config" /var/log/Xorg.0.log                                                                                                                  
[    24.792] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.11.10-29-default root=UUID=cea68159-d9fe-4f4b-a9f3-b040748be581 resume=/dev/disk/by-id/ata-MAXTOR_STM380815AS_5QZ30BAL-part1 splash=silent quiet showopts
[    24.792] Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    24.792] (==) Using config directory: "/etc/X11/xorg.conf.d"
[    24.792] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    24.803] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist.
[    24.832] (WW) Warning, couldn't open module nvidia
[    24.832] (EE) Failed to load module "nvidia" (module does not exist, 0)
[    24.834] (WW) Warning, couldn't open module nv
[    24.834] (EE) Failed to load module "nv" (module does not exist, 0)
[    24.838] (WW) Falling back to old probe method for modesetting
[    24.838] (WW) Falling back to old probe method for fbdev
[    24.839] (WW) Falling back to old probe method for vesa
[    25.149] (EE) NOUVEAU(0): [COPY] failed to allocate class.
[    26.065] (II) config/udev: Adding input device Power Button (/dev/input/event1)
[    26.106] (II) config/udev: Adding input device Power Button (/dev/input/event0)
[    26.107] (II) config/udev: Adding input device HID 046a:0023 (/dev/input/event2)
[    26.108] (II) config/udev: Adding input device HID 046a:0023 (/dev/input/event3)
[    26.109] (WW) evdev: HID 046a:0023: ignoring absolute axes.
[    26.110] (II) config/udev: Adding input device Logitech USB-PS/2 Optical Mouse (/dev/input/event4)
[    26.111] (II) config/udev: Adding input device Logitech USB-PS/2 Optical Mouse (/dev/input/mouse0)
[    26.111] (II) config/udev: Adding input device PC Speaker (/dev/input/event5)
[    39.003] (II) NOUVEAU(0): Using hsync ranges from config file
[    39.003] (II) NOUVEAU(0): Using vrefresh ranges from config file
linux-auj4:/ # uname -a
Linux linux-auj4 3.11.10-29-default #1 SMP Thu Mar 5 16:24:00 UTC 2015 (338c513) i686 athlon i386 GNU/Linux
linux-auj4:/ # xrandr --current
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192
VGA-1 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024     60.02*+  75.02  
   1280x960      60.00  
   1152x864      75.00  
   1024x768      75.08    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   640x480       75.00    72.81    66.67    60.00  
   720x400       70.08  
DVI-I-1 disconnected (normal left inverted right x axis y axis)
linux-auj4:/ # /sbin/lspci -nnk | grep -iA3 vga
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G86 [GeForce 8400 GS] [10de:0422] (rev a1)
        Subsystem: XFX Pine Group Inc. Device [1682:2308]
        Kernel driver in use: nouveau
        Kernel modules: nvidiafb, nouveau
linux-auj4:/ #

Danke für Deine Hilfe!

 

[revealed]

Es ist ja so.

Es gibt die:
/var/log/Xorg.0.log (aktueller Startvorgang).
/var/log/Xorg.0.log.old (voriger Startvorgang).

Bitte starte 1x mit dem neuen kernel mit dem komischen Streifenproblem.
Dann starte wieder mit dem alten und poste die gesamte /var/log/Xorg.0.log.old über einen Pasteservice.

Und das kannst du da auch noch reinhängen:

journalctl -b -1 | egrep "error|fail|drm|dri|nouveau"

Das interessiert mich. Beispielsweise diesen Dienst:
http://paste.opensuse.org/

Dieses vorgehen aus dem Grund, dass ich die richtige Log vom Bootvorgang mit dem komischen Streifen bekomme. Wenn garnix anderes mehr geht.

Wenn er wieder hängt: Versuche mal auf der Tastatur:
ALT + "Drucken/S-Abf" (Halten). --> Mit der anderen Hand in Reihe: R E I S U B

Gruß,

R

 

[josef-wien]

Bis jetzt wissen wir, daß bei allen Versionen des 3.16er-Kernel nouveau Probleme macht und daß der Nvidia-Treiber ebenfalls nicht funktioniert.

Interessant, aber nicht hilfreich ist der Umstand, daß der durch die Angabe von nomodeset verwendete Xorg-Treiber (nouveau verlangt zwingend KMS und kann daher nicht zum Zug kommen) nur eine Auflösung von 640*480 Pixel zusammenbringt, üblich wären in diesem Fall 1024*768 Pixel.

Ich würde einen aktuellen Kernel (z. B. aus http://download.opensuse.org/repositories/Kernel:/stable/standard/) installieren und schauen, wie damit die Dinge stehen.

 

[per pedes]

@revealed:

Ich bin wie vorgeschlagen vorgegangen; das Log findest Du unter http://paste.opensuse.org/6367920

zum Kommando journalctl ... hat sich Folgendes ergeben:

linux-auj4:/ # journalctl -b -1 |egrep 'error|fail|drm|dri|nouveau'
Failed to look up boot -1: Die angeforderte Adresse kann nicht zugewiesen werden

@josef-wien:

Danke für Deine Anregung; ich versuche das evtl. später.

 

[revealed]

Das ist dein Problem an dieser Stelle mit dem Streifen bezüglich Noveau denke ich -- Also ich hab gegoogelt zu:

(EE) NOUVEAU(0): [COPY] failed to allocate class.

Bin hierauf gestoßen.
https://bugs.freedesktop.org/show_bug.cgi?id=82714

Und am Ende steht dorch tatsächlich, dass es dafür wohl irgendeine Form von Fehlerbehebung gibt. In neueren Kernel größer >4.1; Würde da eher josef-wien beipflichten. Hat scheinbar irgendwas mit powersaving (dpms) pm usw zu tun.

Zitat:

Recent kernels should fix the PDISP hang error, which in turn might avoid tickling the vm lockup. Can you test a kernel that includes 697bb728d9e (v4.2 should have it).

Zum anderen:

Failed to look up boot -1: Die angeforderte Adresse kann nicht zugewiesen werden

Ich bin mir keiner Tippfehler bewusst. Bei einer sauberen frischen Installation mit systemd funktioniert das. Eventuell hast du ja aber noch SysV? Verwendest du überhaupt journald und systemd? Das wäre jedenfalls was anderes, dass ich hier in dem Thread nicht lösen möchte bzw. fragilich ob es das überhaupt zu lösen gibt oder als zu lösen gilt.. Ich weiss auch nicht, was da verbogen sein könnte. Schaut mir aber nach Upgradeproblemen aus bei dir.

Gruß,

R

 

[gehrke]

Failed to look up boot -1: Die angeforderte Adresse kann nicht zugewiesen werden

Ich bin mir keiner Tippfehler bewusst.

Ist hier nicht vielleicht eher das gemeint:

journalctl -b 1 | egrep 'error|fail|drm|dri|nouveau'

anstatt

journalctl -b -1 | egrep "error|fail|drm|dri|nouveau"

Der zweite Aufruf scheitert bei mir mit dem selben Hinweis.

EDIT: ... scheitert auf einem openSUSE 13.1 ...

 

[revealed]

Aufklärung bringt: Bei mir -1;;

Aufklärung würde bringen

journalctl --list-boots

Alle vergangengen boots werden (auf meinen Rechnern zumindest) mit führendem minus gekennzeichnet.
Also übergebe ich dort gewohnt "-1" was entsprechend den vorhergehenden Startvorgang heranziehen würde.

Deswegen hab ich das hier auch so niedergeschrieben:
http://linux-club.de/wiki/opensuse/Systemd#Das_Startprotokoll

Falls ich doch wieder nen dreher hatte. Sorry das hab ich manchmal bekanntlich mit Überzeugung drauf. Mein Offtopic zu der Problematik trägt in dieser Situation nicht hilfreich bei. Jedoch die gewünschte Ausgabe würde helfen. Entschuldigt die Ablenkung. Die Ausgabe müsste halt dann jetzt von dem Startvorgang mit in der Fehlstellung kommen. Aber ich vermute das ist sowieso obsolet, da zumindest in meinen Augen der Fehler aus der log vom x server ein gezielter Hinweis sein wird. Aber auch da kann ich mich freilig irren.

Ich weiss aber sowieso nicht alles -- woher auch. Ein Kernel und xserver und Treiber - programmierender Profi hätte an einem tollen Tag jetzt einmal geblinselt und all deine Probleme wären vermutlich gelöst.

Deswegen würde ich gerne nochmal (Ich will ja nichts unterstellen) -- auf josef-wien hinweisen, der weit fundamentiertere Tipps bieten kann als ich:

Ich würde einen aktuellen Kernel (z. B. aus http://download.opensuse.org/repositories/Kernel:/stable/standard/) installieren und schauen, wie damit die Dinge stehen.

Das hat er vorher schon entweder gewusst oder gerochen.

Gruß,

R

 

[josef-wien]

Bei einer sauberen frischen Installation mit systemd funktioniert das.

Da es sich um eine Aktualisierung von 12.3 über 13.1 nach 13.2 handelt, ist zu vermuten, daß kein dauerhaftes systemd-Journal eingerichtet ist. Falls Du forschen willst:

egrep "Storage|Syslog" /etc/systemd/journald.conf
ls /var/log/journal

entweder gewusst oder gerochen

Das ist der Versuch einer Fehlereingrenzung. Wenn ein aktueller Kernel funktioniert, hat sich nach dem 3.11er ein Fehler eingeschlichen, der inzwischen wieder behoben wurde. Wenn er auch nicht funktioniert, müssen wir dem Problem irgendwie näher kommen, denn ewig kann man nicht beim 3.11er bleiben.

 

[per pedes]

Vielen Dank für die weiteren Hinweise, die mir zeigen, dass Ihr Euch sehr intensiv mit meinem Anliegen beschäftigt habt. Ich habe sie wiederum als sehr hilfreich empfunden und neige jetzt dazu, der Empfehlung von josef-wien folgend einen Standard-Kernel einzusetzen.

Den Hinweisen auf das möglicherweise fehlende Boot-Journal bin ich ebenfalls nachgegangen. Es ist so, dass zwar eine Textdatei /etc/systemd/jornal.conf vorhanden ist, das Verzeichnis /var/log/journal aber fehlt. Das Kommando "journalctl --list-boots" zeigt als Ergebnis nur den aktuellen Bootvorgang an. Bisher hatte ich nicht das Bedürfnis nach einem Rückblick verspürt. Das aktuelle Problem zeigt aber, dass es schon sinnvoll ist, eine solche Möglichkeit zu haben.

 

[josef-wien]

/var/log/messages sollte bei Dir vorhanden sein, abhängig von den systemd-Befindlichkeiten und den Boot-Optionen eventuell auch /var/log/boot.msg (aktueller Systemstart) und /var/log/boot.omsg (Systemstart davor) oder /var/log/boot.log.

 

[per pedes]

/var/log/boot.msg ist leer, /var/log/boot.omsg nicht vorhanden, /var/log/boot.log zeigt (nur) den aktuellen Bootvorgang.

var/log/messages habe ich mir näher angesehen. Das ist bei mir eine sehr umfangreiche Datei (seit 25.09.2015 fast 170.000 Zeilen), deren Auswertung sehr mühsam ist. Ich habe nach den Ereignissen der letzten Tage geschaut und dabei festgestellt, dass nach dem Versuch, den Kernel 3.16.7 zu starten, zumeist nur unkenntliche bzw. Zeichen, die keinen Sinn ergaben, gezeigt wurden.

Ich habe auch versucht, heraus zu bekommen, wie ich journalctl besser nutzen kann. Leider habe ich nirgends eine Anleitung dazu gefunden oder einen Hinweis auf eine Konfigurationsdatei o. ä. Kann mir da jemand einen kleinen Hinweis geben?

Ich möchte in dieser Angelegenheit schon weiterkommen, möchte aber Eure Geduld und Hilfsbereitschaft nicht überstrapazieren. Deshalb werde ich jetzt insbesondere den von josef-wien gemachten Vorschlag, einen Standardkernel zu versuchen, verfolgen. Bei den in diesem Zusammenhang in /etc/zypp/zypp.conf erforderlichen Einstellungen zu den "zugelassenen" Kerneln muss ich sehr vorsichtig sein, damit ich mir nichts kaputt mache. Deshalb kann es etwas dauern, bis ich mich wieder melde.

 

[Heinz-Peter]

Ich habe auch versucht, heraus zu bekommen, wie ich journalctl besser nutzen kann. Leider habe ich nirgends eine Anleitung dazu gefunden oder einen Hinweis auf eine Konfigurationsdatei o. ä. Kann mir da jemand einen kleinen Hinweis geben?

Hier was auf deutsch => https://www.suse.com/de-de/documentation/sles-12/book_sle_admin/data/cha_journalctl.html
In der englischen Sprache wirst mehr finden.

Grüße Heinz-Peter

 

[josef-wien]

Hinweis auf eine Konfigurationsdatei

/etc/systemd/journald.conf (dazu gibt es ebenso wie für journalctl eine manpage; falls KDE 4 und Nachfolger das noch unterstützen, kannst Du in der Konqueror-Adreßzeile

man:/journald.conf

eingeben).

/etc/zypp/zypp.conf

Eine Möglichkeit ist, die Zeile

multiversion.kernels = bla,bla,bla

vorübergehend zum Kommentar zu machen, dann werden keine Kernel gelöscht.

 

[per pedes]

Ich habe jetzt den aktuellen "Standardkernel" 4.3.0-11 installiert. Leider zeigte sich ein ähnlich unerfreuliches Ergebnis wie schon zuvor mit den Kerneln 3.16.7: Der Bootvorgang wurde nicht beendet; zum Schluss erschien auf dem Bildschirm die Meldung "[2.145390] Failed to find cpu0 device node".

Ich habe nach dem Neustart des Systems mit dem Kernel 3.11.10 die Datei /var/log/Xorg.0.log.old ausgelesen; das Ergebnis steht unter http://paste.opensuse.org/75674457 zur Verfügung. Ich kann leider nichts erkennen, wo ich ansetzen könnte.

im Hinblick auf die Hinweise, dass sich die nouveau-Bibliotheken möglicherweise mit den nvidia-Bibliotheken nicht vertragen, stellt sich für mich dann aber auch die Frage, ob es zielführend sein könnte, die nvidia-Grafiksoftware zu installieren und die von nouveau zu entfernen und als zusätzliche Bootoption wieder "nomodeset" anzulegen.

 

[revealed]

Wenn du nouveau abschalten möchtest, wäre das der hier:

nouveau.modeset=0

Gruß,

R

 

[josef-wien]

Mir fällt bei der /var/log/Xorg.0.log.old überhaupt nichts Negatives auf. Unterscheidet sich die Zeile

(II) NOUVEAU(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)

beim Start mit dem Kernel 3.11?

Nachdem Du mit dem NVidia-Treiber schon beim Kernel 3.16 gescheitert bist, habe ich wenig Hoffnung beim 4.3 (von nouveau mußt Du nichts enfernen, die bei der Installation erzeugte blacklist-Eintragung reicht, installierte Nvidia-Bibliotheken haben Vorrang vor anderen).

Mit dem Deaktivieren von KMS wirst Du keine Freude haben, aber es mag helfen, um überhaupt eine grafische Oberfläche zu erhalten.

Beim Kernel 4.3 (entweder ohne KMS oder mit der Boot-Option 3 im Textmodus oder auf der mit Strg-Alt-F1 erreichbaren Textkonsole):

dmesg | egrep -i "acpi|erro|warn|crit|fail|fault|nouveau"

(gegebenenfalls mit angehängtem

 > ~/dmsg.txt

in einer Datei speichern)

 

[per pedes]

josef-wien schrieb:

Unterscheidet sich die Zeile

Code: Alles auswählen
(II) NOUVEAU(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
beim Start mit dem Kernel 3.11?

Diese Zeile ist bei einem Start mit dem Kernel 3.11 genau gleich. Aufgefallen sind mir allerdings einige weitere Zeilen am Ende:

 (II) UnloadModule: "evdev"
 (II) NOUVEAU(0): NVLeaveVT is called.
 (EE) Server terminated successfully (0). Closing log file.

Die auf "UnloadModule ..." folgenden beiden Zeilen fehlten in dem Log von dem Start mit 4.3.0. Oder würde das nur mit dem Stillstand beim Booten zusammenhängen?

Außerdem habe ich die Treiber von NVIDIA G03 installiert. Danach zeigte sich am Ende des Bootvorgangs sowohl mit dem Kernel 4.3.0 als auch mit dem Kernel 3.11.10 die KDE-Arbeitsfläche wie schon zuvor mit einer Auflösung von 640 x 480. Nach dem Booten mit den Kerneln 3.16 ergab sich der einfache Anmeldebildschirm im Textmodus, in dem ich mich als root, aber auch als einfacher Anwender anmelden konnte. Die Bootvorgänge habe ich zunächst ohne, später mit der von revealed vorgeschlagenen Bootoption "nouveau.modeset=0" durchgeführt; Unterschiede im jeweils nachfolgenden Erscheinungsbild haben sich nicht ergeben.

Wie von josef-wien vorgeschlagen, habe ich unter dem Kernel 4.3.0 mit dmesg einen Log-Auszug erstellt; dieser findet sich unter http://paste.opensuse.org/42491370

Macht es noch Sinn, dieses Thema weiter zu verfolgen? Ihr habt Euch ja viel Mühe mit meinem Anliegen gegeben. Ich würde jetzt am liebsten die NVIDIA-Treiber herausnehmen, damit ich wieder eine vernünftige Arbeitsfläche habe, erst einmal mit dem Kernel 3.11 weitermachen und in aller Ruhe weiterhin Ursachenforschung betreiben. Vielleicht finde ich ja noch etwas??

 

[josef-wien]

Oder würde das nur mit dem Stillstand beim Booten zusammenhängen?

Meiner Meinung nach ja, da Xorg nicht normal beendet wurde.

Bootoption "nouveau.modeset=0"

Einen Unterschied wird es nur geben, wenn der Nvidia-Treiber nicht installiert ist.

Auch in der Ausgabe von dmesg entdecke ich nichts im Zusammenhang mit Deinem Problem. Zwei Dinge kannst Du noch versuchen:
1. Führe (bei installiertem Nvidia-Treiber)

nvidia-settings

aus (Details dazu muß ein Nvidia-Kundiger liefern). Hast Du den Nvidia-Treiber vom Hersteller heruntergeladen und (nach Entfernung aller Nvidia-Pakete) die *.run-Datei ausgeführt? Für den Kernel 4.3 wird es kein Kernel-Modul als RPM-Paket (...-kmp-...) geben (13.2 verwendet Kernel 3.16, 42.1 verwendet Kernel 4.1), und ohne das jeweils passende Kernel-Modul kann das Xorg-Modul (aus dem Paket x11-video-...) nicht verwendet werden.
2. Starte mit der Boot-Option:

apparmor=0

 

[per pedes]

Die Aktivierung des nvidia-Treibers als weiterer Schritt zur Problemlösung hat bei mir unerwartete Schwierigkeiten bereitet, die ich nicht zügig lösen konnte. Deshalb habe ich mich entschlossen, das System 13.1 vollständig neu zu installieren und in Ruhe zu schauen, wie ich 13.2 schaffen kann. Jetzt läuft bei mir vorerst also 13.1.

Nochmals Danke allen, die mir mit ihren Ratschlägen geholfen haben, insbesondere josef-wien. Eure Hinweise haben mir geholfen, das System gut kennen zu lernen und zu verstehen. Die durch das Update ausgelösten Schwierigkeiten und die danach bekannt gewordenen Schieflagen haben diesen Lernprozess, den ich mir schon seit längerem vorgenommen hatte, befördert.

Ich das Thema auf "Zurückgestellt", würde mich aber wieder melden, wenn ich beim Wechsel zu 13.2 Entdeckungen mache, die helfen, das Thema endgültig zu lösen.