Substituir o Linux pelo IronFlockOS

O ironflock os install substitui pelo IronFlockOS, no mesmo disco, o Linux a partir do qual uma máquina em execução iniciou, e torna a máquina o dispositivo IronFlock de um arquivo de configuração do dispositivo (.flock). Você o executa na própria máquina, ou a partir de outro computador via SSH.

Aviso: Tudo o que está no disco a partir do qual a máquina iniciou é perdido: o sistema em execução, os seus pacotes e configurações, as suas contas de usuário e todos os dados. Não há volta. Execute o comando primeiro com --dry-run e leia o plano.

Quando usar

Use o os install para uma máquina que já roda Debian, Ubuntu ou outro Linux com systemd, e que você não pode ou não quer iniciar a partir de um pen drive: um PC dentro de um painel elétrico, uma máquina virtual em uma nuvem, uma máquina que você só alcança via SSH. Com --host, você executa o comando a partir do seu próprio computador, também de um Mac, e ele espera até que a máquina esteja online como dispositivo IronFlock.

Use outro comando quando:

• Você consegue iniciar a máquina a partir de uma unidade — o ironflock os flash grava o IronFlockOS em um pen drive, um cartão SD ou um disco externo. Com --installer, ele grava um pen drive de instalação, que instala o IronFlockOS no disco interno do PC que inicia a partir dele. O pen drive de instalação também é a saída para a maioria das máquinas que o os install recusa.
• A máquina é um Raspberry Pi — o os install só instala as imagens para máquinas UEFI (alvos amd64-efi e arm64-efi). Grave o cartão SD do Raspberry Pi com o os flash.
• A máquina já roda o IronFlockOS — o os install a recusa. O ironflock os update instala outra release ali.
• Você quer manter o Linux da máquina — o ironflock agent install conecta a máquina ao IronFlock como ela está.

ironflock os install

Verifica a máquina, mostra o plano da substituição e pergunta. Depois prepara o IronFlockOS na memória e reinicia a máquina, que grava o IronFlockOS no disco no fim do seu desligamento e o inicia.

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

No macOS, o comando termina com o código de saída 3 antes de examinar qualquer coisa; ali, execute-o com --host. Ele roda em uma máquina por vez: --host informado mais de uma vez e --hosts terminam com o código de saída 2. As flags globais estão em Flags, saída e códigos de saída.

Flags

As flags de proxy funcionam como no agent install. Sem elas, o comando usa HTTP_PROXY, HTTPS_PROXY e NO_PROXY do ambiente. Uma URL de proxy que contém uma senha é uma linha de comando incorreta (código de saída 2); veja Segredos.

O que a máquina precisa ter

• O sistema — Linux com systemd como PID 1, como Debian ou Ubuntu, fora de um contêiner. IronFlockOS e ReswarmOS são recusados.
• O firmware — UEFI de 64 bits em amd64 ou arm64. As suas variáveis EFI estão montadas (efivarfs) e graváveis. BIOS e UEFI de 32 bits são recusados. O Secure Boot pode estar ativado; veja Secure Boot.
• O disco — o disco a partir do qual o firmware iniciou o sistema: um disco inteiro próprio, com GPT (tabela de partição GUID) e setores lógicos de 512 bytes. O sistema de arquivos raiz está neste disco e em nenhum outro, diretamente ou via LVM ou LUKS. O disco tem pelo menos o tamanho mínimo de disco da imagem: o tamanho que o catálogo indica, senão 10 GiB, ou 18 GiB para uma imagem nvidia.
• Memória — memória disponível (MemAvailable) para a imagem compactada, o binário ironflock e mais 512 MiB: uma máquina de cerca de 2 GiB para a imagem base.
• Ferramentas — lsblk e o ip do iproute2.
• A rede — o servidor de download alcançável, diretamente ou por um proxy, por uma rede que o novo sistema possa usar (O que o novo sistema recebe). Para um dispositivo de um appliance IronFlock, esse pode ser o espelho de downloads do appliance (De onde vêm os arquivos).
• O arquivo .flock — o de -c, ou o do agente do dispositivo instalado na máquina.

De onde vêm os arquivos

