Zastąpienie Linuksa systemem IronFlockOS

ironflock os install zastępuje Linuksa, z którego wystartowała działająca maszyna, systemem IronFlockOS na tym samym dysku i czyni z maszyny urządzenie IronFlock z pliku konfiguracji urządzenia (.flock). Uruchamiasz je na samej maszynie albo z innego komputera przez SSH.

Ostrzeżenie: Wszystko na dysku, z którego wystartowała maszyna, zostaje utracone: działający system, jego pakiety i ustawienia, jego konta użytkowników i wszystkie dane. Nie ma drogi powrotu. Najpierw uruchom polecenie z --dry-run i przeczytaj plan.

Kiedy używać tego polecenia

Używaj os install dla maszyny, która już działa pod Debianem, Ubuntu lub innym Linuksem z systemd i której nie możesz lub nie chcesz uruchamiać z pendrive’a USB: komputera PC w szafie sterowniczej, maszyny wirtualnej w chmurze, maszyny dostępnej tylko przez SSH. Z --host uruchamiasz polecenie ze swojego komputera, także z Maca, a ono czeka, aż maszyna będzie online jako urządzenie IronFlock.

Użyj innego polecenia, gdy:

• Możesz uruchomić maszynę z nośnika — ironflock os flash zapisuje IronFlockOS na pendrivie USB, karcie SD lub dysku zewnętrznym. Z --installer zapisuje pendrive instalacyjny, który instaluje IronFlockOS na dysku wewnętrznym komputera PC, który z niego wystartuje. Pendrive instalacyjny to także wyjście dla większości maszyn, wobec których os install odmawia działania.
• Maszyna to Raspberry Pi — os install instaluje tylko obrazy dla maszyn z UEFI (platformy sprzętowe amd64-efi i arm64-efi). Kartę SD dla Raspberry Pi zapisz poleceniem os flash.
• Maszyna już działa pod IronFlockOS — os install odmawia wtedy działania. ironflock os update instaluje tam inne wydanie.
• Chcesz zachować Linuksa maszyny — ironflock agent install podłącza maszynę do IronFlock bez zmiany jej systemu.

ironflock os install

Sprawdza maszynę, pokazuje plan zastąpienia systemu i pyta. Następnie przygotowuje IronFlockOS w pamięci i restartuje maszynę, która pod koniec zamykania systemu zapisuje IronFlockOS na dysku i go uruchamia.

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

W macOS polecenie kończy się kodem wyjścia 3, zanim cokolwiek sprawdzi; tam uruchamiaj je z --host. Działa na jednej maszynie naraz: --host podane więcej niż raz oraz --hosts kończą się kodem wyjścia 2. Flagi globalne opisuje strona Flagi, wyjście i kody wyjścia.

Flagi

Flagi proxy działają tak jak w agent install. Bez nich polecenie bierze HTTP_PROXY, HTTPS_PROXY i NO_PROXY ze środowiska. Adres URL proxy z hasłem to błędny wiersz poleceń (kod wyjścia 2); zobacz Sekrety.

Czego potrzebuje maszyna

• System — Linux z systemd jako PID 1, na przykład Debian lub Ubuntu, nie w kontenerze. IronFlockOS i ReswarmOS są odrzucane.
• Firmware — 64-bitowe UEFI na amd64 lub arm64. Jego zmienne EFI są zamontowane (efivarfs) i zapisywalne. BIOS i 32-bitowe UEFI są odrzucane. Secure Boot może być włączony, zobacz Secure Boot.
• Dysk — dysk, z którego firmware uruchomił system: cały, osobny dysk z GPT (tablicą partycji GUID) i 512-bajtowymi sektorami logicznymi. Główny system plików leży na tym dysku i na żadnym innym, bezpośrednio lub przez LVM albo LUKS. Dysk ma co najmniej minimalny rozmiar dysku dla obrazu: rozmiar podany w katalogu, a w przeciwnym razie 10 GiB, a dla obrazu nvidia 18 GiB.
• Pamięć — dostępna pamięć (MemAvailable) na skompresowany obraz, plik binarny ironflock i dodatkowe 512 MiB: dla obrazu base wystarcza maszyna z około 2 GiB.
• Narzędzia — lsblk oraz ip z iproute2.
• Sieć — dostęp do serwera pobierania, bezpośrednio lub przez proxy, przez sieć, z której może korzystać nowy system (Co dostaje nowy system). Dla urządzenia IronFlock Appliance może to być kopia lustrzana pobierania Appliance (Skąd pochodzą pliki).
• Plik .flock — z -c albo agenta urządzenia zainstalowanego na maszynie.

