Mise à jour, retour arrière et réinitialisation

Ces commandes s’occupent d’un appareil qui tourne sous IronFlockOS. os update installe une version, os rollback revient à la version qui tournait auparavant, et os reset remet l’appareil dans l’état d’un appareil fraîchement écrit.

Slots racine et partition de données

Le disque d’un appareil IronFlockOS contient :

• Deux slots racine, A et B — chacun contient un système IronFlockOS complet. L’un tourne. L’autre contient le système qui tournait auparavant, ou encore rien sur un appareil fraîchement écrit. RAUC, l’outil de mise à jour qu’utilise IronFlockOS, écrit une version dans le slot qui ne tourne pas et enregistre quel slot démarre ensuite.
• La partition de données (/data) — les apps et leurs données, ainsi que l’agent de l’appareil avec sa copie du fichier de configuration de l’appareil (.flock). Les deux systèmes l’utilisent : une mise à jour ou un retour arrière laisse donc les apps et leurs données telles quelles.
• La partition IRONFLOCKOS (montée sous /boot/efi) — une petite partition FAT. L’appareil s’enrôle avec un fichier .flock qu’il y trouve au démarrage, et os reset y écrit sa demande.

Un nouveau système doit faire ses preuves : l’appareil le conserve une fois que l’agent de l’appareil a joint IronFlock depuis ce système et l’a marqué comme bon. Un système qui ne démarre pas, ou qui n’y parvient pas, est abandonné au redémarrage suivant au profit de celui qui tournait auparavant. ironflock status affiche les slots :

System:        IronFlockOS 0.13.0 (amd64-efi, base)
  Image:       ironflockos-amd64-efi-base (build 20261105T120000Z-g1a2b3c4)
  Slot A:      inactive, good
  Slot B:      booted, good, 0.13.0 installed 2026-11-05T14:00:00Z
  Next boot:   slot B

Où s’exécutent les commandes

Les trois commandes s’exécutent sur un appareil qui tourne sous IronFlockOS, nécessitent root et posent une question avant d’agir. Sur un autre système (macOS, un Linux qui n’est pas IronFlockOS, la clé d’installation d’IronFlockOS), elles se terminent avec le code de sortie 3.

• Sur l’appareil — les versions d’IronFlockOS postérieures à 0.15.0 embarquent ironflock. Connectez-vous à l’appareil et exécutez la commande avec sudo.
• Depuis un autre ordinateur — les versions d’IronFlockOS jusqu’à 0.15.0 n’embarquent pas ironflock. Exécutez la commande depuis un ordinateur Linux ou macOS avec --host, sous l’utilisateur SSH de l’appareil : le compte que le fichier .flock met en place pour le propriétaire du projet, operator dans les exemples. --host copie ironflock sur l’appareil pour l’exécution et y exécute la commande via sudo.

ironflock --host operator@kitchen-pc os update --reboot --yes

os update et os rollback s’exécutent sur plusieurs appareils à la fois (--host donné plusieurs fois, ou --hosts) lorsque --yes est donné. os reset s’exécute sur un seul appareil à la fois ; sur plusieurs, la commande se termine avec le code de sortie 2. Les options globales sont décrites dans Options, sortie et codes de sortie.

ironflock os update

Installe la version d’IronFlockOS que propose le canal de l’appareil dans le slot racine qui ne tourne pas. Le nouveau système démarre au prochain redémarrage, ou immédiatement avec --reboot.

ironflock os update [flags]

Le canal de l’appareil est celui que suit son agent de l’appareil, d’après l’environment du fichier .flock de l’agent : test sur la plateforme de test d’IronFlock et production sinon. Lorsque le catalogue ne contient pas le canal de l’appareil, c’est production. La base de téléchargement provient de --download-base, puis de IRONFLOCK_DL_BASE, puis du serveur de mise à jour (update_url) du fichier .flock de l’agent (sur un appareil d’une IronFlock Appliance, le miroir de téléchargement de l’appliance, qui est tout ce qu’un tel appareil peut joindre) ; à défaut, c’est le cloud IronFlock.

Ce que fait la commande, dans cet ordre :

1. Elle lit le catalogue IronFlockOS signé et prend le bundle de mise à jour de l’image de l’appareil dans la version du canal (ou de --version).
2. Elle indique quelle version tourne dans quel slot, quelle version elle installe, dans quel slot, ce que ce slot contient maintenant, et la taille du téléchargement. Elle pose ensuite la question.
3. Elle télécharge le bundle dans /var/cache/ironflockos, sur la partition de données. Un téléchargement interrompu est repris. Le fichier n’est utilisé que lorsque sa taille et son SHA-256 sont ceux du catalogue.
4. Elle fait installer le bundle par RAUC dans le slot qui ne tourne pas. RAUC vérifie la signature du bundle, écrit le slot et en fait celui qui démarre ensuite. Ce que le slot contenait auparavant est écrasé. Le bundle est supprimé une fois installé.
5. Avec --reboot, elle redémarre l’appareil sur le nouveau système.

