Mageia Forum

Hallo an alle,

Seit langer Zeit melde ich mich mal wieder mit einem Problem :
Ich habe auf 4 Laptops unterschiedlichster Art Mageia 7.1 installiert und null Probleme gehabt. Jetzt beim 5. Laptop habe ich nach der Installation und darauffolgendem Update auf Kernel 5.3.7 folgendes Problem:

> Nach dem Einschalten erscheint das Grub-Menü
> Nach Auswahl von Mageia erscheint ein Textbildschirm mit der Anzeige von KVM-Modulen, welche nicht aktiviert werden können
> Es erscheint der grafische Startbildschirm für ca. 5 Sekunden
> Es erscheint wieder der Textbildschirm
Hier bleibt Mageia solange hängen, bis ich entweder ein paar Tastenanschläge getätigt habe oder die Maus ein paar mal bewegt habe. Erst dann geht der Ladevorgang weiter und ich komme zur Anmeldemaske.

Es handelt sich um eine "nakte" Mageia-Installation ohne irgendwelche zusätzliche Software. Das BIOS des betroffenen Laptops habe ich ebenfalls geupdatet, hat aber nichts gebracht.
Ich habe das Mageia auch zweimal installiert, hat aber jeweils das gleiche Ergebnis gebracht.

Bei dem Rechner handelt es sich um ein Fujitsu Lifebook S760 mit Intel i5 Prozessor und AMD-Grafikkarte. Eigentlich nichts Besonderes. Mageia 6 lief auf diesem Rechner bislang auch problemlos. Die Probleme treten erst mit Mageia 7 auf

Hat jemand eine Idee, woran das liegen kann? Wie gesagt, Mageia 6 lief problemlos. Extra Kernel-Optionen waren hier nicht notwendig...

Grüße aus dem Norden
rowitt

Geh mal ins BIOS und sieh nach ob die Virtualisierung eingeschaltet ist, wenn nicht einschalten; wenn ja ausschalten. Dann booten und schauen ob die Fehlermeldungen weg sind.
https://docs.fedoraproject.org/de-DE/Fe ... _BIOS.html

Hallo alf,

Danke für den Hinweis.
Das habe ich aber aufgrund der vielen KVM-Meldungen schon ausprobiert. Diese besagen ja etwas über die prozessorgestützte Virtualisierung aus. Da habe ich gedacht: Schau mal im BIOS und ändere mal die Einstellung.
Das hat leider im Bezug zum Start von Mageia nichts gebracht.
Oder muss ich das Mageia mit jetzt aktivierter Virtualisierung nochmal neu installieren

Es wäre hilfreich, wenn du die vielen KVM-Meldungen mal abfotografieren könntest, damit man mal sieht was da steht.

doktor5000 hat geschrieben:Es wäre hilfreich, wenn du die vielen KVM-Meldungen mal abfotografieren könntest, damit man mal sieht was da steht.

So hier habe ich mal 2 Screenshots. Der erste zeigt den "Standbildschirm" im normalen Startmodus, der zweite zeigt den "Standbildschirm" im Recovery-Modus:



Die Anzeige bezüglich "KVM disabled by BIOS" habe ich jetzt dadurch wegbekommen, dass ich im BIOS die Funktions "Trusted Execution Technology" ageschaltet habe. Diese Option hat aber bezüglich des Startvorgangs nichts bewirkt. Auch das gestern erfolgte Kernel-Update auf 5.3.11 hat keine Besserung gebracht.

Wie gesagt, unter Mageia 6 war das Startproblem nicht vorhanden.

rowitt

Und für das Verständnis, wenn du auf dem Fujitsu Lifebook S760 einen Kernel älter als 5.3.7 auswählst, bootet die Kiste ganz normal ?

Hallo doktor5000,

habe das mit einer "alte" Kernel-Version 5.1.14 nochmals probiert. Aber auch da bleibt er an der gleichen Stelle hängen.

Finde ich jetzt seltsam, da direkt nach der Installation von Mageia 7.1 keine Probleme waren. Erst nach dem Durchführen der ersten Updates nach der Grundinstallation begann dieses Verhalten. Ich hätte das jetzt wirklich auf die Kernel-Version geschoben.

Kann das auch an dem Display-Manager lieger (SDDM)?
Ich habe das Mageia mit dem Plasma-Desktop installiert. Wobei dieser ja noch nicht so früh aktiviert wird. Direkt nach dem Bewegen der Maus bzw. Drücken von einigen beliebigen Tasten startet doch erstmal der SDDM. Da ist nach meinem Verständnis doch noch nichts mit Plasma, XFCE, ...

Der Displaymanager zeigt normalerweise nur das Symptom, ist aber nicht die Ursache wenn er nicht selber startet.
Meistens kommt das, wenn nicht der richtige Grafiktreiber geladen werden kann oder wenn es andere Probleme mit dem X-Server gibt.

Was passiert denn, wenn du im Recovery Modus mal drakx11 startest und einen anderen Grafiktreiber, z.B. vesa auswählst, dann speicherst und rebootest?

Hm, das übersteigt zwar mein Linuxwissen, aber ich habe mal die andere Fehlermeldung aus deinem Screenshot gegoogelt: "acpi spcr unexpected spcr access width. defaulting to byte size".
Da gibt es bei allen möglichen Distributionen ähnliche Erfahrungen. Eine richtige Fehlerlösung konnte ich zwar auch nicht finden. Aber die gemeinsame Grundlinie war, das es scheinbar mit sehr alten Mainboard Firmware/BIOS zu tun hat die wohl nicht sauber mit aktuellen Kerneln zusammenarbeiten. Und dein Fujitsu ist ja auch aus der 2010er Modellreihe, also wird auch das BIOS-Update welches du durchgeführt hast (vermutlich) aus dem Jahr 2012-2014 stammen. Also auch nicht mehr so taufrisch.
@doktor5000: Wäre das eine Theorie oder ist das nur Stuss von mir?

