Desastre al redimensionar particiones: deshazlo y arranca de nuevo

Reglas de actuación (para que no lo empeores)

La recuperación de particiones no va de heroísmos. Va de controlar las escrituras. La mayoría de los “desastres por redimensionado” se vuelven irrecuperables porque alguien sigue “probando cosas” que modifican la metadata en el dispositivo equivocado.

Haz esto primero

• Deja de escribir. Si es una VM, toma un snapshot a nivel de hipervisor ahora. Si es físico, clona el disco o realiza una imagen si puedes.
• Trabaja desde un entorno Live. No arranques el SO roto y “esperes que se cure”. Arranca un ISO de rescate para poder montar lecturas en modo solo-lectura y pensar con claridad.
• Identifica el disco objetivo exacto. “/dev/sda” no es una característica de personalidad. Usa seriales, WWN e identificadores estables.
• Asume interacciones entre capas. Tablas de particiones, LVM, mdraid, LUKS, sistemas de archivos, bootloaders, fstab/initramfs: los redimensionados pueden afectar cualquiera de ellos.

Un chiste corto, para limpiar el paladar: Las particiones son como los tatuajes: fáciles de hacer, difíciles de quitar y nunca lucen mejor después de una sesión improvisada.

Guion de diagnóstico rápido

Esta es la secuencia para “orientarte en menos de 10 minutos”. El orden importa porque reduce rápidamente los dominios de fallo.

Primero: ¿vemos siquiera el disco y las particiones?

• Desde el entorno de rescate: enumera los dispositivos de bloque y las tablas de particiones.
• Decisión: si la tabla de particiones no es legible, primero repara GPT/MBR antes de cualquier otra cosa.

Segundo: ¿podemos encontrar el sistema de archivos raíz y se monta en solo-lectura?

• Intenta montar en solo-lectura las particiones que probablemente sean la raíz.
• Decisión: si el montaje falla, pivota a reparación del sistema de archivos y revisa si los inicios/tamaños se desplazaron.

Tercero: si la raíz se monta, ¿por qué no arranca?

• Revisa /etc/fstab, UUIDs, el ensamblado de LVM/mdraid y la configuración del bootloader.
• Decisión: si los UUIDs cambiaron, corrige las referencias y recompila initramfs/GRUB, no el sistema de archivos.

Cuarto: ¿mismatch UEFI vs BIOS?

• Verifica si el sistema arranca en modo UEFI y si la EFI System Partition existe y está montada.
• Decisión: si la ESP falta/corrompe/no está montada, arréglala y reinstala GRUB en EFI.

Quinto: confirma que el “redimensionado” no fue en realidad un movimiento

• Compara los sectores de inicio de las particiones con los que tenían antes (si tienes datos históricos, copias o notas en CMDB).
• Decisión: si el sector de inicio se movió inesperadamente, trátalo como recuperación de datos: minimiza escrituras y restaura la geometría correcta.

Datos interesantes y un poco de historia

• El límite de 2 TiB de MBR no es un “problema de Linux”. MBR clásico usa conteos de sectores de 32 bits, lo que limita el espacio direccionable en sectores de 512 bytes.
• GPT mantiene dos copias de su cabecera y tabla de particiones: una primaria al inicio y una de respaldo al final del disco. Esto te salva cuando “el comienzo se puso raro”.
• UEFI hizo de la EFI System Partition (ESP) una ciudadana de primera clase. Muchos fallos de arranque tras redimensionados son en realidad fallos de “ESP sin montar”.
• GRUB2 se volvió más modular que el GRUB heredado. Esa flexibilidad es también la razón de que exista “grub rescue>”: no encuentra sus módulos o configuración, así que entra en pánico educado.
• ext4 puede crecer en línea en muchos casos, pero reducir sigue siendo una danza cuidadosa offline. La gente recuerda “grow es seguro” y olvida que “shrink es una pelea con cuchillos”.
• XFS no puede encogerse (por diseño). Si “encogiste la partición” bajo XFS, no encogiste XFS; simplemente cortaste el suelo debajo de él.
• LVM se creó para el cambio (PV/VG/LV resizing), pero no te exime de la corrección en la tabla de particiones. Solo añade otra capa que debe estar correcta.
• Linux empezó a abrazar montajes por UUID para evitar la volatilidad de nombres de dispositivo. Eso es estupendo—hasta que un redimensionado/regeneración cambia identificadores y tu fstab se vuelve ficción histórica.

Una cita, porque la ingeniería de fiabilidad aprende la misma lección desde hace décadas. El famoso encuadre de John Allspaw se parafrasea a menudo como: “Los incidentes vienen del trabajo normal en sistemas complejos; culpar no repara el sistema.” (idea parafraseada)

Qué se rompe realmente durante un redimensionado

“Redimensionar” suena singular. En la práctica es una canalización de múltiples pasos que toca dominios de metadata independientes. Un fallo en cualquier paso puede dejar inservible el arranque.

1) Cambios en la geometría de la tabla de particiones

