Fase 1: een golden image, en waarom SeaBIOS deze ronde won
De cloud-init-template bouwen waarvan elke VM een kloon maakt — en op de harde manier leren dat UEFI + cloud images + een seriële console je bootfouten verbergt.
Fase 1 is de toolchain en de golden image: één cloud-init-template waarvan elke toekomstige VM een kloon maakt. Eén keer goed krijgen, voor altijd uitstempelen. Ik kreeg het eerst twee keer fout.
Cloud image, niet de installer-ISO
De template is gebouwd op de cloud image van de distributie — een vooraf geïnstalleerde schijf met cloud-init ingebakken — niet op de live-server-ISO. De ISO is een installer; je zou voor elke kloon een onbewaakte installatie en reboot moeten scripten. De cloud image kloon je gewoon, en cloud-init schildert er bij de eerste boot de hostname, gebruiker, SSH-key en het statische IP op. Het is meteen de reden waarom een kloon in enkele seconden klaar is.
De firmware-val
Ik bouwde de template met UEFI (OVMF) en een console die enkel serieel was, met GPU-passthrough in het achterhoofd. De eerste kloon bootte naar een zwart scherm bij “starting serial terminal” en kreeg nooit een IP. De val: onder UEFI schrijft de vroege boot naar de geëmuleerde VGA, die ik had uitgeschakeld — dus het scherm blijft zwart terwijl de echte fout onzichtbaar gebeurt. SeaBIOS boot deze cloud images zonder enige drama. Ik zette de basistemplate over op SeaBIOS, hield een zichtbare console, en parkeerde UEFI voor de ene host die het echt nodig heeft.
Als je de console niet ziet, ben je geen boot aan het debuggen — dan ben je ernaar aan het gissen.
De andere twee valkuilen
Een piepkleine VM met te weinig RAM boot niet traag — hij krijgt een kernel panic op geheugen, middenin cloud-init. En een “latest” cloud image pinnen via URL bijt je de dag dat upstream hem herbouwt: pin een gedateerde snapshot en verifieer de checksum, of je cache en de gepubliceerde hash zijn het stilletjes oneens.
Volgende keer: fase 2 — interne DNS, en een echte kip-en-ei.