Remplacer Linux par IronFlockOS

ironflock os install remplace par IronFlockOS le Linux à partir duquel une machine en fonctionnement a démarré, sur le même disque, et fait de la machine l’appareil IronFlock d’un fichier de configuration de l’appareil (.flock). Vous l’exécutez sur la machine elle-même, ou depuis un autre ordinateur via SSH.

Avertissement : Tout ce qui se trouve sur le disque à partir duquel la machine a démarré est perdu : le système en cours d’exécution, ses paquets et ses paramètres, ses comptes utilisateur et toutes les données. Aucun retour en arrière n’est possible. Exécutez d’abord la commande avec --dry-run et lisez le plan.

Quand l’utiliser

Utilisez os install pour une machine qui tourne déjà sous Debian, Ubuntu ou un autre Linux avec systemd, et que vous ne pouvez pas ou ne voulez pas démarrer à partir d’une clé USB : un PC dans une armoire électrique, une machine virtuelle dans un cloud, une machine que vous ne joignez que via SSH. Avec --host, vous exécutez la commande depuis votre propre ordinateur, y compris depuis un Mac, et elle attend que la machine soit en ligne en tant qu’appareil IronFlock.

Utilisez une autre commande lorsque :

• Vous pouvez démarrer la machine à partir d’un lecteur — ironflock os flash écrit IronFlockOS sur une clé USB, une carte SD ou un disque externe. Avec --installer, la commande écrit une clé d’installation, qui installe IronFlockOS sur le disque interne du PC qui démarre à partir d’elle. La clé d’installation est aussi la solution pour la plupart des machines que refuse os install.
• La machine est un Raspberry Pi — os install n’installe que les images pour machines UEFI (cibles amd64-efi et arm64-efi). Écrivez la carte SD du Raspberry Pi avec os flash.
• La machine tourne déjà sous IronFlockOS — os install la refuse. ironflock os update y installe une autre version.
• Vous voulez conserver le Linux de la machine — ironflock agent install connecte la machine à IronFlock telle quelle.

ironflock os install

Vérifie la machine, affiche le plan du remplacement et pose la question. La commande prépare ensuite IronFlockOS en mémoire et redémarre la machine, qui écrit IronFlockOS sur le disque à la fin de son arrêt, puis le démarre.

ironflock os install [-c <device.flock>] [--disk <disk>] [--dry-run] [flags]

Sous macOS, la commande se termine avec le code de sortie 3 avant d’examiner quoi que ce soit ; exécutez-la alors avec --host. Elle s’exécute sur une seule machine à la fois : --host donné plusieurs fois et --hosts se terminent avec le code de sortie 2. Les options globales sont décrites dans Options, sortie et codes de sortie.

Options

Les options de proxy fonctionnent comme pour agent install. Sans elles, la commande prend HTTP_PROXY, HTTPS_PROXY et NO_PROXY dans l’environnement. Une URL de proxy qui contient un mot de passe est une ligne de commande erronée (code de sortie 2) ; voir Secrets.

Ce dont la machine a besoin

• Le système — Linux avec systemd en PID 1, comme Debian ou Ubuntu, hors conteneur. IronFlockOS et ReswarmOS sont refusés.
• Le firmware — UEFI 64 bits sur amd64 ou arm64. Ses variables EFI sont montées (efivarfs) et accessibles en écriture. Le BIOS et l’UEFI 32 bits sont refusés. Secure Boot peut être activé ; voir Secure Boot.
• Le disque — le disque à partir duquel le firmware a démarré le système : un disque entier à part entière, avec une GPT (table de partitions GUID) et des secteurs logiques de 512 octets. Le système de fichiers racine se trouve sur ce disque et sur aucun autre, directement ou via LVM ou LUKS. Le disque a au moins la taille de disque minimale de l’image : la taille que nomme le catalogue, sinon 10 Gio, ou 18 Gio pour une image nvidia.
• La mémoire — de la mémoire disponible (MemAvailable) pour l’image compressée, le binaire ironflock et 512 Mio de plus : une machine d’environ 2 Gio pour l’image base.
• Les outils — lsblk et ip d’iproute2.
• Le réseau — le serveur de téléchargement joignable, directement ou via un proxy, sur un réseau que le nouveau système peut utiliser (Ce que reçoit le nouveau système). Pour un appareil d’une IronFlock Appliance, ce peut être le miroir de téléchargement de l’appliance (D’où viennent les fichiers).
• Le fichier .flock — celui de -c, ou celui de l’agent de l’appareil installé sur la machine.

