Hay un fallo bastante típico en Linux que suele aparecer justo después de una actualización grande del sistema o del kernel: el sistema operativo se apaga correctamente, pero el ordenador no corta alimentación. O sea, te crees que se ha apagado porque está la pantalla negra, pero si prestas atención el ventilador sigue encendido, los LEDs vivos... y al día siguiente lo vas a encender y está sin batería 🤦🏻‍♂️

Como me ha ocurrido a mi hace poco otra vez, al actualizar el Zorin de mi portátil de la versión 17 a la 18, te comento un poco qué ha pasado y cómo solucionarlo.

Lo importante aquí es entender que normalmente no es un problema de hardware. De hecho, si antes funcionaba bien y dejó de hacerlo justo tras actualizar Ubuntu, Zorin, Mint, Fedora o lo que sea, lo más probable es que el problema esté en la interacción entre el nuevo kernel y el firmware ACPI/UEFI del equipo. Especialmente en equipos viejos (el mío es de 2014, y como era muy potente en su día, sigue yendo como una moto en 2026 con Zorin 18, pero se le notan los años en detalles como este).

¿Qué está pasando realmente?

En un apagado normal hay varias capas. Primero actúa el sistema operativo: cierra procesos, desmonta discos, detiene servicios, sincroniza datos... Hasta ahí suele ir todo bien.

Luego viene la parte delicada que nos falla en este caso: el kernel tiene que hablar con el firmware del equipo para decirle algo como: "Ya terminé. Ahora corta la corriente."

Esa comunicación pasa por mecanismos como ACPI, EFI, PCI, chipset, Embedded Controller, estados S0/S3/S4/S5, etc. El estado que nos interesa aquí es S5, el apagado real. Si el kernel ve que el equipo soporta S5, en teoría la máquina debería apagarse completamente.

Pero a veces una actualización importante del sistema operativo cambia muchas cosas de bajo nivel, como por ejemplo:

  • La versión del kernel
  • Los drivers de GPU
  • systemd
  • El stack de energía
  • La forma en que Linux negocia ACPI con la BIOS
  • La gestión de PCIe
  • los estados de suspensión
  • El comportamiento de Secure Boot o EFI.

Y claro, tú no has tocado el hardware. El portátil es el mismo. Pero el kernel nuevo habla con el firmware de otra manera.

En mi caso pasé de Zorin 17 con la versión 6.8 del kernel, a Zorin 18 con la versión 6.17. A saber qué cambios lleva por el medio para causar esto.

Si un día apaga bien y al siguiente con otra versión del sistema no, hay que sospechar de una incompatibilidad kernel/firmware y no del botón físico, ni de la fuente, ni de la batería. Podría ser, pero es menos probable.

El caso es que cuando pasa esto y le das a apagar, Linux sí termina su trabajo: cierra procesos, desmonta discos y llega al estado de apagado. El problema aparece en el último paso: cuando el kernel tiene que decirle al firmware del ordenador "ya puedes cortar corriente". Y ahí empiezan los malentendidos entre ACPI, BIOS, PCIe y firmware antiguo que "siempre funcionó perfectamente" hasta que alguien decidió modernizar el kernel (lo cual es estupendo, pero... puede dar problemillas).

Si miras los logs del proceso de apagado con:

journalctl -b -1 | grep -i "acpi\|power\|shutdown\|fail"

suelen aparecen mensajes relacionados con ACPI, firmware bugs o control PCIe retenido por la BIOS. Nada demasiado espectacular. Ese es parte del problema: estos fallos rara vez dejan un error evidente. Simplemente el sistema llega al apagado… y el hardware no remata la jugada.

Busca pistas como (esto es sacado del mío):

ACPI: [Firmware Bug]
_OSC: platform retains control
PM: supports S0 S1 S3 S4 S5
Reached target shutdown.target
Reached target System Power Off
Power down

Si ves que systemd llega al apagado (Power Down) pero el hardware no se apaga, el problema está casi seguro en esa fase final: kernel hablando con firmware, que no queda registrado aquí.

¿Cómo solucionar que Linux se apague pero el ordenador no?

La solución más limpia que he encontrado en estos casos suele ser añadir un parámetro a la configuración de GRUB. Aunque GRUB es el gestor de arranque que carga Linux al encender el equipo y no participa directamente en el apagado, sí permite pasar parámetros al kernel que cambian cómo Linux se comunica con el firmware ACPI/UEFI para apagar físicamente el hardware.

Para hacerlo, abre como root el archivo /etc/default/grub. Desde la terminal sería así:

sudo nano /etc/default/grub

Al abrirlo busca la línea GRUB_CMDLINE_LINUX_DEFAULT, que normalmente pondrá solamente quiet splash para no mostrar los mensajes de apagado. Añádele al final: reboot=pci para que quede así:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash reboot=pci"

Luego sales (CTRL+X) y le dices que grabe los cambios y haz lo siguiente desde la terminal para reiniciar el equipo:

sudo update-grub
sudo reboot

Y ahora prueba otra vez a suspender o apagar el ordenador.

En muchos equipos —especialmente Dell XPS, ASUS, Lenovo y portátiles con unos cuantos años encima— esto arregla el problema inmediatamente. Lo que hace es cambiar el método de bajo nivel que usa Linux para reiniciar o apagar el hardware. Nada más. Y precisamente por eso suele ser mejor opción que otras opciones más agresivas relacionados con ACPI.

Por ejemplo, existen cosas como:

acpi_osi=! acpi_osi='Windows 2015'

que lo que hace es modificar cómo Linux se presenta ante el firmware (básicamente le dice que es un Windows antiguo). Y puede arreglar el problema, pero también puede crear otros problemas nuevos relacionados con la suspensión (cuando le bajas la pantalla al portátil) , la batería, los ventiladores o la gestión térmica.

Así que, en mi opinión, si reboot=pci funciona, mejor no tocarlo.

Y sí, puedes dejarlo permanentemente. No afecta al rendimiento ni tiene efectos secundarios importantes.

¡Espero que te resulte útil!