Kannst du bitte GRUB einschalten damit man sieht ob dein system sauber durch grub durchkommt ?
in /etc/default/grub sollte die Zeile so aussehen:
GRUB_TIMEOUT_STYLE=menu
Habe ich getan. Woran sehe ich nun, ob’s sauber durchkommt?
Nach dem Hersteller-LOGO sollte für ca 3 Sekunden Grub zu sehen sein.
Danach folgt dann eventuell wieder das LOGO, dann manjaro.
Wenn es wieder mal nicht bootet, kannst du dann sagen:
Es war im BIOS oder in GRUB oder beim laden des KERNEL
Hm, nach der Änderung und update-grub kam ich beim Reboot sofort in die Auswahl, also alles VOR dem Hersteller-Logo.
1 Like
Habe gerade noch mal komplett Heruntergefahren und wieder gestartet und das Problem trat wieder auf. Habe ein Video gemacht: 2023-02-14-140407
journalctl --boot=-1 --priority=3 --catalog --no-pager
Feb 14 14:00:05 quas-xps kernel: spi-nor spi0.0: BFPT parsing failed. Please consider using SPI_NOR_SKIP_SFDP when declaring the flash
Feb 14 14:00:07 quas-xps kernel:
Feb 14 14:00:08 quas-xps kernel: Bluetooth: hci0: Malformed MSFT vendor event: 0x02
Feb 14 14:00:08 quas-xps bluetoothd[635]: src/plugin.c:plugin_init() Failed to init vcp plugin
Feb 14 14:00:08 quas-xps bluetoothd[635]: src/plugin.c:plugin_init() Failed to init mcp plugin
Feb 14 14:00:08 quas-xps bluetoothd[635]: src/plugin.c:plugin_init() Failed to init bap plugin
Feb 14 14:00:08 quas-xps bluetoothd[635]: Failed to set mode: Failed (0x03)
journalctl --boot=0 --priority=3 --catalog --no-pager
Feb 14 14:02:45 quas-xps kernel: spi-nor spi0.0: BFPT parsing failed. Please consider using SPI_NOR_SKIP_SFDP when declaring the flash
Feb 14 14:02:46 quas-xps kernel:
Feb 14 14:02:47 quas-xps kernel: Bluetooth: hci0: Malformed MSFT vendor event: 0x02
Feb 14 14:02:47 quas-xps bluetoothd[617]: src/plugin.c:plugin_init() Failed to init vcp plugin
Feb 14 14:02:47 quas-xps bluetoothd[617]: src/plugin.c:plugin_init() Failed to init mcp plugin
Feb 14 14:02:47 quas-xps bluetoothd[617]: src/plugin.c:plugin_init() Failed to init bap plugin
Feb 14 14:02:47 quas-xps bluetoothd[617]: Failed to set mode: Failed (0x03)
Feb 14 14:02:59 quas-xps systemd[739]: Failed to start Update XDG user dir configuration.
░░ Subject: A start job for unit UNIT has failed
░░ Defined-By: systemd
░░ Support: https://forum.manjaro.org/c/support
░░
░░ A start job for unit UNIT has finished with a failure.
░░
░░ The job identifier is 22 and the job result is failed.
Feb 14 14:03:05 quas-xps bluetoothd[617]: Failed to set mode: Failed (0x03)
Feb 14 14:04:58 quas-xps konsole[1805]: kf.xmlgui: Shortcut for action "" "SSH-Verwaltung anzeigen" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Feb 14 14:04:58 quas-xps konsole[1805]: kf.xmlgui: Shortcut for action "" "Schnellbefehle anzeigen" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Irgendwie beschleicht mich das Gefühl, dass du das Journal von der Live-Sitzung hast und nicht von der lokalen Installation.
Schick mal den gesamten Journal:
# Wenn kein ext4, dann funktioniert es NICHT automatisch.
sudo manjaro-chroot -a
journalctl --boot 0 --no-hostname | curl -F'file=@-' https://0x0.st
journalctl --boot -1 --no-hostname | curl -F'file=@-' https://0x0.st
Es wird jeweils ein Link ausgegeben.
Auf jeden Fall sind all diese “Fehler”, nicht wirklich der Grund für das Hängen bleiben.
sudo: manjaro-chroot: Befehl nicht gefunden
Muss ich das mit der Live-ISO machen?
Also eigentlich keine hinderlichen Fehler vermerkt im Journal. Im Grunde startet SDDM, wenn auch mit Warnungen. Loggt dich automatisch ein und startet alles, nur es wird auf deinen Bildschirmen nichts angezeigt.
Ich würde mal mit nur einem Bildschirm starten. Liegt wohl irgendwie am Bildschirm-Management von Plasma und Xorg.
An deiner Stelle würde ich mir mal diese Datei ansehen:
cat /var/log/Xorg.0.log
cat /var/log/Xorg.1.log
Kannst du wie oben auch hochladen.
Könnte sein, dass das irgendwie mit den Bildschirmen zusammenhängt.
Gerade heruntergefahren und mit einem externen Bildschirm angeschlossen wieder gestartet: Hängengeblieben beim Hersteller-Logo und dem Manjaro-Schriftzug mit Ladeanimation.
Dann ohne verbundene externe Bildschirme gestartet: Hängengeblieben, schwarzer Screen mit den Meldungen:
[ OK ] Finished Hold until boot process finishes up.
[ OK ] Started CUPS Scheduler.
[ OK ] Finished Terminate Plymouth Boot Screen.
Nächster Versuch, wieder ohne externe Bildschirme: Hängengeblieben beim Hersteller-Logo OHNE Manjaro-Schriftzug/Ladeanimation.
Dann beide Bildschirme wieder angeschlossen und ins System gekommen.
cat /var/log/Xorg.0.log | curl -F'file=@-' https://0x0.st
https://0x0.st/HrWv.txt
cat /var/log/Xorg.1.log | curl -F'file=@-' https://0x0.st
cat: /var/log/Xorg.1.log: Datei oder Verzeichnis nicht gefunden
451 Unavailable For Legal Reasons
Puh… Ich hab das jetzt doppelt durchgesehen. Keine erkennbaren Probleme. Das ist wirklich seltsam, dein Problem.
- Entferne
quietundsplashvon den Kernel-Parametern in/etc/default/grubundupdate-grubausführen. - Deaktiviere den Autologin. Nicht sicher, aber muss eine Datei in diesem Ordner sein:
/etc/sddm.conf.d/ - Erstelle einen neuen Benutzer:
useradd -m testuserund Password vergeben:passwd testuser.
Dann neu starten und mit dem neuen Benutzer einloggen.
Nur zu Anmerkung: Ich selbe benutze kein KDE Plasma, deswegen kenne ich mit den ganzen Bugs da nicht aus.
Danke für deine Mühe. Es ist wirklich seltsam.
Alles befolgt, Autologin war bereits deaktiviert.
Beim Neustart gab’s keine Fehlermeldungen, dann mit dem testuser eingeloggt, wieder neugestartet und hier hängengeblieben:
Beim neuerlichen Starten des Systems ging’s dann hier nicht mehr weiter:
Ok. Es kann womöglich eine Inkompatibilität mit dem BIOS sein, da ACPI Error.
Ich hab mal deinen vorherigen Beitrag angesehen:
Dein UEFI BIOS scheint veraltet zu sein, du solltest es mal auf den neusten Stand bringen: https://www.dell.com/support/home/de-de/drivers/driversdetails?driverid=438kv&oscode=naa&productcode=xps-15-7590-laptop
Oder eine Einstellung verhindert das Starten von Linux. Das BIOS/UEFI von DELL ist eben nur für Win10 und Win11 ausgelegt, kann aber auch mit Linux funktionieren.
fwupdmgr hat’s noch nicht, dann muss ich mal schauen, wie ich das manuell hinbekomme. Allerdings bezweifle ich, dass es am nicht vorhandenen BIOS-Update liegt, das Problem tritt ja schon länger auf, als es das Update gibt. Find’s echt seltsam, der Laptop lief fast zwei Jahre ohne Probleme mit Manjaro und Plasma.
Edit: Update ist doch da, ich mach mal schnell.
Edit2: BIOS-Update erfolgreich, Reboot lief auch problemlos durch. Muss jetzt weg vom PC für heute, werde die Sache morgen weiter beobachten und mich noch mal melden. Wenn es dann immer noch zum Problem kommt, werde ich wahrscheinlich noch mal ganz neu aufsetzen und eine andere DE verwenden. Lieben Dank für die Hilfe bis hierher!
Mich macht ja stutzig das er immer nach terminate plymouth boot screen hängen bleibt.
Dazu hab ich diesen Thread gefunden.
Könnte passen
1 Like
Ich glaube das war’s!
Habe wie beschrieben in /etc/mkinitcpio.conf zur Zeile MODULES=
"nvidia nvidia_modeset nvidia_uvm nvidia_drm"
hinzugefügt und in /etc/default/grub in der Zeile GRUB_CMDLINE_LINUX_DEFAULT
nvidia-drm.modeset=1
Dann
sudo mkinitcpio -P
und
sudo update-grub
Habe jetzt mehrmals neugestartet, heruntergefahren und gebootet, ohne angeschlossene Bildschirme und mit und es lief jedes Mal problemlos durch.
1 Like
Unglaublich. Ist das immer noch ein Problem? Dachte, das wäre jetzt obsolete, aber gut zu wissen.
Veraltetes BIOS war’s jedenfalls nicht, nach dem Update trat das Problem weiter auf.
Seit der von weingeist angeregten Lösung läuft alles. Ich freu mich mal nicht zu früh, beobachte das die nächsten Tage weiter und berichte dann noch mal. Vielen Dank an alle!
Wir sind gespannt
So. Das Problem ist nicht mehr aufgetreten. Herunterfahren, Booten und Rebooten laufen schnell und flüssig durch, nichts zickt mehr. Hab’s in allen erdenklichen Kombinationen ausprobiert (ohne zu wissen, ob irgendetwas davon überhaupt eine Einfluss haben könnte; der Fehler trat ja aber sehr regelmäßig auf, manchmal jedoch nicht): Mit angeschlossenen Monitoren und ohne, an der Steckdose und mit Akku, mit verschiedenen Kerneln - läuft alles. Habe das System seitdem bestimmt dreißig Mal gestartet und keine Probleme.
Dann wollte ich ein Windows-Spiel mit Lutris/Wine spielen, das bisher immer einwandfrei funktionierte und es startete nicht. Habe es folglich deinstalliert und beim Versuch einer Neuinstallation hing Lutris immer direkt beim Erstellen des win64 wine prefix fest.
Ich habe dann in /etc/default/grub in der Zeile GRUB_CMDLINE_LINUX_DEFAULT den Parameter nvidia-drm.modeset=1 wieder gelöscht, wonach Lutris bzw. besagtes Spiel wieder einwandfrei funktionieren.
Das war gestern Nachmittag und das ursprüngliche Problem des Hängenbleibens beim Booten trat nach diversen Versuchen nicht wieder auf. Daher vermute ich, dass nur die andere Änderung, die ich vorgenommen hatte, zur Lösung des Problems nötig war, also in der Datei /etc/mkinitcpio.conf zur Zeile MODULES="" die Parameter nvidia nvidia_modeset nvidia_uvm nvidia_drm hinzuzufügen.
Was genau da passiert, weiss ich ehrlich gesagt nicht, da fehlt mir wahrscheinlich das Grundwissen. Habe mir durchgelesen, was mkinitcpio.conf überhaupt macht und das nicht so wirklich verstanden. Vielleicht brauch man auch gar nicht alle vier Parameter? Ich bin mir jedenfalls relativ sicher, dass diese Änderung das Problem behoben hat. Habe das vorhin noch mal rückgängig gemacht und beim zweiten Bootversuch hing’s wieder.
Vielleicht kann dazu ja noch mal jemand Erleuchtung bringen. Interessiert mich schon, was da überhaupt genau passiert. Vielen Dank!
Probier doch jeden Parameter mal einzeln aus.