Tengo una instalación de Fedora 32 con un HP Probook 450 G0. La BIOS con privilegios de administrador no me deja desactivar el "arranque rápido". ¿Por qué no? ¿Qué hacer? De alguna manera, mi Fedora se enciende automáticamente nuevamente después de apagarse, y en 3 segundos. Así que pensé que tenía que ver con mi "arranque rápido" habilitado, pero desafortunadamente no hay forma de desactivarlo. Mis otras configuraciones:
- Wake on LAN > seguir el orden de inicio
- habilitado Dispositivo WLAN integrado
- Controlador LAN integrado habilitado
- Arranque del dispositivo USB
- Bota personalizada
- El "arranque rápido" está habilitado
- El arranque seguro está desactivado
- Modo de arranque > UEFI nativo (sin CSM)
- Orden de arranque UEFI > Dispositivo USB genérico > Arranque personalizado > Administrador de arranque del sistema operativo
Como dije, entro a mi BIOS como "administrador". Tengo DriveLock habilitado y también configuré una contraseña (= ese era un requisito para activar/desactivar el "arranque rápido").
Respuesta1
Esto se parece al problema que tuve con mi anterior sistema de escritorio doméstico.
HP Probook 450 G0 utiliza un chipset Mobile Intel HM76 Express, que también se conoce con el nombre en clave de desarrollo de Intel "Panther Point". Mi computadora de escritorio que tenía este problema también tenía un chipset Panther Point.
El problema real es que los controladores USB XHCI de los conjuntos de chips Panther Point y Lynxpoint deben apagarse de una manera particular y controlada, o de lo contrario reactivarán el sistema nuevamente. Es exasperante que diferentes versiones de los conjuntos de chips necesitarán diferentes pasos de apagado, y la solución para una versión en realidad desencadena el problema en otra. Algunos BIOS (¿quizás la mayoría?), pero no todos, lo manejan automáticamente, por lo que el problema solo existe en algún subconjunto de sistemas que utilizan estos conjuntos de chips.
Encontrará una larga discusión sobre este problema en:https://bugzilla.kernel.org/show_bug.cgi?id=66171
En pocas palabras, hay dos peculiaridades definidas en el código del controlador XHCI de Linux para este problema: XHCI_SPURIOUS_WAKEUPy XHCI_SPURIOUS_REBOOT. Dependiendo de la versión exacta del chipset, es posible que necesite habilitar una o ambas de estas peculiaridades.
Puede habilitar la XHCI_SPURIOUS_REBOOTpeculiaridad por /etc/modprobe.d/*.conflínea options xhci-hcd quirks=8192o con la opción de arranque del kernel xhci_hcd.quirks=8192.
Para activar la XHCI_SPURIOUS_WAKEUPopción, use el valor 262144en lugar de 8192; para activar ambas peculiaridades a la vez, use el valor 270336(= la suma de los dos valores).
Pruebe primero la ruta de la opción de arranque del kernel: funcionará independientemente de si el controlador XHCI está integrado en el kernel principal o cargado como un módulo del kernel. Si encuentra una opción que lo solucione, agregarlo a un /etc/modprobe.d/*.confarchivo podría ser una forma "más limpia" de hacerlo persistente si el controlador XHCI está cargado como un módulo.
Dado que los controladores USB son esenciales para los teclados USB, el controlador XHCI puede cargarse temprano en la fase initramfs del proceso de arranque, por lo que después de realizar un cambio en /etc/modprobe.d/*.conf, recuerde reconstruir su archivo initramfs ( dracut¿creo que la herramienta initramfs actual está en Fedora?) .
Dejar el controlador XHCI descargado también presentará el problema, ya que sin un controlador XHCI presente, el kernel no sabrá que el controlador XHCI necesita atención especial al apagarlo.