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.