Shutdown und Rebootprobleme seit Update

[lexboreas]

Moin, benutze momentan ein Dualboot System aus Linux Mint 19.3 (Tricia) und Win 10. Windows hat Bootprioritaet und Linux nur uebers Boot Menu beim Hochfahren. Hat bislang alles tiptop geklappt. Nach einem Update vor etwa einer Woche von Mint 19.3 fahrt zwar Linux als Betriebssystem runter bei shutdown bzw Reboot, der Rechner physisch als solches allerdings nicht, er bleibt an bzw macht nicht weiter beim reboot und bleibt "haengen". Ein physisches Reboot mittels dem rebootknopf am towergehaeuse laesst mich dann kalt starten. Notloesung und nicht so wie es eigentlich funktionieren sollte. Waehrend dem runterfahren bzw rebooten blinkt nach dem verschwinden des mint logos nach dem befehl geben zum shutdown oder reboot fuer kurze Zeit die EZ-Debug-Lampe an meinem Mainboard, was schon mal ein erster Zeichengeber ist (kann ich schoen durchs seitenfenster beobachten, allerdings fuer die CPU-Lampe, was mich ein wenig kopfkratzend zurueck laesst. Der CPU gehts blended, temperatur, spannungsmaessig usw, alles ueberprueft. Ueberhaupt keine Probleme beim Nutzen von Linux Mint oder Win 10 waehrend dem betrieb, lediglich ein und ausschalten unter linux mint sind verbuggt.

Auch Konsolenbefehle via -shutdown und -poweroff fuehren zudemselben Ergebnis. Ein wenig erste Internetrecherche bei Leuten mit aehnlichen Problemen von allerdings weiter zurueck liegenden versionen machte drei vermeintliche Hauptbaustellen aus: GPU-Treiber, Boot (grub loader) bzw. UEFI-Einstellungen. Die Treiber habe ich mittlerweile aktualisiert, Secure-Boot im UEFI ausgestellt, wie in manchen anderen foren gefordert in der grub config GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" den Teil in italics entfernt, gespeichert und anschliessend sudo update-grub ausgefuehrt, aber bislang immer noch kein Erfolg.

Linux Mint 19.3 (Tricia), Kernel 5.3.0-53-generic
Windows ist win 10 1909
GPU-Treiber

Waere ueber jegliche Tipps dankbar,
LG
Alex

 

[Photon]

Für mich klingt das so, als wäre ein Kernel-Update die Ursache. Poste doch mal dein Update-Log, dann sieht man, was da alles aktualisiert worden ist.

 

[Uridium]

Was ist das denn für Hardware?
Vielleicht mal andere 'shutdown' Methoden ausprobieren:
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
Ich habe ein Laptop, das braucht auch explizit 'pci, warm' für ordnungsgemäßen betrieb.

reboot=         [KNL]
                        Format (x86 or x86_64):
                                [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \
                                [[,]s[mp]#### \
                                [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \
                                [[,]f[orce]
                        Where reboot_mode is one of warm (soft) or cold (hard) or gpio
                                        (prefix with 'panic_' to set mode for panic
                                        reboot only),
                              reboot_type is one of bios, acpi, kbd, triple, efi, or pci,
                              reboot_force is either force or not specified,
                              reboot_cpu is s[mp]#### with #### being the processor
                                        to be used for rebooting.

 

[K-BV]

Starte Mint mal mit dem älteren Kernel (im Grubmenü über erweiterte....,) aufzurufen und schau, ob der Fehler dort auch auftritt.
Um Grub sichtbar zu machen, musst bei Neustart auf die esc-Taste Hämmern bei UEFI Sytemen. Ggf. Bootpriorität ändern. Hat eh keinerlei Auswirkungen, ob Grub oder Windows vorne steht bei UEFI. Die tun sich nichts!

Fastboot in Windows und UEFI/BIOS ist hoffentlich deaktiviert!?

 

[Uridium]

Hat eh keinerlei Auswirkungen, ob Grub oder Windows vorne steht bei UEFI. Die tun sich nichts!

Microsoft first!
https://unix.stackexchange.com/a/242219
https://askubuntu.com/questions/838780/windows-10-changes-uefi-boot-order-every-time
https://answers.microsoft.com/en-us...ipulates/34921a27-f05a-4853-b7fc-183d900870fa
[...]

 

[K-BV]

Ja, ist vorgekommen und kann vorkommen. Nur warum soll man in den 99,x % der anderen Fälle auf den Komfort von Grub verzichten? I.d.R. passiert etwas gleich nach der Einrichtung und man kann sich daran orientieren. Grub selbst ist i.d.R. auch nicht der Übeltäter, sondern die Firmware im Zusammenspiel mit Windows. Nutzt man vorwiegend Windows, kann es sinnvoll sein, den WinBootManager nach vorne zu schieben. Bei ständigem Wechsel oder vorwiegend Linux aber komplett überflüssig.
BTW: Wenn nur die Bootorder geändert wird ist das ja noch harmlos. Es gibt Firmwares, die killen gleich den ganzen Eintrag im NVRAM.

 

[lexboreas]

Ok, hab nach den Empfehlungen hier mich noch mal ran gesetzt und es scheint in der tat am letzten kernel update gelegen zu haben... was ich natürlich nicht gleich als erstes gecheckt habe... (Memo an mich selbst: Die naheliegendsten Lösungen sind dann doch oft die richtigen). Ungewöhnlich dennoch, trotzdem ist das Problem mit vorläufig mit vorigem Kernel behoben.

Vielen lieben Dank und reingehaun!

 

[polyphase]

Das gleiche Problem habe ich mit dem Ryzen Notebook meiner Mutter auch.
Ist ein bekannter Bug (das Netz ist voll davon). Alle Workarounds haben nicht geholfen.
Auch der LTS Kernel der 4er Reihe nicht.

Mit einer Disti mit aktuellem kernel tritt das Problem nicht mehr auf (mit Manjaro getestet)