Reemplazar Linux por IronFlockOS

ironflock os install reemplaza por IronFlockOS el Linux desde el que arrancó una máquina en funcionamiento, en el mismo disco, y convierte la máquina en el dispositivo IronFlock de un archivo de configuración del dispositivo (.flock). Lo ejecutas en la propia máquina, o desde otra computadora por SSH.

Advertencia: Se pierde todo lo que hay en el disco desde el que arrancó la máquina: el sistema en ejecución, sus paquetes y ajustes, sus cuentas de usuario y todos los datos. No hay vuelta atrás. Ejecuta primero el comando con --dry-run y lee el plan.

Cuándo usarlo

Usa os install para una máquina que ya ejecuta Debian, Ubuntu u otro Linux con systemd, y que no puedes o no quieres arrancar desde una memoria USB: un PC en un armario de control, una máquina virtual en una nube, una máquina a la que solo llegas por SSH. Con --host ejecutas el comando desde tu propia computadora, también desde un Mac, y el comando espera hasta que la máquina está en línea como dispositivo de IronFlock.

Usa otro comando cuando:

• Puedes arrancar la máquina desde una unidad — ironflock os flash escribe IronFlockOS en una memoria USB, una tarjeta SD o un disco externo. Con --installer escribe una memoria USB de instalación, que instala IronFlockOS en el disco interno del PC que arranca desde ella. La memoria USB de instalación es también la salida para la mayoría de las máquinas que os install rechaza.
• La máquina es una Raspberry Pi — os install solo instala las imágenes para máquinas UEFI (targets amd64-efi y arm64-efi). Escribe la tarjeta SD de la Raspberry Pi con os flash.
• La máquina ya ejecuta IronFlockOS — os install la rechaza. ironflock os update instala allí otro release.
• Quieres conservar el Linux de la máquina — ironflock agent install conecta la máquina a IronFlock tal como está.

ironflock os install

Comprueba la máquina, muestra el plan del reemplazo y pregunta. Después prepara IronFlockOS en memoria y reinicia la máquina, que escribe IronFlockOS en el disco al final de su apagado y lo arranca.

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

En macOS, el comando termina con el código de salida 3 antes de examinar nada; ejecútalo allí con --host. Se ejecuta en una sola máquina a la vez: --host indicado más de una vez y --hosts terminan con el código de salida 2. Los flags globales están en Flags, salida y códigos de salida.

Flags

Los flags de proxy funcionan como en agent install. Sin ellos, el comando toma HTTP_PROXY, HTTPS_PROXY y NO_PROXY del entorno. Una URL de proxy que contiene una contraseña es una línea de comandos incorrecta (código de salida 2); consulta Secretos.

Qué necesita la máquina

• El sistema — Linux con systemd como PID 1, como Debian o Ubuntu, no en un contenedor. IronFlockOS y ReswarmOS se rechazan.
• El firmware — UEFI de 64 bits en amd64 o arm64. Sus variables EFI están montadas (efivarfs) y se pueden escribir. BIOS y UEFI de 32 bits se rechazan. Secure Boot puede estar activado; consulta Secure Boot.
• El disco — el disco desde el que el firmware arrancó el sistema: un disco entero propio con una GPT (tabla de particiones GUID) y sectores lógicos de 512 bytes. El sistema de archivos raíz está en este disco y en ningún otro, directamente o a través de LVM o LUKS. El disco tiene al menos el tamaño mínimo de disco de la imagen: el que indica el catálogo o, si no, 10 GiB, o 18 GiB para una imagen nvidia.
• Memoria — memoria disponible (MemAvailable) para la imagen comprimida, el binario ironflock y 512 MiB más: una máquina de unos 2 GiB para la imagen base.
• Herramientas — lsblk e ip de iproute2.
• La red — el servidor de descargas alcanzable, directamente o a través de un proxy, por una red que pueda usar el sistema nuevo (Qué recibe el sistema nuevo). Para un dispositivo de un appliance de IronFlock, puede ser la réplica de descargas del appliance (De dónde vienen los archivos).
• El archivo .flock — el de -c, o el del agente del dispositivo instalado en la máquina.

De dónde vienen los archivos

El comando necesita el catálogo firmado de IronFlockOS, la imagen y la lista de hardware de la imagen. Los toma de:

