From 5c26a76ba0ac71332ce18ab27f45f5a24827db94 Mon Sep 17 00:00:00 2001
From: Sergio <sergio@gioser.net>
Date: Thu, 10 Sep 2026 20:01:59 +0000
Subject: [PATCH] =?UTF-8?q?install-image:=20el=20wrapper=20PID1=20montaba?=
 =?UTF-8?q?=20/store=20y=20el=20diario=20en=20`vda`=20CABLEADO=20=E2=80=94?=
 =?UTF-8?q?=20en=20hcloud=20es=20`sda`?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

El wrapper que `install-image.sh` escribe como `/sbin/init` monta las dos particiones dedicadas
antes de hacer `exec` del init real, y las nombraba `/dev/vda3` y `/dev/vda4`. Eso vale sólo donde
el disco es virtio-blk. **En una caja Hetzner Cloud la controladora es virtio-SCSI y el disco es
`sda`** (medido: el driver de `sda` es `sd` y `virtio_scsi` está cargado), así que los dos montajes
fallaban.

Y fallaban del peor modo posible: **el sistema arranca igual**. Sólo que `hammerd` —que la semilla
de arje lanza con `--store /store --journal /var/lib/hammer/journal`— queda sin store y sin diario,
con dos líneas de aviso perdidas en el arranque. Es exactamente la regla 3 de CLAUDE.md: un ausente
falla ruidosamente, un vacío llega hasta el final diciendo que todo fue bien.

Ahora el disco se DERIVA de dónde está montada la raíz (`/proc/mounts`), que es la única fuente que
no depende ni del nombre del dispositivo ni de udev. Probado en los dos sentidos con /proc/mounts
sintéticos: `/dev/sda2` → `/dev/sda3`, `/dev/vda2` → `/dev/vda3`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x
---
 scripts/install-image.sh | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/scripts/install-image.sh b/scripts/install-image.sh
index 711be9c9..bb3798b7 100755
--- a/scripts/install-image.sh
+++ b/scripts/install-image.sh
@@ -100,9 +100,17 @@ CFG
 rm -f "$ROOT_TREE/sbin/init"
 cat > "$ROOT_TREE/sbin/init" <<'INIT'
 #!/bin/sh
-# Wrapper PID1 (Etapa E/B3): el kernel monta vda2 como /; montamos las particiones dedicadas.
-/bin/busybox mount -t ext4 /dev/vda3 /store          || echo "init: no pude montar /store (/dev/vda3)"
-/bin/busybox mount -t ext4 /dev/vda4 /var/lib/hammer || echo "init: no pude montar /var/lib/hammer (/dev/vda4)"
+# Wrapper PID1 (Etapa E/B3): el kernel montó la raíz; montamos las particiones dedicadas.
+#
+# El disco NO se cablea. Decía `/dev/vda3` y `/dev/vda4`, y eso vale sólo donde el disco es virtio-blk:
+# en una caja Hetzner Cloud la controladora es virtio-SCSI y el disco es `sda`, así que los dos
+# montajes fallaban —el sistema arrancaba igual, pero hammerd quedaba SIN /store y SIN diario, que es
+# el modo de fallo que llega hasta el final diciendo que todo fue bien—. Se deriva de dónde está
+# montada la raíz, que es la única fuente que no depende del nombre del dispositivo ni de udev.
+_root=$(/bin/busybox awk '$2=="/" {print $1; exit}' /proc/mounts)
+_disk=${_root%[0-9]}
+/bin/busybox mount -t ext4 "${_disk}3" /store          || echo "init: no pude montar /store (${_disk}3)"
+/bin/busybox mount -t ext4 "${_disk}4" /var/lib/hammer || echo "init: no pude montar /var/lib/hammer (${_disk}4)"
 exec /usr/bin/arje-zero
 INIT
 chmod +x "$ROOT_TREE/sbin/init"