Chroot, la salvación elegante ante un Kernel Panic

Este post lo publiqué hace unos días en otro espacio digital, pero debido a que podría ser muy útil para algunos, decido traspasarlo también para GUTL. ¿Nunca te ha pasado que tu sistema GNU/Linux se queda en medio de la nada por un fallo grave en el Kernel? Ojalá no hayas tenido que atravesar tan mal rato para un linuxero. Si bien esta situación es bastante rara o poco común, de vez en cuando, muy de vez en cuando puede ocurrir. A mi me sucedió hace unos días mientras intentaba actualizar mi sistema. Gracias a la disparatada conexión a ¿Internet? que tengo a mi alcance, hubo un error en el paquete «linux» y pacman no lo detectó hasta ya comenzada la instalación y bumm, al reiniciar me llevé el bambonazo: pantallazo negro… Kernel Panic. De como salí de esa mala situación y la ayuda que me dio chroot les estaré hablando en este artículo.

La breve historia de mi último Kernel Panic

Como muchos de los que me leen saben, llevo ya buen tiempo usando Manjaro Linux con Plasma, específicamente Manjaro Testing, para disfrutar un poco más del verdadero sabor del Rolling Release y satisfacer mi versionitis crónica. Por desgracia, he ido adquiriendo una mala costumbre que no recomiendo a nadie: Siempre mantengo un único Kernel instalado, para ahorrar espacio en disco duro. Y bueno, esa mala costumbre me costó un poco caro (aunque al final pude sortear el lío).

Pues resulta que en una accidentada actualización de mi sistema, y gracias a la problemática cuestión de la conectividad en mi isla, pacman intentó instalarme un paquete linux414 con problemas (algo raro, porque pacman siempre verifica la integridad de cada paquete a instalar). En fin, que todo aparentaba estar bien, apagué el ordenador y al reiniciar, bummmm, pantallazo negro y kernel corrupto.

Si hubiera tenido dos kernels instalados en mi sistema (por ejemplo, en ese momento linux4.14.x y linux4.13.x) la solución hubiera sido sencilla. Hubiese podido acceder al sistema cargando el kernel funcional y reinstalando la versión dañada. Por desgracia en ese preciso instante solo tenía instalada la versión 4.14, y al resultar dañada en un intento fallido de actualización la solución pintaba feo y poco más.

Lo primero que viene a la cabeza en ese momento es reinstalar el sistema Linux, pero cuando recuerdas la cantidad de configuraciones globales que has ido sumando en /etc/ o en /usr/share/ o las instalaciones opcionales que tienes en /opt/ entonces te lo piensas dos o más veces antes de volarte el sistema de un zarpazo (por suerte siempre tengo /home/ en una partición aparte de la raiz, pero aún así siempre tengo inventos propios añadidos a las configuraciones globales del sistema) .

Por suerte la solución estaba bien a mano, se resumía a usar un LiveCD (realmente lo que usé fue un liveUSB) de Manjaro y conexión a Internet (esto último era lo más complicado de volver a obtener)

De como el comando chroot me salvó el día

El comando chroot es conocido como CHangeROOT, es decir, un comando que te permite cambiar la raíz del sistema sobre la que estás trabajando. En otra palabras: si estás desde un LiveCD y quieres que todo lo que estés trabajando sobre la consola tenga efecto en el sistema instalado, previamente debes hacer uso de chroot. El detalle a tener en cuenta es que no basta con usar chroot tal cual, antes debemos montar adecuadamente determinadas particiones. Lo que aca escribo lo hice desde Manjaro pero en teoría debería funcionar en cualquier sistema GNU/Linux siempre y cuando la arquitectura del LiveCD coincida con la del sistema a reparar (32 o 64 bits)

Para salvar el mal momento sin necesidad de reinstalar mi sistema Manjaro Linux, lo que hice fue auxiliarme de un pendrive en el que tenía montada la imagen booteable de Manjaro. Inicié el ordenador desde esa unidad USB y cargué el sistema Live. Luego seguí los siguientes pasos antes de hacer uso de chroot:

Lo primero es identificar el disco duro local del ordenador, es decir, el disco duro donde está instalado el sistema problematico, en el caso que describo sería el disco duro donde está instalado el sistema con Kernel corrupto. Identificaremos el disco duro y la numeración de su sistema de particiones. Para esto abriremos una consola y haremos uso de fdisk:

sudo fdisk -l

Supongamos que en nuestro ejemplo fdisk nos aclaró que el disco duro a tener en cuenta es sda y la raiz del sistema está en /dev/sda1.

Para este ejemplo consideraremos que nuestro sistema roto está en /dev/sda1 .