Si el inicio de la partición se mueve, todo lo que esté encima se desplaza. Los sistemas de archivos y LVM almacenan sus propias expectativas sobre dónde residen. Mueve el inicio y estás apuntando al sistema operativo a un offset incorrecto en el disco. A veces los datos siguen ahí; solo estás mirando en la dirección equivocada.

2) La metadata del sistema de archivos ya no coincide con el dispositivo

En ext4, puedes acabar con un sistema de archivos que cree tener N bloques, pero la partición ahora ofrece N-Δ. Los montajes fallan, fsck se queja o, peor: los montajes tienen éxito y las escrituras caen en el vacío más allá del nuevo fin.

En XFS, “encogerle por debajo” equivale a riesgo de corrupción. XFS espera que el dispositivo de bloques no se reduzca. Cuando lo hace, obtienes errores I/O y fallas al reproducir el log.

3) Rutas e IDs del bootloader se desplazan

GRUB a menudo referencia UUIDs de sistemas de archivos o busca particiones específicas. Las entradas de arranque UEFI apuntan a un binario EFI en la ESP. Si la ESP se movió, fue reformatada o no se monta durante las actualizaciones, tu sistema puede arrancar hacia un vacío.

4) initramfs no puede ensamblar tu pila de almacenamiento

Si la raíz vive en LVM, mdraid o LUKS, el entorno de arranque temprano debe ensamblarlo. El redimensionado puede cambiar el orden de descubrimiento de dispositivos, confundir mdadm o invalidar las expectativas de crypttab. El kernel arranca y luego te deja en initramfs porque no encuentra /dev/mapper/root.

Runbook: 14 tareas concretas con comandos, salidas y decisiones

Estas tareas asumen un entorno de rescate Linux. Los comandos están escritos como si estuvieras en la consola con privilegios root disponibles (vía sudo o root directo). Sustituye los nombres de dispositivo con cuidado.

Tarea 1: Listar discos y particiones (confía, pero verifica)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,FSUUID,MOUNTPOINTS,MODEL,SERIAL
NAME        SIZE TYPE FSTYPE FSVER FSUUID                                 MOUNTPOINTS MODEL          SERIAL
sda        477G  disk                                                Samsung_SSD     S4X...
├─sda1     512M  part vfat   FAT32 1A2B-3C4D                              /boot/efi
├─sda2       1G  part ext4   1.0   2c1d...                                /boot
└─sda3   475.5G  part LVM2_member      hP0x...                             
  ├─vg0-root 80G lvm  ext4   1.0   9f7a...                                /
  └─vg0-var  50G lvm  xfs          4e2b...                                /var

Qué significa: Puedes ver el disco, las particiones, sus sistemas de archivos y si LVM está involucrado.

Decisión: Si las particiones esperadas faltan o los tamaños parecen incorrectos, céntrate en la integridad de la tabla de particiones antes de las reparaciones del sistema de archivos.

Tarea 2: Confirma el tipo de tabla y la geometría

cr0x@server:~$ sudo parted -s /dev/sda print
Model: Samsung SSD (scsi)
Disk /dev/sda: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  538MB   537MB   fat32              boot, esp
 2      538MB   1612MB  1074MB  ext4
 3      1612MB  512GB   510GB

Qué significa: Los límites de inicio/fin están en unidades humanas; la tabla es GPT.

Decisión: Si esperabas MBR pero ves GPT (o viceversa), confirma el modo de firmware y cómo se instaló GRUB. Las discordancias causan arranques fantasma.

Tarea 3: Obtén los sectores de inicio exactos (los únicos números que importan)

cr0x@server:~$ sudo sfdisk -d /dev/sda
label: gpt
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1000215214

/dev/sda1 : start=        2048, size=     1048576, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
/dev/sda2 : start=     1050624, size=     2097152, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
/dev/sda3 : start=     3147776, size=  996?..., type=E6D6D379-F507-44C2-A23C-238F2A3DF928

Qué significa: Estos son los offsets verdaderos. Si un redimensionado movió accidentalmente un sector de inicio, esta salida es tu evidencia.

Decisión: Si los sectores de inicio cambiaron respecto a valores buenos conocidos (de notas, backups o estado de la automatización), detente y planifica una corrección de geometría. No ejecutes fsck todavía; podrías estar comprobando el offset equivocado.

Tarea 4: Verifica la consistencia de GPT y recupera la cabecera de respaldo si es necesario

cr0x@server:~$ sudo sgdisk -v /dev/sda
Verifying disk /dev/sda
Problem: The secondary GPT header is not at the end of the disk.
Problem: The secondary partition table is not at the end of the disk.
No problems found. 0 free sectors (0 bytes) available in 0 segments.

Qué significa: Común tras cambios de tamaño de disco u operaciones mal hechas: la GPT de respaldo no está donde debería.

Decisión: Si sgdisk -v informa problemas de ubicación de cabecera/tabla, planifica relocarla con sgdisk -e (con cuidado). Si informa errores CRC, prioriza restaurar GPT desde la cabecera de respaldo.

Tarea 5: Reloca la GPT de respaldo al final del disco (solución relativamente segura para ciertas advertencias)

cr0x@server:~$ sudo sgdisk -e /dev/sda
Relocating backup data structures to the end of the disk
The operation has completed successfully.