1. --download-base o, si no, IRONFLOCK_DL_BASE: solo de ese servidor.
2. Si no, de la réplica de descargas del appliance de IronFlock que el archivo .flock indica como su servidor de actualizaciones: su update_url, cuando es una URL http o https absoluta cuyo host no es de la nube de IronFlock, como https://registry.<domain>/dl o http://<host>:<port>/dl. Stderr dice Download base: ... (from the device's .flock). Así se convierte una máquina que alcanza el appliance pero no ironflock.com. Un archivo .flock de la nube de IronFlock usa la nube.
3. Si no, de la nube de IronFlock, https://instance-registry.ironflock.com/dl.

Con la réplica del appliance, los archivos vienen primero de la réplica y, cuando la réplica no los ofrece, de la nube de IronFlock:

• El catálogo, <mirror>/ironflockos/manifest.json — cuando la réplica no ofrece ninguno en ese momento (no se puede alcanzar, responde con un error, o solo la copia guardada de su último catálogo lo sustituiría), todo viene de la nube, como sin appliance. Un catálogo que ofrece la réplica y que se rechaza (su firma, más antiguo que la copia guardada, demasiado grande) hace fallar el comando, como desde cualquier servidor.
• La imagen, <mirror>/ironflockos/<version>/<file> — cuando la réplica no la ofrece (no se puede alcanzar, responde con algo que no es el archivo, o lo que envía no es el principio de la imagen), viene de la URL que indica el catálogo firmado. Un archivo de la caché de os flash no pregunta a ninguna de las dos.
• La lista de hardware, <mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — la misma regla, por separado.