Le système en cours d’exécution reste tel quel jusqu’au redémarrage. Les apps et leurs données restent. Le slot qui tourne maintenant conserve sa version, et l’appareil y revient lorsque la nouvelle version ne démarre pas ou ne joint pas IronFlock.

Rien n’est installé, et le code de sortie est 0, lorsque l’appareil exécute déjà la version, et lorsque la version est déjà installée dans l’autre slot et attend le redémarrage. Dans le second cas, --reboot pose la question et redémarre l’appareil.

# Installer la version du canal de l'appareil ; elle démarre au prochain redémarrage
sudo ironflock os update
# L'installer et redémarrer dessus, sans question
sudo ironflock os update --reboot --yes
# Installer une version plus ancienne du catalogue
sudo ironflock os update --version 0.13.0

La progression va sur stderr : le téléchargement et sa vérification, puis chaque étape que nomme RAUC. Ce qu’affiche os update --yes sur un appareil qui exécute 0.13.0 dans le slot A :

Download base: https://instance-registry.ironflock.com/dl (from default)
IronFlockOS catalog of 2026-11-20T09:00:00Z, signed with key 036ef3bd: production 0.14.0, test 0.14.0.
This device runs IronFlockOS 0.13.0 (ironflockos-amd64-efi-base) from slot A.
IronFlockOS 0.14.0, the release of the production channel, is installed into slot B, which holds nothing yet:
  - the bundle (580.2 MB) is downloaded into /var/cache/ironflockos
  - RAUC checks its signature and writes it into slot B
  - it starts with the next restart
Slot A keeps IronFlockOS 0.13.0: the device goes back to it when 0.14.0 does not start or does not reach IronFlock. Apps and their data stay.
Downloading: 0% (0 B of 580.2 MB)
...
Installing IronFlockOS 0.14.0 into slot B.
Installing:   0% Installing
...
Installing:  82% Copying image to rootfs.1
...
Installing: 100% Installing done.
IronFlockOS 0.14.0, the release of the production channel, is installed in slot B and starts with the next restart ('sudo reboot').

Avec --json, l’installation est la phase de progression installing, en pourcentage. Le résultat de os update --reboot --yes --json :

{"action":"installed","image":"ironflockos-amd64-efi-base","channel":"production","version":"0.14.0","running_version":"0.13.0","slot":"B","up_to_date":false,"reboot":true}

Refuse, avec le code de sortie 3, dans ces cas :

• sans root, sur une machine qui ne tourne pas sous IronFlockOS, et sur la clé d’installation.
• RAUC installe déjà un bundle, lancé par IronFlock Studio via l’agent ou par un autre appel. RAUC en installe un seul à la fois.
• la version n’a pas de bundle pour l’image de l’appareil.
• la version est plus ancienne que celle qui tourne, sauf si --version la nomme. Lorsque l’autre slot contient cette version, le message nomme os rollback.
• /var/cache/ironflockos n’a pas l’espace nécessaire pour ce qui reste à télécharger. Le message liste les bundles des mises à jour antérieures présents dans le dossier, que vous pouvez supprimer.

Lignes de commande erronées, code de sortie 2 : --channel et --version ensemble, une version qui n’en est pas une, un canal ou une version que le catalogue ne contient pas.

Échoue, avec le code de sortie 1, lorsque : le catalogue ne se vérifie pas ou ne peut pas être lu ; le téléchargement s’interrompt (ce qui est arrivé reste dans /var/cache/ironflockos, et la même commande le reprend) ; le téléchargement n’est pas le fichier du catalogue ; RAUC refuse le bundle ou ne parvient pas à l’installer. L’erreur donne la raison de RAUC. Lorsque RAUC avait commencé à écrire, le slot est marqué comme défectueux et ne contient aucun système utilisable, et l’appareil continue de démarrer le système qui tourne. Le bundle reste dans le cache pour la tentative suivante.

Ctrl-C pendant le téléchargement, ou juste après, met fin à la commande avec le code de sortie 130 avant que quoi que ce soit ne soit installé ou redémarré ; la même commande reprend le téléchargement. Une question qui reçoit la réponse non met fin à la commande avec le code de sortie 4.

