Corrido por primera vez en la caja (una máquina busybox, no GNU), el recolector funcionó —337
artefactos borrados y verificados, 26,8 G liberados— pero sus dos NÚMEROS salieron vacíos:
==> espacio: superados · huérfanos
==> 337 artefactos borrados y VERIFICADOS (0 sobrevivientes) · libres: Available → Available
1. `du -sch --files0-from=-` es de GNU coreutils y busybox NO lo tiene ⇒ `espacio()` devolvía vacío.
Un número que falta se lee como un número chico: sin él nadie puede decidir si vale la pena
correrlo, que es justo para lo que está el dry-run. Ahora `xargs du -sk` + awk, que anda en los
dos mundos.
2. `df -h /home` estaba CABLEADO, y el store casi nunca vive ahí: en gioser es un bind-mount del
volumen y en una caja takana es `/store`, su propia partición. En la caja no hay `/home`, así que
`tail -1` se quedó con la CABECERA y el resultado fue «Available → Available». Se mide `$STORE`.
Medido de verdad con `df` a mano: /store pasó de 84,7 G usados (91 %) a 57,9 G (62 %) — 26,8 G
liberados, 1657 → 1320 artefactos. Y el control que importa después de un gc: los 11 enlaces de
`/usr/bin` que apuntan DENTRO del store siguen resolviendo y los 21 entes siguen corriendo.
⚠ Vale anotar la advertencia que el propio gc imprime y que en esa caja no se puede satisfacer: «sin
.config legible ⇒ NO se protege ningún kernel por esta vía». El default (sólo superados) no toca lo
vigente, pero `--huerfanos` en una máquina que arranca de su store hay que pensarlo dos veces.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