Einfach irgendeine beliebige Meldung googeln, die evtl. nicht mal mit dem ursprünglichen Problem zu tun hat, ist meistens nicht zielführend.
Bislang hat rowitt ja nur die Symptone beschrieben, aber z.B. keine Logs o.ä. gepostet wo man sieht was das eigtl. Problem ist.

Und gesprächige ACPI-Meldungen gibt es bei den meisten Mainboards bei neueren Kerneln, das ist aber meistens nichts wirklich problematisches.

doktor5000 hat geschrieben:Und gesprächige ACPI-Meldungen gibt es bei den meisten Mainboards bei neueren Kerneln, das ist aber meistens nichts wirklich problematisches.

d'accord; hab da auch ein ca. 5 Jahre altes Asus-Board mit i7-CPU bei dem es mit MGA7(auch schon bei MGA6) reichlich Fehlermeldungen wg. im BIOS(UEFI) deaktiviertem KVM gibt, die aber in keiner Weise den Boot-Vorgang beeinträchtigen, in der Art, dass der Xserver resp. Plasma nicht gestartet werden werden kann.

Ok, Asche auf mein Haupt. Die Ergebnisse die ich gefunden hatte hatten halt die gleichen graphischen Effekte wie rowitt. Und diese Ergebnisse hingen mit der ACPI Meldung zusammen.
Ich bin raus...

Hallo rowitt,

folgender Vorschlag:

Starte deinen "Problemrechner" normal
Öffne ein Terminalfenster und
führe als root das Kommando

Code: Alles auswählen

journalctl -b > log.txt

aus.
Anschließend kopiere die erzeugte Datei in das Verzeichnis deines normalen Benutzers und mache ihn zum Eigentümer der Datei.
Diese Datei hängst du dann an deinen nächsten Post.

man-draker hat geschrieben:führe als root das Kommando

Code: Alles auswählen

journalctl -b > log.txt

aus.

Ich habe jetzt hier mal die log.txt.

Gruß
rowitt

Hm, dem angehängten Log entnehme ich keine echten Probleme.
Auffällig ist die zeitliche Lücke hier:

Code: Alles auswählen

Nov 23 13:52:27 localhost postfix/qmgr[3339]: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol
Nov 23 13:52:27 localhost postfix/pickup[3338]: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol
Nov 23 13:52:27 localhost ifplugd(wlp16s0)[2699]: Program executed successfully.
Nov 23 13:52:46 localhost systemd-timesyncd[791]: Initial synchronization to time server 216.239.35.8:123 (time3.google.com).
Nov 23 13:52:49 localhost systemd[1]: systemd-hostnamed.service: Succeeded.
Nov 23 13:52:50 localhost kernel: random: crng init done


Da scheint es ziemlich lange (~19 Sekunden) zu dauern, bis die Zeitsynchronisation übers Netz erledigt ist.


Hier ist noch mal ein 3 Sekunden-Sprung:

Code: Alles auswählen

Nov 23 13:52:53 localhost chronyd[925]: Selected source 131.234.137.64
Nov 23 13:52:56 localhost sddm-greeter[4900]: Reading from "/usr/share/xsessions/01plasma.desktop"


Aber das war es dann auch.

Ich würde jetzt mit einer LAN-Anbindung weiter testen.

Und vielleicht auch noch etwas Kontextinformationen dazu, was da passiert ist?
Das Log sieht für mich nach einem normalen Start von SDDM und danach Login in Plasma aus, anschließend hast du dich eine Minute später als root auf der Konsole angemeldet und vermutlich das Log gezogen.

Kann es sein dass du mehrere Bildschirme verwendest, z.B. am Laptop und die grafische Session aber nur auf dem internen Display läuft, und du die nicht gesehen hast?

So, am Samstag wie auch am Sonntag hatte ich leider keine weitere Zeit, mich des Problems zu widmen. Deswegen erst heute wieder eine Antwort von mir.

doktor5000 hat geschrieben:anschließend hast du dich eine Minute später als root auf der Konsole angemeldet und vermutlich das Log gezogen.

Das eine Minute später war die Wartezeit, die ich vor dem Laptop gesessen habe, bevor ich die Maus bewegt habe um weiter durchzustarten.

Es handelt sich hier wirklich nur um einen "einfachen" Laptop. Kein weiterer Bildschirm angeschlossen. Netzwerkverbindung über WLAN. Nackte Mageia-Installation. Angeschlossen ist nur eine Standard einfache USB-Maus.

Das mit der direkten LAN-Verbindung kann ich noch probieren. Werde mich dann später dazu melden...

So...,

krankheitsbedingt konnte ich die letzte Woche nicht viel am "Problemkind" werden. Habe erst heute wieder an das Gerät ran können und habe dort erstmal das Kernel-Update auf 5.3.13 durchgeführt.
Ich weiß jetzt zwar nicht, was da sich im einzelnen alles gegenüber der 5.3.11 und Vorversionen geändert hat. Aber das Startproblem ist jetzt behoben!
Ich habe - um wirklich sicher zu sein - das Gerät mehrmals ausgeschaltet und neu gestartet. Es ist immer ohne Probleme / Wartezeit hochgefahren.

Manche Dinge erledigen sich anscheinend doch einfach nur durch abwarten