A mi vuelta del verano, al cambiar la placa con mi hija, observé que tanto su Ubuntu, cómo mi Debian daban al arrancar unos, para mi, crípticos mensajes de «ACPI Error …».

Los errores no parecían tener mayor importancia, ya que el sistema funcionaba correctamente, pero a mí me molesta mucho ver errores en el equipo y no saber de donde vienen, así que que he ido investigando a ratos y cuento lo hecho para mi memoria y por si a alguno le sirve.

Identificar el error.

Lo primero fue registrar el error algo que al ser una serie de mensajes en el arranque del sistema me resultaba difícil, pero GNU/Linux  sé que tiene recursos para todo y gracias a ello pude en encontrar la forma de resolverlo.

Comando dmesg.

Buscando por ahí vi este comando y recurriendo MAN pude leer esto:

NAME
 dmesg - print or control the kernel ring buffer
SYNOPSIS
 dmesg [options]
dmesg --clear
 dmesg --read-clear [options]
 dmesg --console-level level
 dmesg --console-on
 dmesg --console-off
DESCRIPTION
 dmesg is used to examine or control the kernel ring buffer.
The default action is to display all messages from the kernel ring buffer.

Así que dicho y hecho después de ver algunas salidas ininteligibles por su longitud consigo esto:

$ sudo dmesg | grep ACPI | grep -i error
[ 1.737417] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[ 1.737693] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT1._GTF] (Node ffff9fc3960c07a8), AE_NOT_FOUND (20160831/psparse-543)
[ 1.738094] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[ 1.738418] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff9fc3960c06e0), AE_NOT_FOUND (20160831/psparse-543)
[ 1.738814] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[ 1.739081] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT0._GTF] (Node ffff9fc3960c0898), AE_NOT_FOUND (20160831/psparse-543)
[ 1.740221] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[ 1.740504] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT1._GTF] (Node ffff9fc3960c07a8), AE_NOT_FOUND (20160831/psparse-543)
[ 1.740917] ACPI Error: [DSSP]
[ 1.741098] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT2._GTF] (Node ffff9fc3960c06e0), AE_NOT_FOUND (20160831/psparse-543)
[ 1.741734] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359)
[ 1.742032] ACPI Error: Method parse/execution failed [\_SB.PCI0.SAT0.SPT0._GTF] (Node ffff9fc3960c0898), AE_NOT_FOUND (20160831/psparse-543)

Ya lo tengo localizado.

Que significa ACPI.

Cómo estoy un poco oxidado lo siguiente fue recordar que es eso de la ACPI, paso muy sencillo en la Web:

ACPI es el acrónimo inglés de «Advanced Configuration and Power Interface» (Interfaz Avanzada de Configuración y Energía). Es un estándar resultado de la actualización de APM a nivel de hardware, que controla el funcionamiento del BIOS y proporciona mecanismos avanzados para la gestión y ahorro de la energía.

En que consiste el error.

Es imposible que os cuente todo lo que he tenido que leer, en especial en la listas de Debian y la wiki de Arch, para entenderlo, pero al final el resumen al que he llegado es este, y, por favor, si hay alguna confusión en ello os ruego lo indiquéis en los comentarios.

Cómo se indica en el punto anterior ACPI es un estandar, al cual se ajusta de manera estricta el kernel Linux en especial desde su versión 4.9.

Los fabricantes de placas y procesadores – en mi caso Intel y Asus – sólo se preocupan de comprobar el buen funcionamiento de este estándar con Winkk, por lo que desde la citada versión de Linux el error es común, desconozco si también con otras placas o procesadores AMD, ya que el kernel no es capaz de interpretar adecuadamente lo recibido de la BIOS.

Buscar la solución.

Llegados a este punto se me presentaban dos alternativas:

1. Pasar del problema
2. Intentar arreglarlo

Lo siento, soy cabezota 😉 y la primera aunque no la di por urgente me parecía la obvia, no soy de los que si algo esta mal lo dejan por que no pasa nada, creo que lo correcto es que si algo esta mal se corrija.

Parámetros del Kernel.

Rebuscando por ahí llegue a encontrar está pagina que hace referencia a los parámetros del kernel de Linux pero esto era algo que me superaba.

acpi=off.

Gracias a una pista del grupo de Telegram de Debian  parecía que este parámetro podría resolver el problema pero las pruebas realizadas, daban cómo resultado que, aunque efectivamente resolvía los errore, la suspensión y el apagado del equipo dejan de funcionar correctamente.

libata.noacpi=1.

Por último, consultada la lista de Debian, Rafael Ruiz Gozález, al que agradezco infinito su aportación me sugirió este otro parámetro, que es el que finalmente ha resuelto el problema.

La solución.

Lo primero que ha tocado averiguar es como poner esos parámetros en la carga del kernel, lo que para las prueba hacía siguiendo estos pasos:

• Pulsar «e» en el arranque del grub
• Incluir en la línea «linux /boot/vmlinuz-4.9.0-3-amd64 … quiet» el parámetro indicado

Lo último ha sido incluirlo de forma definitiva, para lo que tenía que tocar la citada línea en el archivo /etc/grub/grub.cfg que por desgracia incluye en su inicio este bonito texto 🙁 :

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

La solución al final ha sido:

sudo nano /etc/default/grub

En el fichero editado añadir el texto en azul:

GRUB_CMDLINE_LINUX_DEFAULT="quiet libata.noacpi=1"

He quitado el quiet para ver mejor los mensajes de arranque, ahora aparecen todos preciosos con Ok. en verde ;).

Por último para generar el citado /boot/grub/grub.cfg

sudo update-grub

Eso es todo y espero no haberos aburrido ni haber dicho ninguna barbaridad.

!Nos vemos pronto¡ 😉