Cada recurso a la nube es una advertencia en el plan, con la réplica, el archivo y el motivo; con --json, en warnings. El plan decide una sola vez la fuente de cada archivo: la preparación descarga la imagen de la image.url del plan y no vuelve a recurrir a otra fuente. Cuando ni la réplica ni la nube ofrecen un archivo, el comando falla con un único error que nombra ambas fuentes y ambos motivos (neither the appliance's mirror ... nor the IronFlock cloud gives ...).

A la réplica se llega directamente, y a la nube a través del proxy, como en agent install. Una réplica HTTPS con un certificado de la CA propia del appliance solo funciona donde el sistema de la máquina confía en esa CA. Cuando el appliance responde, el sistema nuevo conserva la tarjeta de red que llegó a él (Qué recibe el sistema nuevo).

Antes de que cambie nada

El comando comprueba la máquina en este orden. La primera comprobación que falla rechaza la máquina, con el código de salida 3 y una frase que indica la causa y, si la hay, la salida. Hasta ese momento no se ha cambiado nada.

1. El sistema — systemd es PID 1, el sistema no es un contenedor y no es IronFlockOS ni ReswarmOS.
2. El firmware — UEFI de 64 bits, variables EFI que se pueden escribir y, con Secure Boot activado, una cadena de arranque de la imagen que el firmware vaya a arrancar (Secure Boot).
3. La imagen — del catálogo firmado de IronFlockOS, como la lista os images: la imagen de --image o, si no, la imagen base del target de la máquina. El comando lee los primeros MiB del archivo de imagen: de la caché de os flash cuando el archivo está allí o, si no, del servidor de descargas (primero de la réplica del appliance, consulta De dónde vienen los archivos). Un archivo .flock para otro hardware solo provoca una advertencia.
4. El disco — el que tiene la partición que indica la opción de arranque actual del firmware; si no, el que tiene la partición de sistema EFI montada en /boot/efi o /efi; si no, el que indica --disk. Se rechaza un --disk que indica un disco distinto de aquel desde el que arrancó el sistema. También se rechaza un disco que no es un disco entero propio: un array MD RAID (también uno que crea Intel RST), un dispositivo device-mapper, loop o de bloques en red, un disco en memoria.
5. Lo que hay construido sobre el disco — particiones, LVM con volúmenes lineales y lo que configura cryptsetup para el cifrado (LUKS, dm-crypt simple, BitLocker, FileVault, TrueCrypt). Todo lo demás se rechaza: MD RAID, bcache, multipath, un pool ZFS, thin pools de LVM, snapshots, cachés, RAID y espejos, dm-verity, dm-integrity. Los demás discos se quedan como están, así que se rechaza un sistema de archivos btrfs o un grupo de volúmenes LVM con miembros en este disco y en otro: reemplazar el disco lo destruiría en ambos. También se rechaza una máquina con otro disco que tiene una partición llamada IRONFLOCKOS, rootfs-a, rootfs-b o data, ya que IronFlockOS encuentra sus particiones por estos nombres.
6. Memoria — como arriba.
7. El archivo .flock, la red, el proxy, los drivers — el archivo .flock se lee como lo lee os flash, y su clave SSH tiene que ser válida. La red y el proxy se comprueban como se describe en Qué recibe el sistema nuevo. Para los drivers, el comando toma los dispositivos en el camino hacia el disco y hacia la tarjeta de red (el disco, la tarjeta, sus controladoras y sus buses) y los busca en la lista de hardware de la imagen. Solo rechaza la máquina cuando la lista muestra que la imagen no tiene driver para uno de ellos. Un dispositivo sobre el que no puede decidir se nombra en la advertencia drivers not checked; para un release sin lista de hardware (hasta 0.14.0), la advertencia nombra todos los dispositivos.
8. El plan y la pregunta — consulta más abajo.

Ctrl-C mientras el comando lee el principio de la imagen lo termina con el código de salida 130, y lo mismo ocurre con una terminal perdida mientras se muestra el plan o espera la pregunta. En ese caso no se ha cambiado nada.

El plan y --dry-run

El plan va a stderr. Indica la máquina y su firmware, el disco y cómo se encontró, la imagen y de dónde viene su archivo, y la memoria. Dice que se pierde todo lo que hay en el disco, qué recibe el sistema nuevo y qué no recibe, y las advertencias. --dry-run muestra el plan, no cambia nada y termina con el código de salida 0. Con --dry-run, --yes no necesita --disk.

En una VM de Compute Engine, el plan advierte de que desaparece el entorno de invitado de Google: gcloud compute ssh, OS Login y las claves SSH de los metadatos dejan de funcionar, y la consola serie se mantiene.

Qué recibe el sistema nuevo

El sistema nuevo recibe:

• La identidad del dispositivo — la del archivo .flock, que va a la partición IRONFLOCKOS. El dispositivo se inscribe con él en su primer inicio.
• La red — la de la tarjeta de red por la que pasó la descarga de la imagen, hacia el servidor de descargas o hacia el proxy. Cuando la base de descarga es la réplica del appliance del archivo .flock y la réplica respondió de algún modo a la petición del catálogo (también con un 404), es en su lugar la tarjeta de la conexión con la réplica, vengan de donde vengan los archivos: el appliance es adonde se conecta el dispositivo nuevo. Un cable con DHCP no necesita nada. Una dirección estática (direcciones sin tiempo de vida, puertas de enlace y rutas definidas a mano, los servidores DNS de systemd-resolved o de /etc/resolv.conf) se convierte en un perfil de NetworkManager que identifica la tarjeta por su dirección MAC permanente. Una dirección estática junto a DHCP o SLAAC mantiene DHCP y añade la estática. Con WiFi, la red del archivo .flock no necesita nada; otra red con un perfil WPA-PSK o WPA3-SAE de NetworkManager, oculta o no, recibe ese perfil. Las direcciones de otras tarjetas no se trasladan, y el plan lo advierte.
• El proxy — el proxy de la descarga pasa a ser el ajuste de proxy de IronFlockOS (proxy.conf en la partición IRONFLOCKOS), con el usuario y la contraseña, y no_proxy. Se rechaza un proxy en la propia máquina (127.0.0.1), ya que el sistema nuevo no lo tiene. También una réplica que responde en el loopback de la máquina: un archivo .flock cuyo update_url indica localhost, como lo tiene el agente del propio host del appliance. Se rechaza una URL de proxy con caracteres que proxy.conf no admite, y el rechazo nombra la parte.
• SSH — la cuenta del propietario del proyecto con la clave del archivo .flock, como la tiene todo dispositivo IronFlockOS.

IronFlockOS 0.15.0 y posteriores toman los perfiles de red y el ajuste de proxy de la partición IRONFLOCKOS. Con una imagen de un release anterior, se rechaza una máquina cuya red necesita un perfil o cuya descarga pasa por un proxy; el rechazo nombra la tarjeta, su dirección estática o su WiFi, y qué hacer en su lugar.

El sistema nuevo no recibe las cuentas de usuario del sistema anterior con sus contraseñas y claves SSH, las claves de host SSH (los clientes SSH ven una clave de host nueva), ni los paquetes, los ajustes y los datos. Las apps del dispositivo vuelven desde IronFlock; sus datos en esta máquina, no.

La pregunta

El comando te pide que escribas el nombre de host corto de la máquina, que muestra la pregunta. En una máquina cuyo kernel tiene el nombre completo (las imágenes de Ubuntu de Compute Engine), también se acepta el nombre completo. Cualquier otra cosa, también Enter solo, responde no: código de salida 4. Consulta Preguntas y confirmación.

--yes solo responde a la pregunta cuando --disk indica el disco. En un sistema cifrado, --yes necesita además --allow-unencrypted; si no, el comando termina con el código de salida 4. Sin terminal, y con --json, no se puede hacer la pregunta: sin --yes el comando termina con el código de salida 4.

Después de la pregunta: preparación y traspaso

No se escribe nada en el disco antes del reinicio. El comando prepara el reemplazo en memoria:

1. Un sistema de archivos en memoria recibe la imagen: el archivo de la caché de os flash cuando el plan la leyó allí o, si no, una descarga (que se muestra como Downloading), comprobada con el catálogo firmado (Checking). La imagen se descomprime una vez (Preparing) y se compara con lo que leyó el plan. Se preparan los archivos para la partición IRONFLOCKOS.
2. Una opción de arranque para IronFlockOS se añade al final del orden de arranque del firmware, detrás de la del sistema en ejecución. Hasta que se escribe el disco, sigue arrancando primero el sistema en ejecución.
3. Staged: en stderr nombra la nueva opción de arranque y las opciones de arranque del sistema anterior, que se borran después de la escritura.
4. El comando hace el traspaso: la máquina se reinicia de inmediato o, cuando el comando se ejecuta en una sesión SSH (también a través de sudo y de --host), diez segundos después de que haya terminado el comando, para que el resultado llegue antes a la sesión. Stdout dice Handed over: ..., y el comando termina con el código de salida 0.

Ctrl-C o SIGTERM desde la pregunta hasta el traspaso deshacen la preparación: el comando termina con el código de salida 130, y la máquina queda como estaba. Después de la pregunta, una terminal o una sesión SSH perdida ya no detiene el comando: la preparación continúa, y el traspaso y el reinicio se producen. Una vez traspasado el reinicio, Ctrl-C termina el comando, y el reinicio sigue adelante.

El reinicio y la escritura

Al final del apagado, ironflock escribe la imagen desde la memoria en el disco. La consola de la máquina muestra sus líneas, que empiezan por ironflock-install:. Después, la máquina arranca IronFlockOS, y el dispositivo aparece en IronFlock en unos diez minutos. El registro de la escritura es ironflock-install.log, en la partición IRONFLOCKOS del sistema nuevo.

Cuando vuelve a arrancar el sistema anterior

Antes de escribir, ironflock comprueba el disco una vez más. Cuando algo no se cumple, vuelve a arrancar el sistema anterior, sin cambios: el disco está ocupado o es de solo lectura, no es el disco del plan, la imagen preparada está dañada, o los pasos previos a la escritura tardan más de dos minutos. El motivo está en la variable EFI IronFlockInstall. ironflock status lo muestra en su línea OS install:, sin 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

# En la máquina
ironflock status
# Desde otra computadora
ironflock --host admin@machine status
# Sin ironflock: imprime la etapa, la hora y el motivo
tail -c +5 /sys/firmware/efi/efivars/IronFlockInstall-7b2f7cb6-eb8f-4acd-b7fd-e92df1a035a0

Con --host

ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes ejecuta el comando en esa máquina como se ejecuta cualquier comando con --host: el binario y el archivo .flock van allí, las comprobaciones, el plan y la pregunta se ejecutan allí, y su salida vuelve. La carpeta con el binario y la copia del archivo .flock se elimina cuando termina allí el comando, también tras un rechazo o una interrupción. --dry-run no cambia nada en la máquina aparte de esa carpeta.

El reinicio llega diez segundos después de que haya terminado el comando, así que su resultado llega antes a tu lado. Después de la pregunta, una conexión perdida ya no detiene allí el comando: cuando la conexión se corta, el comando de tu lado termina con el código de salida 255 y dice que la máquina sigue por sí sola.

Después del traspaso, el comando espera hasta 15 minutos a que la máquina vuelva como IronFlockOS:

• Cada 15 segundos inicia sesión en la misma dirección como el usuario SSH del archivo .flock, con la clave del archivo .flock. La clave va a un archivo de una carpeta nueva que solo tú puedes leer, y la carpeta se elimina cuando termina la espera. La clave no va al agente SSH.
• Toma la clave de host del sistema nuevo sin escribirla en ninguna parte: known_hosts se queda como está.
• Lee qué ejecuta el sistema y si el agente del dispositivo se ha conectado a IronFlock desde el arranque.
• Mientras tanto, pregunta al sistema anterior, solo con una clave de host que tenga known_hosts, por la variable EFI IronFlockInstall: una máquina que vuelve con su sistema anterior termina la espera de inmediato.

La espera termina con el código de salida 0 cuando la máquina ejecuta IronFlockOS y el agente del dispositivo está conectado. Termina con 1 cuando la máquina ejecuta IronFlockOS sin un agente conectado, ha vuelto con su sistema anterior o no ha respondido como IronFlockOS en 15 minutos. Una dirección que DHCP ha cambiado hace fallar la comprobación; el mensaje remite entonces al dispositivo en IronFlock y a la consola de la máquina. Ctrl-C termina la espera con 130, y la máquina sigue por sí sola.

La espera no puede saber qué máquina responde en la dirección, porque la clave de host del sistema nuevo es nueva para tu lado. La prueba es que el dispositivo aparezca como conectado en IronFlock.

La espera necesita el archivo .flock en tu lado. Sin -c, o con un archivo .flock que no configura ningún usuario SSH, el comando termina con el código de salida 2 antes de que nada vaya a la máquina, salvo que indiques --no-wait. --no-wait hace el traspaso y termina con el código de salida del comando en la máquina.

Secure Boot

Con Secure Boot activado, el comando comprueba que el firmware vaya a arrancar la cadena de arranque de la imagen, shim y después GRUB:

• una firma del shim de la imagen se encadena, a través de los certificados que lo acompañan, hasta un certificado de la base de datos de firmas del firmware (db), y la base de datos de firmas prohibidas (dbx) no revoca ninguno de ellos; o db contiene el hash de shim.
• ni dbx ni la lista de prohibidos de shim en esta máquina (MokListX) contienen el shim o el GRUB de la imagen, ni un certificado con el que está firmado GRUB.
• el nivel SBAT de la máquina (SbatLevelRT) no revoca ni shim ni GRUB.

Cuando el firmware no arrancaría la imagen, el comando la rechaza. Puedes desactivar Secure Boot en la configuración del firmware: IronFlockOS también arranca sin él. En un sistema que no arrancó a través de shim, el plan advierte de que no se comprobaron el nivel SBAT ni MokListX. El comando no verifica el valor de la firma de shim ni examina el kernel; el catálogo firmado responde por ellos. Con --json, machine.secure_boot.ca indica el certificado de db hasta el que se encadena la firma de shim, como Microsoft UEFI CA 2023.

Ejemplos

# Mostrar el plan para el dispositivo del agente instalado, sin cambiar nada
sudo ironflock os install --dry-run
# El plan para un dispositivo nuevo, como JSON
sudo ironflock os install -c device.flock --dry-run --json
# Reemplazar el sistema sin pregunta
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# Desde otra computadora, y esperar hasta que el dispositivo esté en línea
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

Resultado

El plan de sudo ironflock os install -c device.flock --dry-run, en 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.

La ejecución de sudo ironflock os install -c device.flock --disk /dev/sda --yes muestra el mismo plan y después la preparación y el traspaso:

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, el resultado es el plan como un objeto JSON: con --dry-run de inmediato; sin él, después del traspaso, con dry_run en false y con staging; y con --host, después de la espera, también con wait. Stderr recibe el progreso como líneas JSON y nada más (Salida y JSON). Ningún campo contiene un secreto: los archivos para la partición IRONFLOCKOS se nombran con su tamaño, y las URL de proxy se muestran sin la contraseña. El resultado de la simulación de arriba, con saltos de línea añadidos (el comando escribe una sola línea; ... marca lo que omite el ejemplo):

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

Cuándo se niega

El comando se niega con el código de salida 3, y no se cambia nada, en estos casos:

• un contenedor, un sistema sin systemd como PID 1, IronFlockOS (os update instala allí un release), ReswarmOS.
• BIOS, UEFI de 32 bits, una arquitectura sin imagen, variables EFI que no están montadas (el rechazo nombra el comando mount) o que están montadas como solo lectura (nombra mount -o remount,rw).
• un Secure Boot que no arrancaría el shim o el GRUB de la imagen.
• un disco que el comando no puede determinar (indícalo con --disk), un --disk que no es el disco desde el que arrancó el sistema, una partición, ningún disco; un disco que no es un disco entero propio, o que lsblk no lista; un disco sin GPT.
• un sistema de archivos raíz en otro disco, repartido en varios discos, en ZFS o en ningún disco (un sistema live).
• sectores lógicos distintos de 512 bytes, un disco demasiado pequeño, una pila de almacenamiento que el comando no sabe descomponer, un sistema de archivos btrfs o un grupo de volúmenes LVM repartido entre este disco y otro, otro disco con los nombres de partición de IronFlockOS.
• demasiado poca memoria.
• una red que el comando no traslada, un proxy en la propia máquina o la réplica del appliance en el loopback de la máquina, un proxy con una imagen que no admite proxy.conf o con caracteres que proxy.conf no admite, un perfil activo de NetworkManager que no se puede leer.
• una lista de hardware del release que muestra que la imagen no tiene driver para un dispositivo del disco o de la tarjeta de red.
• un ip de iproute2 que no se ejecuta: no se puede leer la red.
• después de la pregunta, antes de que la preparación cambie nada: un disco que ya no es el del plan, un /run/initramfs que ya es un punto de montaje, un plan que no se puede llevar a cabo tal como está.

Estas son líneas de comandos incorrectas, código de salida 2, comprobadas antes de que se cambie nada:

• --yes sin --disk, salvo con --dry-run.
• sin -c en una máquina sin agente del dispositivo instalado; con --host sin --no-wait, sin -c o con un archivo .flock que no configura ningún usuario SSH.
• un --image que el catálogo no tiene, uno para un target distinto del de la máquina, o la memoria USB de instalación (que escribe os flash --installer).
• una URL de proxy con contraseña, y los demás errores en los flags de proxy que rechaza agent install.
• varias máquinas (--host más de una vez, --hosts).

Cuándo falla

El comando falla con el código de salida 1, y no se cambia nada, cuando:

• el archivo .flock no es válido, o su clave SSH no es válida.
• el catálogo no se verifica o no se puede obtener, como en os images; con la réplica del appliance, ni de la réplica ni de la nube.
• no se puede descargar el principio del archivo de imagen (getting the image ...), con la réplica del appliance ni de la réplica ni de la nube, o no es una imagen de IronFlockOS tal como la conoce el comando. Cuando el catálogo vino de la nube porque la réplica no ofreció ninguno, el error empieza con la advertencia del catálogo, the appliance's mirror ... gives no IronFlockOS catalog now (...), y nombra ambos servidores.
• la dirección local de la descarga no pertenece a ninguna tarjeta de red; no se pueden leer la tabla de montajes, los dispositivos de bloques o la memoria; las variables EFI no se pueden analizar.
• después de la pregunta: el archivo de imagen no es el del catálogo o no es lo que leyó el plan (el mensaje nombra ambos valores), la descarga falla, el firmware no acepta la opción de arranque o no se puede iniciar el reinicio. La preparación se deshace. Cuando deshacerla también falla, el mensaje pide un reinicio, que elimina lo que queda.

No se imprime ninguna URL con el usuario y la contraseña que pueda contener.

Códigos de salida

El significado de cada código para todos los comandos está en Flags, salida y códigos de salida.