D’où viennent les fichiers

La commande a besoin du catalogue IronFlockOS signé, de l’image et de la liste du matériel de l’image. Elle les prend :

1. de --download-base, sinon de IRONFLOCK_DL_BASE : ce serveur seul ;
2. sinon du miroir de téléchargement de l’IronFlock Appliance que le fichier .flock désigne comme serveur de mise à jour : son update_url, lorsque c’est une URL http ou https absolue dont l’hôte n’est pas un hôte du cloud IronFlock, comme https://registry.<domain>/dl ou http://<host>:<port>/dl. Stderr indique Download base: ... (from the device's .flock). Une machine qui joint l’appliance mais pas ironflock.com est convertie de cette façon. Un fichier .flock du cloud IronFlock prend le cloud ;
3. sinon du cloud IronFlock, https://instance-registry.ironflock.com/dl.

Avec le miroir de l’appliance, les fichiers proviennent d’abord du miroir, et du cloud IronFlock là où le miroir ne les fournit pas :

• Le catalogue, <mirror>/ironflockos/manifest.json — lorsque le miroir n’en fournit pas pour l’instant (il est injoignable, il répond par une erreur, ou seule la copie conservée de son dernier catalogue en tiendrait lieu), tout provient du cloud, comme sans appliance. Un catalogue que fournit le miroir et qui est refusé (sa signature, plus ancien que la copie conservée, trop volumineux) fait échouer la commande, comme avec n’importe quel serveur.
• L’image, <mirror>/ironflockos/<version>/<file> — lorsque le miroir ne la fournit pas (il est injoignable, répond par autre chose que le fichier, ou ce qu’il envoie n’est pas le début de l’image), elle provient de l’URL que nomme le catalogue signé. Un fichier du cache de os flash ne sollicite ni l’un ni l’autre.
• La liste du matériel, <mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — la même règle, indépendamment.

