[gelöst]neuer Kernel - schwarzer Schirm

[unklar]

Ich habe jetzt nachstellbar folgendes Verhalten auf meinem Testdesktop mit kf5 festgestellt:

Wird ein neuer Kernel eingespielt, lande ich nach dem Neustart immer am schwarzen Schirm mit Good luck "und betätigen einer Taste" auf tty1.
Herausgefunden hatte ich, wenn man beim Start mit "e" die Kernelzeile editiert und ein

Code: Alles auswählen

nokmsboot

anhängt/einfügt, dann ist der Start erfolgreich. Vorsorglich hatte ich in der

Code: Alles auswählen

/boot/grub/menu.lst

alle Kernel mit nokmsboot deshalb bereits ausgestattet.

Mit neuen Kernel, wird auch die menu.lst neu geschrieben - natürlich ohne nokmsboot - und das Ringelbietz begann von vorn, indem der Display-Manager (sddm) eben seine Dienst verweigert.

Das System:

Code: Alles auswählen

$ inxi -SG
System:    Host: localhost.localdomain Kernel: 4.2.6-desktop-1.mga6 x86_64 (64 bit)
           Desktop: KDE Plasma 5.4.90 Distro: Mageia 6 thornicroft
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Barts XT [Radeon HD 6870]
           Display Server: X.Org 1.18.0 drivers: ati,v4l,radeon
           Resolution: 1680x1050@59.88hz
           GLX Renderer: Gallium 0.4 on AMD BARTS (DRM 2.43.0, LLVM 3.7.0)
           GLX Version: 3.0 Mesa 11.0.5

Die Fehlermeldung(en):

Code: Alles auswählen

Display_Manager startet nicht nach neuen Kernel 4.2.6 gestern (betrifft alle ab 4.1.7)

systemctl status prefdm -a ergibt:
● prefdm.service - Display Manager
   Loaded: loaded (/usr/lib/systemd/system/prefdm.service; static; vendor preset: enabled)
   Active: failed (Result: start-limit) since Do 2015-11-12 13:30:36 CET; 10min ago
  Process: 1384 ExecStart=/etc/X11/prefdm -nodaemon (code=killed, signal=SEGV)
 Main PID: 1384 (code=killed, signal=SEGV)

Nov 12 13:30:36 localhost.localdomain systemd[1]: prefdm.service: Failed with result 'signal'.
Nov 12 13:30:36 localhost.localdomain systemd[1]: prefdm.service: Service has no hold-off time, scheduling restart.
Nov 12 13:30:36 localhost.localdomain systemd[1]: Stopped Display Manager.
Nov 12 13:30:36 localhost.localdomain systemd[1]: prefdm.service: Start request repeated too quickly.
Nov 12 13:30:36 localhost.localdomain systemd[1]: Failed to start Display Manager.
Nov 12 13:30:36 localhost.localdomain systemd[1]: prefdm.service: Unit entered failed state.
Nov 12 13:30:36 localhost.localdomain systemd[1]: prefdm.service: Triggering OnFailure= dependencies.
Nov 12 13:30:36 localhost.localdomain systemd[1]: prefdm.service: Failed with result 'start-limit'.

Code: Alles auswählen

journalctl _PID=1384 ergibt:
-- Logs begin at Di 2015-07-14 19:27:08 CEST, end at Do 2015-11-12 13:35:11 CET. --
Jul 14 21:19:17 localhost sshd[1384]: Server listening on 0.0.0.0 port 22.
Jul 14 21:19:17 localhost sshd[1384]: Server listening on :: port 22.
Jul 14 22:15:16 localhost sshd[1384]: Received signal 15; terminating.
-- Reboot --
Okt 11 13:04:53 localhost.localdomain rpc.statd[1384]: Version 1.3.0 starting
-- Reboot --
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Initializing...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Starting...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Adding new display on vt 1 ...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Display server starting...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{c8e40d30-f1f0-4587-84d8-4e3c30892752} -background none -noreset -displayfd 17 vt1
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Running display setup script  "/usr/share/sddm/scripts/Xsetup"
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Display server started.
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Socket server starting...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Socket server started.
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Greeter starting...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Adding cookie to "/var/run/sddm/{c8e40d30-f1f0-4587-84d8-4e3c30892752}"
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Display server stopped.
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Socket server stopping...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Socket server stopped.
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Removing display "" ...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Adding new display on vt 1 ...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Display server starting...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{44f58b15-f2d2-48d6-a293-1e840419cc84} -background none -noreset -displayfd 19 vt1
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Running display setup script  "/usr/share/sddm/scripts/Xsetup"
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Display server started.
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Socket server starting...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Socket server started.
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Greeter starting...
Nov 12 13:30:36 localhost.localdomain sddm[1384]: Adding cookie to "/var/run/sddm/{44f58b15-f2d2-48d6-a293-1e840419cc84}"
Nov 12 13:30:36 localhost.localdomain sddm[1384]: QProcess: Destroyed while process ("/usr/libexec/sddm-helper") is still running.