Qué significa: Las estructuras de respaldo de GPT se mueven a la ubicación correcta al final del disco.

Decisión: Haz esto solo cuando estés seguro de que el tamaño del disco es correcto y no intentas preservar un “final” anterior para recuperación de datos. En caso de duda: imagina el disco primero.

Tarea 6: Sondea firmas de sistemas de archivos (¿estamos viendo lo correcto?)

cr0x@server:~$ sudo blkid /dev/sda1 /dev/sda2 /dev/sda3
/dev/sda1: UUID="1A2B-3C4D" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="..."
/dev/sda2: UUID="2c1d..." BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="..."
/dev/sda3: TYPE="LVM2_member" PARTUUID="..."

Qué significa: blkid lee los superbloques en disco. Si no puede identificar algo que esperas, podrías tener offsets erróneos o corrupción.

Decisión: Si la raíz debería ser ext4 pero blkid dice “unknown”, no formatees. Estás aquí para recuperar, no para crear nuevos desastres.

Tarea 7: Ensambla mdraid si está presente (común en servidores)

cr0x@server:~$ sudo mdadm --examine --scan
ARRAY /dev/md0 metadata=1.2 name=server:0 UUID=8b3c...

Qué significa: Los arreglos son detectables. Si esto no retorna nada, la metadata md puede faltar o los dispositivos haberse renombrado.

Decisión: Si existen arreglos, ensámblalos antes de trabajar en LVM/sistemas de archivos.

cr0x@server:~$ sudo mdadm --assemble --scan
mdadm: /dev/md0 has been started with 2 drives.

Decisión: Si el ensamblado falla con “device busy” o “wrong uuid”, detente e inspecciona miembros individualmente; no fuerces ensamblado a menos que estés seguro de cuáles son los miembros actuales.

Tarea 8: Activa LVM (si tu raíz está en LVs)

cr0x@server:~$ sudo pvscan
  PV /dev/sda3   VG vg0   lvm2 [475.50 GiB / 0    free]
  Total: 1 [475.50 GiB] / in use: 1 [475.50 GiB] / in no VG: 0 [0   ]

cr0x@server:~$ sudo vgscan
  Found volume group "vg0" using metadata type lvm2

cr0x@server:~$ sudo vgchange -ay
  2 logical volume(s) in volume group "vg0" now active

Qué significa: La metadata de LVM es legible y los LVs están activados.

Decisión: Si pvscan no ve el PV, la partición puede haberse movido o la etiqueta PV haber sido sobrescrita. Trátalo como un problema de offset/geometría primero, no como “LVM roto”.

Tarea 9: Intenta montar la raíz en solo-lectura (no seas valiente todavía)

cr0x@server:~$ sudo mount -o ro /dev/vg0/root /mnt
cr0x@server:~$ ls /mnt
bin  boot  dev  etc  home  lib  lib64  opt  root  sbin  usr  var

Qué significa: El sistema de archivos es montable y probablemente está intacto.

Decisión: Si se monta en solo-lectura, a menudo puedes reparar el arranque sin ejecutar fsck. Si no se monta, captura el mensaje de error y pivota a comprobaciones del sistema de archivos.

Tarea 10: Valida fstab frente a los UUID reales (fallo clásico post-redimensionado)

cr0x@server:~$ sudo cat /mnt/etc/fstab
UUID=9f7a...  /      ext4  defaults  0 1
UUID=2c1d...  /boot  ext4  defaults  0 2
UUID=1A2B-3C4D /boot/efi vfat umask=0077 0 1

Qué significa: fstab usa UUIDs. Bien. Ahora asegúrate de que coincidan con lo que reporta blkid.

Decisión: Si fstab referencia UUIDs que ya no existen, corrige fstab (y recompila initramfs si es necesario). No hagas un “fsck más fuerte”.

Tarea 11: Revisa qué espera initramfs (dispositivo raíz, crypt, md, lvm)

cr0x@server:~$ sudo grep -R "UUID=" -n /mnt/etc/default/grub /mnt/etc/crypttab /mnt/etc/fstab 2>/dev/null
/mnt/etc/fstab:1:UUID=9f7a...  /      ext4  defaults  0 1
/mnt/etc/fstab:2:UUID=2c1d...  /boot  ext4  defaults  0 2

Qué significa: Estás buscando en la superficie de configuración que comúnmente se rompe tras redimensionados.

Decisión: Si crypttab referencia un UUID antiguo para el contenedor LUKS, initramfs no desbloqueará la raíz. Actualízalo y recompila initramfs.

Tarea 12: Chroot correctamente (para que tus reparaciones afecten al sistema instalado)