ironflock os rollback

Fait de l’autre slot racine celui qui démarre, et redémarre l’appareil sur celui-ci : retour au système qui tournait avant la dernière mise à jour. Utilisez cette commande pour un système qui démarre mais se comporte mal. Un système qui ne démarre pas, ou qui ne joint pas IronFlock, est abandonné par IronFlockOS lui-même au redémarrage suivant.

ironflock os rollback [flags]

La commande n’a pas d’options propres. Elle redémarre toujours l’appareil : un retour arrière sans redémarrage ne changerait rien jusqu’au redémarrage suivant.

Seul un slot dont le système a démarré sur cet appareil est éligible :

• un slot dont le système a été marqué comme bon pendant qu’il tournait, et qui n’a pas été réessayé depuis. Un slot qui a été essayé et jamais marqué comme bon n’est pas éligible.
• le slot avec lequel l’appareil a été écrit (A), tant que rien n’y a été installé et qu’il n’a pas été marqué comme défectueux.

Les apps et leurs données restent, car les deux systèmes utilisent la même partition de données. Le slot qui tournait conserve sa version. Après le redémarrage, le système plus ancien doit de nouveau faire ses preuves : l’appareil le conserve une fois que l’agent de l’appareil a joint IronFlock depuis ce système. Sur une machine UEFI, un slot qui y est déjà parvenu auparavant est aussi conservé une fois qu’il a tourné pendant deux minutes. D’ici là, un redémarrage peut ramener le système plus récent. IronFlock Studio propose de nouveau la version du canal, et os update l’installe.

# Revenir au système de l'autre slot, après une question
sudo ironflock os rollback
# Sans question
sudo ironflock os rollback --yes

Ce qu’affiche os rollback --yes sur un appareil qui exécute 0.14.0 dans le slot B :

This device runs IronFlockOS 0.14.0 from slot B.
Slot A holds IronFlockOS 0.13.0, which ran on this device before. The rollback makes slot A the one that starts and restarts the device now.
Slot B keeps IronFlockOS 0.14.0. Apps and their data stay: both systems use the same data partition.
The device keeps IronFlockOS 0.13.0 once it has proven itself again (the device agent reaches IronFlock from it); until then a restart can bring back 0.14.0.
Rolled back to IronFlockOS 0.13.0 in slot A: the device restarts now.

Avec --json, slot et version sont le slot qui démarre et sa version (vide lorsqu’elle ne peut pas être lue), from_slot et from_version le système qui tournait :

{"action":"rolled_back","slot":"A","version":"0.13.0","from_slot":"B","from_version":"0.14.0"}

Refuse, avec le code de sortie 3 et en indiquant pourquoi, dans ces cas :

• sans root, sur une machine qui ne tourne pas sous IronFlockOS, sur la clé d’installation, et pendant que RAUC installe un bundle.
• l’appareil a un chargeur d’amorçage que la commande ne connaît pas : elle connaît GRUB (machines UEFI) et celui du Raspberry Pi.
• l’autre slot ne contient encore rien (un appareil fraîchement écrit), contient un système qui a été essayé et pas marqué comme bon, ne contient aucun système utilisable parce que son installation ne s’est pas terminée, ou est marqué comme défectueux.
• l’autre slot attend le prochain redémarrage, après une mise à jour qui a été installée ou un retour arrière qui n’a pas redémarré. sudo reboot le démarre, et sudo rauc status mark-bad other l’écarte.

Échoue, avec le code de sortie 1, lorsque : RAUC ne parvient pas à faire du slot celui qui démarre (rien n’a été modifié) ; le redémarrage échoue (le slot démarre alors au prochain redémarrage). Une question qui reçoit la réponse non met fin à la commande avec le code de sortie 4.

ironflock os reset

Demande la réinitialisation d’usine d’IronFlockOS et redémarre l’appareil. Au démarrage suivant, l’appareil efface ce qu’ont laissé son propriétaire, ses apps et l’enrôlement, et démarre comme un appareil fraîchement écrit ; avec -c, il s’enrôle en tant qu’appareil d’un nouveau fichier .flock.

ironflock os reset [-c <new.flock>] [flags]

IronFlockOS 0.15.0 est la première version dotée de la réinitialisation d’usine. Sur une version plus ancienne, la commande refuse ; os update installe une version plus récente.

La réinitialisation efface, sur la partition de données et dans les deux slots racine :

