Con el disco ya agrandado del lado del hipervisor (qm resize 100 scsi0 +50G en Proxmox, Edit disk en VMware, la consola de tu nube):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 1. Que el kernel vea el tamaño nuevo (virtio-scsi/SATA; virtio-blk lo detecta solo)
echo 1 > /sys/class/block/sda/device/rescan
lsblk /dev/sda

# 2. Agrandar la partición (paquete cloud-guest-utils en Debian/Ubuntu, cloud-utils-growpart en RHEL)
growpart /dev/sda 3

# 3a. Con LVM: PV, LV y sistema de archivos
pvresize /dev/sda3
lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv      # -r: resize2fs o xfs_growfs según el fs

# 3b. Sin LVM
resize2fs /dev/sda3        # ext4
xfs_growfs /               # xfs: se indica el punto de montaje

Sin reinicio. df -h / confirma.

Antes de empezar

• Snapshot o backup en el hipervisor. Crecer es seguro; equivocarse de partición no.
• Mira el layout: lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS. Ahí ves el número de partición, si hay LVM debajo y qué sistema de archivos toca.
• Nombres: virtio-blk es /dev/vda; virtio-scsi y SATA, /dev/sda; NVMe, /dev/nvme0n1 con particiones p1, p2… (growpart /dev/nvme0n1 1).
• A veces el espacio ya está: Ubuntu Server crea el LV usando solo parte del VG. Si vgs muestra VFree grande, salta directo al lvextend.

1. Que el kernel vea el disco nuevo

lsblk tiene que mostrar el tamaño nuevo en el disco antes de seguir; si no lo muestra, growpart dirá NOCHANGE.

2. growpart

1
2

growpart /dev/sda 3
# CHANGED: partition=3 start=4198400 old: size=… end=… new: size=… end=…

growpart estira la partición hasta el final del disco, mueve la cabecera de respaldo de GPT y avisa al kernel de la tabla nueva aunque la partición esté montada (usa partx --update). Solo funciona con la última partición; si hay una de swap detrás de la raíz, quítala primero (swapoff, fdisk para borrarla, y la vuelves a crear al final).

Sin growpart: parted /dev/sda resizepart 3 100% hace lo mismo con una pregunta de confirmación.

3a. LVM

1
2
3
4

pvresize /dev/sda3                                  # el PV ocupa la partición ya grande
vgs                                                 # VFree > 0
lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv   # todo el espacio
lvextend -r -L +20G /dev/ubuntu-vg/ubuntu-lv        # o solo una parte

-r llama a resize2fs o xfs_growfs según lo que haya en el LV. Sin -r, hazlo tú: resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv o xfs_growfs /.

3b. Sin LVM

1
2
3

resize2fs /dev/sda3                 # ext4: online
xfs_growfs /                        # xfs: online, sobre el punto de montaje
btrfs filesystem resize max /       # btrfs

Raspberry Pi y tarjetas SD

Mismo guion con otros nombres (imagen de Fedora ARM con LVM):

1
2
3
4

growpart /dev/mmcblk0 3
pvresize /dev/mmcblk0p3
lvextend -l +100%FREE /dev/fedora/root
xfs_growfs -d /

Trampas

• growpart: NOCHANGE: el kernel todavía no vio el tamaño nuevo. Vuelve al paso 1.
• growpart falla en un locale que no es inglés (parsea la salida de sfdisk): LC_ALL=C growpart /dev/sda 3.
• GPT PMBR size mismatch en fdisk -l después de crecer el disco: la cabecera de respaldo de GPT quedó donde terminaba el disco viejo. growpart la mueve; si lo hiciste a mano, sgdisk -e /dev/sda.
• La partición no es la última. Swap o /home detrás de la raíz: o mueves esas, o añades un disco nuevo y lo sumas al VG (pvcreate /dev/sdb && vgextend ubuntu-vg /dev/sdb), que en LVM es más rápido que reordenar particiones.
• Encoger es otra historia: ext4 solo desmontado; XFS nunca. Piénsalo antes de dar 2 TB “por si acaso”.
• Windows se agranda desde Administración de discos → Extender volumen; no aplica nada de esto.

Ver también

• Plantillas cloud-init en Proxmox: ahí el qm resize del lado del host.
• LVM: no se activa el volume group, por si el paso 3 se pone raro.
• Mover los datos de k3s a otro disco, la alternativa cuando lo que se llena es un servicio concreto.

1
2
3
4
5
6

vgscan
pvs; vgs; lvs -a -o +devices,lv_health_status     # ¿falta un PV? ¿qué LV no activa y por qué?