cr0x@server:~$ sudo mount --bind /dev  /mnt/dev
cr0x@server:~$ sudo mount --bind /proc /mnt/proc
cr0x@server:~$ sudo mount --bind /sys  /mnt/sys
cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# mount | head
/dev/mapper/vg0-root on / type ext4 (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

Qué significa: Ahora operas dentro del contexto del SO instalado.

Decisión: Si la raíz está montada en solo-lectura en chroot y necesitas editar archivos, remóntala en lectura-escritura solo después de confiar en la integridad del sistema de archivos.

Tarea 13: Rebuild initramfs (porque cachea la realidad del almacenamiento)

cr0x@server:~$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-31-generic

Qué significa: La imagen de arranque temprano se regenera con los UUIDs/módulos actuales.

Decisión: Si cambiaste crypttab, la configuración de mdadm o LVM, recompila initramfs. Omitir esto es la razón por la que vuelves al prompt de initramfs preguntándote por qué el universo te odia.

Tarea 14: Reinstala GRUB y regenera la configuración (caminos BIOS y UEFI)

cr0x@server:~$ grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.

cr0x@server:~$ update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
Found initrd image: /boot/initrd.img-6.8.0-31-generic
done

Qué significa: Para sistemas BIOS, GRUB se instala en el MBR/área de embedding del disco. Luego se regenera la configuración.

Decisión: Si en realidad arrancas por UEFI, grub-install /dev/sda no es la solución correcta. Debes instalar en la ESP y asegurarte de que esté montada en /boot/efi. Verifica el modo de arranque antes de actuar.

Estrategias de “deshacer” que funcionan en la vida real

No puedes “deshacer” realmente un redimensionado de partición como deshaces un commit de git. Sin embargo, puedes restaurar la geometría y las referencias de metadata a lo que el sistema espera. Eso suele ser suficiente para arrancar.

Estrategia A: Restaurar el sector de inicio correcto de la partición (el grande)

Si se movió el inicio de la partición, tu sistema de archivos/LVM probablemente esté intacto pero desplazado. La solución es devolver exactamente el sector de inicio. “Aproximadamente” no existe aquí. Un desfase de un sector sigue siendo incorrecto, solo que más confiado.

Cómo hacerlo depende de qué herramienta lo cambió. En la práctica, usas parted o sfdisk para recrear la entrada de partición con el inicio original y un tamaño que al menos cubra el antiguo fin del sistema de archivos. No formatees. No crees un sistema de archivos nuevo. Solo corriges la entrada de la tabla.

Si no conoces el sector de inicio antiguo, revisa:

• Tickets o solicitudes de cambio antiguas (a veces alguien pegó la salida de sfdisk -d).
• Inventarios de monitorización o snapshots de la CMDB.
• Backups de /etc que puedan incluir logs de instalador o scripts de particionado.
• Cabecera de respaldo de GPT (si la primaria fue destruida) y herramientas de recuperación.

Estrategia B: Arreglar la deriva de UUIDs (fstab/crypttab/grub)

A veces nada se movió. Simplemente cambiaste algo que provocó que los identificadores cambiasen, o clonaste un disco y ahora el sistema tiene UUIDs duplicados y elige el equivocado. La solución es aburrida: hacer consistentes los identificadores y corregir las referencias.

Movimientos comunes:

• Actualizar /etc/fstab para que coincida con blkid.
• Para raíces cifradas: actualizar /etc/crypttab y luego recompilar initramfs.
• Para mdraid: asegurar que /etc/mdadm/mdadm.conf sea correcto y luego recompilar initramfs.
• Regenerar la configuración de GRUB para que detecte la raíz correcta.

Estrategia C: Reparar metadata de GPT (cuando la tabla es “válida pero inconsistente”)

La cabecera de respaldo de GPT salva a muchas personas. Si sgdisk -v informa mismatches CRC o corrupción de cabecera, a menudo puedes restaurar desde la cabecera de respaldo o relocarla al nuevo final de disco tras redimensionar un disco virtual.

Esto funciona bien cuando las particiones de datos están intactas y solo la contabilidad de GPT está mal.

Estrategia D: Reparación de sistema de archivos (solo después de que la geometría sea correcta)

Si redimensionaste un sistema de archivos y se perdió energía a mitad de operación, o si fijaste mal el límite de partición, puede que necesites fsck (ext4) o xfs_repair (XFS). Hazlo después de confirmar que apuntas al offset correcto en disco y que el dispositivo de bloques tiene el tamaño esperado.

Segundo chiste corto, porque te lo mereces: Nada acelera un “resize rápido” como un manager preguntando por un ETA.

Reparación del cargador de arranque: BIOS/MBR, UEFI y las trampas habituales

Los fallos de arranque tras cambios de particionado suelen ser fallos del bootloader disfrazados de fallos de almacenamiento. El truco es separar “el kernel no encuentra la raíz” de “el firmware no encuentra el bootloader”.

Conoce tu modo de arranque

Desde un entorno de rescate, comprueba si arrancaste el ISO en modo UEFI. Si el entorno live arrancó en modo BIOS pero tu SO instalado espera UEFI, aún puedes montar y arreglar cosas—pero sé deliberado sobre dónde instalas GRUB.

cr0x@server:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
UEFI

Qué significa: Si esto imprime UEFI, el entorno en ejecución soporta variables EFI y puedes gestionar entradas NVRAM.

Decisión: Si necesitas reparar un arranque UEFI, arranca el ISO de rescate en modo UEFI. De lo contrario reinstalarás GRUB “con éxito” en un lugar que el firmware nunca usa.

Verifica la EFI System Partition (ESP)

La ESP debería ser FAT32, típicamente 100–512MB (a veces mayor), con la bandera esp. Si falta, se movió o no está montada en /boot/efi durante las actualizaciones de GRUB, tu entrada de arranque UEFI puede apuntar a un archivo que ya no existe.

cr0x@server:~$ sudo lsblk -f | grep -E "vfat|/boot/efi"
sda1 vfat   FAT32 1A2B-3C4D                             /mnt/boot/efi

Decisión: Si la ESP no está montada, móntala y vuelve a ejecutar la instalación/configuración de GRUB dentro del chroot.

Patrón de reinstalación de GRUB en UEFI (dentro del chroot)

cr0x@server:~$ sudo chroot /mnt /bin/bash
root@server:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
Installing for x86_64-efi platform.
Installation finished. No error reported.

root@server:/# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-31-generic
done

Qué significa: El binario EFI se escribe en la ESP y se regenera la configuración de GRUB.

Decisión: Si el firmware aún no arranca, inspecciona las entradas NVRAM y considera la ruta de respaldo \EFI\BOOT\BOOTX64.EFI según las políticas de la plataforma.

Patrón de reinstalación de GRUB en BIOS (dentro del chroot)

Para instalaciones BIOS, GRUB necesita espacio de embedding (a menudo en el gap post-MBR) o una partición BIOS boot en discos GPT. Las operaciones de redimensionado pueden eliminar accidentalmente ese gap o relabelar la partición BIOS boot.

cr0x@server:~$ sudo parted -s /dev/sda print | grep -i "bios"
Partition Table: gpt

Decisión: Si esto es GPT+BIOS, asegúrate de tener una pequeña partición BIOS boot (usualmente 1–2MB) con la bandera bios_grub. Sin ella, la instalación de GRUB puede fallar o “tener éxito” pero no arrancar.

Reparación y verificación de sistemas de archivos (ext4, XFS)

ext4: comprobar, luego reparar

ext4 es tolerante, pero no confundas “tolerante” con “invencible”. Si el fin de partición se definió más pequeño que el sistema de archivos, ext4 puede montarse en solo-lectura, negarse a montar o mostrar errores de replay del journal.

cr0x@server:~$ sudo e2fsck -f -n /dev/vg0/root
e2fsck 1.47.0 (5-Feb-2023)
/dev/vg0/root: clean, 412345/5242880 files, 8123456/20971520 blocks

Qué significa: -n es una ejecución en seco. “clean” es lo que quieres ver.

Decisión: Si la ejecución en seco muestra solo problemas menores, planifica una reparación real con -y en una ventana de mantenimiento. Si muestra “bad magic number”, probablemente estés apuntando al dispositivo/offset equivocado.

cr0x@server:~$ sudo e2fsck -f -y /dev/vg0/root
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg0/root: ***** FILE SYSTEM WAS MODIFIED *****
/dev/vg0/root: 412346/5242880 files, 8123460/20971520 blocks

Decisión: Si fsck modifica el sistema de archivos, vuélvelo a ejecutar hasta que reporte “clean”. Luego móntalo en solo-lectura y valida rutas clave (/etc, /boot, datos de aplicaciones).

XFS: realidades de reparación

XFS puede crecer; no puede encogerse. Si redujiste el dispositivo subyacente, es posible que hayas truncado metadata viva. A veces puedes reparar; otras veces estás en territorio de restaurar desde backup.

cr0x@server:~$ sudo xfs_repair -n /dev/vg0/var
Phase 1 - find and verify superblock...
Phase 2 - using internal log
Phase 3 - for each AG...
No modify flag set, skipping filesystem flush and exiting.

Qué significa: Modo en seco; te indica si una reparación intentaría modificaciones.

Decisión: Si informa un desajuste severo de geometría, detente y comprueba si el tamaño del LV/partición coincide con lo que XFS espera. Arregla el tamaño subyacente primero (amplía de nuevo), luego repara.

LVM, RAID y encriptación: la tarta por capas del dolor

Los sistemas modernos apilan abstracciones porque hacen la vida mejor el 99% del tiempo. Durante la recuperación, pagas el impuesto del 1% con intereses. La clave es reconstruir la pila desde abajo hacia arriba: disco → partición → mdraid → LUKS → LVM → sistema de archivos.

Si redimensionaste una partición que contiene un PV de LVM

Mejor caso: la partición creció, el PV no, así que solo necesitas pvresize. Peor caso: la partición se encogió o movió y la etiqueta PV no está donde LVM la espera.

cr0x@server:~$ sudo pvs -o+pv_used,pv_size,vg_name
  PV         VG  Fmt  Attr PSize    PUsed    VG
  /dev/sda3  vg0 lvm2 a--  <475.50g 130.00g  vg0

Qué significa: LVM ve el PV y su tamaño. Si el tamaño del PV es menor que la partición y tenías la intención de agrandarlo, eso es un paso normal post-redimensionado.

Decisión: Si el PV es visible y solo creciste la partición, ejecuta pvresize /dev/sda3. Si el PV no es visible, no crees un PV nuevo. Eso sobrescribe metadata.

cr0x@server:~$ sudo pvresize /dev/sda3
  Physical volume "/dev/sda3" changed
  1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Si mdraid no se ensambla después de un redimensionado

Redimensionar particiones que respaldan miembros mdraid puede cambiar sus tamaños. mdraid es exigente: los tamaños de los miembros deben ser compatibles. Si un miembro es más pequeño, el arreglo puede negarse a ensamblarse o marcarlo como faulty.

cr0x@server:~$ sudo cat /proc/mdstat
Personalities : [raid1]
md0 : inactive sdb1[1] sda1[0]
      976630336 blocks super 1.2

unused devices: <none>

Qué significa: El arreglo está inactivo. Eso no es “estupendo”. Eso es “la raíz está a punto de desaparecer”.

Decisión: Inspecciona cada miembro con mdadm --examine, compara contadores de eventos y asegúrate de que los tamaños de partición sean consistentes antes de forzar el ensamblado.

Si LUKS está implicado

Si la raíz está cifrada, initramfs debe desbloquearla. Un redimensionado puede no afectar a LUKS en sí, pero puede afectar el UUID o la ruta de dispositivo referenciada en crypttab, o el mapeo de la partición subyacente.

cr0x@server:~$ sudo cryptsetup luksDump /dev/sda3 | head
LUKS header information for /dev/sda3
Version:        2
UUID:           7c0b...

Decisión: Si la cabecera LUKS se lee bien, no la “repaires”. Arregla las referencias y la cadena de arranque. Si la cabecera es ilegible, esa es otra clase de incidente—restaura desde backup o una copia de la cabecera si está disponible.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: prompt “grub rescue>” tras reiniciar

Causa raíz: GRUB no puede encontrar sus módulos/config porque los IDs de partición cambiaron, /boot se movió o el UUID del sistema de archivos cambió.

Solución: Arranca ISO de rescate, monta raíz y boot/ESP, chroot, ejecuta grub-install (correcto para BIOS/UEFI), update-grub, recompila initramfs si cambió la pila de almacenamiento.

2) Síntoma: cae a initramfs con “cannot find UUID=…”