O comando precisa do catálogo assinado do IronFlockOS, da imagem e da lista de hardware da imagem. Ele os obtém de:

1. --download-base, senão IRONFLOCK_DL_BASE: apenas desse servidor.
2. Senão, do espelho de downloads do appliance IronFlock que o arquivo .flock indica como servidor de atualizações: o seu update_url, quando ele é uma URL http ou https absoluta cujo host não é um da nuvem IronFlock, como https://registry.<domain>/dl ou http://<host>:<port>/dl. O stderr diz Download base: ... (from the device's .flock). Uma máquina que alcança o appliance, mas não o ironflock.com, é convertida assim. Um arquivo .flock da nuvem IronFlock usa a nuvem.
3. Senão, da nuvem IronFlock, https://instance-registry.ironflock.com/dl.

Com o espelho do appliance, os arquivos vêm primeiro do espelho e, quando o espelho não os fornece, da nuvem IronFlock:

• O catálogo, <mirror>/ironflockos/manifest.json — quando o espelho não fornece nenhum no momento (não pode ser alcançado, responde com um erro, ou só a cópia guardada do seu último catálogo o substituiria), tudo vem da nuvem, como sem appliance. Um catálogo que o espelho fornece e que é rejeitado (pela assinatura, mais antigo que a cópia guardada, grande demais) faz o comando falhar, como com qualquer servidor.
• A imagem, <mirror>/ironflockos/<version>/<file> — quando o espelho não a fornece (não pode ser alcançado, responde com algo que não é o arquivo, ou o que envia não é o início da imagem), ela vem da URL que o catálogo assinado indica. Um arquivo do cache do os flash não consulta nenhum dos dois.
• A lista de hardware, <mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — a mesma regra, por conta própria.