Skąd pochodzą pliki

Polecenie potrzebuje podpisanego katalogu IronFlockOS, obrazu i listy sprzętu obrazu. Pobiera je:

1. Z --download-base, a w przeciwnym razie z IRONFLOCK_DL_BASE: tylko z tego serwera.
2. W przeciwnym razie z kopii lustrzanej pobierania tego IronFlock Appliance, który plik .flock podaje jako swój serwer aktualizacji: z jego update_url, gdy jest to bezwzględny adres URL http lub https, którego host nie należy do chmury IronFlock, na przykład https://registry.<domain>/dl lub http://<host>:<port>/dl. Stderr podaje Download base: ... (from the device's .flock). W ten sposób przekształca się maszynę, która dociera do Appliance, ale nie do ironflock.com. Plik .flock z chmury IronFlock korzysta z chmury.
3. W przeciwnym razie z chmury IronFlock, https://instance-registry.ironflock.com/dl.

Przy kopii lustrzanej Appliance pliki pochodzą najpierw z kopii lustrzanej, a tam, gdzie kopia lustrzana ich nie udostępnia, z chmury IronFlock:

• Katalog, <mirror>/ironflockos/manifest.json — gdy kopia lustrzana w danej chwili go nie udostępnia (nie można się z nią połączyć, odpowiada błędem albo zastąpiłaby go tylko zachowana kopia jej ostatniego katalogu), wszystko pochodzi z chmury, tak jak bez Appliance. Katalog, który kopia lustrzana udostępnia, ale który zostaje odrzucony (jego podpis, starszy niż zachowana kopia, za duży), kończy polecenie błędem, tak jak z każdego serwera.
• Obraz, <mirror>/ironflockos/<version>/<file> — gdy kopia lustrzana go nie udostępnia (nie można się z nią połączyć, odpowiada czymś innym niż ten plik albo to, co wysyła, nie jest początkiem obrazu), pochodzi z adresu URL podanego w podpisanym katalogu. Plik z pamięci podręcznej os flash nie pyta żadnego z nich.
• Lista sprzętu, <mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — ta sama zasada, osobno.