Causa raíz: fstab/crypttab/initramfs espera un UUID antiguo, o el dispositivo no se ensambla (mdraid/LVM no activado) en el arranque temprano.

Solución: En rescate, compara la salida de blkid con /etc/fstab y /etc/crypttab. Actualiza, luego update-initramfs -u -k all.

3) Síntoma: el sistema de archivos se monta, pero /var o /home faltan

Causa raíz: Los volúmenes lógicos existen pero no se activaron, o las entradas de fstab cambiaron y ahora los puntos de montaje fallan silenciosamente.

Solución: vgchange -ay, verifica LVs con lvs, revisa journalctl después del arranque o monta manualmente para ver el error real.

4) Síntoma: ext4 “bad magic number” en fsck

Causa raíz: Estás ejecutando fsck sobre el dispositivo equivocado (partición equivocada, offset incorrecto debido a inicio movido), o el superbloque está dañado.

Solución: Confirma con blkid y los sectores de inicio de partición. Si la geometría es correcta, intenta superbloques alternativos (mke2fs -n para listarlos). Si la geometría es incorrecta, corrige la tabla de particiones primero.

5) Síntoma: errores de replay del log XFS tras redimensionado

Causa raíz: El dispositivo de bloques subyacente se encogió o truncó; XFS ve geometría inconsistente.

