Una imagen se escribe con `dd` sobre un disco casi siempre más grande que ella. La del perfil
servidor son 7 G; la caja hcloud tiene 76,3 G. **Sobraban 69 G que nadie podía usar**, y la caja
arrancaba perfecta con el disco a un décimo — el fallo que no falla, otra vez.
Dos cambios que van juntos:
1. **El store pasa a ser la ÚLTIMA partición** (p1 bios, p2 `/`, p3 `/var/lib/hammer`, p4 `/store`).
Sólo la última puede extenderse sin mover datos, y el store es justamente la que crece con el uso.
Con él en el medio, la partición extensible era la de ESTADO, de 512 M, que no le sirve a nadie.
El cambio es seguro porque nada referencia números de partición: `root=PARTLABEL=hammer-root` y
el wrapper monta por etiqueta con `findfs`.
2. **El wrapper de `/sbin/init` la extiende en el primer arranque**, antes de montarla:
`sfdisk -N <n> ', +'` → `partx -u` → `e2fsck -pf` → `resize2fs`. Idempotente: si ya llega al
final, los dos últimos no hacen nada. Guardado tras `-x /sbin/sfdisk` para no romper un rootfs
que no lo traiga, y el aviso va a `/dev/kmsg`, que es donde se lee.
Probado en QEMU volcando la imagen de 7 G en un disco de 20 G: el arranque imprime
`init: store: /dev/sda4 extendido al final de /dev/sda` y `/store` queda en **13,3 G** con 12,6 G
libres, sin tocar nada a mano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