• les apps avec leurs données, ainsi que les conteneurs, les images et les volumes de Docker.
• l’identité de l’appareil chez IronFlock : l’agent de l’appareil avec sa copie du fichier .flock, sa base de données et son service. Le nom d’hôte redevient ironflockos, et l’identifiant de machine est recréé.
• l’utilisateur SSH et tous les autres comptes utilisateur, avec leurs répertoires personnels et leurs règles sudo.
• les journaux, les clés d’hôte SSH, les mises à jour téléchargées et le réglage temps réel.
• sans --keep-network : les profils réseau (dont le WiFi), le paramètre de proxy (proxy.conf) et le paramètre PTP (ptp.conf).

Elle conserve les systèmes IronFlockOS des slots racine, celui qui tourne et l’autre lorsqu’il contient un système, ainsi que l’enregistrement que RAUC en tient : les mises à jour et les retours arrière fonctionnent donc comme avant. Avec --keep-network, elle conserve aussi les paramètres réseau ci-dessus. Elle n’annule pas ce qui a été modifié à la main dans le système lui-même, comme un paquet ou un fichier dans /etc ; écrire de nouveau IronFlockOS sur le disque avec os flash le fait.

Ce que fait la commande, dans cet ordre :

1. Elle refuse ce que l’appareil ne ferait pas comme demandé (voir ci-dessous), et vérifie le fichier .flock de -c : un fichier nommé *.flock d’au plus 5 Mio, un objet JSON avec un secret et un device_key, dont le name et le serial_number sont des noms simples.
2. Elle indique sur stderr ce qui disparaît, ce qui reste, comment l’appareil revient et ce qu’a fait sa dernière réinitialisation, puis vous demande de taper le nom de l’appareil : son nom dans le fichier .flock de l’agent, tel que l’affiche ironflock status, ou le nom d’hôte d’un appareil qui n’est pas enrôlé. Toute autre saisie, Entrée seule comprise, vaut un non.
3. Elle écrit la demande sur la partition IRONFLOCKOS, une fois que la propre vérification de l’appareil l’a acceptée. Une demande déjà présente est remplacée ; celle-ci est une nouvelle demande, avec ses propres trois tentatives.
4. Avec -c, elle supprime tous les autres fichiers .flock de la partition, car l’appareil s’enrôle avec le plus récent, et y écrit le nouveau fichier .flock. Si cela échoue, la demande est de nouveau supprimée.
5. Elle redémarre l’appareil. Au démarrage suivant, l’appareil se réinitialise, en quelques secondes (en quelques minutes sur une carte SD lente), redémarre encore une fois et démarre comme un appareil fraîchement écrit, avec de nouvelles clés d’hôte SSH.

Après la réinitialisation, avec -c, l’appareil s’enrôle en tant qu’appareil de ce fichier .flock et peut être joint via SSH sous son utilisateur SSH. Sans -c, il attend un fichier .flock sur sa partition IRONFLOCKOS et n’est joignable que sur sa console : il n’a ni utilisateur SSH ni connexion à IronFlock. Une connexion SSH à l’appareil, y compris celle de --host, prend fin avec le redémarrage ; sans -c, aucune ne revient.

Note : Si vous ne joignez l’appareil que par le réseau, donnez le nouveau fichier .flock avec -c. Sans lui, quelqu’un doit se rendre auprès de l’appareil pour le remettre en ligne.

Une tentative qui échoue ne redémarre pas l’appareil : celui-ci démarre tel quel, et son prochain démarrage, déclenché par une personne ou par une mise à jour, fait une nouvelle tentative. Après trois tentatives échouées, la réinitialisation abandonne, et l’appareil démarre avec ce qui est présent. Avec ses anciennes données, il reste l’appareil qu’il était, en ligne avec son ancienne identité, et le fichier .flock et le paramètre de proxy venus avec la demande sont supprimés. Une demande terminée, menée à bien ou abandonnée, ne se déclenche plus jamais, dans aucun slot et après aucune mise à jour. Un disque qui ne répond pas peut retenir une tentative jusqu’à 25 minutes. ironflock status affiche une réinitialisation échouée ou abandonnée dans sa ligne Last reset:.

Avant de poser la question, la commande affiche la dernière réinitialisation que l’appareil a enregistrée :

# Réinitialiser l'appareil ; il attend ensuite un fichier .flock
sudo ironflock os reset
# Le réinitialiser et en faire l'appareil de new-device.flock
sudo ironflock os reset -c new-device.flock
# Conserver les paramètres réseau, sans question
sudo ironflock os reset --keep-network --yes
# Depuis un autre ordinateur, sur IronFlockOS 0.15.0
ironflock --host operator@edge-01 os reset -c new-device.flock