Chaque repli est un avertissement dans le plan, avec le miroir, le fichier et la raison ; avec --json, dans warnings. Le plan décide une seule fois de la source de chaque fichier : la préparation télécharge l’image depuis l’image.url du plan et ne se replie pas une seconde fois. Lorsque ni le miroir ni le cloud ne fournissent un fichier, la commande échoue avec une seule erreur qui nomme les deux sources et les deux raisons (neither the appliance's mirror ... nor the IronFlock cloud gives ...).

Le miroir est joint directement, le cloud via le proxy, comme pour agent install. Un miroir HTTPS dont le certificat provient de la propre CA de l’appliance ne fonctionne que là où le système de la machine fait confiance à cette CA. Lorsque l’appliance répond, le nouveau système garde la carte réseau qui l’a jointe (Ce que reçoit le nouveau système).

Avant toute modification

La commande vérifie la machine dans cet ordre. La première vérification qui échoue entraîne un refus, avec le code de sortie 3 et une phrase qui nomme la cause et, s’il y en a une, la solution. À ce stade, rien n’a été modifié.

1. Le système — systemd est le PID 1, le système n’est pas un conteneur, et ce n’est ni IronFlockOS ni ReswarmOS.
2. Le firmware — UEFI 64 bits, des variables EFI accessibles en écriture et, avec Secure Boot activé, une chaîne de démarrage de l’image que le firmware démarrera (Secure Boot).
3. L’image — tirée du catalogue IronFlockOS signé, telle que la liste os images : l’image de --image, sinon l’image de base de la cible de la machine. La commande lit les premiers Mio du fichier image : depuis le cache de os flash lorsque le fichier s’y trouve, sinon depuis le serveur de téléchargement (d’abord le miroir de l’appliance, voir D’où viennent les fichiers). Un fichier .flock pour un autre matériel ne donne lieu qu’à un avertissement.
4. Le disque — celui qui porte la partition que nomme l’option de démarrage actuelle du firmware ; sinon celui qui porte la partition système EFI montée sous /boot/efi ou /efi ; sinon celui que nomme --disk. Un --disk qui désigne un autre disque que celui à partir duquel le système a démarré est refusé. Il en va de même d’un disque qui n’est pas un disque entier à part entière : une grappe MD RAID (y compris celle que crée Intel RST), un périphérique device-mapper, loop ou bloc réseau, un disque en mémoire.
5. Ce qui est construit sur le disque — des partitions, LVM avec des volumes linéaires, et ce que cryptsetup met en place pour le chiffrement (LUKS, dm-crypt simple, BitLocker, FileVault, TrueCrypt). Tout le reste est refusé : MD RAID, bcache, multipath, un pool ZFS, les thin pools LVM, les snapshots, les caches, le RAID et les miroirs, dm-verity, dm-integrity. Les autres disques restent tels quels : un système de fichiers btrfs ou un groupe de volumes LVM dont des membres se trouvent sur ce disque et sur un autre est donc refusé, car remplacer le disque le détruirait sur les deux. Une machine dotée d’un autre disque qui a une partition nommée IRONFLOCKOS, rootfs-a, rootfs-b ou data est aussi refusée, car IronFlockOS trouve ses partitions par ces noms.
6. La mémoire — comme ci-dessus.
7. Le fichier .flock, le réseau, le proxy, les pilotes — le fichier .flock est lu comme os flash le lit, et sa clé SSH doit être valide. Le réseau et le proxy sont vérifiés comme décrit dans Ce que reçoit le nouveau système. Pour les pilotes, la commande prend les périphériques situés sur le chemin vers le disque et vers la carte réseau (le disque, la carte, leurs contrôleurs et leurs bus) et les recherche dans la liste du matériel de l’image. Elle ne refuse que lorsque la liste montre que l’image n’a pas de pilote pour l’un d’eux. Un périphérique pour lequel elle ne peut pas trancher est nommé dans l’avertissement drivers not checked ; pour une version sans liste du matériel (jusqu’à 0.14.0), l’avertissement nomme chaque périphérique.
8. Le plan et la question — voir ci-dessous.

Ctrl-C pendant que la commande lit le début de l’image y met fin avec le code de sortie 130, de même qu’un terminal perdu pendant l’affichage du plan ou pendant que la question attend sa réponse. Rien n’a alors été modifié.

Le plan et --dry-run

Le plan va sur stderr. Il nomme la machine et son firmware, le disque et la façon dont il a été trouvé, l’image et la provenance de son fichier, ainsi que la mémoire. Il indique que tout ce qui se trouve sur le disque est perdu, ce que reçoit le nouveau système et ce qu’il ne reçoit pas, ainsi que les avertissements. --dry-run affiche le plan, ne modifie rien et se termine avec le code de sortie 0. Avec --dry-run, --yes n’a pas besoin de --disk.

Sur une VM Compute Engine, le plan avertit que l’environnement invité de Google disparaît : gcloud compute ssh, OS Login et les clés SSH des métadonnées cessent de fonctionner, et la console série reste.

Ce que reçoit le nouveau système

Le nouveau système reçoit :

• L’identité de l’appareil — celle du fichier .flock, qui va sur la partition IRONFLOCKOS. L’appareil s’enrôle avec ce fichier à son premier démarrage.
• Le réseau — celui de la carte réseau par laquelle est passé le téléchargement de l’image, vers le serveur de téléchargement ou vers le proxy. Lorsque la base de téléchargement est le miroir de l’appliance du fichier .flock et que le miroir a répondu d’une manière ou d’une autre à la demande du catalogue (un 404 aussi), c’est à la place la carte de la connexion au miroir, d’où que viennent les fichiers : l’appliance est l’endroit où le nouvel appareil se connecte. Un câble avec DHCP ne nécessite rien. Une adresse statique (des adresses sans durée de vie, des passerelles et des routes définies à la main, les serveurs DNS de systemd-resolved ou de /etc/resolv.conf) devient un profil NetworkManager qui reconnaît la carte à son adresse MAC permanente. Une adresse statique à côté de DHCP ou de SLAAC conserve DHCP et ajoute l’adresse statique. En WiFi, le réseau du fichier .flock ne nécessite rien ; un autre réseau doté d’un profil NetworkManager WPA-PSK ou WPA3-SAE, masqué ou non, reçoit ce profil. Les adresses des autres cartes ne sont pas reprises, et le plan émet un avertissement.
• Le proxy — le proxy du téléchargement devient le paramètre de proxy d’IronFlockOS (proxy.conf sur la partition IRONFLOCKOS), avec l’utilisateur et le mot de passe, ainsi que no_proxy. Un proxy sur la machine elle-même (127.0.0.1) est refusé, car le nouveau système ne l’a pas. Il en va de même d’un miroir qui répond sur la boucle locale de la machine : un fichier .flock dont l’update_url nomme localhost, comme l’a l’agent sur l’hôte même de l’appliance. Une URL de proxy contenant des caractères que proxy.conf n’accepte pas est refusée, et le refus nomme la partie concernée.
• SSH — le compte du propriétaire du projet avec la clé du fichier .flock, comme sur chaque appareil IronFlockOS.

IronFlockOS 0.15.0 et les versions ultérieures prennent les profils réseau et le paramètre de proxy sur la partition IRONFLOCKOS. Avec l’image d’une version plus ancienne, une machine dont le réseau nécessite un profil, ou dont le téléchargement passe par un proxy, est refusée ; le refus nomme la carte, son adresse statique ou son WiFi, et ce qu’il faut faire à la place.

Le nouveau système ne reçoit ni les comptes utilisateur de l’ancien système avec leurs mots de passe et leurs clés SSH, ni les clés d’hôte SSH (les clients SSH voient une nouvelle clé d’hôte), ni les paquets, les paramètres et les données. Les apps de l’appareil reviennent depuis IronFlock ; leurs données sur cette machine, non.

La question

La commande vous demande de taper le nom d’hôte court de la machine, que la question affiche. Sur une machine dont le noyau a le nom complet (les images Ubuntu de Compute Engine), le nom complet est également accepté. Toute autre saisie, Entrée seule comprise, vaut un non : code de sortie 4. Voir Questions et confirmation.

--yes ne répond à la question que lorsque --disk nomme le disque. Sur un système chiffré, --yes nécessite aussi --allow-unencrypted, sinon la commande se termine avec le code de sortie 4. Sans terminal, et avec --json, la question ne peut pas être posée : sans --yes, la commande se termine avec le code de sortie 4.

Après la question : préparation et passage de relais

Rien n’est écrit sur le disque avant le redémarrage. La commande prépare le remplacement en mémoire :

1. Un système de fichiers en mémoire reçoit l’image : le fichier du cache de os flash lorsque le plan l’y a lu, sinon un téléchargement (affiché comme Downloading), vérifié par rapport au catalogue signé (Checking). L’image est décompressée une fois (Preparing) et comparée à ce que le plan a lu. Les fichiers pour la partition IRONFLOCKOS sont préparés.
2. Une option de démarrage pour IronFlockOS va en fin d’ordre de démarrage du firmware, derrière celle du système en cours d’exécution. Tant que le disque n’est pas écrit, le système en cours d’exécution démarre toujours en premier.
3. Staged: sur stderr nomme la nouvelle option de démarrage et les options de démarrage de l’ancien système, qui sont supprimées après l’écriture.
4. La commande passe le relais : la machine redémarre immédiatement ou, lorsque la commande s’exécute dans une session SSH (y compris via sudo et --host), dix secondes après la fin de la commande, afin que le résultat parvienne d’abord à la session. Stdout indique Handed over: ..., et la commande se termine avec le code de sortie 0.

Ctrl-C ou SIGTERM entre la question et le passage de relais annule la préparation : la commande se termine avec le code de sortie 130, et la machine est telle qu’elle était. Après la question, un terminal ou une session SSH perdus n’arrêtent plus la commande : la préparation continue, et le passage de relais et le redémarrage ont lieu. Une fois que le relais est passé au redémarrage, Ctrl-C met fin à la commande, et le redémarrage a lieu malgré tout.

Le redémarrage et l’écriture

À la fin de l’arrêt, ironflock écrit l’image depuis la mémoire sur le disque. La console de la machine affiche ses lignes, qui commencent par ironflock-install:. La machine démarre ensuite IronFlockOS, et l’appareil apparaît dans IronFlock en une dizaine de minutes environ. Le journal de l’écriture est ironflock-install.log sur la partition IRONFLOCKOS du nouveau système.

Lorsque l’ancien système redémarre

Avant d’écrire, ironflock vérifie le disque une fois de plus. Lorsqu’une condition n’est pas remplie, l’ancien système redémarre, inchangé : le disque est occupé ou en lecture seule, ce n’est pas le disque du plan, l’image préparée est endommagée, ou les étapes précédant l’écriture prennent plus de deux minutes. La raison se trouve dans la variable EFI IronFlockInstall. ironflock status l’affiche dans sa ligne OS install:, sans root :

System:        Debian GNU/Linux 13 (trixie)
  OS install:  'ironflock os install' stopped at 2026-11-11T10:00:00Z before it wrote the disk: the disk /dev/sda is not the plan's: its size changed from 64.0 GB to 32.0 GB; nothing was changed, and this system runs as before

# Sur la machine
ironflock status
# Depuis un autre ordinateur
ironflock --host admin@machine status
# Sans ironflock : affiche l'étape, l'heure et la raison
tail -c +5 /sys/firmware/efi/efivars/IronFlockInstall-7b2f7cb6-eb8f-4acd-b7fd-e92df1a035a0

Via --host

ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes exécute la commande sur cette machine comme toute commande s’exécute via --host : le binaire et le fichier .flock y sont transmis, les vérifications, le plan et la question s’y exécutent, et leur sortie revient. Le dossier contenant le binaire et la copie du fichier .flock est supprimé lorsque la commande s’y termine, y compris après un refus ou une interruption. --dry-run ne modifie rien sur la machine en dehors de ce dossier.

Le redémarrage a lieu dix secondes après la fin de la commande : son résultat parvient donc d’abord de votre côté. Après la question, une connexion perdue n’arrête plus la commande là-bas : lorsque la connexion est coupée, la commande de votre côté se termine avec le code de sortie 255 et indique que la machine continue d’elle-même.

Après le passage de relais, la commande attend, jusqu’à 15 minutes, que la machine revienne sous IronFlockOS :

• Toutes les 15 secondes, elle se connecte à la même adresse en tant qu’utilisateur SSH du fichier .flock, avec la clé du fichier .flock. La clé va dans un fichier d’un nouveau dossier que vous seul pouvez lire, et le dossier est supprimé à la fin de l’attente. La clé ne va pas dans l’agent SSH.
• Elle accepte la clé d’hôte du nouveau système sans l’écrire nulle part : known_hosts reste tel quel.
• Elle lit ce qu’exécute le système et si l’agent de l’appareil s’est connecté à IronFlock depuis le démarrage.
• Entre-temps, elle demande à l’ancien système, uniquement avec une clé d’hôte que contient known_hosts, la variable EFI IronFlockInstall : une machine qui revient avec son ancien système met immédiatement fin à l’attente.

L’attente se termine avec le code de sortie 0 lorsque la machine tourne sous IronFlockOS et que l’agent de l’appareil est connecté. Elle se termine avec 1 lorsque la machine tourne sous IronFlockOS sans agent connecté, est revenue avec son ancien système, ou n’a pas répondu en tant qu’IronFlockOS dans les 15 minutes. Une adresse que DHCP a changée met la vérification en échec ; le message renvoie alors à l’appareil dans IronFlock et à la console de la machine. Ctrl-C met fin à l’attente avec 130, et la machine continue d’elle-même.

L’attente ne peut pas savoir quelle machine répond à l’adresse, car la clé d’hôte du nouveau système est nouvelle pour votre côté. La preuve est l’appareil affiché comme connecté dans IronFlock.

L’attente a besoin du fichier .flock de votre côté. Sans -c, ou avec un fichier .flock qui ne met en place aucun utilisateur SSH, la commande se termine avec le code de sortie 2 avant que quoi que ce soit ne soit transmis à la machine, sauf si vous donnez --no-wait. --no-wait passe le relais et se termine avec le code de sortie de la commande sur la machine.

Secure Boot

Avec Secure Boot activé, la commande vérifie que le firmware démarrera la chaîne de démarrage de l’image, shim puis GRUB :

• une signature du shim de l’image remonte, par les certificats qui l’accompagnent, jusqu’à un certificat de la base de données des signatures du firmware (db), et la base des signatures interdites (dbx) n’en révoque aucun ; ou db liste le hash de shim.
• ni dbx ni la liste d’interdiction de shim sur cette machine (MokListX) ne listent le shim ou le GRUB de l’image, ni un certificat avec lequel GRUB est signé.
• le niveau SBAT de la machine (SbatLevelRT) ne révoque ni shim ni GRUB.

Lorsque le firmware ne démarrerait pas l’image, la commande refuse. Vous pouvez désactiver Secure Boot dans la configuration du firmware : IronFlockOS démarre aussi sans. Sur un système qui n’a pas démarré via shim, le plan avertit que le niveau SBAT et MokListX n’ont pas été vérifiés. La commande ne vérifie pas la valeur de la signature de shim et n’examine pas le noyau ; le catalogue signé s’en porte garant. Avec --json, machine.secure_boot.ca nomme le certificat de db auquel remonte la signature de shim, par exemple Microsoft UEFI CA 2023.

Exemples

# Afficher le plan pour l'appareil de l'agent installé, sans rien modifier
sudo ironflock os install --dry-run
# Le plan pour un nouvel appareil, en JSON
sudo ironflock os install -c device.flock --dry-run --json
# Remplacer le système sans question
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# Depuis un autre ordinateur, en attendant que l'appareil soit en ligne
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

Résultat

Le plan de sudo ironflock os install -c device.flock --dry-run, sur stderr :

IronFlockOS catalog of 2026-11-20T09:00:00Z, signed with key 036ef3bd.
Machine:      debian-vm, Debian GNU/Linux 13 (trixie), amd64, UEFI without Secure Boot
Disk:         /dev/sda: Google PersistentDisk, 21.5 GB, serial persistent-disk-0 (the EFI system partition at /boot/efi is on it); it holds plain partitions
Image:        ironflockos-amd64-efi-base 0.15.0, 4.6 GB unpacked
Image file:   https://instance-registry.ironflock.com/dl/ironflockos/0.15.0/ironflockos-amd64-efi-base-0.15.0.img.gz (662.9 MB), downloaded into memory and checked against the catalog
Memory:       1.7 GB available, 1.2 GB needed
Everything on /dev/sda is lost: this system, its packages and settings, and all data. There is no way back.
The new system gets:
  - the identity of the device kitchen-pc, from device.flock
  - the network: ens4 by cable with DHCP, which needs nothing carried over
  - SSH: the account operator with the .flock's key, as every IronFlockOS device has it
It does not get:
  - the user accounts of this system, their passwords and SSH keys
  - the SSH host keys: clients see a new host key
  - the packages, settings and data of this system: the device's apps come back from IronFlock, their data on this machine does not
Then the machine restarts, writes IronFlockOS from memory at the end of its shutdown and starts it; the device appears in IronFlock within about ten minutes.
Warning: drivers not checked: whether IronFlockOS ironflockos-amd64-efi-base 0.15.0 drives virtio-pci of the disk (/sys/devices/pci0000:00/0000:00:03.0), virtio-pci of the network card (/sys/devices/pci0000:00/0000:00:04.0) is not known: the hardware list of this release does not name the drivers built into its kernel
Warning: this is a Compute Engine VM: it keeps its address, but loses Google's guest environment, so 'gcloud compute ssh', OS Login and metadata SSH keys stop working; the serial console stays. With Shielded VM's integrity monitoring on, the first boot of IronFlockOS fails its check until the baseline is learned again
Dry run: nothing was changed.

L’exécution de sudo ironflock os install -c device.flock --disk /dev/sda --yes affiche le même plan, puis la préparation et le passage de relais :

Staging IronFlockOS in memory: nothing is written to /dev/sda before the restart, and Ctrl-C until then leaves the machine as it was.
Downloading: 100% (662.9 MB of 662.9 MB)
Checking: 100% (662.9 MB of 662.9 MB)
Preparing: 100% (662.9 MB of 662.9 MB)
Staged: the image is in memory and checked against the catalog and the plan; the boot option Boot0003 for IronFlockOS is at the end of the boot order, and goes first after the write.
The old system's boot option Boot0001 (debian) is deleted after the write.
Handed over: the machine restarts now, writes IronFlockOS onto /dev/sda at the end of its shutdown (the console shows it) and starts it; the device kitchen-pc appears in IronFlock within about ten minutes. If it does not, see the machine's console; a machine that comes back with its old system has the reason in its EFI variable IronFlockInstall.

Avec --json, le résultat est le plan sous la forme d’un objet JSON : immédiatement avec --dry-run ; sans cette option, après le passage de relais, avec dry_run à false et staging ; et via --host, après l’attente, avec en plus wait. Stderr reçoit la progression sous forme de lignes JSON et rien d’autre (Sortie et JSON). Aucun champ ne contient de secret : les fichiers pour la partition IRONFLOCKOS sont nommés avec leur taille, et les URL de proxy sont affichées sans le mot de passe. Le résultat de la simulation ci-dessus, avec des sauts de ligne ajoutés (la commande écrit une seule ligne ; ... marque ce que l’exemple omet) :

{"dry_run":true,
 "machine":{"hostname":"debian-vm","os":"Debian GNU/Linux 13 (trixie)","architecture":"amd64","secure_boot":{"enabled":false},"memory_available":1651179520,"memory_needed":1220587675},
 "disk":{"device":"/dev/sda","devnum":"8:0","size":21474836480,"model":"Google PersistentDisk","serial":"persistent-disk-0","sysfs":{"vpd83":"0:persistent-disk-0"},"guid":"a6c1e3f4-0b2d-4c8e-9f1a-2b3c4d5e6f70","found_by":"esp","esp":"/boot/efi","storage":["partitions"],"encrypted":false},
 "image":{"image_id":"ironflockos-amd64-efi-base","version":"0.15.0",...,"raw_size":4564471808,"min_disk_size":10737418240,"guid":"...","ironflockos":{"guid":"d53fd016-10da-40c6-8d85-a4eae33538af","start":1048576,"size":268435456},"shim_sha256":"...","head_size":269484032,"head_sha256":"..."},
 "device":"kitchen-pc","device_file":"device.flock","flock":"/home/admin/device.flock",
 "network":{"interface":"ens4","mac":"42:01:0a:84:00:02","kind":"wired","addressing":"dhcp","carried":"nothing","addresses":[],"gateways":[],"dns":[]},
 "proxy":null,"ssh_user":"operator","files":[{"path":"device.flock","size":1234}],
 "drivers":{"checked":false,"devices":[...]},"not_carried_over":[...],"delayed_reboot":false,"warnings":[...]}

Cas de refus

La commande refuse avec le code de sortie 3, et rien n’est modifié, dans ces cas :

• un conteneur, un système sans systemd en PID 1, IronFlockOS (os update y installe une version), ReswarmOS.
• le BIOS, l’UEFI 32 bits, une architecture sans image, des variables EFI qui ne sont pas montées (le refus nomme la commande mount) ou qui sont montées en lecture seule (il nomme mount -o remount,rw).
• un Secure Boot qui ne démarrerait pas le shim ou le GRUB de l’image.
• un disque que la commande ne parvient pas à déterminer (nommez-le avec --disk), un --disk qui n’est pas le disque à partir duquel le système a démarré, une partition, aucun disque ; un disque qui n’est pas un disque entier à part entière, ou que lsblk ne liste pas ; un disque sans GPT.
• un système de fichiers racine sur un autre disque, réparti sur plusieurs disques, sur ZFS ou sur aucun disque (un système live).
• des secteurs logiques d’une autre taille que 512 octets, un disque trop petit, une pile de stockage que la commande ne sait pas défaire, un système de fichiers btrfs ou un groupe de volumes LVM réparti sur ce disque et sur un autre, un autre disque portant les noms de partition d’IronFlockOS.
• trop peu de mémoire.
• un réseau que la commande ne reprend pas, un proxy sur la machine elle-même ou le miroir de l’appliance sur la boucle locale de la machine, un proxy avec une image qui n’accepte pas proxy.conf ou avec des caractères que proxy.conf n’accepte pas, un profil NetworkManager actif qui ne peut pas être lu.
• une liste du matériel de la version qui montre que l’image n’a pas de pilote pour un périphérique du disque ou de la carte réseau.
• un ip d’iproute2 qui ne s’exécute pas : le réseau ne peut pas être lu.
• après la question, avant que la préparation ne modifie quoi que ce soit : un disque qui n’est plus celui du plan, un /run/initramfs qui est déjà un point de montage, un plan qui ne peut pas être exécuté tel quel.

Ces cas sont des lignes de commande erronées, code de sortie 2, vérifiés avant toute modification :

• --yes sans --disk, sauf avec --dry-run.
• pas de -c sur une machine sans agent de l’appareil installé ; via --host sans --no-wait, pas de -c ou un fichier .flock qui ne met en place aucun utilisateur SSH.
• une --image que le catalogue ne contient pas, une image pour une autre cible que celle de la machine, ou la clé d’installation (qu’écrit os flash --installer).
• une URL de proxy avec mot de passe, ainsi que les autres options de proxy que refuse agent install.
• plusieurs machines (--host donné plusieurs fois, --hosts).

Cas d’échec

La commande échoue avec le code de sortie 1, et rien n’est modifié, dans ces cas :

• le fichier .flock n’est pas valide, ou sa clé SSH n’est pas valide.
• le catalogue ne se vérifie pas ou ne peut pas être récupéré, comme pour os images ; avec le miroir de l’appliance, ni depuis le miroir ni depuis le cloud.
• le début du fichier image ne peut pas être téléchargé (getting the image ...), avec le miroir de l’appliance ni depuis le miroir ni depuis le cloud, ou ce n’est pas une image IronFlockOS telle que la commande les connaît. Lorsque le catalogue provient du cloud parce que le miroir n’en a fourni aucun, l’erreur commence par l’avertissement du catalogue, the appliance's mirror ... gives no IronFlockOS catalog now (...), et nomme les deux serveurs.
• l’adresse locale du téléchargement n’appartient à aucune carte réseau ; la table des montages, les périphériques bloc ou la mémoire ne peuvent pas être lus ; les variables EFI ne s’analysent pas.
• après la question : le fichier image n’est pas celui du catalogue ou pas ce que le plan a lu (le message nomme les deux valeurs), le téléchargement échoue, le firmware n’accepte pas l’option de démarrage, ou le redémarrage ne peut pas être lancé. La préparation est annulée. Lorsque l’annulation échoue elle aussi, le message demande un redémarrage, qui supprime ce qui reste.

Aucune URL n’est affichée avec l’utilisateur et le mot de passe qu’elle peut contenir.

Codes de sortie

La signification de chaque code pour toutes les commandes figure dans Options, sortie et codes de sortie.