Kernel panic: /init: conf/conf.d/zz-resume-auto: line 1: syntax error: unexpected "("

Introducción

Nada peor que un kernel panic en un sistema linux y más si este esta en producción.

Que malo es tener servidores baremetal en lugar de virtualizar con KVM. Sonbre todo para el corazón.

Me llamo un cliente, para apagar el fuego. Centralita de rendimiento espectacular (Dos a tres mil euros la hora de facturación por lineas). Como parta estar offline. E infraestructura sin HA o cuando menos espejos de backup.

Ya me han pedido presupuesto.

Lo primero que se observa en Google o DuckDuckGo es que es un problema recurrente con distintos sabores o variantes.

Pero lo que nos queda claro es que no se trata de encontrar ese fichero sino de otra cosa.

Estamos en OVH así que vamos a abrir un IPMI para tratar de entrar en modo rescate.

Al rescate

Consola remota IPMI de OVH

Bueno la ilusión se nos fue, cuando vimos que el administrador del equipo, tenia configurado de tal forma no visualizar el screen de arranque, sino entrar directamente al trapo con la carga del kernel (Muy mal compañero).

Tampoco el IPMI nos permitía una comunicación correcta del teclado, para forzar la pantalla de inicio, asi que opte por un arranque en modo rescue de OVH basado en una Debian 11.

Modo rescue

Lo primero es ver que tenemos con un fdisk

root@rescue-customer-eu ~# fdisk -l
/dev/nvme0n1p1       2048    1048575   1046528  511M EFI System
/dev/nvme0n1p2    1048576  999161855 998113280  476G Linux RAID
/dev/nvme0n1p3  999161856 1000210431   1048576  512M Linux filesystem
/dev/nvme0n1p4 1000211120 1000215182      4063    2M Linux filesystem

Que bonito, un RAID por software en un sistema en producción de ese nivel.

Vemos que nos cuenta

root@rescue-customer-eu ~ # mdadm --examine --scan
ARRAY /dev/md/md2  metadata=1.2 UUID=f3f612c5:98f99127:fd587ee0:8dc97d19 name=md2
root@rescue-customer-eu  ~ # mount /dev/md/md2 /mnt
mount: /mnt: special device /dev/md/md2 does not exist.

Limpieza con update-initramfs

Bien, vamos a montarlo en modo chroot para poder limpiar el problema

root@rescue-customer-eu ~ # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md127 : active (auto-read-only) raid1 nvme0n1p2[1]
      498924544 blocks super 1.2 [2/1] [_U]
      bitmap: 4/4 pages [16KB], 65536KB chunk

unused devices: <none>

¿Porqué?

Basado en la salida de cat /proc/mdstat, parece que el dispositivo RAID que se ha ensamblado automáticamente al intentar arrancar el sistema en modo rescate es /dev/md127 y no /dev/md/md2 como se esperaba inicialmente. Esto puede suceder a veces, donde el número de dispositivo RAID puede cambiar dependiendo de cómo y cuándo se ensambla el RAID durante el arranque del sistema.

La salida muestra que el dispositivo /dev/md127 es un RAID 1 (espejo) y actualmente está en modo "auto-read-only" con uno de los dos discos funcionando (indicado por [2/1] [_U], donde _U significa que un disco está faltante o no está funcionando).

Problemas a la vista con el raid. Continuar con algunas propuestas no tiene sentido, cuando el raid esta mal, pues se trata de trabajar con el grub y sin el raid consistente, ni lo intentes.

update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-28-amd64
Found initrd image: /boot/initrd.img-5.10.0-28-amd64
/usr/sbin/grub-probe: error: disk `mduuid/f3f612c598f99127fd587ee08dc97d19' not found.
/usr/sbin/grub-probe: error: disk `mduuid/f3f612c598f99127fd587ee08dc97d19' not found.
/usr/sbin/grub-probe: error: disk `mduuid/f3f612c598f99127fd587ee08dc97d19' not found.
Found linux image: /boot/vmlinuz-5.10.0-27-amd64
Found initrd image: /boot/initrd.img-5.10.0-27-amd64
/usr/sbin/grub-probe: error: disk `mduuid/f3f612c598f99127fd587ee08dc97d19' not found.
/usr/sbin/grub-probe: error: disk `mduuid/f3f612c598f99127fd587ee08dc97d19' not found.
Found linux image: /boot/vmlinuz-5.10.0-19-amd64
Found initrd image: /boot/initrd.img-5.10.0-19-amd64
/usr/sbin/grub-probe: error: disk `mduuid/f3f612c598f99127fd587ee08dc97d19' not found.
/usr/sbin/grub-probe: error: disk `mduuid/f3f612c598f99127fd587ee08dc97d19' not found.
done

En este punto decir que algunos de los tips de google, sobre este tema, podrán ser validos en determinadas circunstancias pero aquí, con un raid por software la cosa estaba más clara.

Vamos a ensamblar manualmente el array.

ATENCION ⚠️ Lo que se hace, se hace en una máquina con backups, y consciente de lo que haces y de que puede pasar de todo. No soy responsable delos copy & paste sin tener ni idea de sistemas.

mdadm --assemble /dev/md/md2 --uuid f3f612c5:98f99127:fd587ee0:8dc97d19

Después vamos a ver el estado. Es necesario porque lo que haremos después no funcionaria, por los errores que ya tuvimos.

root@rescue-customer-eu:/# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md127 : active raid1 nvme1n1p2[0] nvme0n1p2[1]
      498924544 blocks super 1.2 [2/1] [_U]
      [===>.................]  recovery = 19.6% (98150912/498924544) finish=32.4min speed=205769K/sec
      bitmap: 4/4 pages [16KB], 65536KB chunk

Bien esperaremos hasta que acabe

Si tienes un gran tamaño de discos, tardará. Si tienes discos mecanicos, y raid soft, mejor date una vuelta.

Montemos en chroot cuando termine.

mount /dev/md127 /mnt
mount -t proc /proc /mnt/proc
mount -t sysfs /sys /mnt/sys
mount --rbind /dev /mnt/dev
mount --make-rslave /mnt/dev
chroot /mnt /bin/bash

Ahora ya puedes hacer un update-grub o editar el fichero por ejemplo para tener la venta splash del arranque para poder elegir un kernel o el modo rescue, etc.

En mi caso sirvió el update-grub

update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.10.0-28-amd64
Found initrd image: /boot/initrd.img-5.10.0-28-amd64
Found linux image: /boot/vmlinuz-5.10.0-27-amd64
Found initrd image: /boot/initrd.img-5.10.0-27-amd64
Found linux image: /boot/vmlinuz-5.10.0-19-amd64
Found initrd image: /boot/initrd.img-5.10.0-19-amd64
done

Si estas en un entorno UEFI de arranque, tendrás que asegurarte. de que estas apuntando correctamente

Desmontado

exit
umount /mnt/sys
umount /mnt/proc
umount /mnt/dev
umount /mnt/boot

Y finalmente desactivar el kernel rescue de OVH y hacer un shutdown.

In Sha Allah... y a disfrutar de tu máquina.

Aviso

Esta documentación y su contenido, no implica que funcione en tu caso o determinados casos. También implica que tienes conocimientos sobre lo que trata, y que en cualquier caso tienes copias de seguridad. El contenido el contenido se entrega, tal y como está, sin que ello implique ningún obligación ni responsabilidad por parte de Castris

Si necesitas soporte profesional puedes contratar con Castris soporte profesional.