Beryl::Bootstrap::QemuInRescue

Template URL GitHub releases (source officielle actuelle mfsBSD). L'endpoint /releases/latest/download/<asset> redirige toujours vers la release la plus récente — pas besoin de tag à maintenir.

Matche tous les mfsBSD-SE quelle que soit leur version / extension (.iso côté GitHub, .img côté ancien vx.sk).

Le rescue répond encore « Permission denied » au 1er essai (il n'est pas encore tombé) : au-delà de ce délai, un refus fait vérifier si le serveur n'est pas tout simplement REVENU au rescue.

Script d'install pkgbase autonome (validé in vivo, boot FreeBSD 15). Utilisé quand install_type: packages au lieu de bsdinstall+tarballs.

admin refusé : Linux à root = serveur revenu au rescue ; FreeBSD = FreeBSD démarré mais clé d'admin refusée ; sinon, rien de sûr.

Commande (rescue Linux) de téléchargement de l'image. Avec une empreinte : vérifiée par sha256sum -c, y compris pour une image déjà en cache ; une image qui ne correspond pas est effacée et la commande échoue (rien n'est démarré). Pure, exposée pour les specs.

Ordre global des disques passés à QEMU : boot d'abord, puis pools data dans l'ordre de déclaration. Les index QEMU correspondent : vtbd0 = mfsBSD, vtbd1..vtbd(N) = boot, vtbd(N+1).. = data.

Script shell (non base64) qui crée les pools data sous /mnt via zpool create. Vide si aucun pool data. Pour chaque pool :

zpool create -f -R /mnt -m <mountpoint> <nom> <vdev...> zpool set cachefile=/mnt/boot/zfs/zpool.cache <nom>

-R /mnt = altroot : les cache files ZFS écrivent sous /mnt (bon emplacement au reboot bare metal). -f car les disques sont neufs, mais zpool create chipote parfois sur résidus.

Le zpool set cachefile est INDISPENSABLE : sans lui, l'export final (zpool export -a) retire le pool du cache, et au reboot bare-metal FreeBSD ne retrouve plus que zroot dans /boot/zfs/zpool.cache. Le pool data existe sur disque (visible via zpool import) mais doit être importé à la main. Constaté terrain quantas.example.net 24 avril 2026.

Pointer vers /mnt/boot/zfs/zpool.cache (le cachefile du système cible, dans zroot altroot /mnt) garantit qu'au reboot, le rc.d/zfs du FreeBSD installé importe les deux pools.

Pools chiffrés : si encryption_key_hex est posé, on génère :

• Un bloc { ... } qui décode la clé base64 dans une variable locale KEY (jamais en argument de commande).
• zpool create -O encryption=on -O keyformat=hex -O keylocation=prompt … avec la clé fournie sur stdin.
• unset KEY pour libérer la mémoire shell après l'usage.
• PAS de zpool set cachefile : on EXCLUT le pool chiffré du cache pour qu'au reboot bare-metal, FreeBSD ne tente pas d'importer un pool dont la clé n'est pas chargée. L'opérateur fera beryl unlock (qui appelle zpool import + zfs load-key). Voir zpool-encryption-architecture.adoc § « Au bootstrap ».

Le script complet est ensuite encodé en base64 et exécuté côté VM via bash -c "$(echo ... | base64 -d)" — la clé hex n'apparaît jamais dans la ligne de commande.

Version base64 du script pour injection dans le template shell (évite les problèmes de quoting). Vide si aucun pool data.

Nom à suggérer dans le hint beryl follow-install <name> (typiquement FQDN ou <société>/<host>). nil → fallback « <host> ».

Alias rétrocompat — ancien paramètre iso_url.

Chemin local (côté rescue) où l'image mfsBSD SE est téléchargée. Inclut la version pour qu'un changement de version upstream (ex: 14.2 → 15.0) force un nouveau téléchargement au lieu de réutiliser un cache périmé d'une version précédente. L'extension provient de l'URL (.iso GitHub, .img vx.sk).

Args -drive pour chaque disque cible passthrough dans QEMU. Inclut boot ET pools data : on veut que la VM voie tout pour créer les pools data post-install dans le même qemu-system-x86_64. Chaque disque devient un vtbd* dans la VM (vtbd0=mfsBSD, vtbd1+=cibles).

Rend le script d'install pkgbase (autonome). Multi-disque (Phase 2) : le pool boot s'étend sur vtbd1..vtbd(N) (N = @disks.size ; vtbd0 = mfsBSD), assemblés selon @raid (stripe/mirror/raidz…). Les pools data (vtbd(N+1)..) sont créés via le même data_pools_script que le chemin tarball (mapping vtbd, cachefile, chiffrement réutilisés). Clés root = union des clés SSH des users déclarés.

Rend l'installerconfig minimaliste (préambule seul, pas de chroot). ZFSBOOT_DISKS : dans la VM QEMU, les disques passthrough sont vtbd1, vtbd2, … (vtbd0 est l'image mfsBSD elle-même). Ordre = ordre d'apparition dans le -drive côté QEMU.

Rend le driver shell. Tous les placeholders de la template sont substitués ici (noms mfsbsd, OVMF, QEMU args, users, packages, sudoers).

Clés à autoriser pour root (base64, une par ligne). UNIQUEMENT en Option I (/home chiffré) : root clé-seule devient la porte de secours fail-safe lisible avant l'unlock (/root est clair), beryl unlock s'y connecte. Vide sinon → root reste coupé (durcissement historique). Voir zpool-encryption-architecture.adoc § « Accès SSH au boot ».

Contenu base64 du fichier sudoers (chaque ligne == une règle). Vide si aucune règle → le driver shell skip la création du fichier.

Script ZFS des datasets système du profil C+ (profile: standard). Exécuté SUR la VM APRÈS le remount de zroot sur /mnt, AVANT le post-install (users/packages écrivent alors DANS les datasets chiffrés montés, pas dans zroot/ROOT/default qui serait masqué au montage). Flux :

1. Encryptionroot zroot/encrypted (non monté), clé 64-hex via stdin.
2. Datasets enfants chiffrés (héritent la clé) + datasets clairs, chacun avec sa compression et son mountpoint (altroot /mnt → /mnt/<mp>).

La clé n'apparaît jamais en argv (base64 → $KEY → stdin). L'zpool export -a final du template largue la clé → datasets verrouillés au reboot bare-metal (l'opérateur fait beryl unlock). Vide si pas de profil.