Sostituire Linux con IronFlockOS

ironflock os install sostituisce con IronFlockOS, sullo stesso disco, il Linux da cui si è avviata una macchina in funzione, e rende la macchina il dispositivo IronFlock di un file di configurazione del dispositivo (.flock). Lo esegui sulla macchina stessa, oppure da un altro computer via SSH.

Avviso: Tutto ciò che si trova sul disco da cui si è avviata la macchina va perso: il sistema in esecuzione, i suoi pacchetti e le sue impostazioni, i suoi account utente e tutti i dati. Non si può tornare indietro. Esegui prima il comando con --dry-run e leggi il piano.

Quando usarlo

Usa os install per una macchina che esegue già Debian, Ubuntu o un altro Linux con systemd e che non puoi o non vuoi avviare da una chiavetta USB: un PC in un quadro elettrico, una macchina virtuale in un cloud, una macchina che raggiungi solo via SSH. Con --host esegui il comando dal tuo computer, anche da un Mac, e il comando attende finché la macchina non è online come dispositivo IronFlock.

Usa un altro comando quando:

• Puoi avviare la macchina da un’unità — ironflock os flash scrive IronFlockOS su una chiavetta USB, una scheda SD o un disco esterno. Con --installer scrive una chiavetta di installazione, che installa IronFlockOS sul disco interno del PC che si avvia da essa. La chiavetta di installazione è anche la via d’uscita per la maggior parte delle macchine che os install rifiuta.
• La macchina è un Raspberry Pi — os install installa solo le immagini per macchine UEFI (target amd64-efi e arm64-efi). Scrivi la scheda SD del Raspberry Pi con os flash.
• La macchina esegue già IronFlockOS — os install la rifiuta. Lì ironflock os update installa un’altra release.
• Vuoi mantenere il Linux della macchina — ironflock agent install collega la macchina a IronFlock così com’è.

ironflock os install

Controlla la macchina, mostra il piano della sostituzione e chiede. Poi prepara IronFlockOS in memoria e riavvia la macchina, che alla fine del suo arresto scrive IronFlockOS sul disco e lo avvia.

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

Su macOS il comando termina con il codice di uscita 3 prima di esaminare qualsiasi cosa; lì eseguilo con --host. Funziona su una macchina alla volta: --host indicato più volte e --hosts terminano con il codice di uscita 2. I flag globali sono descritti in Flag, output e codici di uscita.

Flag

I flag del proxy funzionano come per agent install. Senza di essi il comando prende HTTP_PROXY, HTTPS_PROXY e NO_PROXY dall’ambiente. Un URL di proxy che contiene una password è una riga di comando errata (codice di uscita 2); vedi Segreti.

Cosa serve alla macchina

• Il sistema — Linux con systemd come PID 1, ad esempio Debian o Ubuntu, non in un container. IronFlockOS e ReswarmOS vengono rifiutati.
• Il firmware — UEFI a 64 bit su amd64 o arm64. Le sue variabili EFI sono montate (efivarfs) e scrivibili. BIOS e UEFI a 32 bit vengono rifiutati. Secure Boot può essere attivo, vedi Secure Boot.
• Il disco — il disco da cui il firmware ha avviato il sistema: un disco intero a sé stante con una GPT (GUID partition table) e settori logici da 512 byte. Il file system di root si trova su questo disco e su nessun altro, direttamente o tramite LVM o LUKS. Il disco è grande almeno quanto il disco minimo dell’immagine: la dimensione indicata dal catalogo, altrimenti 10 GiB, o 18 GiB per un’immagine nvidia.
• Memoria — memoria disponibile (MemAvailable) per l’immagine compressa, il binario ironflock e altri 512 MiB: per l’immagine base, una macchina con circa 2 GiB.
• Strumenti — lsblk e ip di iproute2.
• La rete — il server di download raggiungibile, direttamente o tramite un proxy, su una rete che il nuovo sistema può usare (Cosa riceve il nuovo sistema). Per un dispositivo di un IronFlock Appliance, può essere il mirror di download dell’Appliance (Da dove vengono i file).
• Il file .flock — quello di -c, oppure quello dell’agente del dispositivo installato sulla macchina.

Da dove vengono i file

Il comando ha bisogno del catalogo firmato di IronFlockOS, dell’immagine e dell’elenco hardware dell’immagine. Li prende da:

