Linux durch IronFlockOS ersetzen

ironflock os install ersetzt das Linux, von dem eine laufende Maschine gestartet ist, auf derselben Festplatte durch IronFlockOS und macht die Maschine zum IronFlock-Gerät einer Gerätekonfigurationsdatei (.flock). Sie führen den Befehl auf der Maschine selbst aus oder über SSH von einem anderen Computer aus.

Warnung: Alles auf der Festplatte, von der die Maschine gestartet ist, geht verloren: das laufende System, seine Pakete und Einstellungen, seine Benutzerkonten und alle Daten. Es gibt keinen Weg zurück. Führen Sie den Befehl zuerst mit --dry-run aus, und lesen Sie den Plan.

Wann Sie den Befehl verwenden

Verwenden Sie os install für eine Maschine, auf der bereits Debian, Ubuntu oder ein anderes Linux mit systemd läuft und die Sie nicht von einem USB-Stick starten können oder wollen: ein PC in einem Schaltschrank, eine virtuelle Maschine in einer Cloud, eine Maschine, die Sie nur über SSH erreichen. Mit --host führen Sie den Befehl von Ihrem eigenen Computer aus, auch von einem Mac, und er wartet, bis die Maschine als IronFlock-Gerät online ist.

Verwenden Sie einen anderen Befehl, wenn:

• Sie die Maschine von einem Laufwerk starten können — ironflock os flash schreibt IronFlockOS auf einen USB-Stick, eine SD-Karte oder eine externe Festplatte. Mit --installer schreibt es einen Installer-Stick, der IronFlockOS auf die interne Festplatte des PCs installiert, der von ihm startet. Der Installer-Stick ist auch der Ausweg für die meisten Maschinen, die os install ablehnt.
• die Maschine ein Raspberry Pi ist — os install installiert nur die Images für UEFI-Maschinen (Targets amd64-efi und arm64-efi). Schreiben Sie die SD-Karte des Raspberry Pi mit os flash.
• auf der Maschine bereits IronFlockOS läuft — os install lehnt sie ab. ironflock os update installiert dort ein anderes Release.
• Sie das Linux der Maschine behalten wollen — ironflock agent install verbindet die Maschine so, wie sie ist, mit IronFlock.

ironflock os install

Prüft die Maschine, zeigt den Plan der Ersetzung und fragt. Dann stellt der Befehl IronFlockOS im Arbeitsspeicher bereit und startet die Maschine neu, die IronFlockOS am Ende ihres Herunterfahrens auf die Festplatte schreibt und es startet.

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

Unter macOS endet der Befehl mit Exit-Code 3, bevor er sich irgendetwas ansieht; führen Sie ihn dort mit --host aus. Er läuft jeweils nur auf einer Maschine: Mehrfach angegebenes --host und --hosts enden mit Exit-Code 2. Die globalen Flags stehen unter Flags, Ausgabe & Exit-Codes.

Flags

Die Proxy-Flags funktionieren wie bei agent install. Ohne sie nimmt der Befehl HTTP_PROXY, HTTPS_PROXY und NO_PROXY aus der Umgebung. Eine Proxy-URL, die ein Passwort enthält, ist eine falsche Befehlszeile (Exit-Code 2); siehe Secrets.

Was die Maschine braucht

• Das System — Linux mit systemd als PID 1, etwa Debian oder Ubuntu, nicht in einem Container. IronFlockOS und ReswarmOS werden abgelehnt.
• Die Firmware — 64-Bit-UEFI auf amd64 oder arm64. Ihre EFI-Variablen sind eingehängt (efivarfs) und beschreibbar. BIOS und 32-Bit-UEFI werden abgelehnt. Secure Boot darf eingeschaltet sein, siehe Secure Boot.
• Die Festplatte — die Festplatte, von der die Firmware das System gestartet hat: eine eigenständige ganze Festplatte mit GPT (GUID-Partitionstabelle) und logischen Sektoren von 512 Bytes. Das Root-Dateisystem liegt auf dieser Festplatte und auf keiner anderen, direkt oder über LVM oder LUKS. Die Festplatte ist mindestens so groß wie die kleinste Festplatte des Images: die Größe, die der Katalog nennt, sonst 10 GiB oder 18 GiB für ein nvidia-Image.
• Arbeitsspeicher — verfügbarer Arbeitsspeicher (MemAvailable) für das komprimierte Image, die Binärdatei ironflock und 512 MiB mehr: eine Maschine mit etwa 2 GiB für das Image base.
• Werkzeuge — lsblk und ip aus iproute2.
• Das Netzwerk — der Download-Server ist erreichbar, direkt oder über einen Proxy, über ein Netzwerk, das das neue System verwenden kann (Was das neue System erhält). Für ein Gerät einer IronFlock-Appliance kann das der Download-Spiegel der Appliance sein (Woher die Dateien kommen).
• Die .flock-Datei — die von -c oder die des Geräte-Agenten, der auf der Maschine installiert ist.