vgchange -ay                                       # intento normal
vgchange -ay --activationmode degraded             # LVs raid1/raid5/raid6 de LVM con un PV ausente
vgchange -ay --activationmode partial              # cualquier LV con PV ausente: SOLO para copiar datos, monta ro

Si el fallo es al arrancar (emergency shell porque / o /home no aparecen), los mismos comandos desde el prompt del initramfs, precedidos de lvm si no hay binarios sueltos (lvm vgchange -ay), y luego exit.

Qué mirar primero

Los tres modos de activación (man vgchange): complete (por defecto) solo activa LVs con todos sus PV presentes; degraded activa LVs RAID de LVM a los que les falta una pata; partial activa cualquier LV aunque falten PV, rellenando lo que falta con errores o ceros, y solo sirve para recuperar.

Casos

1. Falta un PV

Arregla primero el hardware: reconecta, cambia de puerto, revisa la controladora. En cuanto pvs lo vea, vgchange -ay y listo.

Si el disco no vuelve y el LV era lineal sobre varios PV, lo que estaba en ese disco se perdió. Rescata el resto en solo lectura:

1
2
3

vgchange -ay --activationmode partial
mount -o ro /dev/vg01/datos /mnt/rescate
rsync -a /mnt/rescate/ /otro/sitio/

Y solo después de copiar, deja el VG limpio: vgreduce --removemissing --force vg01.

2. LVs RAID de LVM (raid1, raid5, raid6)

Con una pata ausente arrancan en modo degradado:

1

vgchange -ay --activationmode degraded

Después, reemplaza el PV: vgextend vg01 /dev/sdX con el disco nuevo y lvconvert --repair vg01/datos. Si el LV no se deja activar ni así (reload ioctl … failed, subvolúmenes _rimage_ activos pero el LV no), estás en el escenario donde el tooling de LVM RAID se queda corto; la restauración desde backup es la salida honesta. Para RAID con paridad, mdadm debajo de LVM da mejores herramientas de recuperación.

3. Thin pool

Los thin pools son los que más sufren un corte: al arrancar, thin_check encuentra la metadata inconsistente y LVM se niega:

1

Check of pool vg01/pool0 failed (status:1). Manual repair required!

El arreglo es el que dice el mensaje, con el pool inactivo:

1
2

lvconvert --repair vg01/pool0
vgchange -ay vg01

--repair reconstruye la metadata en un LV nuevo y deja la vieja como pool0_meta0; cuando compruebes que los volúmenes thin montan bien, lvremove vg01/pool0_meta0. Un thin pool con un PV ausente no se activa ni en modo degraded; ahí solo queda partial para copiar.

4. Metadatos rotos (PVs presentes, VG “incompleto” o “unknown”)

1
2
3

vgcfgrestore --list vg01                                # archivos en /etc/lvm/archive con fecha y motivo
vgcfgrestore -f /etc/lvm/archive/vg01_00042-1234567890.vg vg01
vgchange -ay vg01

Solo para metadatos: si lo que falta es un disco, restaurar la configuración no lo trae de vuelta.

5. El disco está, pero LVM lo ignora

En RHEL 9, Fedora y derivados LVM solo mira los dispositivos listados en /etc/lvm/devices/system.devices. Si el apagón hizo que un disco volviera con otro identificador (cambio de controladora, WWID distinto, disco clonado), LVM no lo considera aunque lsblk lo muestre:

1
2
3
4

lvmdevices                          # lista actual
lvmdevices --adddev /dev/sdc        # añadir el dispositivo
vgimportdevices -a                  # o importar todos los VG que encuentre
vgchange -ay

Después de activar

Un apagón rompe sistemas de archivos con más frecuencia que LVM. Antes de montar en escritura:

1
2

fsck -n /dev/vg01/datos        # ext4: solo mirar
xfs_repair -n /dev/vg01/datos  # xfs: solo mirar

Y si el resultado da miedo, monta ro, copia, y repara después.

Trampas

• partial no arregla nada: lo que falta se lee como ceros o errores y cualquier escritura ahí se pierde. Monta en solo lectura y copia.
• No hagas vgreduce --removemissing antes de copiar. Es lo último, no lo primero.
• /etc/lvm/backup y /etc/lvm/archive valen oro y viven en el mismo disco que puede fallar. Cópialos fuera de la máquina de vez en cuando (vgcfgbackup -f /ruta/externa/%s.vg).
• En VMs el “corte de luz” es un stop forzado; misma receta. Y si lo que no arranca es el propio GRUB con root en LVM, es otro problema.

Referencias: man 8 vgchange, man 7 lvmthin y man 8 lvmdevices.

