Commit graph

3 commits

Author SHA1 Message Date
83b9674176 [REF] qemu firmware : une table pour les deux voies, fuseau décodé
Deux tables opposées vivaient dans le même fichier : l'une forçait le
BIOS, l'autre l'UEFI, chacune lue d'un seul côté. Elles pouvaient se
contredire sans que rien ne le dise. FIRMWARE_IMPOSE les remplace, et les
deux suites passent inchangées. « --bios » l'emportait sur un fait
physique : forcé sur une image sans secteur d'amorçage, il donnait une VM
« running » à console muette. Il est ignoré, et l'appelant l'apprend.

Le fuseau était lu en UTF-8 strict sous un « except OSError » : un octet
qui n'en est pas faisait échouer tout le déploiement pour une traduction
de confort.

--- EN ---

Two opposing tables lived in one file: one forced BIOS, the other UEFI,
each read by one side only. They could contradict each other silently.
FIRMWARE_IMPOSE replaces both, and both suites pass unchanged. "--bios"
overrode a physical fact: forced on an image with no boot sector it gave a
"running" VM with a mute console. It is ignored now, and the caller is
told.

The timezone was read as strict UTF-8 under an "except OSError": a byte
that is not one failed the whole deployment for a convenience
translation.

Assisted-by: Claude Opus 5
2026-09-16 21:31:03 -04:00
814251f19f [FIX] déploiement qemu : amorcer Fedora en BIOS, sa chaîne UEFI se fige
Aucune VM Fedora ne démarrait : pas de console, pas de bail DHCP, une machine
« en cours d'exécution » qui ne fait rien. Le micrologiciel charge et DÉMARRE
le chargeur — il l'annonce — puis se fige sans écrire un octet sur le disque.
La même image en BIOS démarre son noyau : ce n'est donc ni l'image, saine, ni
sa partition EFI, dont le chemin de repli est bien là. Ni l'entropie ni la
machine q35 n'y changent rien. Une table nomme les distributions concernées et
« --bios » l'emporte toujours, pour l'hôte qui n'a pas OVMF.

--- EN ---

No Fedora VM would start: no console, no DHCP lease, a machine "running" that
does nothing. The firmware loads and STARTS the loader — it says so — then
freezes without writing a byte to disk. The same image under BIOS boots its
kernel: so it is neither the image, which is sound, nor its EFI partition,
whose fallback path is present. Neither entropy nor the q35 machine changes
anything. A table names the distributions concerned, and "--bios" always
wins, for the host that has no OVMF.

Assisted-by: Claude Opus 5
2026-09-14 16:46:15 -04:00
2892606690 [FIX] déploiement qemu : nom d'hôte valide, fuseau connu de l'invité
Deux réglages que cloud-init applique au premier démarrage, et qui échouaient
tous les deux SANS arrêter le déploiement. Un nom d'hôte n'accepte ni souligné
ni point, là où un nom de domaine libvirt les tolère : la VM gardait le nom
générique de son image. Un alias de fuseau hérité — la forme que plusieurs
distributions récentes ont reléguée à un paquet séparé — faisait marquer
l'exécution de cloud-init en erreur et laissait la machine en UTC, ce qui ne
se voit qu'après coup sur des horodatages à +0000. Le nom est nettoyé, le
fuseau rendu canonique par la table d'alias de tzdata.

--- EN ---

Two settings cloud-init applies at first boot, both of which failed WITHOUT
stopping the deployment. A hostname accepts neither underscore nor dot, where
a libvirt domain name tolerates them: the VM kept its image's generic name. A
legacy timezone alias — the form several recent distributions moved to a
separate package — marked the cloud-init run as failed and left the machine in
UTC, which only shows up later on +0000 timestamps. The name is cleaned, the
timezone made canonical through tzdata's alias table.

Assisted-by: Claude Opus 5
2026-09-14 16:46:15 -04:00