Ich habe eine Fedora 32-Installation mit einem HP Probook 450 G0. Das BIOS mit Administratorrechten lässt mich "Fast Boot" nicht deaktivieren. Warum nicht? Was soll ich tun? Irgendwie schaltet sich mein Fedora nach dem Herunterfahren automatisch wieder ein, und zwar innerhalb von 3 Sekunden. Ich dachte also, es läge an meinem aktivierten "Fast Boot", aber leider gibt es keine Möglichkeit, es zu deaktivieren. Meine anderen Einstellungen:
- Wake on LAN > Bootreihenfolge befolgen
- Eingebettetes WLAN-Gerät aktiviert
- Eingebetteter LAN-Controller aktiviert
- Booten des USB-Geräts
- Maßgeschneiderter Schuh
- "Fast Boot" ist aktiviert
- Sicherer Start ist AUS
- Bootmodus > UEFI native (ohne CSM)
- UEFI-Startreihenfolge > Allgemeines USB-Gerät > Benutzerdefinierter Start > OS-Startmanager
Wie gesagt, ich greife auf mein BIOS als „Administrator“ zu. Ich habe DriveLock aktiviert und auch ein Passwort festgelegt (= das war eine Voraussetzung für das Ein-/Ausschalten von „Fast Boot“).
Antwort1
Das klingt genau wie das Problem, das ich mit meinem vorherigen Desktop-System zu Hause hatte.
HP Probook 450 G0 verwendet einen Mobile Intel HM76 Express-Chipsatz, der auch unter dem Intel-Entwicklungscodenamen „Panther Point“ bekannt ist. Mein Desktop, bei dem dieses Problem auftrat, hatte auch einen Panther Point-Chipsatz.
Das eigentliche Problem besteht darin, dass die XHCI-USB-Controller der Panther Point- und Lynxpoint-Chipsätze auf eine bestimmte, kontrollierte Weise heruntergefahren werden müssen, da sie sonst das System sofort wieder aufwecken. Ärgerlicherweise erfordern verschiedene Versionen der Chipsätze unterschiedliche Herunterfahrschritte, und der Fix für eine Version löst tatsächlich das Problem für eine andere aus. Einige (vielleicht die meisten?), aber nicht alle BIOSe handhaben es automatisch, sodass das Problem nur auf einer Teilmenge von Systemen mit diesen Chipsätzen auftritt.
Eine ausführliche Diskussion zu diesem Problem finden Sie unter:https://bugzilla.kernel.org/show_bug.cgi?id=66171
Kurz gesagt gibt es für dieses Problem zwei im Linux XHCI-Treibercode definierte Eigenheiten: XHCI_SPURIOUS_WAKEUPund XHCI_SPURIOUS_REBOOT. Abhängig von der genauen Chipsatzversion müssen Sie möglicherweise eine oder beide dieser Eigenheiten aktivieren.
XHCI_SPURIOUS_REBOOTSie können die Eigenart /etc/modprobe.d/*.confzeilenweise options xhci-hcd quirks=8192oder mit der Kernel-Boot-Option aktivieren xhci_hcd.quirks=8192.
Um die XHCI_SPURIOUS_WAKEUPOption zu aktivieren, verwenden Sie den Wert 262144anstelle von 8192; um beide Macken gleichzeitig zu aktivieren, verwenden Sie den Wert 270336(= die Summe der beiden Werte).
Versuchen Sie es zuerst mit der Kernel-Bootoption: Sie funktioniert unabhängig davon, ob der XHCI-Treiber in den Hauptkernel integriert oder als Kernelmodul geladen ist. Wenn Sie eine Option finden, die das Problem für Sie behebt, /etc/modprobe.d/*.confist das Hinzufügen zu einer Datei möglicherweise eine „sauberere“ Möglichkeit, das Problem dauerhaft zu machen, wenn der XHCI-Treiber als Modul geladen ist.
Da USB-Treiber für USB-Tastaturen unbedingt erforderlich sind, wird der XHCI-Treiber möglicherweise schon früh in der Initramfs-Phase des Startvorgangs geladen. /etc/modprobe.d/*.confDenken Sie daher nach einer Änderung an daran, Ihre Initramfs-Datei neu zu erstellen ( dracutist das aktuelle Initramfs-Tool in Fedora, glaube ich?).
Das Problem tritt auch auf, wenn der XHCI-Treiber entladen bleibt, da der Kernel ohne vorhandenen XHCI-Treiber nicht weiß, dass der XHCI-Controller beim Herunterfahren besondere Aufmerksamkeit erfordert.