# 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. ![Kernel panic](https://multimedia.castris.com/imagenes/wiki/kernel-panic-2024-ok.jpeg) Lo primero que se observa en [Google](https://www.google.com/search?q=zz-resume-auto+what+is) o [DuckDuckGo](https://duckduckgo.com/?q=zz-resume-auto&ia=web) 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 ```bash 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 ```bash 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 ```bash 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: ``` ¿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. ```bash 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. ```bash 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. ```bash 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. ```bash 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` ```bash 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](https://castris.com) Si necesitas soporte profesional puedes contratar con Castris [soporte profesional](https://intranet.castris.com/store/soporte-profesional).