Die Installation befindet sich in einem Multiboot-System und der Grub2 von MGA4 startet das.
Vielleicht kann wer was damit anfangen (obwohl ich aus arch-linux weiß, dass der sddm "noch einige Macken hat").

[doktor5000]

Vorsorglich hatte ich in der

Code: Alles auswählen

/boot/grub/menu.lst

alle Kernel mit nokmsboot deshalb bereits ausgestattet.

Mit neuen Kernel, wird auch die menu.lst neu geschrieben - natürlich ohne nokmsboot - und das Ringelbietz begann von vorn, indem der Display-Manager (sddm) eben seine Dienst verweigert.
[...]
Die Installation befindet sich in einem Multiboot-System und der Grub2 von MGA4 startet das.

Das heißt, der grub2 startet den grub legacy von Cauldron via chainload?
Oder startet er die Bootloader-Einträge von Cauldron direkt? In letzterem Fall sind natürlich deine Anpassungen in der Cauldron-menu.lst irrelevant und du musst das in den grub2-Einträgen von deinem mga4 ergänzen ...
Siehe auch https://wiki.mageia.org/en/Mageia_5_Err ... el_options

Abgesehen davon, die Option heißt eigentlich nomodeset - nokmsboot funktioniert zwar auch, aber bei keiner anderen Distro ...
Siehe https://wiki.archlinux.org/index.php/Ke ... odesetting

[unklar]

Das heißt, der grub2 startet den grub legacy von Cauldron via chainload?

Nein, warum den Umweg.

In letzterem Fall sind natürlich deine Anpassungen in der Cauldron-menu.lst irrelevant...

Warum irrelevant, ich muß eh

Code: Alles auswählen

update-grub2

ausführen, damit neue Kernel hier im Menü (von mga4) zur Verfügung stehen.

Na gut, ich kann das ja in der /etc/default/grub mal ausprobieren, wäre ein Schritt weniger. Ja, und das nokmsboot habe ich eben aus dem von dir verlinkten Wiki...

Danke für deine Hinweise.

Übrigens, wer sich für dieses Plasma5 interessiert und sich nicht diesen Testdesktop von MGA antun möchte (der wirklich jeden Tag
eine andere "Überraschung" bietet) und schon einmal das "Gefühl" spüren will, den empfehle ich die Kleine aber feine KaOS .
- ist eine RollingRelease auf der Basis von arch
- gibt es nur in x86_64 Architektur
- umfasst gegenwärtig "nur" um die 2000 Pakete, weil alles von Grund auf neu erstellt
- wird faßt nur von einer Frau gestemmt
- kann man alles in deutsch haben (außer das Forum), wie von mir verlinkt und die Paketverwaltung pacman ist wirklich ein Klacks

So einen Installer habe ich noch nirgend erlebt.

[unklar]

Ich denke, dass ich das hier jetzt für mich als gelöst makieren kann.

Gestern wurde, seit ich den lightdm benutze, zum zweiten mal ein neuer Kernel eingespielt. Der anschließende Neustart verläuft ohne Probleme.

Was ich anfangs nicht erkannt habe war

Code: Alles auswählen

journalctl -b -p err
-- Logs begin at Di 2015-07-14 19:27:08 CEST, end at Mi 2015-10-28 19:07:17 CET. --                                                                                                     
Okt 28 18:45:12 localhost.localdomain kernel: CX24123: cx24123_i2c_readreg: reg=0x0 (error=-121)                                                                                       
Okt 28 18:45:12 localhost.localdomain kernel: CX24123: wrong demod revision: 87                                                                                                         
>>>>>>>>>Okt 28 18:45:17 localhost.localdomain kernel: RIP  [<ffffffffc07b8b51>] firegl_trace+0x61/0x1e0 [fglrx]<<<<<<<<<<<<<<<
(am Start: "Ein kernel-modul wurde erkannt und geladen, was möglicherweise im Konflikt mit der Konfiguration Ihres X-Server steht"
ODER so ähnlich. Siehe "RadeonHD6870" hier im VZ)

Code: Alles auswählen

in der orig. xorg.conf steht
ati  als Driver

und in der xorg.conf.mga1444...
fglrx

Schaffte es nach einigen Versuchen dann der fglrx doch, dann kam der obige Fehler mit dem sddm und ich hatte das von mir erwähnte
"Ringelbietz".
Durch den Austausch des fglrx mit dem ati und dem sddm mit lightdm habe ich jetzt wenigstens wieder ein benutzbares plasma5.

Ich kann nicht erklären, warum.
Vor allem, weil der andere cauldron mit lxqt den fglrx-driver schmerzfrei verwendet.

Der einzigste Unterschied:
plasma5 installiert den desktop-Kernel und
lxqt hat den server-kernel

Hierfür habe ich keine Hand angelegt. Das System hat das so gewählt.