Ce qu’affiche os reset -c kitchen-pi.flock sur l’appareil edge-01, dont la dernière réinitialisation a abandonné, avec le nom tapé à la question :

This device runs IronFlockOS 0.15.0 from slot B and is the IronFlock device edge-01.
The last factory reset of this device: gave up after 3 attempts at 2026-11-11T09:00:00Z: the data partition is not the partition named data on the disk of the root slot; /data holds the old data; left of the old owner: the data partition, the booted root slot, the other root slot; the device stayed the device it was, online with its old identity, and the .flock and proxy.conf that came with the request were removed.
What can be done: request the reset again, as this command does now, with three new attempts; or write IronFlockOS to the device's disk anew ('ironflock os flash'), which clears everything.
The factory reset restarts the device now. During the next boot the device resets itself, in seconds (minutes on a slow SD card), and restarts once more. It clears:
  - the apps with their data, and Docker's containers, images and volumes
  - the device's identity at IronFlock: the agent with its copy of the .flock and its database; the hostname goes back to ironflockos
  - the SSH user and every other user account, with their home folders
  - the logs, the SSH host keys and the downloaded updates
  - the network profiles (the WiFi among them), the proxy setting and the PTP setting
It keeps IronFlockOS 0.15.0 in slot B, which runs, and IronFlockOS 0.14.0 in slot A, so updates and rollbacks work as before.
It does not undo what was changed by hand in the system itself, such as a package or a file in /etc.
Then the device starts as a freshly written one with kitchen-pi.flock, which goes onto its IRONFLOCKOS partition: it enrolls as kitchen-pi and can be reached over SSH as operator, with the device key of that .flock and new SSH host keys.
An attempt that fails does not restart the device: it comes up as it is, and its next start tries again; after three failed attempts the reset gives up, and the device starts with what is there. 'ironflock status' shows a failed or given-up reset.
An SSH connection to the device, also the one of --host, ends with the restart.
? Type the device's name, edge-01, to reset it: edge-01
Factory reset requested: the device restarts now, resets itself and enrolls as kitchen-pi.

Le résultat de os reset --keep-network --yes --json :

{"action":"reset","device":"edge-01","keep_network":true}

Refuse, avec le code de sortie 3 et en indiquant pourquoi et quoi faire, dans ces cas :

• sans root, sur une machine qui ne tourne pas sous IronFlockOS, sur la clé d’installation, et pendant que RAUC installe un bundle.
• l’IronFlockOS de l’appareil n’a pas de réinitialisation d’usine : une version plus récente l’apporte, et os update l’installe.
• /boot/efi n’est pas la partition IRONFLOCKOS montée : rien n’y est monté, ou un système de fichiers autre que FAT.
• une réinitialisation a commencé : elle continue au prochain démarrage, et rien ne doit être modifié d’ici là. Le message indique la dernière tentative.
• sans -c, un fichier .flock se trouve sur la partition IRONFLOCKOS : après la réinitialisation, l’appareil s’enrôlerait avec lui au lieu d’en attendre un.
• le prochain démarrage ne serait pas celui du système en cours d’exécution marqué comme bon. Une mise à jour ou un retour arrière attend son redémarrage : sudo reboot le démarre, sudo rauc status mark-bad other l’écarte. Ou bien le système en cours d’exécution n’a pas encore été marqué comme bon : sudo rauc status mark-good le conserve, os rollback revient en arrière.
• la propre vérification de l’appareil n’accepte pas la demande : rien n’est demandé, et le message donne la raison de l’appareil.

Échoue, avec le code de sortie 1, dans ces cas :

• la table des montages ne peut pas être lue : la commande ne peut donc pas savoir si /boot/efi est la partition IRONFLOCKOS. Rien n’est écrit.
• le fichier .flock de -c n’est pas valide.
• la demande ou le fichier .flock ne peut pas être écrit, ou un autre fichier .flock ne peut pas être supprimé. La demande est retirée, et l’erreur dit ce qui a disparu.
• le redémarrage échoue. L’appareil se réinitialise alors à son prochain démarrage ; supprimer /boot/efi/factory-reset.conf et le fichier .flock de la partition IRONFLOCKOS annule la réinitialisation.

Ctrl-C, SIGTERM ou une session SSH perdue pendant que la commande écrit sa demande lui font retirer la demande : elle se termine avec le code de sortie 130, et l’appareil ne redémarre pas. Un nom mal tapé à la question met fin à la commande avec le code de sortie 4.

Les codes de sortie de toutes les commandes sont expliqués dans Options, sortie et codes de sortie. Via --host, le code de sortie 255 signifie que la connexion SSH a échoué.