Woher die Dateien kommen

Der Befehl braucht den signierten IronFlockOS-Katalog, das Image und die Hardwareliste des Images. Er nimmt sie:

1. von --download-base, sonst von IRONFLOCK_DL_BASE: nur von diesem Server.
2. Sonst vom Download-Spiegel der IronFlock-Appliance, die die .flock-Datei als ihren Update-Server nennt: ihre update_url, wenn das eine absolute http- oder https-URL ist, deren Host keiner der IronFlock-Cloud ist, etwa https://registry.<domain>/dl oder http://<host>:<port>/dl. Stderr sagt Download base: ... (from the device's .flock). So wird eine Maschine umgestellt, die die Appliance erreicht, aber nicht ironflock.com. Eine .flock-Datei der IronFlock-Cloud nimmt die Cloud.
3. Sonst aus der IronFlock-Cloud, https://instance-registry.ironflock.com/dl.

Mit dem Spiegel der Appliance kommen die Dateien zuerst vom Spiegel und, wo der Spiegel sie nicht liefert, aus der IronFlock-Cloud:

• Der Katalog, <mirror>/ironflockos/manifest.json — liefert der Spiegel gerade keinen (er ist nicht erreichbar, er antwortet mit einem Fehler, oder nur die aufbewahrte Kopie seines letzten Katalogs würde für ihn einspringen), kommt alles aus der Cloud, wie ohne Appliance. Ein Katalog, den der Spiegel liefert und der abgelehnt wird (seine Signatur, älter als die aufbewahrte Kopie, zu groß), lässt den Befehl scheitern, wie bei jedem Server.
• Das Image, <mirror>/ironflockos/<version>/<file> — liefert der Spiegel es nicht (er ist nicht erreichbar, antwortet mit etwas anderem als der Datei, oder was er sendet, ist nicht der Anfang des Images), kommt es von der URL, die der signierte Katalog nennt. Eine Datei aus dem Cache von os flash fragt keinen von beiden.
• Die Hardwareliste, <mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — dieselbe Regel, für sich allein.