Cada fallback é um aviso no plano, com o espelho, o arquivo e o motivo; com --json, em warnings. O plano decide a origem de cada arquivo uma única vez: a preparação baixa a imagem do image.url do plano e não faz fallback de novo. Quando nem o espelho nem a nuvem fornecem um arquivo, o comando falha com um único erro que indica as duas fontes e os dois motivos (neither the appliance's mirror ... nor the IronFlock cloud gives ...).

O espelho é alcançado diretamente, e a nuvem pelo proxy, como no agent install. Um espelho HTTPS com um certificado da CA própria do appliance só funciona onde o sistema da máquina confia nessa CA. Quando o appliance responde, o novo sistema mantém a placa de rede que o alcançou (O que o novo sistema recebe).

Antes de qualquer alteração

O comando verifica a máquina nesta ordem. A primeira verificação que falha recusa, com o código de saída 3 e uma frase que indica a causa e, quando existe, a saída. Até ali, nada foi alterado.

1. O sistema — o systemd é o PID 1, o sistema não é um contêiner, e não é IronFlockOS nem ReswarmOS.
2. O firmware — UEFI de 64 bits, variáveis EFI graváveis e, com o Secure Boot ativado, uma cadeia de boot da imagem que o firmware vai iniciar (Secure Boot).
3. A imagem — do catálogo assinado do IronFlockOS, como o os images a lista: a imagem de --image, senão a imagem base do alvo da máquina. O comando lê os primeiros MiB do arquivo de imagem: do cache do os flash quando o arquivo está lá, senão do servidor de download (primeiro do espelho do appliance, veja De onde vêm os arquivos). Um arquivo .flock para outro hardware gera apenas um aviso.
4. O disco — o que tem a partição que a opção de boot atual do firmware indica; senão o que tem a partição de sistema EFI montada em /boot/efi ou /efi; senão o que --disk indica. Um --disk que indica outro disco que não aquele a partir do qual o sistema iniciou é recusado. Também é recusado um disco que não é um disco inteiro próprio: um array MD RAID (também um criado pelo Intel RST), um dispositivo device-mapper, loop ou de bloco de rede, um disco em memória.
5. O que está construído sobre o disco — partições, LVM com volumes lineares e o que o cryptsetup configura para criptografia (LUKS, dm-crypt plain, BitLocker, FileVault, TrueCrypt). Todo o resto é recusado: MD RAID, bcache, multipath, um pool ZFS, thin pools LVM, snapshots, caches, RAID e espelhamentos, dm-verity, dm-integrity. Os outros discos ficam como estão, então um sistema de arquivos btrfs ou um volume group LVM com membros neste disco e em outro é recusado: substituir o disco o destruiria nos dois. Uma máquina com outro disco que tem uma partição chamada IRONFLOCKOS, rootfs-a, rootfs-b ou data também é recusada, pois o IronFlockOS encontra as suas partições por esses nomes.
6. Memória — como acima.
7. O arquivo .flock, a rede, o proxy, os drivers — o arquivo .flock é lido como o os flash o lê, e a sua chave SSH precisa ser válida. A rede e o proxy são verificados como descrito em O que o novo sistema recebe. Para os drivers, o comando pega os dispositivos no caminho até o disco e até a placa de rede (o disco, a placa, os seus controladores e barramentos) e os procura na lista de hardware da imagem. Ele só recusa quando a lista mostra que a imagem não tem driver para um deles. Um dispositivo sobre o qual ele não consegue decidir é indicado no aviso drivers not checked; para uma release sem lista de hardware (até a 0.14.0), o aviso indica todos os dispositivos.
8. O plano e a pergunta — veja abaixo.

Ctrl-C enquanto o comando lê o início da imagem o encerra com o código de saída 130, e o mesmo acontece com um terminal perdido enquanto o plano é mostrado ou a pergunta espera. Nada foi alterado nesse caso.

O plano e --dry-run

O plano vai para o stderr. Ele indica a máquina e o seu firmware, o disco e como ele foi encontrado, a imagem e de onde vem o seu arquivo, e a memória. Ele diz que tudo o que está no disco é perdido, o que o novo sistema recebe e o que não recebe, e os avisos. --dry-run mostra o plano, não altera nada e termina com o código de saída 0. Com --dry-run, --yes não precisa de --disk.

Em uma VM do Compute Engine, o plano avisa que o ambiente de convidado do Google é removido: gcloud compute ssh, o OS Login e as chaves SSH de metadados deixam de funcionar, e o console serial continua.

O que o novo sistema recebe

O novo sistema recebe:

• A identidade do dispositivo — do arquivo .flock, que vai para a partição IRONFLOCKOS. O dispositivo se registra com ele na sua primeira inicialização.
• A rede — da placa de rede pela qual passou o download da imagem, até o servidor de download ou até o proxy. Quando a base de download é o espelho do appliance do arquivo .flock e o espelho respondeu de alguma forma à solicitação do catálogo (também com um 404), é a placa da conexão com o espelho, seja de onde for que os arquivos vieram: o appliance é onde o novo dispositivo se conecta. Um cabo com DHCP não precisa de nada. Um endereço estático (endereços sem tempo de vida, gateways e rotas definidos manualmente, os servidores DNS do systemd-resolved ou de /etc/resolv.conf) se torna um perfil do NetworkManager que identifica a placa pelo seu endereço MAC permanente. Um endereço estático ao lado de DHCP ou SLAAC mantém o DHCP e adiciona o estático. No WiFi, a rede do arquivo .flock não precisa de nada; outra rede com um perfil WPA-PSK ou WPA3-SAE do NetworkManager, oculta ou não, recebe esse perfil. Endereços de outras placas não são levados para o novo sistema, e o plano emite um aviso.
• O proxy — o proxy do download se torna a configuração de proxy do IronFlockOS (proxy.conf na partição IRONFLOCKOS), com o usuário e a senha, e no_proxy. Um proxy na própria máquina (127.0.0.1) é recusado, pois o novo sistema não o tem. O mesmo vale para um espelho que responde no loopback da máquina: um arquivo .flock cujo update_url indica localhost, como o tem o agente no próprio host do appliance. Uma URL de proxy com caracteres que o proxy.conf não aceita é recusada, e a recusa indica a parte.
• SSH — a conta do proprietário do projeto com a chave do arquivo .flock, como todo dispositivo IronFlockOS tem.

O IronFlockOS 0.15.0 e posteriores aceitam perfis de rede e a configuração de proxy da partição IRONFLOCKOS. Com uma imagem de uma release mais antiga, uma máquina cuja rede precisa de um perfil, ou cujo download passa por um proxy, é recusada; a recusa indica a placa, o seu endereço estático ou o seu WiFi, e o que fazer em vez disso.

O novo sistema não recebe as contas de usuário do sistema antigo com as suas senhas e chaves SSH, as chaves de host SSH (os clientes SSH veem uma nova chave de host), nem os pacotes, as configurações e os dados. Os apps do dispositivo voltam do IronFlock; os dados deles nesta máquina, não.

A pergunta

O comando pede que você digite o nome de host curto da máquina, que a pergunta mostra. Em uma máquina cujo kernel tem o nome completo (as imagens do Ubuntu do Compute Engine), o nome completo também é aceito. Qualquer outra coisa, inclusive Enter sozinho, responde não: código de saída 4. Veja Perguntas e confirmação.

--yes só responde à pergunta quando --disk indica o disco. Em um sistema criptografado, --yes também precisa de --allow-unencrypted; caso contrário, o comando termina com o código de saída 4. Sem terminal, e com --json, a pergunta não pode ser feita: sem --yes, o comando termina com o código de saída 4.

Depois da pergunta: preparação e transferência

Nada é gravado no disco antes da reinicialização. O comando prepara a substituição na memória:

1. Um sistema de arquivos em memória recebe a imagem: o arquivo do cache do os flash quando o plano o leu ali, senão um download (mostrado como Downloading), verificado com o catálogo assinado (Checking). A imagem é descompactada uma vez (Preparing) e comparada com o que o plano leu. Os arquivos para a partição IRONFLOCKOS são preparados.
2. Uma opção de boot para o IronFlockOS vai para o fim da ordem de boot do firmware, atrás da opção do sistema em execução. Até que o disco seja gravado, o sistema em execução ainda inicia primeiro.
3. Staged: no stderr indica a nova opção de boot e as opções de boot do sistema antigo, que são apagadas depois da gravação.
4. O comando faz a transferência: a máquina reinicia imediatamente ou, quando o comando roda em uma sessão SSH (também via sudo e --host), dez segundos depois que o comando terminou, para que o resultado chegue antes à sessão. O stdout diz Handed over: ..., e o comando termina com o código de saída 0.

Ctrl-C ou SIGTERM entre a pergunta e a transferência desfazem a preparação: o comando termina com o código de saída 130, e a máquina fica como estava. Depois da pergunta, um terminal ou uma sessão SSH perdidos não interrompem mais o comando: a preparação continua, e a transferência e a reinicialização acontecem. Depois da transferência, Ctrl-C encerra o comando, e a reinicialização segue adiante.

A reinicialização e a gravação

No fim do desligamento, o ironflock grava a imagem da memória no disco. O console da máquina mostra as suas linhas, que começam com ironflock-install:. Então a máquina inicia o IronFlockOS, e o dispositivo aparece no IronFlock em cerca de dez minutos. O log da gravação é ironflock-install.log na partição IRONFLOCKOS do novo sistema.

Quando o sistema antigo inicia de novo

Antes de gravar, o ironflock verifica o disco mais uma vez. Quando algo não se confirma, o sistema antigo inicia de novo, sem alteração: o disco está ocupado ou é somente leitura, não é o disco do plano, a imagem preparada está danificada, ou as etapas antes da gravação levam mais de dois minutos. O motivo fica na variável EFI IronFlockInstall. O ironflock status o mostra na sua linha OS install:, sem 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

# Na máquina
ironflock status
# A partir de outro computador
ironflock --host admin@machine status
# Sem o ironflock: imprime a etapa, o horário e o motivo
tail -c +5 /sys/firmware/efi/efivars/IronFlockInstall-7b2f7cb6-eb8f-4acd-b7fd-e92df1a035a0

Com --host

ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes executa o comando nessa máquina como todo comando roda com --host: o binário e o arquivo .flock vão para lá, as verificações, o plano e a pergunta rodam lá, e a saída deles volta. A pasta com o binário e a cópia do arquivo .flock é removida quando o comando lá termina, também depois de uma recusa ou de uma interrupção. --dry-run não altera nada na máquina além dessa pasta.

A reinicialização vem dez segundos depois que o comando terminou, para que o resultado chegue aqui primeiro. Depois da pergunta, uma conexão perdida não interrompe mais o comando lá: quando a conexão cai, o comando aqui termina com o código de saída 255 e diz que a máquina continua sozinha.

Depois da transferência, o comando espera, por até 15 minutos, que a máquina volte como IronFlockOS:

• A cada 15 segundos, ele faz login no mesmo endereço como o usuário SSH do arquivo .flock, com a chave do arquivo .flock. A chave vai para um arquivo em uma pasta nova que só você pode ler, e a pasta é removida quando a espera termina. A chave não vai para o agente SSH.
• Ele aceita a chave de host do novo sistema sem escrevê-la em lugar nenhum: o known_hosts fica como está.
• Ele lê qual sistema a máquina roda e se o agente do dispositivo se conectou ao IronFlock desde a inicialização.
• Enquanto isso, ele consulta o sistema antigo, apenas com uma chave de host que o known_hosts tem, sobre a variável EFI IronFlockInstall: uma máquina que volta com o seu sistema antigo encerra a espera imediatamente.

A espera termina com o código de saída 0 quando a máquina roda o IronFlockOS e o agente do dispositivo está conectado. Ela termina com 1 quando a máquina roda o IronFlockOS sem um agente conectado, voltou com o seu sistema antigo, ou não respondeu como IronFlockOS em até 15 minutos. Um endereço que o DHCP alterou frustra a verificação; a mensagem então aponta para o dispositivo no IronFlock e para o console da máquina. Ctrl-C encerra a espera com 130, e a máquina continua sozinha.

A espera não consegue saber qual máquina responde no endereço, porque a chave de host do novo sistema é desconhecida aqui. A prova é o dispositivo mostrado como conectado no IronFlock.

A espera precisa do arquivo .flock aqui. Sem -c, ou com um arquivo .flock que não configura nenhum usuário SSH, o comando termina com o código de saída 2 antes que qualquer coisa vá para a máquina, a menos que você informe --no-wait. --no-wait faz a transferência e termina com o código de saída do comando na máquina.

Secure Boot

Com o Secure Boot ativado, o comando verifica se o firmware vai iniciar a cadeia de boot da imagem, o shim e depois o GRUB:

• uma assinatura do shim da imagem forma uma cadeia, pelos certificados que vêm com ele, até um certificado no banco de dados de assinaturas do firmware (db), e o banco de dados de assinaturas proibidas (dbx) não revoga nenhum deles; ou o db lista o hash do shim.
• nem o dbx nem a lista de proibidos do shim nesta máquina (MokListX) listam o shim ou o GRUB da imagem, ou um certificado com que o GRUB é assinado.
• o nível SBAT da máquina (SbatLevelRT) não revoga nem o shim nem o GRUB.

Quando o firmware não iniciaria a imagem, o comando recusa. Você pode desativar o Secure Boot na configuração do firmware: o IronFlockOS também inicia sem ele. Em um sistema que não iniciou pelo shim, o plano avisa que o nível SBAT e a MokListX não foram verificados. O comando não verifica o valor da assinatura do shim nem examina o kernel; o catálogo assinado responde por eles. Com --json, machine.secure_boot.ca indica o certificado no db até o qual a assinatura do shim forma a cadeia, como Microsoft UEFI CA 2023.

Exemplos

# Mostrar o plano para o dispositivo do agente instalado, sem alterar nada
sudo ironflock os install --dry-run
# O plano para um novo dispositivo, como JSON
sudo ironflock os install -c device.flock --dry-run --json
# Substituir o sistema sem pergunta
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# A partir de outro computador, esperando até que o dispositivo esteja online
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

Resultado

O plano de sudo ironflock os install -c device.flock --dry-run, no 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.

A execução de sudo ironflock os install -c device.flock --disk /dev/sda --yes mostra o mesmo plano e depois a preparação e a transferência:

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.

Com --json, o resultado é o plano como um único objeto JSON: com --dry-run, imediatamente; sem ele, depois da transferência, com dry_run igual a false e com staging; e, com --host, depois da espera, também com wait. O stderr recebe o progresso como linhas JSON e nada mais (Saída e JSON). Nenhum campo contém um segredo: os arquivos para a partição IRONFLOCKOS são indicados com o seu tamanho, e as URLs de proxy são mostradas sem a senha. O resultado da simulação acima, com quebras de linha adicionadas (o comando escreve uma linha; ... marca o que o exemplo omite):

{"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 recusa

O comando recusa com o código de saída 3, e nada é alterado:

• um contêiner, um sistema sem systemd como PID 1, o IronFlockOS (o os update instala uma release ali), o ReswarmOS.
• BIOS, UEFI de 32 bits, uma arquitetura sem imagem, variáveis EFI que não estão montadas (a recusa indica o comando mount) ou estão montadas como somente leitura (ela indica mount -o remount,rw).
• um Secure Boot que não iniciaria o shim ou o GRUB da imagem.
• um disco que o comando não consegue determinar (indique-o com --disk), um --disk que não é o disco a partir do qual o sistema iniciou, uma partição, nenhum disco; um disco que não é um disco inteiro próprio, ou que o lsblk não lista; um disco sem GPT.
• um sistema de arquivos raiz em outro disco, distribuído por vários discos, em ZFS ou em nenhum disco (um sistema live).
• setores lógicos diferentes de 512 bytes, um disco pequeno demais, uma pilha de armazenamento que o comando não sabe desfazer, um sistema de arquivos btrfs ou volume group LVM distribuído por este disco e outro, outro disco com os nomes de partição do IronFlockOS.
• memória insuficiente.
• uma rede que o comando não leva para o novo sistema, um proxy na própria máquina ou o espelho do appliance no loopback da máquina, um proxy com uma imagem que não aceita proxy.conf ou com caracteres que o proxy.conf não aceita, um perfil ativo do NetworkManager que não pode ser lido.
• uma lista de hardware da release que mostra que a imagem não tem driver para um dispositivo do disco ou da placa de rede.
• um ip do iproute2 que não roda: a rede não pode ser lida.
• depois da pergunta, antes que a preparação altere qualquer coisa: um disco que não é mais o do plano, um /run/initramfs que já é um ponto de montagem, um plano que não pode ser executado como está.

Estas são linhas de comando incorretas, código de saída 2, verificadas antes que qualquer coisa seja alterada:

• --yes sem --disk, a não ser com --dry-run.
• nenhum -c em uma máquina sem um agente do dispositivo instalado; com --host sem --no-wait, nenhum -c ou um arquivo .flock que não configura nenhum usuário SSH.
• um --image que o catálogo não tem, um para outro alvo que não o da máquina, ou o pen drive de instalação (que o os flash --installer grava).
• uma URL de proxy com senha, e as outras flags de proxy que o agent install recusa.
• várias máquinas (--host mais de uma vez, --hosts).

Quando falha

O comando falha com o código de saída 1, e nada é alterado:

• o arquivo .flock não é válido, ou a sua chave SSH não é válida.
• o catálogo não passa na verificação ou não pode ser obtido, como no os images; com o espelho do appliance, nem do espelho nem da nuvem.
• o início do arquivo de imagem não pode ser baixado (getting the image ...), com o espelho do appliance nem do espelho nem da nuvem, ou não é uma imagem do IronFlockOS como o comando a conhece. Quando o catálogo veio da nuvem porque o espelho não forneceu nenhum, o erro começa com o aviso do catálogo, the appliance's mirror ... gives no IronFlockOS catalog now (...), e indica os dois servidores.
• o endereço local do download não pertence a nenhuma placa de rede; a tabela de montagem, os dispositivos de bloco ou a memória não podem ser lidos; as variáveis EFI não podem ser interpretadas.
• depois da pergunta: o arquivo de imagem não é o do catálogo ou não é o que o plano leu (a mensagem indica os dois valores), o download falha, o firmware não aceita a opção de boot, ou a reinicialização não pode ser iniciada. A preparação é desfeita. Quando desfazê-la também falha, a mensagem pede uma reinicialização, que remove o que sobrou.

Nenhuma URL é impressa com o usuário e a senha que ela possa conter.

Códigos de saída

O significado de cada código para todos os comandos está em Flags, saída e códigos de saída.