Każde przejście na chmurę to ostrzeżenie w planie, z kopią lustrzaną, plikiem i przyczyną; z --json w warnings. Plan raz ustala źródło każdego pliku: przygotowanie pobiera obraz z image.url planu i nie przechodzi ponownie na chmurę. Gdy pliku nie udostępnia ani kopia lustrzana, ani chmura, polecenie kończy się jednym błędem, który podaje oba źródła i obie przyczyny (neither the appliance's mirror ... nor the IronFlock cloud gives ...).

Z kopią lustrzaną polecenie łączy się bezpośrednio, a z chmurą przez proxy, tak jak agent install. Kopia lustrzana HTTPS z certyfikatem własnego CA Appliance działa tylko tam, gdzie system maszyny ufa temu CA. Gdy Appliance odpowiada, nowy system zachowuje kartę sieciową, przez którą do niego dotarł (Co dostaje nowy system).

Zanim cokolwiek się zmieni

Polecenie sprawdza maszynę w tej kolejności. Pierwsze nieudane sprawdzenie kończy się odmową z kodem wyjścia 3 i jednym zdaniem, które podaje przyczynę oraz, jeśli istnieje, wyjście z sytuacji. Do tego momentu nic nie zostaje zmienione.

1. System — systemd jest PID 1, system nie jest kontenerem i nie jest IronFlockOS ani ReswarmOS.
2. Firmware — 64-bitowe UEFI, zapisywalne zmienne EFI, a przy włączonym Secure Boot łańcuch rozruchu obrazu, który firmware uruchomi (Secure Boot).
3. Obraz — z podpisanego katalogu IronFlockOS, tak jak wyświetla go os images: obraz z --image, a w przeciwnym razie obraz podstawowy dla platformy sprzętowej maszyny. Polecenie odczytuje pierwsze kilka MiB pliku obrazu: z pamięci podręcznej os flash, gdy plik tam jest, a w przeciwnym razie z serwera pobierania (najpierw z kopii lustrzanej Appliance, zobacz Skąd pochodzą pliki). Plik .flock dla innego sprzętu powoduje tylko ostrzeżenie.
4. Dysk — ten z partycją, którą wskazuje bieżąca opcja rozruchu firmware; w przeciwnym razie ten z partycją systemową EFI zamontowaną w /boot/efi lub /efi; w przeciwnym razie ten wskazany przez --disk. --disk wskazujący inny dysk niż ten, z którego wystartował system, jest odrzucany. Tak samo dysk, który nie jest całym, osobnym dyskiem: macierz MD RAID (także utworzona przez Intel RST), urządzenie device-mapper, loop lub sieciowe urządzenie blokowe, dysk w pamięci.
5. Co jest zbudowane na dysku — partycje, LVM z woluminami liniowymi oraz to, co cryptsetup konfiguruje do szyfrowania (LUKS, zwykły dm-crypt, BitLocker, FileVault, TrueCrypt). Wszystko inne jest odrzucane: MD RAID, bcache, multipath, pula ZFS, pule thin LVM, migawki, woluminy cache, RAID i woluminy lustrzane, dm-verity, dm-integrity. Inne dyski pozostają bez zmian, więc system plików btrfs lub grupa woluminów LVM z członkami na tym dysku i na innym jest odrzucana: zastąpienie dysku zniszczyłoby je na obu dyskach. Maszyna z innym dyskiem, który ma partycję o nazwie IRONFLOCKOS, rootfs-a, rootfs-b lub data, również jest odrzucana, ponieważ IronFlockOS znajduje swoje partycje po tych nazwach.
6. Pamięć — jak wyżej.
7. Plik .flock, sieć, proxy, sterowniki — plik .flock jest odczytywany tak, jak odczytuje go os flash, a jego klucz SSH musi być prawidłowy. Sieć i proxy są sprawdzane tak, jak opisuje sekcja Co dostaje nowy system. W przypadku sterowników polecenie bierze urządzenia na drodze do dysku i do karty sieciowej (dysk, kartę, ich kontrolery i magistrale) i wyszukuje je na liście sprzętu obrazu. Odmawia działania tylko wtedy, gdy lista pokazuje, że obraz nie ma sterownika dla któregoś z nich. Urządzenie, którego polecenie nie potrafi ocenić, jest wymieniane w ostrzeżeniu drivers not checked; dla wydania bez listy sprzętu (do 0.14.0 włącznie) ostrzeżenie wymienia każde urządzenie.
8. Plan i pytanie — zobacz poniżej.

Ctrl-C w czasie, gdy polecenie odczytuje początek obrazu, kończy je kodem wyjścia 130; tak samo utrata terminala w czasie wyświetlania planu lub oczekiwania na odpowiedź na pytanie. Nic nie zostało wtedy zmienione.

Plan i --dry-run

Plan trafia na stderr. Podaje maszynę i jej firmware, dysk i sposób, w jaki go znaleziono, obraz i źródło jego pliku oraz pamięć. Mówi, że wszystko na dysku zostanie utracone, co nowy system dostanie, a czego nie, oraz podaje ostrzeżenia. --dry-run pokazuje plan, niczego nie zmienia i kończy się kodem wyjścia 0. Z --dry-run flaga --yes nie wymaga --disk.

Na maszynie wirtualnej Compute Engine plan ostrzega, że znika środowisko gościa Google: przestają działać gcloud compute ssh, OS Login i klucze SSH z metadanych, a konsola szeregowa pozostaje.

Co dostaje nowy system

Nowy system dostaje:

• Tożsamość urządzenia — z pliku .flock, który trafia na partycję IRONFLOCKOS. Urządzenie rejestruje się z nim przy pierwszym starcie.
• Sieć — karty sieciowej, przez którą szło pobieranie obrazu, do serwera pobierania lub do proxy. Gdy bazowym adresem pobierania jest kopia lustrzana Appliance z pliku .flock i kopia lustrzana w ogóle odpowiedziała na żądanie katalogu (także kodem 404), jest to zamiast tego karta połączenia z kopią lustrzaną, niezależnie od tego, skąd pochodziły pliki: to z Appliance łączy się nowe urządzenie. Kabel z DHCP niczego nie potrzebuje. Adres statyczny (adresy bez czasu życia, ręcznie ustawione bramy i trasy, serwery DNS z systemd-resolved lub /etc/resolv.conf) staje się profilem NetworkManager, który rozpoznaje kartę po jej stałym adresie MAC. Adres statyczny obok DHCP lub SLAAC zachowuje DHCP i dodaje adres statyczny. Przy WiFi sieć z pliku .flock niczego nie potrzebuje; inna sieć z profilem NetworkManager typu WPA-PSK lub WPA3-SAE, ukryta lub nie, dostaje ten profil. Adresy innych kart nie są przenoszone, a plan o tym ostrzega.
• Proxy — proxy pobierania staje się ustawieniem proxy IronFlockOS (proxy.conf na partycji IRONFLOCKOS), z użytkownikiem i hasłem oraz no_proxy. Proxy na samej maszynie (127.0.0.1) jest odrzucane, ponieważ nowy system go nie ma. Tak samo kopia lustrzana, która odpowiada na interfejsie loopback maszyny: plik .flock, którego update_url wskazuje localhost, jak ma go agent na hoście samego Appliance. Adres URL proxy ze znakami, których proxy.conf nie przyjmuje, jest odrzucany, a odmowa wskazuje tę część adresu.
• SSH — konto właściciela projektu z kluczem z pliku .flock, jak na każdym urządzeniu z IronFlockOS.

IronFlockOS 0.15.0 i nowsze biorą profile sieciowe i ustawienie proxy z partycji IRONFLOCKOS. Z obrazem starszego wydania maszyna, której sieć wymaga profilu albo której pobieranie idzie przez proxy, jest odrzucana; odmowa podaje kartę, jej adres statyczny lub sieć WiFi oraz to, co zrobić zamiast tego.

Nowy system nie dostaje kont użytkowników starego systemu z ich hasłami i kluczami SSH, kluczy hosta SSH (klienci SSH widzą nowy klucz hosta) ani pakietów, ustawień i danych. Aplikacje urządzenia wracają z IronFlock; ich dane z tej maszyny nie wracają.

Pytanie

Polecenie prosi o wpisanie krótkiej nazwy hosta maszyny, którą pokazuje pytanie. Na maszynie, której jądro ma pełną nazwę (obrazy Ubuntu w Compute Engine), przyjmowana jest także pełna nazwa. Każda inna odpowiedź, także sam Enter, oznacza „nie”: kod wyjścia 4. Zobacz Pytania i potwierdzenie.

--yes odpowiada na pytanie tylko wtedy, gdy --disk wskazuje dysk. Na zaszyfrowanym systemie --yes wymaga też --allow-unencrypted, w przeciwnym razie polecenie kończy się kodem wyjścia 4. Bez terminala i z --json nie można zadać pytania: bez --yes polecenie kończy się kodem wyjścia 4.

Po pytaniu: przygotowanie i przekazanie

Przed restartem nic nie jest zapisywane na dysku. Polecenie przygotowuje zastąpienie systemu w pamięci:

1. System plików w pamięci przyjmuje obraz: plik z pamięci podręcznej os flash, gdy plan odczytał go stamtąd, a w przeciwnym razie pobrany plik (pokazywane jako Downloading), sprawdzony z podpisanym katalogiem (Checking). Obraz jest raz rozpakowywany (Preparing) i porównywany z tym, co odczytał plan. Przygotowywane są pliki dla partycji IRONFLOCKOS.
2. Opcja rozruchu IronFlockOS trafia na koniec kolejności rozruchu firmware, za opcję działającego systemu. Dopóki dysk nie zostanie zapisany, nadal jako pierwszy startuje działający system.
3. Staged: na stderr podaje nową opcję rozruchu i opcje rozruchu starego systemu, które są usuwane po zapisie.
4. Polecenie dokonuje przekazania: maszyna restartuje się od razu albo, gdy polecenie działa w sesji SSH (także przez sudo i --host), dziesięć sekund po zakończeniu polecenia, tak aby wynik najpierw dotarł do sesji. Stdout podaje Handed over: ..., a polecenie kończy się kodem wyjścia 0.

Ctrl-C lub SIGTERM w czasie od pytania do przekazania cofa przygotowanie: polecenie kończy się kodem wyjścia 130, a maszyna jest taka jak przedtem. Po pytaniu utrata terminala lub sesji SSH nie zatrzymuje już polecenia: przygotowanie trwa dalej, a przekazanie i restart następują. Gdy restart zostanie przekazany, Ctrl-C kończy polecenie, a restart przebiega dalej.

Restart i zapis

Pod koniec zamykania systemu ironflock zapisuje obraz z pamięci na dysku. Konsola maszyny pokazuje jego wiersze, które zaczynają się od ironflock-install:. Następnie maszyna uruchamia IronFlockOS, a urządzenie pojawia się w IronFlock w ciągu około dziesięciu minut. Log zapisu to ironflock-install.log na partycji IRONFLOCKOS nowego systemu.

Gdy stary system startuje ponownie

Przed zapisem ironflock jeszcze raz sprawdza dysk. Gdy coś się nie zgadza, ponownie startuje stary system, bez zmian: dysk jest zajęty lub tylko do odczytu, nie jest dyskiem z planu, przygotowany obraz jest uszkodzony albo kroki przed zapisem trwają dłużej niż dwie minuty. Przyczyna jest w zmiennej EFI IronFlockInstall. ironflock status pokazuje ją w wierszu OS install:, bez roota:

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 maszynie
ironflock status
# Z innego komputera
ironflock --host admin@machine status
# Bez ironflock: wypisuje etap, czas i przyczynę
tail -c +5 /sys/firmware/efi/efivars/IronFlockInstall-7b2f7cb6-eb8f-4acd-b7fd-e92df1a035a0

Przez --host

ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes uruchamia polecenie na tej maszynie tak, jak każde polecenie działa przez --host: plik binarny i plik .flock trafiają tam, sprawdzenia, plan i pytanie działają tam, a ich wyjście wraca. Folder z plikiem binarnym i kopią pliku .flock jest usuwany, gdy polecenie tam się zakończy, także po odmowie lub przerwaniu. --dry-run nie zmienia na maszynie niczego poza tym folderem.

Restart następuje dziesięć sekund po zakończeniu polecenia, więc jego wynik najpierw dociera do ciebie. Po pytaniu utracone połączenie nie zatrzymuje już polecenia na maszynie: gdy połączenie zostanie zerwane, polecenie po twojej stronie kończy się kodem wyjścia 255 i informuje, że maszyna kontynuuje samodzielnie.

Po przekazaniu polecenie czeka do 15 minut, aż maszyna wróci jako IronFlockOS:

• Co 15 sekund loguje się pod tym samym adresem jako użytkownik SSH z pliku .flock, kluczem z pliku .flock. Klucz trafia do pliku w nowym folderze, który możesz odczytać tylko ty, a folder jest usuwany po zakończeniu oczekiwania. Klucz nie trafia do agenta SSH.
• Przyjmuje klucz hosta nowego systemu, nigdzie go nie zapisując: known_hosts pozostaje bez zmian.
• Odczytuje, jaki system działa i czy agent urządzenia połączył się z IronFlock od startu.
• W międzyczasie odpytuje stary system, tylko z kluczem hosta, który jest w known_hosts, o zmienną EFI IronFlockInstall: maszyna, która wraca ze starym systemem, natychmiast kończy oczekiwanie.

Oczekiwanie kończy się kodem wyjścia 0, gdy maszyna działa pod IronFlockOS, a agent urządzenia jest połączony. Kończy się kodem 1, gdy maszyna działa pod IronFlockOS bez połączonego agenta, wróciła ze starym systemem albo nie odpowiedziała jako IronFlockOS w ciągu 15 minut. Adres zmieniony przez DHCP uniemożliwia to sprawdzenie; komunikat wskazuje wtedy urządzenie w IronFlock i konsolę maszyny. Ctrl-C kończy oczekiwanie kodem 130, a maszyna kontynuuje samodzielnie.

Oczekiwanie nie może rozpoznać, która maszyna odpowiada pod danym adresem, ponieważ klucz hosta nowego systemu jest dla twojej strony nowy. Dowodem jest urządzenie pokazane w IronFlock jako połączone.

Oczekiwanie wymaga pliku .flock po twojej stronie. Bez -c albo z plikiem .flock, który nie konfiguruje użytkownika SSH, polecenie kończy się kodem wyjścia 2, zanim cokolwiek trafi na maszynę, chyba że podasz --no-wait. --no-wait dokonuje przekazania i kończy się kodem wyjścia polecenia na maszynie.

Secure Boot

Przy włączonym Secure Boot polecenie sprawdza, czy firmware uruchomi łańcuch rozruchu obrazu, czyli shim, a potem GRUB:

• łańcuch podpisu shima z obrazu prowadzi, przez dołączone do niego certyfikaty, do certyfikatu w bazie podpisów firmware (db), a baza zabronionych podpisów (dbx) nie unieważnia żadnego z nich; albo db zawiera skrót shima.
• ani dbx, ani lista zabronionych shima na tej maszynie (MokListX) nie zawiera shima ani GRUB-a z obrazu ani certyfikatu, którym podpisano GRUB-a.
• poziom SBAT maszyny (SbatLevelRT) nie unieważnia ani shima, ani GRUB-a.

Gdy firmware nie uruchomiłby obrazu, polecenie odmawia działania. Secure Boot możesz wyłączyć w ustawieniach firmware: IronFlockOS startuje także bez niego. Na systemie, który nie wystartował przez shim, plan ostrzega, że poziom SBAT i MokListX nie zostały sprawdzone. Polecenie nie weryfikuje wartości podpisu shima ani nie sprawdza jądra; ręczy za nie podpisany katalog. Z --json pole machine.secure_boot.ca podaje certyfikat w db, do którego prowadzi łańcuch podpisu shima, na przykład Microsoft UEFI CA 2023.

Przykłady

# Pokaż plan dla urządzenia zainstalowanego agenta, niczego nie zmieniaj
sudo ironflock os install --dry-run
# Plan dla nowego urządzenia jako JSON
sudo ironflock os install -c device.flock --dry-run --json
# Zastąp system bez pytania
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# Z innego komputera, z oczekiwaniem, aż urządzenie będzie online
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

Wynik

Plan z sudo ironflock os install -c device.flock --dry-run na 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.

Uruchomienie sudo ironflock os install -c device.flock --disk /dev/sda --yes pokazuje ten sam plan, a potem przygotowanie i przekazanie:

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.

Z --json wynikiem jest plan jako jeden obiekt JSON: z --dry-run od razu, bez niego po przekazaniu, z dry_run równym false i z staging, a przez --host po oczekiwaniu, także z wait. Stderr dostaje postęp jako wiersze JSON i nic poza tym (Wyjście i JSON). Żadne pole nie zawiera sekretu: pliki dla partycji IRONFLOCKOS są podawane z nazwą i rozmiarem, a adresy URL proxy bez hasła. Wynik przebiegu próbnego z powyższego przykładu, z dodanymi podziałami wierszy (polecenie zapisuje jeden wiersz; ... oznacza to, co przykład pomija):

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

Kiedy polecenie odmawia

Polecenie odmawia działania z kodem wyjścia 3 i niczego nie zmienia. Przyczyny odmowy:

• kontener, system bez systemd jako PID 1, IronFlockOS (tam wydanie instaluje os update), ReswarmOS.
• BIOS, 32-bitowe UEFI, architektura bez obrazu, zmienne EFI, które nie są zamontowane (odmowa podaje polecenie mount) lub są zamontowane tylko do odczytu (odmowa podaje mount -o remount,rw).
• Secure Boot, który nie uruchomiłby shima lub GRUB-a z obrazu.
• dysk, którego polecenie nie potrafi ustalić (wskaż go przez --disk), --disk, który nie jest dyskiem, z którego wystartował system, partycja, brak dysku; dysk, który nie jest całym, osobnym dyskiem albo którego nie wymienia lsblk; dysk bez GPT.
• główny system plików na innym dysku, rozpięty na kilku dyskach, na ZFS lub na żadnym dysku (system live).
• sektory logiczne inne niż 512-bajtowe, za mały dysk, stos pamięci masowej, którego polecenie nie rozkłada, system plików btrfs lub grupa woluminów LVM rozpięte na tym dysku i innym, inny dysk z nazwami partycji IronFlockOS.
• za mało pamięci.
• sieć, której polecenie nie przenosi, proxy na samej maszynie albo kopia lustrzana Appliance na interfejsie loopback maszyny, proxy z obrazem, który nie przyjmuje proxy.conf, lub ze znakami, których proxy.conf nie przyjmuje, aktywny profil NetworkManager, którego nie da się odczytać.
• lista sprzętu wydania, która pokazuje, że obraz nie ma sterownika dla któregoś z urządzeń dysku lub karty sieciowej.
• ip z iproute2, które nie działa: nie da się odczytać sieci.
• po pytaniu, zanim przygotowanie cokolwiek zmieni: dysk, który nie jest już dyskiem z planu, /run/initramfs, który już jest punktem montowania, plan, którego nie da się wykonać w obecnej postaci.

Błędne wiersze poleceń (kod wyjścia 2), sprawdzane, zanim cokolwiek zostanie zmienione:

• --yes bez --disk, chyba że z --dry-run.
• brak -c na maszynie bez zainstalowanego agenta urządzenia; przez --host bez --no-wait brak -c albo plik .flock, który nie konfiguruje użytkownika SSH.
• --image, którego nie ma w katalogu, obraz dla innej platformy sprzętowej niż platforma maszyny albo pendrive instalacyjny (który zapisuje os flash --installer).
• adres URL proxy z hasłem oraz pozostałe przypadki flag proxy, które odrzuca agent install.
• kilka maszyn (--host podane więcej niż raz, --hosts).

Kiedy polecenie kończy się błędem

Polecenie kończy się błędem z kodem wyjścia 1 i niczego nie zmienia, gdy:

• plik .flock nie jest prawidłowy albo jego klucz SSH nie jest prawidłowy.
• katalog nie przechodzi weryfikacji lub nie da się go pobrać, tak jak w os images; przy kopii lustrzanej Appliance ani z kopii lustrzanej, ani z chmury.
• nie da się pobrać początku pliku obrazu (getting the image ...), przy kopii lustrzanej Appliance ani z kopii lustrzanej, ani z chmury, albo nie jest to obraz IronFlockOS w postaci, którą zna polecenie. Gdy katalog pochodził z chmury, ponieważ kopia lustrzana żadnego nie udostępniła, błąd zaczyna się od ostrzeżenia dotyczącego katalogu, the appliance's mirror ... gives no IronFlockOS catalog now (...), i podaje oba serwery.
• lokalny adres pobierania nie należy do żadnej karty sieciowej; nie da się odczytać tabeli montowań, urządzeń blokowych lub pamięci; zmiennych EFI nie da się sparsować.
• po pytaniu: plik obrazu nie jest plikiem z katalogu lub nie jest tym, co odczytał plan (komunikat podaje obie wartości), pobieranie się nie powiedzie, firmware nie przyjmie opcji rozruchu albo nie da się uruchomić restartu. Przygotowanie jest wtedy cofane. Gdy cofnięcie również się nie powiedzie, komunikat prosi o restart, który usuwa to, co zostało.

Żaden adres URL nie jest wypisywany z użytkownikiem i hasłem, które może zawierać.

Kody wyjścia

Znaczenie każdego kodu dla wszystkich poleceń opisuje strona Flagi, wyjście i kody wyjścia.