1. --download-base, altrimenti IRONFLOCK_DL_BASE: solo da quel server.
2. Altrimenti dal mirror di download dell’IronFlock Appliance che il file .flock indica come suo server di aggiornamento: il suo update_url, quando è un URL http o https assoluto il cui host non è uno del cloud IronFlock, come https://registry.<domain>/dl o http://<host>:<port>/dl. Stderr indica Download base: ... (from the device's .flock). Così si converte una macchina che raggiunge l’Appliance ma non ironflock.com. Un file .flock del cloud IronFlock usa il cloud.
3. Altrimenti dal cloud IronFlock, https://instance-registry.ironflock.com/dl.

Con il mirror dell’Appliance, i file vengono prima dal mirror e, quando il mirror non li fornisce, dal cloud IronFlock:

• Il catalogo, <mirror>/ironflockos/manifest.json — quando il mirror al momento non ne fornisce uno (non è raggiungibile, risponde con un errore, oppure al suo posto ci sarebbe solo la copia conservata del suo ultimo catalogo), tutto viene dal cloud, come senza un Appliance. Un catalogo fornito dal mirror ma rifiutato (la sua firma, più vecchio della copia conservata, troppo grande) fa fallire il comando, come da qualsiasi server.
• L’immagine, <mirror>/ironflockos/<version>/<file> — quando il mirror non la fornisce (non è raggiungibile, risponde con qualcosa che non è il file, oppure ciò che invia non è l’inizio dell’immagine), viene dall’URL indicato dal catalogo firmato. Un file della cache di os flash non interroga nessuno dei due.
• L’elenco hardware, <mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — la stessa regola, per conto suo.