Solución: Expande la partición/LV de nuevo al tamaño previo si es posible, luego ejecuta xfs_repair. Si se truncó verdaderamente, planifica restaurar desde backup.

6) Síntoma: el sistema arranca, pero panic del kernel al montar la raíz

Causa raíz: initramfs carece de drivers/módulos para la pila de almacenamiento, o parámetro root= erróneo en GRUB.

Solución: Chroot y recompila initramfs; regenera la configuración de GRUB; verifica que los módulos de almacenamiento estén incluidos.

7) Síntoma: “no bootable device” en la pantalla del firmware

Causa raíz: La entrada NVRAM UEFI apunta a un binario EFI inexistente; la ESP está corrupta; o el sector de arranque BIOS fue sobrescrito.

Solución: Monta la ESP, reinstala GRUB EFI objetivo, asegúrate de que /boot/efi es correcto; opcionalmente crea la ruta EFI de fallback. Para BIOS, reinstala GRUB en el disco correcto.

Listas de verificación / plan paso a paso

Checklist A: Contén el radio de impacto

1. Snapshot a nivel de hipervisor/capa de almacenamiento si es virtualizado.
2. Si es físico, considera imagenar el disco antes de escribir reparaciones.
3. Arranca un ISO de rescate en el mismo modo de arranque (UEFI vs BIOS) que el sistema instalado.
4. Identifica el disco correcto usando modelo/serial, no solo /dev/sdX.

Checklist B: Triar al dominio de fallo correcto