Ahora que ya sabemos donde esta la raiz de nuestro sistema, pararemos a montar las particiones necesarias. Primero crearemos la carpeta donde vamos a trabajar y posteriormente montamos la partición donde se encuentra nuestro sistema roto en dicha carpeta:

sudo mkdir /mnt/sistema_roto
sudo mount /dev/sda1 /mnt/sistema_roto

En el hipotético caso qne que tengas la carpeta /boot, /home o /var o cualquier otra en otra partición y para lo que necesitas hacer tengas que montarla, luego de obtenido la información de fdisk deberás montarla (s) de la siguiente manera:

sudo mount /dev/sda2 /mnt/sistema_roto/var

En este ejemplo he tomado como ejemplo la partición /dev/sda2 para la carpeta /var. Cada quien usara los ajustes según lo que le haya devuelto fdisk y teniendo en cuenta las particiones que realmente necesiten montar

Pasos adicionales

Si lo único que queremos arreglar conlleva exclusivamente la edición de archivos a mano, con lo anterior podría bastar, pero si queremos ejecutar algunos comandos que configuran el sistema o instalar paquetes desde los repositorios, entonces hará falta montar determinadas carpetas especiales del sistema: /dev, /proc y /sys.

sudo mount -t proc proc /mnt/sistema_roto/proc
sudo mount -t sysfs sys /mnt/sistema_roto/sys
sudo mount -o bind /dev /mnt/sistema_roto/dev

¿Qué significa cada parámetro? Te explico:

  • El parámetro -t le aclara a mount el tipo de “filesystem” que queremos montar. Esto hay que especificarlo debido a la naturaleza especial de las carpetas /proc y /sys.
  • Con el parámetro -o especificamos las opciones de mount.
  • La opción bind sirve para “enlazar”. En sistemas like-UNIX todos los dispositivos hardware son accesibles a través de la carpeta /dev, por eso debemos montar nuestro actual /dev en la carpeta donde ahora se encuentra nuestro sistema roto. Al ya estar montada esta carpeta, solo es necesario decirle a mount dónde está originalmente montada.

Listos para usar chroot

Ahora solo resta usar chroot para que, como por arte de magia, te coloques en el interior del sistema operativo roto y puedas manipularlo como si estuvieras realmente logueado en este:

sudo chroot /mnt/sistema_roto/ /bin/bash

Al ejecutar la línea de comandos anterior verás que el prompt de tu terminal cambia un poco (puedes cambiar /bin/bash por el shell que habitualmente uses en el sistema a reparar, por ejemplo /bin/zsh). Listo, ya estás dentro del sistema roto y ya podras hacer los arreglos necesarios en el sistema roto. En mi caso el objetivo era reinstalar el Kernel.

Luego de hacer los cambios que necesitábamos realizar en el sistema roto (en mi caso reinstalar kernel y por si acaso actualizar grub), se supone que puedes reiniciar el ordenador y entrar normalmente por el sistema arreglado. No obstante, en ocasiones he visto fallos, por lo cual recomiendo antes de cerrar la consola en la que hemos hecho el trabajo, salir del chroot y desmontar las particiones montadas antes de abandonar el LiveCD (LiveDVD, LiveUSB o lo que sea que hayas usado). Es decir, recorrer el camino en sentido exactamente inverso:

exit
sudo umount /mnt/sistema_roto/sys
sudo umount /mnt/sistema_roto/proc
sudo umount /mnt/sistema_roto
reboot

Conclusiones

Siempre que tengamos un problemas grave en nuestros sistemas GNU/Linux, no te lances a reinstalar sin antes buscar alguna solución alternativa. Por otro lado, siempre es bueno mantener instalados dos kernels en el sistema GNU/Linux.

Fuente:

http://swlx.260mb.net/chroot-kernel-panic

¿Te resultó interesante? Compártelo ...



Maikel Llamaret Heredia

Publicado por Maikel Llamaret Heredia

https://swlx.info » Facebook » Twitter » Google+ » Linkedin » Forma parte de GUTL desde el 6 diciembre, 2011. Parte de la familia GUTL. Usuario de Tecnologías Libres desde hace varios años. Fiel a GNU/Linux y las filosofías del Software Libre y el Código Abierto. Linux User # 587451. Creador y actual mantenedor del Proyecto SWL-X. Freelancer dedicado al Desarrollo / Diseño Web y Marketing Online. Creador de Web & Media Integrated Solutions

Este artículo tiene 2 comentarios

  1. Muy buen post. Gracias Maykel por esta guia. Creeme de veras que me ha pasado y por la mente lo primero que uno piensa, por desconocimiento al inicio, es reinstalar sin conocimientos de este tipo de herramientas que sacan de apuros. Vuelvo y repito muy buen post.
    S, P

Los comentarios están cerrados.