Ogni ripiego è un avviso nel piano, con il mirror, il file e il motivo; con --json in warnings. Il piano decide una volta la fonte di ogni file: la preparazione scarica l’immagine da image.url del piano e non ripiega di nuovo. Quando né il mirror né il cloud forniscono un file, il comando fallisce con un unico errore che indica entrambe le fonti ed entrambi i motivi (neither the appliance's mirror ... nor the IronFlock cloud gives ...).

Il mirror viene raggiunto direttamente, il cloud attraverso il proxy, come per agent install. Un mirror HTTPS con un certificato della CA propria dell’Appliance funziona solo dove il sistema della macchina considera attendibile quella CA. Quando l’Appliance risponde, il nuovo sistema mantiene la scheda di rete che l’ha raggiunto (Cosa riceve il nuovo sistema).

Prima di qualsiasi modifica

Il comando controlla la macchina in questo ordine. Il primo controllo che fallisce produce un rifiuto, con il codice di uscita 3 e una frase che indica la causa e, dove esiste, la via d’uscita. Fino a quel punto non è stato modificato nulla.

1. Il sistema — systemd è PID 1, il sistema non è un container, e non è IronFlockOS né ReswarmOS.
2. Il firmware — UEFI a 64 bit, variabili EFI scrivibili e, con Secure Boot attivo, una catena di avvio dell’immagine che il firmware avvierà (Secure Boot).
3. L’immagine — dal catalogo firmato di IronFlockOS, come la elenca os images: l’immagine di --image, altrimenti l’immagine base del target della macchina. Il comando legge i primi MiB del file immagine: dalla cache di os flash quando il file è lì, altrimenti dal server di download (prima dal mirror dell’Appliance, vedi Da dove vengono i file). Un file .flock per un altro hardware produce solo un avviso.
4. Il disco — quello con la partizione indicata dall’opzione di avvio corrente del firmware; altrimenti quello con la partizione di sistema EFI montata in /boot/efi o /efi; altrimenti quello indicato da --disk. Un --disk che indica un disco diverso da quello da cui si è avviato il sistema viene rifiutato. Lo stesso vale per un disco che non è un disco intero a sé stante: un array MD RAID (anche uno creato da Intel RST), un device-mapper, un loop device o un network block device, un disco in memoria.
5. Cosa è costruito sul disco — partizioni, LVM con volumi lineari, e ciò che cryptsetup configura per la cifratura (LUKS, dm-crypt plain, BitLocker, FileVault, TrueCrypt). Tutto il resto viene rifiutato: MD RAID, bcache, multipath, un pool ZFS, thin pool LVM, snapshot, cache, RAID e mirror, dm-verity, dm-integrity. Gli altri dischi restano come sono, quindi un file system btrfs o un volume group LVM con membri su questo disco e su un altro viene rifiutato: sostituire il disco lo distruggerebbe su entrambi. Viene rifiutata anche una macchina con un altro disco che ha una partizione chiamata IRONFLOCKOS, rootfs-a, rootfs-b o data, perché IronFlockOS trova le sue partizioni in base a questi nomi.
6. Memoria — come sopra.
7. Il file .flock, la rete, il proxy, i driver — il file .flock viene letto come lo legge os flash, e la sua chiave SSH deve essere valida. La rete e il proxy vengono controllati come descritto in Cosa riceve il nuovo sistema. Per i driver, il comando prende i dispositivi sul percorso verso il disco e verso la scheda di rete (il disco, la scheda, i loro controller e bus) e li cerca nell’elenco hardware dell’immagine. Rifiuta solo quando l’elenco mostra che l’immagine non ha un driver per uno di essi. Un dispositivo per cui non riesce a decidere viene indicato nell’avviso drivers not checked; per una release senza elenco hardware (fino alla 0.14.0) l’avviso indica ogni dispositivo.
8. Il piano e la domanda — vedi sotto.

Ctrl-C mentre il comando legge l’inizio dell’immagine lo termina con il codice di uscita 130, e lo stesso fa un terminale perso mentre viene mostrato il piano o la domanda è in attesa. In quel caso non è stato modificato nulla.

Il piano e --dry-run

Il piano va su stderr. Indica la macchina e il suo firmware, il disco e come è stato trovato, l’immagine e da dove proviene il suo file, e la memoria. Dice che tutto ciò che si trova sul disco va perso, cosa riceve il nuovo sistema e cosa non riceve, e gli avvisi. --dry-run mostra il piano, non modifica nulla e termina con il codice di uscita 0. Con --dry-run, --yes non richiede --disk.

Su una VM di Compute Engine il piano avvisa che l’ambiente guest di Google va perso: gcloud compute ssh, OS Login e le chiavi SSH dei metadati smettono di funzionare, mentre la console seriale resta.

Cosa riceve il nuovo sistema

Il nuovo sistema riceve:

• L’identità del dispositivo — quella del file .flock, che va sulla partizione IRONFLOCKOS. Il dispositivo si registra con esso al primo avvio.
• La rete — quella della scheda di rete attraverso cui è passato il download dell’immagine, verso il server di download o verso il proxy. Quando la base di download è il mirror dell’Appliance del file .flock e il mirror ha risposto in qualche modo alla richiesta del catalogo (anche con un 404), è invece la scheda della connessione al mirror, da qualunque parte siano venuti i file: l’Appliance è il punto a cui si connette il nuovo dispositivo. Un cavo con DHCP non richiede nulla. Un indirizzo statico (indirizzi senza scadenza, gateway e route impostati a mano, i server DNS di systemd-resolved o di /etc/resolv.conf) diventa un profilo NetworkManager che riconosce la scheda dal suo indirizzo MAC permanente. Un indirizzo statico accanto a DHCP o SLAAC mantiene DHCP e aggiunge quello statico. Su WiFi, la rete del file .flock non richiede nulla; un’altra rete con un profilo NetworkManager WPA-PSK o WPA3-SAE, nascosta o no, riceve quel profilo. Gli indirizzi di altre schede non vengono trasferiti, e il piano dà un avviso.
• Il proxy — il proxy del download diventa l’impostazione del proxy di IronFlockOS (proxy.conf sulla partizione IRONFLOCKOS), con l’utente e la password, e no_proxy. Un proxy sulla macchina stessa (127.0.0.1) viene rifiutato, perché il nuovo sistema non lo ha. Lo stesso vale per un mirror che risponde sul loopback della macchina: un file .flock il cui update_url indica localhost, come lo ha l’agente sull’host stesso dell’Appliance. Un URL di proxy con caratteri che proxy.conf non accetta viene rifiutato, e il rifiuto indica la parte.
• SSH — l’account del proprietario del progetto con la chiave del file .flock, come lo ha ogni dispositivo IronFlockOS.

IronFlockOS 0.15.0 e le versioni successive prendono i profili di rete e l’impostazione del proxy dalla partizione IRONFLOCKOS. Con un’immagine di una release precedente, una macchina la cui rete richiede un profilo, o il cui download passa attraverso un proxy, viene rifiutata; il rifiuto indica la scheda, il suo indirizzo statico o la sua rete WiFi, e cosa fare invece.

Il nuovo sistema non riceve gli account utente del vecchio sistema con le loro password e chiavi SSH, né le chiavi host SSH (i client SSH vedono una nuova chiave host), né i pacchetti, le impostazioni e i dati. Le app del dispositivo tornano da IronFlock; i loro dati su questa macchina no.

La domanda

Il comando ti chiede di digitare il nome host breve della macchina, che la domanda mostra. Su una macchina il cui kernel ha il nome completo (le immagini Ubuntu di Compute Engine), viene accettato anche il nome completo. Qualsiasi altra cosa, anche Invio da solo, vale come no: codice di uscita 4. Vedi Domande e conferma.

--yes risponde alla domanda solo quando --disk indica il disco. Su un sistema cifrato --yes richiede anche --allow-unencrypted, altrimenti il comando termina con il codice di uscita 4. Senza terminale, e con --json, la domanda non può essere posta: senza --yes il comando termina con il codice di uscita 4.

Dopo la domanda: preparazione e passaggio di consegne

Prima del riavvio non viene scritto nulla sul disco. Il comando prepara la sostituzione in memoria:

1. Un file system in memoria accoglie l’immagine: il file della cache di os flash quando il piano l’ha letto lì, altrimenti un download (mostrato come Downloading), verificato rispetto al catalogo firmato (Checking). L’immagine viene decompressa una volta (Preparing) e confrontata con ciò che ha letto il piano. Vengono preparati i file per la partizione IRONFLOCKOS.
2. Un’opzione di avvio per IronFlockOS va alla fine dell’ordine di avvio del firmware, dopo quella del sistema in esecuzione. Finché il disco non viene scritto, si avvia ancora per primo il sistema in esecuzione.
3. Staged: su stderr indica la nuova opzione di avvio e le opzioni di avvio del vecchio sistema, che vengono eliminate dopo la scrittura.
4. Il comando effettua il passaggio di consegne: la macchina si riavvia subito oppure, quando il comando viene eseguito in una sessione SSH (anche tramite sudo e --host), dieci secondi dopo la fine del comando, così che il risultato raggiunga prima la sessione. Stdout riporta Handed over: ..., e il comando termina con il codice di uscita 0.

Ctrl-C o SIGTERM tra la domanda e il passaggio di consegne annullano la preparazione: il comando termina con il codice di uscita 130, e la macchina resta com’era. Dopo la domanda un terminale o una sessione SSH persi non fermano più il comando: la preparazione prosegue, e il passaggio di consegne e il riavvio avvengono. Dopo il passaggio di consegne per il riavvio, Ctrl-C termina il comando, e il riavvio avviene comunque.

Il riavvio e la scrittura

Alla fine dell’arresto, ironflock scrive l’immagine dalla memoria sul disco. La console della macchina mostra le sue righe, che iniziano con ironflock-install:. Poi la macchina avvia IronFlockOS, e il dispositivo compare in IronFlock entro una decina di minuti. Il log della scrittura è ironflock-install.log sulla partizione IRONFLOCKOS del nuovo sistema.

Quando si riavvia il vecchio sistema

Prima di scrivere, ironflock controlla il disco ancora una volta. Quando qualcosa non torna, si riavvia il vecchio sistema, invariato: il disco è occupato o di sola lettura, non è il disco del piano, l’immagine preparata è danneggiata, oppure i passi prima della scrittura richiedono più di due minuti. Il motivo si trova nella variabile EFI IronFlockInstall. ironflock status lo mostra nella sua riga OS install:, senza 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

# Sulla macchina
ironflock status
# Da un altro computer
ironflock --host admin@machine status
# Senza ironflock: stampa la fase, l'ora e il motivo
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 esegue il comando su quella macchina come ogni comando eseguito via --host: il binario e il file .flock vengono trasferiti lì, i controlli, il piano e la domanda vengono eseguiti lì, e il loro output torna indietro. La cartella con il binario e la copia del file .flock viene rimossa quando il comando lì termina, anche dopo un rifiuto o un’interruzione. --dry-run non modifica nulla sulla macchina oltre a quella cartella.

Il riavvio avviene dieci secondi dopo la fine del comando, così il suo risultato arriva prima sul tuo computer. Dopo la domanda una connessione persa non ferma più il comando lì: quando la connessione si interrompe, il comando sul tuo computer termina con il codice di uscita 255 e dice che la macchina prosegue da sola.

Dopo il passaggio di consegne il comando attende, fino a 15 minuti, che la macchina torni come IronFlockOS:

• Ogni 15 secondi accede allo stesso indirizzo come l’utente SSH del file .flock, con la chiave del file .flock. La chiave va in un file di una nuova cartella che solo tu puoi leggere, e la cartella viene rimossa quando l’attesa termina. La chiave non va nell’agente SSH.
• Accetta la chiave host del nuovo sistema senza scriverla da nessuna parte: known_hosts resta com’è.
• Legge cosa esegue il sistema e se l’agente del dispositivo si è connesso a IronFlock dall’avvio.
• Nel frattempo chiede al vecchio sistema, solo con una chiave host presente in known_hosts, la variabile EFI IronFlockInstall: una macchina che torna con il suo vecchio sistema termina subito l’attesa.

L’attesa termina con il codice di uscita 0 quando la macchina esegue IronFlockOS e l’agente del dispositivo è connesso. Termina con 1 quando la macchina esegue IronFlockOS senza un agente connesso, è tornata con il suo vecchio sistema, o non ha risposto come IronFlockOS entro 15 minuti. Un indirizzo cambiato da DHCP rende vano il controllo; il messaggio rimanda allora al dispositivo in IronFlock e alla console della macchina. Ctrl-C termina l’attesa con 130, e la macchina prosegue da sola.

L’attesa non può sapere quale macchina risponde all’indirizzo, perché la chiave host del nuovo sistema è nuova per il tuo computer. La prova è il dispositivo mostrato come connesso in IronFlock.

L’attesa richiede il file .flock sul tuo computer. Senza -c, o con un file .flock che non configura alcun utente SSH, il comando termina con il codice di uscita 2 prima che qualsiasi cosa arrivi alla macchina, a meno che tu non indichi --no-wait. --no-wait effettua il passaggio di consegne e termina con il codice di uscita del comando sulla macchina.

Secure Boot

Con Secure Boot attivo, il comando controlla che il firmware avvierà la catena di avvio dell’immagine, shim e poi GRUB:

• una firma dello shim dell’immagine risale, attraverso i certificati che la accompagnano, a un certificato nel database delle firme del firmware (db), e il database delle firme vietate (dbx) non ne revoca nessuno; oppure db elenca l’hash di shim.
• né dbx né l’elenco dei divieti di shim su questa macchina (MokListX) elencano lo shim o il GRUB dell’immagine, o un certificato con cui è firmato GRUB.
• il livello SBAT della macchina (SbatLevelRT) non revoca né shim né GRUB.

Quando il firmware non avvierebbe l’immagine, il comando rifiuta. Puoi disattivare Secure Boot nel setup del firmware: IronFlockOS si avvia anche senza. Su un sistema che non si è avviato tramite shim, il piano avvisa che il livello SBAT e MokListX non sono stati controllati. Il comando non verifica il valore della firma di shim e non esamina il kernel; li garantisce il catalogo firmato. Con --json, machine.secure_boot.ca indica il certificato in db a cui risale la firma di shim, ad esempio Microsoft UEFI CA 2023.

Esempi

# Mostra il piano per il dispositivo dell'agente installato, senza modificare nulla
sudo ironflock os install --dry-run
# Il piano per un nuovo dispositivo, come JSON
sudo ironflock os install -c device.flock --dry-run --json
# Sostituisci il sistema senza domande
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# Da un altro computer, attendendo finché il dispositivo non è online
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

Risultato

Il piano di sudo ironflock os install -c device.flock --dry-run, su 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’esecuzione di sudo ironflock os install -c device.flock --disk /dev/sda --yes mostra lo stesso piano, poi la preparazione e il passaggio di consegne:

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.

Con --json il risultato è il piano come un unico oggetto JSON: con --dry-run subito, senza --dry-run dopo il passaggio di consegne, con dry_run a false e staging, e via --host dopo l’attesa, con in più wait. Stderr riceve l’avanzamento come righe JSON e nient’altro (Output e JSON). Nessun campo contiene un segreto: i file per la partizione IRONFLOCKOS sono indicati con la loro dimensione, e gli URL del proxy sono mostrati senza la password. Il risultato della simulazione qui sopra, con interruzioni di riga aggiunte (il comando scrive una sola riga; ... segna ciò che l’esempio tralascia):

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

Quando rifiuta

Il comando rifiuta con il codice di uscita 3, e non viene modificato nulla:

• un container, un sistema senza systemd come PID 1, IronFlockOS (lì os update installa una release), ReswarmOS.
• BIOS, UEFI a 32 bit, un’architettura senza immagine, variabili EFI non montate (il rifiuto indica il comando mount) o montate in sola lettura (indica mount -o remount,rw).
• un Secure Boot che non avvierebbe lo shim o il GRUB dell’immagine.
• un disco che il comando non riesce a determinare (indicalo con --disk), un --disk che non è il disco da cui si è avviato il sistema, una partizione, nessun disco; un disco che non è un disco intero a sé stante, o che lsblk non elenca; un disco senza GPT.
• un file system di root su un altro disco, distribuito su più dischi, su ZFS o su nessun disco (un sistema live).
• settori logici diversi da 512 byte, un disco troppo piccolo, uno stack di storage che il comando non scompone, un file system btrfs o un volume group LVM distribuito su questo disco e su un altro, un altro disco con i nomi di partizione di IronFlockOS.
• memoria insufficiente.
• una rete che il comando non trasferisce, un proxy sulla macchina stessa o il mirror dell’Appliance sul loopback della macchina, un proxy con un’immagine che non accetta proxy.conf o con caratteri che proxy.conf non accetta, un profilo NetworkManager attivo che non può essere letto.
• un elenco hardware della release che mostra che l’immagine non ha un driver per un dispositivo del disco o della scheda di rete.
• ip di iproute2 che non funziona: la rete non può essere letta.
• dopo la domanda, prima che la preparazione modifichi qualcosa: un disco che non è più quello del piano, /run/initramfs che è già un punto di mount, un piano che non può essere eseguito così com’è.

Queste sono righe di comando errate, codice di uscita 2, controllate prima di qualsiasi modifica:

• --yes senza --disk, tranne che con --dry-run.
• nessun -c su una macchina senza un agente del dispositivo installato; via --host senza --no-wait, nessun -c o un file .flock che non configura alcun utente SSH.
• un --image che il catalogo non ha, uno per un target diverso da quello della macchina, o la chiavetta di installazione (che scrive os flash --installer).
• un URL di proxy con una password, e gli altri flag del proxy che agent install rifiuta.
• più macchine (--host più volte, --hosts).

Quando fallisce

Il comando fallisce con il codice di uscita 1, e non viene modificato nulla:

• il file .flock non è valido, oppure la sua chiave SSH non è valida.
• il catalogo non supera la verifica o non può essere scaricato, come per os images; con il mirror dell’Appliance, né dal mirror né dal cloud.
• l’inizio del file immagine non può essere scaricato (getting the image ...), con il mirror dell’Appliance né dal mirror né dal cloud, oppure non è un’immagine IronFlockOS come la conosce il comando. Quando il catalogo è venuto dal cloud perché il mirror non ne ha fornito uno, l’errore inizia con l’avviso del catalogo, the appliance's mirror ... gives no IronFlockOS catalog now (...), e indica entrambi i server.
• l’indirizzo locale del download non appartiene ad alcuna scheda di rete; la tabella dei mount, i dispositivi a blocchi o la memoria non possono essere letti; le variabili EFI non si possono interpretare.
• dopo la domanda: il file immagine non è quello del catalogo o non corrisponde a ciò che ha letto il piano (il messaggio indica entrambi i valori), il download fallisce, il firmware non accetta l’opzione di avvio, o il riavvio non può essere avviato. La preparazione viene annullata. Quando fallisce anche l’annullamento, il messaggio chiede un riavvio, che rimuove ciò che resta.

Nessun URL viene stampato con l’utente e la password che potrebbe contenere.

Codici di uscita

Il significato di ogni codice per tutti i comandi è descritto in Flag, output e codici di uscita.