1. Ejecuta lsblk y parted print para ver si las particiones existen y parecen plausibles.
2. Ejecuta sfdisk -d para capturar sectores de inicio; compáralos con los conocidos buenos si los tienes.
3. Ejecuta blkid para confirmar que las firmas de sistema de archivos existen en las particiones esperadas.
4. Ensamblar mdraid (mdadm --assemble --scan) y activar LVM (vgchange -ay) si aplica.
5. Intenta montar la raíz en solo-lectura.

Checklist C: Reparar cadena de arranque (camino “monta, pero no arranca”)

1. Monta la raíz en /mnt.
2. Monta /boot y /boot/efi si existen particiones separadas.
3. Verifica que los UUIDs en /mnt/etc/fstab y /mnt/etc/crypttab coincidan con blkid.
4. Bind-mount /dev, /proc, /sys, luego chroot.
5. Recompila initramfs.
6. Reinstala GRUB apropiado al modo de arranque; regenera la configuración de GRUB.
7. Sale del chroot, desmonta y reinicia.

Checklist D: Reparar sistema de archivos (camino “no monta”)

1. Confirma que tienes los sectores de inicio correctos antes de fsck/xfs_repair.
2. Para ext4: e2fsck -f -n primero; luego la reparación real si es necesario.
3. Para XFS: xfs_repair -n primero; nunca intentes “encogerlo de vuelta”. Amplía el dispositivo subyacente primero si hay desajuste de geometría.
4. Tras la reparación: monta en solo-lectura, valida datos críticos y luego procede a reparaciones de arranque.

Tres mini-historias corporativas (anonimizadas, plausibles, instructivas)

Incidente causado por una suposición equivocada: “Es solo /dev/sda”

Una compañía SaaS mediana tenía un playbook estándar: cuando el disco raíz de un nodo se quedaba sin espacio, amplía el disco virtual, crece la partición y luego el sistema de archivos. Rutina. Hasta que no lo fue.

El ingeniero de guardia siguió la memoria muscular y ejecutó el resize contra /dev/sda. En ese clúster de hipervisor, el orden de udev no era estable respecto a esa plantilla: el disco del SO era /dev/sdb y /dev/sda era un disco de datos adjunto para logs. La operación de resize “funcionó”. Incluso imprimió mensajes tranquilizadores. A nadie le gustan más esos mensajes que quien acaba de redimensionar el disco equivocado.

El reinicio que siguió fue catastrófico de forma sutil. El nodo arrancó, pero el volumen de logs quedó ahora desalineado; el sistema de archivos se montó sucio; la aplicación arrancó; luego se bloqueó bajo carga de escritura. Las alertas eran confusas: parecía una regresión de aplicación. En realidad era un problema de geometría de almacenamiento.

La recuperación tardó más de lo debido porque el equipo persiguió síntomas en la capa equivocada. Una vez que alguien comparó lsblk -o MODEL,SERIAL con el mapeo de discos de la VM, todo encajó: redimensionaron el dispositivo equivocado y los nombres de dispositivo no eran identificadores confiables.

Lo arreglaron de la forma aburrida: desacoplaron el disco mal redimensionado, tomaron snapshot, repararon la geometría de partición usando sectores de inicio buenos del inventario del día anterior y luego ejecutaron comprobaciones de sistemas de archivos. El disco del SO se redimensionó correctamente usando rutas estables /dev/disk/by-id en los scripts.

Una optimización que salió mal: encoger espacio “no usado” para ahorrar

Un equipo empresarial quiso recortar costes en la nube. Alguien notó que una flota de servidores de build tenía discos de 200GB pero usaba solo 40GB. Victoria fácil: encoger volúmenes, ahorrar dinero. El plan se aprobó porque parecía mantenimiento, no cirugía.

El problema fue XFS en /var, que contenía cachés de build y capas de contenedores. El script redujo primero el tamaño de la partición, planeando encoger el sistema de archivos después. Ese último paso no existe para XFS. El script no lo sabía; solo sabía llamar a parted y luego “hacer cosas con el sistema de archivos”.

La mayoría de los servidores no fallaron de inmediato. Fallaron después, bajo carga, cuando XFS intentó asignaciones cerca del antiguo fin del dispositivo. Eso produjo errores I/O, problemas de journal y, eventualmente, nodos que arrancaron en modo de emergencia porque systemd no pudo montar /var. Los incidentes llegaron como una fuga lenta, que es el peor tipo de fuga para captar atención organizacional.

La recuperación fue contundente: expandir los discos de nuevo a sus tamaños originales, reparar XFS donde fue posible y restaurar desde backups donde el truncado había dañado metadata. La “optimización” terminó costando más en tiempo de ingeniería y riesgo operativo que lo ahorrado.

Lección aprendida: reducir no es la inversa de ampliar. Ni operativamente, ni matemáticamente, ni emocionalmente.

Una práctica tediosa pero correcta que salvó el día: capturar mapas de particiones antes de tocarlas

Un equipo de servicios financieros tenía un requisito tedioso previo al cambio: antes de cualquier trabajo de disco/partición, capturar la salida de sfdisk -d y almacenarla con el registro del cambio. Los ingenieros se quejaban. Parecía papeleo fingiendo ser ingeniería.