Jeder Rückgriff ist eine Warnung im Plan, mit dem Spiegel, der Datei und dem Grund; mit --json in warnings. Der Plan legt die Quelle jeder Datei einmal fest: Die Bereitstellung lädt das Image von der image.url des Plans herunter und greift nicht noch einmal zurück. Liefern weder der Spiegel noch die Cloud eine Datei, scheitert der Befehl mit einem Fehler, der beide Quellen und beide Gründe nennt (neither the appliance's mirror ... nor the IronFlock cloud gives ...).

Der Spiegel wird direkt erreicht, die Cloud über den Proxy, wie bei agent install. Ein HTTPS-Spiegel mit einem Zertifikat der eigenen CA der Appliance funktioniert nur, wo das System der Maschine dieser CA vertraut. Antwortet die Appliance, behält das neue System die Netzwerkkarte, die sie erreicht hat (Was das neue System erhält).

Bevor sich etwas ändert

Der Befehl prüft die Maschine in dieser Reihenfolge. Die erste Prüfung, die fehlschlägt, lehnt ab, mit Exit-Code 3 und einem Satz, der die Ursache nennt und, wo es einen gibt, den Ausweg. Bis dahin ist nichts geändert.

1. Das System — systemd ist PID 1, das System ist kein Container, und es ist weder IronFlockOS noch ReswarmOS.
2. Die Firmware — 64-Bit-UEFI, beschreibbare EFI-Variablen und bei eingeschaltetem Secure Boot eine Boot-Kette des Images, die die Firmware starten wird (Secure Boot).
3. Das Image — aus dem signierten IronFlockOS-Katalog, wie os images es auflistet: das Image von --image, sonst das Basis-Image für das Target der Maschine. Der Befehl liest die ersten paar MiB der Image-Datei: aus dem Cache von os flash, wenn die Datei dort liegt, sonst vom Download-Server (zuerst vom Spiegel der Appliance, siehe Woher die Dateien kommen). Eine .flock-Datei für andere Hardware ergibt nur eine Warnung.
4. Die Festplatte — die mit der Partition, die die aktuelle Boot-Option der Firmware nennt; sonst die mit der EFI-Systempartition, die unter /boot/efi oder /efi eingehängt ist; sonst die, die --disk nennt. Ein --disk, das eine andere Festplatte nennt als die, von der das System gestartet ist, wird abgelehnt. Ebenso eine Festplatte, die keine eigenständige ganze Festplatte ist: ein MD-RAID-Array (auch eines, das Intel RST anlegt), ein device-mapper-, Loop- oder Netzwerk-Blockgerät, eine Festplatte im Arbeitsspeicher.
5. Was auf der Festplatte aufgebaut ist — Partitionen, LVM mit linearen Volumes und was cryptsetup zur Verschlüsselung einrichtet (LUKS, plain dm-crypt, BitLocker, FileVault, TrueCrypt). Alles andere wird abgelehnt: MD-RAID, bcache, Multipath, ein ZFS-Pool, LVM-Thin-Pools, Snapshots, Caches, RAID und Spiegelungen, dm-verity, dm-integrity. Andere Festplatten bleiben, wie sie sind, daher wird ein btrfs-Dateisystem oder eine LVM-Volume-Group mit Mitgliedern auf dieser und auf einer anderen Festplatte abgelehnt: Die Festplatte zu ersetzen, würde es auf beiden zerstören. Eine Maschine mit einer anderen Festplatte, die eine Partition namens IRONFLOCKOS, rootfs-a, rootfs-b oder data hat, wird ebenfalls abgelehnt, da IronFlockOS seine Partitionen an diesen Namen erkennt.
6. Arbeitsspeicher — wie oben.
7. Die .flock-Datei, das Netzwerk, der Proxy, die Treiber — Die .flock-Datei wird gelesen, wie os flash sie liest, und ihr SSH-Schlüssel muss gültig sein. Das Netzwerk und der Proxy werden geprüft, wie unter Was das neue System erhält beschrieben. Für die Treiber nimmt der Befehl die Geräte auf dem Weg zur Festplatte und zur Netzwerkkarte (die Festplatte, die Karte, ihre Controller und Busse) und sucht sie in der Hardwareliste des Images. Er lehnt nur ab, wenn die Liste zeigt, dass das Image für eines davon keinen Treiber hat. Ein Gerät, über das er nicht entscheiden kann, wird in der Warnung drivers not checked genannt; bei einem Release ohne Hardwareliste (bis 0.14.0) nennt die Warnung jedes Gerät.
8. Der Plan und die Frage — siehe unten.

Strg+C, während der Befehl den Anfang des Images liest, beendet ihn mit Exit-Code 130, ebenso ein verlorenes Terminal, während der Plan angezeigt wird oder die Frage wartet. Dann wurde nichts geändert.

Der Plan und --dry-run

Der Plan geht auf stderr. Er nennt die Maschine und ihre Firmware, die Festplatte und wie sie gefunden wurde, das Image und woher seine Datei kommt, und den Arbeitsspeicher. Er sagt, dass alles auf der Festplatte verloren geht, was das neue System erhält und was nicht, und nennt die Warnungen. --dry-run zeigt den Plan, ändert nichts und endet mit Exit-Code 0. Mit --dry-run braucht --yes kein --disk.

Auf einer Compute-Engine-VM warnt der Plan, dass die Gastumgebung von Google verschwindet: gcloud compute ssh, OS Login und SSH-Schlüssel aus den Metadaten funktionieren nicht mehr, die serielle Konsole bleibt.

Was das neue System erhält

Das neue System erhält:

• Die Identität des Geräts — aus der .flock-Datei, die auf die IRONFLOCKOS-Partition kommt. Das Gerät registriert sich damit bei seinem ersten Start.
• Das Netzwerk — das der Netzwerkkarte, über die der Download des Images lief, zum Download-Server oder zum Proxy. Ist die Download-Basis der Spiegel der Appliance aus der .flock-Datei und hat der Spiegel die Anfrage nach dem Katalog überhaupt beantwortet (auch mit 404), ist es stattdessen die Karte der Verbindung zum Spiegel, woher die Dateien auch kamen: Mit der Appliance verbindet sich das neue Gerät. Ein Kabel mit DHCP braucht nichts. Eine statische Adresse (Adressen ohne Lebensdauer, von Hand gesetzte Gateways und Routen, die DNS-Server von systemd-resolved oder /etc/resolv.conf) wird zu einem NetworkManager-Profil, das die Karte an ihrer permanenten MAC-Adresse erkennt. Eine statische Adresse neben DHCP oder SLAAC behält DHCP und fügt die statische hinzu. Im WLAN braucht das Netzwerk der .flock-Datei nichts; ein anderes Netzwerk mit einem WPA-PSK- oder WPA3-SAE-Profil von NetworkManager, versteckt oder nicht, erhält dieses Profil. Adressen anderer Karten werden nicht übernommen, und der Plan warnt.
• Der Proxy — der Proxy des Downloads wird zur Proxy-Einstellung von IronFlockOS (proxy.conf auf der IRONFLOCKOS-Partition), mit Benutzer und Passwort, und no_proxy. Ein Proxy auf der Maschine selbst (127.0.0.1) wird abgelehnt, da das neue System ihn nicht hat. Ebenso ein Spiegel, der auf dem Loopback der Maschine antwortet: eine .flock-Datei, deren update_url localhost nennt, wie sie der Agent auf dem Host der Appliance selbst hat. Eine Proxy-URL mit Zeichen, die proxy.conf nicht annimmt, wird abgelehnt, und die Ablehnung nennt den Teil.
• SSH — das Konto des Projekteigentümers mit dem Schlüssel aus der .flock-Datei, wie es jedes IronFlockOS-Gerät hat.

IronFlockOS 0.15.0 und neuer übernehmen Netzwerkprofile und die Proxy-Einstellung von der IRONFLOCKOS-Partition. Mit einem Image eines älteren Release wird eine Maschine abgelehnt, deren Netzwerk ein Profil braucht oder deren Download über einen Proxy läuft; die Ablehnung nennt die Karte, ihre statische Adresse oder ihr WLAN und was stattdessen zu tun ist.

Das neue System erhält nicht die Benutzerkonten des alten Systems mit ihren Passwörtern und SSH-Schlüsseln, nicht die SSH-Host-Schlüssel (SSH-Clients sehen einen neuen Host-Schlüssel) und nicht die Pakete, Einstellungen und Daten. Die Apps des Geräts kommen von IronFlock zurück, ihre Daten auf dieser Maschine nicht.

Die Frage

Der Befehl bittet Sie, den kurzen Hostnamen der Maschine einzutippen, den die Frage zeigt. Auf einer Maschine, deren Kernel den vollständigen Namen hat (die Images von Ubuntu in Compute Engine), wird auch der vollständige Name angenommen. Alles andere, auch Enter allein, beantwortet die Frage mit Nein: Exit-Code 4. Siehe Fragen und Bestätigung.

--yes beantwortet die Frage nur, wenn --disk die Festplatte nennt. Auf einem verschlüsselten System braucht --yes zusätzlich --allow-unencrypted, sonst endet der Befehl mit Exit-Code 4. Ohne Terminal und mit --json kann die Frage nicht gestellt werden: Ohne --yes endet der Befehl mit Exit-Code 4.

Nach der Frage: Bereitstellung und Übergabe

Vor dem Neustart wird nichts auf die Festplatte geschrieben. Der Befehl stellt die Ersetzung im Arbeitsspeicher bereit:

1. Ein Dateisystem im Arbeitsspeicher nimmt das Image auf: die Datei aus dem Cache von os flash, wenn der Plan sie dort gelesen hat, sonst einen Download (angezeigt als Downloading), geprüft gegen den signierten Katalog (Checking). Das Image wird einmal entpackt (Preparing) und mit dem verglichen, was der Plan gelesen hat. Die Dateien für die IRONFLOCKOS-Partition werden vorbereitet.
2. Eine Boot-Option für IronFlockOS kommt an das Ende der Bootreihenfolge der Firmware, hinter die des laufenden Systems. Bis die Festplatte beschrieben ist, startet weiterhin zuerst das laufende System.
3. Staged: auf stderr nennt die neue Boot-Option und die Boot-Optionen des alten Systems, die nach dem Schreiben gelöscht werden.
4. Der Befehl übergibt: Die Maschine startet sofort neu oder, wenn der Befehl in einer SSH-Sitzung läuft (auch über sudo und --host), zehn Sekunden nach dem Ende des Befehls, damit das Ergebnis zuerst die Sitzung erreicht. Stdout sagt Handed over: ..., und der Befehl endet mit Exit-Code 0.

Strg+C oder SIGTERM zwischen der Frage und der Übergabe nimmt die Bereitstellung zurück: Der Befehl endet mit Exit-Code 130, und die Maschine ist so wie vorher. Nach der Frage hält ein verlorenes Terminal oder eine verlorene SSH-Sitzung den Befehl nicht mehr an: Die Bereitstellung geht weiter, und die Übergabe und der Neustart finden statt. Sobald der Neustart übergeben ist, beendet Strg+C den Befehl, und der Neustart läuft weiter.

Der Neustart und das Schreiben

Am Ende des Herunterfahrens schreibt ironflock das Image aus dem Arbeitsspeicher auf die Festplatte. Die Konsole der Maschine zeigt seine Zeilen, die mit ironflock-install: beginnen. Dann startet die Maschine IronFlockOS, und das Gerät erscheint innerhalb von etwa zehn Minuten in IronFlock. Das Log des Schreibens ist ironflock-install.log auf der IRONFLOCKOS-Partition des neuen Systems.

Wenn das alte System wieder startet

Bevor es schreibt, prüft ironflock die Festplatte noch einmal. Trifft etwas nicht zu, startet das alte System wieder, unverändert: Die Festplatte ist belegt oder schreibgeschützt, sie ist nicht die Festplatte des Plans, das bereitgestellte Image ist beschädigt, oder die Schritte vor dem Schreiben dauern länger als zwei Minuten. Der Grund steht in der EFI-Variablen IronFlockInstall. ironflock status zeigt ihn in seiner Zeile OS install:, ohne Root-Rechte:

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

# Auf der Maschine
ironflock status
# Von einem anderen Computer aus
ironflock --host admin@machine status
# Ohne ironflock: gibt die Stufe, die Zeit und den Grund aus
tail -c +5 /sys/firmware/efi/efivars/IronFlockInstall-7b2f7cb6-eb8f-4acd-b7fd-e92df1a035a0

Über --host

ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes führt den Befehl auf dieser Maschine aus, so wie jeder Befehl über --host läuft: Die Binärdatei und die .flock-Datei gehen dorthin, die Prüfungen, der Plan und die Frage laufen dort, und ihre Ausgabe kommt zurück. Der Ordner mit der Binärdatei und der Kopie der .flock-Datei wird entfernt, wenn der Befehl dort endet, auch nach einer Ablehnung oder einer Unterbrechung. --dry-run ändert auf der Maschine nichts außer diesem Ordner.

Der Neustart kommt zehn Sekunden nach dem Ende des Befehls, sodass sein Ergebnis zuerst Ihre Seite erreicht. Nach der Frage hält eine verlorene Verbindung den Befehl dort nicht mehr an: Bricht die Verbindung ab, endet der Befehl auf Ihrer Seite mit Exit-Code 255 und sagt, dass die Maschine von selbst weitermacht.

Nach der Übergabe wartet der Befehl bis zu 15 Minuten darauf, dass die Maschine als IronFlockOS zurückkommt:

• Alle 15 Sekunden meldet er sich unter derselben Adresse als SSH-Benutzer der .flock-Datei an, mit dem Schlüssel aus der .flock-Datei. Der Schlüssel kommt in eine Datei in einem neuen Ordner, den nur Sie lesen können, und der Ordner wird entfernt, wenn das Warten endet. Der Schlüssel kommt nicht in den SSH-Agenten.
• Er übernimmt den Host-Schlüssel des neuen Systems, ohne ihn irgendwohin zu schreiben: known_hosts bleibt, wie es ist.
• Er liest, was das System ausführt und ob sich der Geräte-Agent seit dem Start mit IronFlock verbunden hat.
• In der Zwischenzeit fragt er das alte System, nur mit einem Host-Schlüssel, den known_hosts enthält, nach der EFI-Variablen IronFlockInstall: Eine Maschine, die mit ihrem alten System zurückkommt, beendet das Warten sofort.

Das Warten endet mit Exit-Code 0, wenn die Maschine IronFlockOS ausführt und der Geräte-Agent verbunden ist. Es endet mit 1, wenn die Maschine IronFlockOS ohne verbundenen Agenten ausführt, mit ihrem alten System zurückgekommen ist oder innerhalb von 15 Minuten nicht als IronFlockOS geantwortet hat. Eine Adresse, die DHCP geändert hat, macht die Prüfung zunichte; die Meldung verweist dann auf das Gerät in IronFlock und auf die Konsole der Maschine. Strg+C beendet das Warten mit 130, und die Maschine macht von selbst weiter.

Das Warten kann nicht erkennen, welche Maschine unter der Adresse antwortet, da der Host-Schlüssel des neuen Systems für Ihre Seite neu ist. Den Beweis liefert das Gerät, das IronFlock als verbunden anzeigt.

Das Warten braucht die .flock-Datei auf Ihrer Seite. Ohne -c oder mit einer .flock-Datei, die keinen SSH-Benutzer einrichtet, endet der Befehl mit Exit-Code 2, bevor irgendetwas an die Maschine geht, außer Sie geben --no-wait an. --no-wait übergibt und endet mit dem Exit-Code des Befehls auf der Maschine.

Secure Boot

Bei eingeschaltetem Secure Boot prüft der Befehl, dass die Firmware die Boot-Kette des Images starten wird, shim und dann GRUB:

• eine Signatur des shim des Images führt über die mitgelieferten Zertifikate zu einem Zertifikat in der Signaturdatenbank der Firmware (db), und die Sperrdatenbank (dbx) widerruft keines davon; oder db listet den Hash von shim.
• weder dbx noch die Sperrliste von shim auf dieser Maschine (MokListX) listet den shim oder GRUB des Images oder ein Zertifikat, mit dem GRUB signiert ist.
• der SBAT-Level der Maschine (SbatLevelRT) widerruft weder shim noch GRUB.

Würde die Firmware das Image nicht starten, lehnt der Befehl ab. Sie können Secure Boot im Setup der Firmware ausschalten: IronFlockOS startet auch ohne. Auf einem System, das nicht über shim gestartet ist, warnt der Plan, dass der SBAT-Level und MokListX nicht geprüft wurden. Der Befehl prüft nicht den Signaturwert von shim und sieht sich den Kernel nicht an; für beide bürgt der signierte Katalog. Mit --json nennt machine.secure_boot.ca das Zertifikat in db, zu dem die Signatur von shim führt, etwa Microsoft UEFI CA 2023.

Beispiele

# Den Plan für das Gerät des installierten Agenten zeigen, nichts ändern
sudo ironflock os install --dry-run
# Der Plan für ein neues Gerät, als JSON
sudo ironflock os install -c device.flock --dry-run --json
# Das System ohne Frage ersetzen
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# Von einem anderen Computer aus, und warten, bis das Gerät online ist
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

Ergebnis

Der Plan von sudo ironflock os install -c device.flock --dry-run, auf 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.

Die Ausführung von sudo ironflock os install -c device.flock --disk /dev/sda --yes zeigt denselben Plan, dann die Bereitstellung und die Übergabe:

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.

Mit --json ist das Ergebnis der Plan als ein JSON-Objekt: mit --dry-run sofort, ohne dieses Flag nach der Übergabe, mit dry_run false und staging, und über --host nach dem Warten, zusätzlich mit wait. Stderr erhält den Fortschritt als JSON-Zeilen und sonst nichts (Ausgabe und JSON). Kein Feld enthält ein Secret: Die Dateien für die IRONFLOCKOS-Partition werden mit ihrer Größe genannt, und Proxy-URLs werden ohne das Passwort gezeigt. Das Ergebnis des Probelaufs oben, mit eingefügten Zeilenumbrüchen (der Befehl schreibt eine Zeile; ... markiert, was das Beispiel auslässt):

{"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":[...]}

Wann der Befehl ablehnt

Der Befehl lehnt mit Exit-Code 3 ab, und nichts wird geändert:

• ein Container, ein System ohne systemd als PID 1, IronFlockOS (os update installiert dort ein Release), ReswarmOS.
• BIOS, 32-Bit-UEFI, eine Architektur ohne Image, EFI-Variablen, die nicht eingehängt sind (die Ablehnung nennt den Befehl mount) oder schreibgeschützt eingehängt sind (sie nennt mount -o remount,rw).
• Secure Boot, das den shim oder GRUB des Images nicht starten würde.
• eine Festplatte, die der Befehl nicht bestimmen kann (nennen Sie sie mit --disk), ein --disk, das nicht die Festplatte ist, von der das System gestartet ist, eine Partition, keine Festplatte; eine Festplatte, die keine eigenständige ganze Festplatte ist oder die lsblk nicht auflistet; eine Festplatte ohne GPT.
• ein Root-Dateisystem auf einer anderen Festplatte, über mehrere Festplatten verteilt, auf ZFS oder auf keiner Festplatte (ein Live-System).
• logische Sektoren, die nicht 512 Bytes groß sind, eine zu kleine Festplatte, ein Speicher-Stack, den der Befehl nicht zerlegt, ein btrfs-Dateisystem oder eine LVM-Volume-Group über diese und eine andere Festplatte, eine andere Festplatte mit den Partitionsnamen von IronFlockOS.
• zu wenig Arbeitsspeicher.
• ein Netzwerk, das der Befehl nicht übernimmt, ein Proxy auf der Maschine selbst oder der Spiegel der Appliance auf dem Loopback der Maschine, ein Proxy mit einem Image, das proxy.conf nicht annimmt, oder mit Zeichen, die proxy.conf nicht annimmt, ein aktives NetworkManager-Profil, das sich nicht lesen lässt.
• eine Hardwareliste des Release, die zeigt, dass das Image keinen Treiber für ein Gerät der Festplatte oder der Netzwerkkarte hat.
• ip aus iproute2, das nicht läuft: Das Netzwerk lässt sich nicht lesen.
• nach der Frage, bevor die Bereitstellung etwas ändert: eine Festplatte, die nicht mehr die des Plans ist, ein /run/initramfs, das bereits ein Mountpoint ist, ein Plan, der sich so nicht ausführen lässt.

Diese Fälle sind falsche Befehlszeilen, Exit-Code 2, geprüft, bevor irgendetwas geändert wird:

• --yes ohne --disk, außer mit --dry-run.
• kein -c auf einer Maschine ohne installierten Geräte-Agenten; über --host ohne --no-wait kein -c oder eine .flock-Datei, die keinen SSH-Benutzer einrichtet.
• ein --image, das der Katalog nicht hat, eines für ein anderes Target als das der Maschine oder der Installer-Stick (den os flash --installer schreibt).
• eine Proxy-URL mit Passwort und die anderen Proxy-Flags, die agent install ablehnt.
• mehrere Maschinen (--host mehrfach angegeben, --hosts).

Wann der Befehl fehlschlägt

Der Befehl schlägt mit Exit-Code 1 fehl, und nichts wird geändert:

• die .flock-Datei ist nicht gültig, oder ihr SSH-Schlüssel ist nicht gültig.
• die Prüfung des Katalogs schlägt fehl, oder er lässt sich nicht abrufen, wie bei os images; mit dem Spiegel der Appliance weder vom Spiegel noch aus der Cloud.
• der Anfang der Image-Datei lässt sich nicht herunterladen (getting the image ...), mit dem Spiegel der Appliance weder vom Spiegel noch aus der Cloud, oder er ist kein IronFlockOS-Image, wie der Befehl es kennt. Kam der Katalog aus der Cloud, weil der Spiegel keinen lieferte, beginnt der Fehler mit der Warnung zum Katalog, the appliance's mirror ... gives no IronFlockOS catalog now (...), und nennt beide Server.
• die lokale Adresse des Downloads gehört zu keiner Netzwerkkarte; die Mount-Tabelle, die Blockgeräte oder der Arbeitsspeicher lassen sich nicht lesen; die EFI-Variablen lassen sich nicht parsen.
• nach der Frage: Die Image-Datei ist nicht die des Katalogs oder nicht das, was der Plan gelesen hat (die Meldung nennt beide Werte), der Download schlägt fehl, die Firmware nimmt die Boot-Option nicht an, oder der Neustart lässt sich nicht auslösen. Die Bereitstellung wird zurückgenommen. Schlägt auch das Zurücknehmen fehl, bittet die Meldung um einen Neustart, der entfernt, was übrig ist.

Keine URL wird mit einem Benutzer und Passwort ausgegeben, die sie enthalten kann.

Exit-Codes

Was jeder Code bei allen Befehlen bedeutet, steht unter Flags, Ausgabe & Exit-Codes.