Arranca la ISO de Proxmox → Advanced Options → Install Proxmox VE (Debug mode); en el primer shell pulsa Ctrl+D para llegar al segundo, que ya tiene LVM:

1
2
3
4

vgscan
vgchange -ay
lvcreate -L 4M pve -n grubtemp   # cualquier cambio en los metadatos de LVM sirve
reboot

Con el nodo ya arriba, limpia y deja el arreglo permanente:

1
2
3

lvremove pve/grubtemp
[ -d /sys/firmware/efi ] && apt install grub-efi-amd64     # UEFI
# BIOS legacy: grub-install /dev/sdX && update-grub        # el disco, no la partición

El error

1
2
3

error: disk 'lvmid/Xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx/Yyyyyy-yyyy-yyyy-yyyy-yyyy-yyyy-yyyyyy' not found.
Entering rescue mode...
grub rescue>

El disco está bien, el VG pve está bien y los datos están bien. A veces el mismo bug avisa antes, durante un apt full-upgrade:

1

/usr/sbin/grub-probe: error: disk `lvmid/...' not found.

Si ves eso en update-grub, aplica el arreglo antes de reiniciar.

Por qué pasa

LVM guarda sus metadatos en disco en un ring buffer. Cada cambio (crear, borrar o redimensionar un LV) escribe una copia nueva más adelante en el buffer, y tarde o temprano el texto da la vuelta al final. GRUB 2.06 de Debian 11 (PVE 7, 2.06-3) no sabe leer esa vuelta: no encuentra el VG, no encuentra el LV pve/root y cae a grub rescue.

Por eso “arreglarlo” es tan raro como hacer un cambio cualquiera en LVM: los metadatos se reescriben en otra posición, normalmente sin vuelta, y GRUB los vuelve a leer. Y por eso vuelve a pasar semanas o meses después, cuando el buffer da la vuelta otra vez, si el GRUB instalado en el disco sigue siendo el viejo.

En el lab el cambio que sacó del apuro fue lvextend -L +1G /dev/pve/root. Funciona igual, pero deshacerlo con lvreduce sobre el root montado es jugar con fuego; si lo hiciste así, mejor conserva el 1G (resize2fs /dev/pve/root) o usa el LV de usar y tirar del En corto.

Procedimiento completo

1. Entra al sistema. Dos vías desde la ISO de Proxmox:

   • Rescue Boot (Advanced Options): la ISO busca la instalación y arranca su kernel saltándose el GRUB roto. Si funciona, ya estás dentro del sistema real y puedes pasar al paso 3.
   • Debug mode: shell de rescate. Ctrl+D en el primer prompt; en el segundo ya están los módulos de LVM.

2. Dispara un cambio de metadatos (solo si entraste por Debug mode):

   1 2 3 4

   vgscan vgchange -ay lvcreate -L 4M pve -n grubtemp reboot

3. Ya en el sistema normal, quita el LV temporal y mira si los metadatos siguen dando la vuelta:

   1 2	lvremove pve/grubtemp vgscan -vvv 2>&1 | grep 'Reading metadata'

   Una salida que termina en (+0) significa sin vuelta; cualquier otro valor, que el problema va a repetirse hasta que reinstales GRUB.

4. Reinstala el GRUB con el fix. El paquete de PVE 8 y 9 (2.06-13 o más nuevo) ya lo trae, pero el binario que está en el ESP o en el MBR solo se reescribe cuando el paquete se (re)instala:

   1 2 3 4 5 6 7 8

   # UEFI: en nodos actualizados desde PVE 7 suele estar grub-pc y no grub-efi-amd64 dpkg -l | grep -E '^ii +grub-' apt install grub-efi-amd64 efibootmgr -v # confirma la entrada "proxmox" # BIOS legacy grub-install /dev/sdX update-grub

   En PVE 7 el arreglo de verdad es actualizar a PVE 8; el workaround solo te compra tiempo.

Trampas

• grub rescue> no te va a sacar de esta. ls (lvm/pve-root) no muestra nada porque el módulo lvm es precisamente el que no entiende los metadatos. No pierdas tiempo ahí.
• Root en ZFS no pasa por aquí. Los nodos con rpool arrancan con proxmox-boot-tool; ese es otro camino y otros errores.
• Apunta a las particiones correctas si haces grub-install a mano: el disco (/dev/sda), no /dev/sda1; el ESP montado en /boot/efi para UEFI.
• En clúster, arreglado un nodo revisa los demás con vgscan -vvv | grep 'Reading metadata'; la instalación es la misma y el buffer también.

Referencias: Recover From Grub Failure en la wiki de Proxmox y el hilo del foro.