Entonces una VM de base de datos de producción recibió una expansión de disco y un crecimiento de partición. Un ingeniero junior usó una herramienta GUI que accidentalmente movió el sector de inicio de la partición LVM. Fue un único error, pero desplazó el offset del PV. Al reiniciar, el sistema cayó en initramfs. LVM no pudo encontrar el VG. La base de datos estaba caída.

En lugar de adivinar, el on-call sacó el sfdisk -d pre-cambio del ticket, lo comparó con la geometría actual y recreó la entrada de partición con el sector de inicio original. LVM reconoció inmediatamente el PV, el VG se activó y la raíz se montó como si nada hubiera pasado.

El resto de la reparación fue rutinario: recompilar initramfs para asegurar que el arranque temprano supiera ensamblar la pila, reinstalar GRUB por seguridad, reiniciar. El tiempo de inactividad se midió en “gente molesta”, no en “se convocaron ejecutivos”.

La práctica aburrida funcionó porque convirtió un misterio en una corrección de geometría. Esa es la diferencia entre respuesta a incidentes y arqueología.

Preguntas frecuentes

1) ¿Puedo “deshacer” un redimensionado de partición?

No con un botón. Con frecuencia puedes restaurar la geometría previa de la partición (especialmente el sector de inicio) y corregir la deriva de UUID/config. Eso es el equivalente práctico de deshacer en muchos incidentes.

2) ¿Debería ejecutar fsck inmediatamente?

No. Primero confirma que estás apuntando al dispositivo correcto en el offset correcto. Si el inicio de la partición se movió, fsck como mucho fallará y como peor empeorará las cosas.

3) ¿Por qué arrancó antes del reinicio y luego falló?

Porque el kernel en ejecución tenía los mapeos viejos en memoria y usaba felizmente dispositivos de bloques ya abiertos. Reiniciar obliga al sistema a redescubrir el mundo desde la metadata en disco, que es donde rompiste la realidad.

4) Si blkid muestra los UUID correctos, ¿por qué no monta?

La presencia del UUID no garantiza la consistencia del sistema de archivos. El superbloque puede ser legible pero el journal o la metadata de asignación pueden estar inconsistentes. Monta en solo-lectura; revisa dmesg por errores I/O; ejecuta la herramienta de reparación adecuada.

5) ¿Cuál es la forma más rápida de decir UEFI vs BIOS?

En Linux: comprueba si existe /sys/firmware/efi. También busca una EFI System Partition (vfat, bandera esp). Luego alinea tu reparación de GRUB a ese modo.

6) Mi raíz está en LVM. ¿Reparo particiones o LVM primero?

Particiones primero. La metadata de LVM vive en offsets fijos dentro del PV. Si la entrada de partición apunta al sector de inicio equivocado, LVM buscará en el lugar erróneo y dirá que falta.

7) ¿Es seguro sgdisk -e?

Usualmente es seguro cuando el único problema es que las estructuras de respaldo de GPT no están al final del disco tras una expansión. No es una varita universal de “reparar GPT”. Imagen primero si sospechas corrupción más profunda.

8) ¿Por qué importa redimensionar la ESP?

El firmware UEFI arranca un binario EFI desde la ESP. Si la ESP se movió, reformató o dejó de montarse durante actualizaciones, tu entrada de arranque puede apuntar a un archivo que ya no existe.

9) ¿Qué pasa si redimensioné la partición más pequeña que los datos?

Si truncaste datos vivos del sistema de archivos, puede que no puedas recuperarlo completamente. Tu mejor movimiento es expandir la partición/LV de nuevo al tamaño previo inmediatamente (si es posible) y luego reparar. Si los datos más allá del nuevo fin se perdieron, restaura desde backup.

10) ¿Cómo prevengo esto la próxima vez?

Captura mapas de particiones antes de cambios, usa identificadores estables (by-id), ensaya en clones y separa “expandir disco” de “cambiar inicio de partición” con salvaguardas explícitas en las herramientas.

Conclusión: siguientes pasos para evitar reincidencias

Si estás aquí porque un redimensionado nukeó el arranque, tu trabajo es detener la sangría, restaurar la geometría o las referencias y volver a tener una raíz montable. El camino más rápido raramente es “reparar todo”. Es “reparar la capa que está mintiendo”.

Haz esto después, incluso si ya estás en línea:

• Captura la verdad post-recuperación: guarda lsblk, sfdisk -d, blkid y detalles del modo de arranque con el registro del incidente.
• Automatiza snapshots previos al cambio: snapshot de VM o de almacenamiento antes de operaciones de partición. Hazlo política, no heroicidad.
• Estandariza la identificación de dispositivos: prefiere /dev/disk/by-id en scripts y runbooks.
• Prohíbe el encogimiento casual: trata las operaciones de shrink como proyectos de migración, no como “limpieza”. Especialmente con XFS.
• Prueba el reinicio: tras cualquier cambio en almacenamiento/arranque, programa un reinicio controlado mientras aún tienes contexto y tiempo.

Las particiones no dan tanto miedo. Las escrituras no planificadas sí. Mantén las manos firmes, los offsets exactos y tus reparaciones aburridas.