Dicen que hay dos tipos de usuarios de Linux: los que ya han destruido su tabla de particiones por error y los que están a punto de hacerlo. En su momento, mientras preparaba una imagen para una Raspberry Pi, me convertí oficialmente en el primer tipo. El error ocurrió estando en Fedora 42, logré recuperar el sistema, escalé a Fedora 43 y hoy en día el equipo sigue firme corriendo la versión actual (Fedora 44).
El Error: Un comando, un desastre
Todo empezó con un descuido al usar arm-image-installer. En lugar de apuntar a la tarjeta SD, el destino fue mi unidad principal: /dev/nvme0n1. En segundos, el instalador comenzó a escribir la imagen, destruyendo mi configuración de arranque y dejando el sistema en un estado crítico.
El Diagnóstico: GPT dañado y particiones fantasmas
Al intentar reparar el sistema con un Live-USB, me encontré con un panorama desolador. Herramientas como gdisk reportaban que la tabla de particiones GPT estaba dañada, aunque por suerte conservaba un respaldo válido.
Lo más confuso fue descubrir que ahora tenía dos particiones de boot:
- p2: Una partición nueva creada por el instalador (en formato XFS).
- p5: Mi partición /boot original (en formato Ext4).
Además, mi /boot/efi estaba corrupto o desaparecido, y al usar Btrfs, si no montas los subvolúmenes correctamente (root y home), parece que no hay nada en el disco.
El Rescate: Paso a Paso técnico
Paso 1: Sanar la tabla de particiones
Usé gdisk para recuperar la estructura GPT a partir del backup interno del disco. Esto permitió que el kernel volviera a ver las particiones correctamente.
Paso 2: Preparar el entorno de reparación (chroot)
Desde el Live-USB, monté el sistema real:
# Montar el subvolumen root de Btrfs
mount -o subvol=root /dev/nvme0n1p6 /mnt
# Montar la partición /boot original y la EFI mount /dev/nvme0n1p5 /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot/efi
# Bind mounts para el entorno chroot
for dir in /dev /proc /sys /run; do
mount --bind $dir /mnt$dir
done
Paso 3: Sincronizar el fstab
Revisé los UUIDs con blkid y me aseguré de que el archivo /etc/fstab apuntara a las particiones correctas. El sistema fallaba si el UUID de la partición de arranque no coincidía exactamente con lo que esperaba GRUB.
Paso 4: Reinstalar el cargador de arranque y el Kernel
Una vez dentro del entorno chroot, procedí a reinstalar los paquetes esenciales:
dnf reinstall grub2-efi grub2-efi-modules shim-* kernel*
Paso 5: Regenerar GRUB y SELinux
Finalmente, generé el archivo de configuración de GRUB y programé un reetiquetado de SELinux para el siguiente inicio:
grub2-mkconfig -o /boot/grub2/grub.cfg fixfiles -B onboot
Comunidad: El ingrediente secreto
Este rescate no fue una hazaña solitaria. Pude resolverlo gracias a la guía constante de la Comunidad de Fedora México. Es, sin duda, una de las mejores comunidades: siempre hay alguien dispuesto a ayudar, sin importar cuán "novato" o "grave" sea tu error. No hay discriminación ni burlas, solo el deseo genuino de que otro usuario recupere su sistema.
En Fedora, nunca caminas solo.
Recursos Adicionales y Descargables
Para compensar la demora en publicar este artículo y ofrecer un recurso práctico a la comunidad, preparé una hoja de referencia rápida en PDF con todos los comandos de rescate y montaje de subvolúmenes Btrfs.
Puedes descargar el archivo directamente desde mi repositorio de archivos:
👉 Descargar Btrfs Rescue & Mount Cheat Sheet (PDF)
Documentación de Referencia para Investigación y Reparación
Espero te sirva.
