Zapis IronFlockOS na nośniku

ironflock os flash przygotowuje nośnik, z którego startuje nowe urządzenie. Zapisuje na nośniku IronFlockOS i plik konfiguracji urządzenia (.flock), a urządzenie rejestruje się przy pierwszym rozruchu: łączy się z IronFlock jako urządzenie z tego pliku .flock. Możesz przygotować:

• pendrive USB, kartę SD lub dysk zewnętrzny, z którego startuje urządzenie,
• pendrive instalacyjny, który instaluje IronFlockOS na dysku wewnętrznym komputera PC,
• plik obrazu dysku, z którego startuje maszyna wirtualna.

FlockFlasher to aplikacja desktopowa do tego samego zadania. Skąd wziąć plik .flock urządzenia, opisuje strona Podłączanie urządzeń.

Typowe użycie

# 1. Włóż pendrive lub kartę SD, a potem wyświetl nośniki, które można zapisać
ironflock os drives
# 2. Opcjonalnie: wyświetl obrazy, które oferuje katalog
ironflock os images
# 3. Zapisz IronFlockOS i plik .flock urządzenia na nośniku
sudo ironflock os flash -c device.flock -d /dev/sdb

os flash pokazuje swój plan i pyta, zanim wymaże nośnik. Gdy skończy, włóż nośnik do urządzenia i uruchom z niego urządzenie.

ironflock os images

Wyświetla obrazy IronFlockOS, które można zapisać na nośniku. Domyślnie wyświetla obrazy wydania z kanału produkcyjnego.

ironflock os images [flags]

Działa w systemach Linux i macOS. Nie wymaga roota. O nic nie pyta.

Flagi

Flagi wspólne dla wszystkich poleceń opisuje strona Flagi, wyjście i kody wyjścia.

Co robi polecenie

Lista pochodzi z podpisanego katalogu IronFlockOS na serwerze pobierania, <download base>/ironflockos/manifest.json. ironflock używa katalogu tylko wtedy, gdy jego podpis Ed25519 przejdzie weryfikację kluczem katalogu wbudowanym w ironflock. FlockFlasher i agent urządzenia mają przypięty ten sam klucz. Żadna flaga ani zmienna środowiskowa nie wyłącza tego sprawdzenia. Bazowym adresem pobierania jest chmura IronFlock, chyba że podasz inny, zobacz Bazowy adres pobierania.

Ostatni katalog, który przeszedł weryfikację, jest przechowywany w folderze pamięci podręcznej, po jednej kopii na każdy bazowy adres pobierania:

Gdy serwer pobierania jest nieosiągalny, zastępuje go zachowana kopia, z informacją na stderr. Katalog z tego samego bazowego adresu pobierania, który jest starszy niż zachowana kopia, jest odrzucany.

Nazwa obrazu składa się z platformy sprzętowej, wariantu i jądra: ironflockos-<target>-<variant>, z -rt dla jądra czasu rzeczywistego. ironflockos-amd64-efi-base-rt to system podstawowy z jądrem czasu rzeczywistego dla komputerów PC x86-64 z UEFI. Platformy sprzętowe to:

• amd64-efi — komputer PC x86-64 z UEFI
• arm64-efi — maszyna ARM64 z UEFI
• rpi-arm64 — Raspberry Pi 4, 400 i CM4; Raspberry Pi 5 i CM5

Warianty to base, nvidia i installer. Obraz instalatora tworzy pendrive USB, który instaluje jeden z zawartych w nim obrazów na dysku maszyny, która z niego wystartuje. Obraz wariantu, jądra lub architektury, których ten ironflock nie zna (z nowszego wydania), jest pomijany, z informacją na stderr.

Przykłady

# Obrazy bieżącego wydania produkcyjnego
ironflock os images
# Tylko obrazy dla Raspberry Pi
ironflock os images --target rpi-arm64
# Obrazy z kanału testowego jako JSON
ironflock os images --channel test --json

Wynik

IMAGE                            VERSION  SIZE      HARDWARE
ironflockos-amd64-efi-base       0.13.0   638.1 MB  x86-64 PC with UEFI
ironflockos-amd64-efi-base-rt    0.13.0   650.4 MB  x86-64 PC with UEFI
ironflockos-amd64-efi-nvidia     0.13.0   1.0 GB    x86-64 PC with UEFI
ironflockos-amd64-efi-installer  0.13.0   2.5 GB    x86-64 PC with UEFI, installer stick for base, base-rt, nvidia
ironflockos-arm64-efi-base       0.13.0   582.4 MB  ARM64 machine with UEFI
ironflockos-arm64-efi-base-rt    0.13.0   594.1 MB  ARM64 machine with UEFI
ironflockos-arm64-efi-installer  0.13.0   1.5 GB    ARM64 machine with UEFI, installer stick for base, base-rt
ironflockos-rpi-arm64-base       0.13.0   639.4 MB  Raspberry Pi 4, 400 and CM4; Raspberry Pi 5 and CM5

Z --json (tutaj z --target rpi-arm64):

{"issued_at":"2026-11-10T09:41:47Z","key_id":"036ef3bd","from_cache":false,"channels":{"production":"0.13.0","test":"0.13.0"},"images":[{"image_id":"ironflockos-rpi-arm64-base","version":"0.13.0","channels":["production","test"],"target":"rpi-arm64","variant":"base","kernel":"std","architecture":"arm64","boards":["raspberrypi4","raspberrypi5"],"hardware":["Raspberry Pi 4, 400 and CM4","Raspberry Pi 5 and CM5"],"file":"ironflockos-rpi-arm64-base-0.13.0.img.gz","url":"https://instance-registry.ironflock.com/dl/ironflockos/0.13.0/ironflockos-rpi-arm64-base-0.13.0.img.gz","size":639408901,"sha256":"9abd17f2098dfa236d440005222d0a6b583546ea9768e5eca8807c4e24ec88db"}]}

issued_at i key_id opisują katalog, channels podaje wydanie każdego kanału, a from_cache ma wartość true, gdy serwer pobierania nie odpowiedział. Każdy obraz ma swój plik file z polami url, size i sha256. boards to modele płyt, które podaje plik .flock (board.model), a hardware to ich nazwy. Obraz instalatora ma też pole payloads z identyfikatorami obrazów, które zawiera.

Kiedy polecenie kończy się błędem

• Kod wyjścia 2 — --channel razem z --version, wartość, która nie jest numerem wersji, albo kanał, wydanie, platforma sprzętowa, wariant lub jądro, których nie ma w katalogu. Błąd podaje, co zawiera katalog.
• Kod wyjścia 1 — katalog nie przechodzi weryfikacji, jest większy niż 64 KiB, nie jest katalogiem, który ten ironflock umie odczytać, albo jest starszy niż zachowana kopia; albo nie da się go pobrać, a nie ma zachowanej kopii.

ironflock os drives

Wyświetla nośniki tej maszyny, na których można zapisać obraz IronFlockOS: pendrive’y USB, karty SD, dyski zewnętrzne. Nie zapisuje, nie odmontowuje ani nie otwiera żadnego nośnika.

ironflock os drives [flags]

Działa w systemach Linux i macOS. Nie wymaga roota. O nic nie pyta. W Linuksie uruchamia lsblk (z util-linux) i odczytuje /proc oraz /sys. W macOS uruchamia diskutil list, diskutil info i hdiutil info.

Flagi

Flagi wspólne dla wszystkich poleceń opisuje strona Flagi, wyjście i kody wyjścia.

Które nośniki są odrzucane

os flash odrzuca te same nośniki co os drives, z tych samych przyczyn. Nośnik jest odrzucany, gdy (pokazywana jest pierwsza przyczyna, która ma zastosowanie):

1. jest partycją, na przykład /dev/sdb1. Odmowa wskazuje dysk tej partycji: obraz trafia na cały dysk.
2. nie jest dyskiem: napęd optyczny, dysk w pamięci (zram), wolumin zbudowany na innych nośnikach (LVM, dm-crypt, RAID, device-mapper; w macOS kontener APFS, zestaw AppleRAID lub inny dysk syntetyczny) albo rodzaj urządzenia, którego polecenie nie zna (nbd, mtdblock).
3. zawiera część działającego systemu: /, /boot, /efi, /usr, /var, /etc lub punkt montowania pod jednym z nich (partycja EFI w /boot/efi, dane Dockera w /var/lib/docker), /home, /opt, /srv, /data, swap albo nośnik systemu live. Dotyczy to każdego sposobu, w jaki system leży na nośniku: na partycji, przez LVM, dm-crypt, RAID lub device-mapper, w systemie plików btrfs rozpiętym na kilku nośnikach, w puli ZFS, w nakładce (overlay) albo w pliku odczytywanym przez urządzenie loop. W macOS: / i woluminy pod /System, przez ich kontenery APFS aż do dysku, na którym leżą.
4. jest w użyciu: przez LVM, dm-crypt, RAID lub device-mapper, przez pulę ZFS z zamontowanym zbiorem danych albo przez urządzenie loop, które odczytuje leżący na nim plik. W macOS także przez kontener APFS na nim, zestaw AppleRAID, obraz dysku, którego plik leży na nim, albo przez Core Storage, AppleRAID lub kontener APFS, który nie jest podłączony. macOS zwalnia pendrive z kontenerem APFS dopiero wtedy, gdy pendrive zostanie wymazany, więc przyczyna podaje polecenie, które go wymazuje, na przykład diskutil eraseDisk FAT32 IRONFLOCK MBR /dev/disk6 (albo Wymaż w Narzędziu dyskowym).
5. jest dyskiem wewnętrznym maszyny: dysk SATA lub NVMe, pamięć eMMC płyty. Nośnik jest wewnętrzny, chyba że jest podłączony przez USB lub inną magistralę, której urządzenia można odłączać. Wbudowany czytnik kart jest wewnętrzny, ale włożona do niego karta SD jest nośnikiem wymiennym i jest oferowana, także na Macu. W macOS dysk, który nie podaje, gdzie się znajduje, jest traktowany jako wewnętrzny. os flash --allow-internal zapisuje dysk wewnętrzny wskazany przez --drive, gdy nie odrzuca go żadna inna przyczyna.
6. może zawierać część działającego systemu: gdy jakiejś części działającego systemu nie da się przypisać do nośnika, odrzucany jest każdy nośnik. Tak jest w kontenerze, którego system leży na jego hoście, oraz w macOS dla systemu na woluminie, który nie sięga żadnego dysku fizycznego, jak Core Storage.
7. jest tylko do odczytu, na przykład zablokowana karta SD.
8. nie ma włożonego nośnika, na przykład czytnik kart bez karty.

Nośnik z zamontowanymi systemami plików jest oferowany; mounted je wymienia, a os flash odmontowuje je przed zapisem. Urządzenia loop i, w macOS, podłączone obrazy dysków nie są wyświetlane, ale os flash zapisuje takie urządzenie, gdy wskazuje je --drive.

Na urządzeniu z IronFlockOS polecenie ostrzega na stderr i w warnings: każdy obraz IronFlockOS danej platformy sprzętowej ma te same UUID partycji, więc gdy podłączony jest drugi nośnik z IronFlockOS, działający system nie odróżnia swoich partycji od partycji tego nośnika.

Przykłady

# Nośniki, które można zapisać
ironflock os drives
# Wszystkie nośniki, z przyczyną dla każdego odrzuconego
ironflock os drives --all
# Nośniki jako JSON
ironflock os drives --json

Wynik

W Linuksie:

DEVICE        SIZE     BUS  MODEL
/dev/sdb      15.9 GB  usb  SanDisk Ultra
/dev/mmcblk0  31.9 GB  mmc  SD32G

Z --all:

DEVICE        SIZE     BUS   MODEL                    WRITABLE
/dev/sda      2.0 TB   sata  WDC WD20EZBX-00AYRA0     no: is an internal disk of this machine
/dev/sdb      15.9 GB  usb   SanDisk Ultra            yes
/dev/mmcblk0  31.9 GB  mmc   SD32G                    yes
/dev/nvme0n1  1.0 TB   nvme  Samsung SSD 980 PRO 1TB  no: holds / of the running system

Na Macu, z --all:

DEVICE      SIZE      BUS             MODEL                 WRITABLE
/dev/disk0  500.3 GB  Apple Fabric    APPLE SSD AP0512R     no: holds / of the running system
/dev/disk1  524.3 MB  Apple Fabric    APPLE SSD AP0512R     no: is a volume (APFS container), not a disk
/dev/disk2  5.4 GB    Apple Fabric    APPLE SSD AP0512R     no: is a volume (APFS container), not a disk
/dev/disk3  494.4 GB  Apple Fabric    APPLE SSD AP0512R     no: is a volume (APFS container), not a disk
/dev/disk5  15.9 GB   Secure Digital  Built In SDXC Reader  yes

Z --json (skrócone):

{"drives":[{"device":"/dev/sdb","kind":"disk","size":15931539456,"bus":"usb","removable":true,"internal":false,"read_only":false,"vendor":"SanDisk","model":"Ultra","serial":"4C530001230812115352","mounted":[{"device":"/dev/sdb1","mountpoint":"/media/anna/STICK"}],"system":[],"maybe_system":[],"holders":[],"writable":true},{"device":"/dev/mmcblk0",...}],"warnings":[]}

Gdy nie ma nośnika, który można zapisać, tekst o tym mówi, drives jest puste, a kod wyjścia wynosi 0.

Kiedy polecenie kończy się błędem

• Kod wyjścia 3 — w Linuksie nie jest zainstalowany lsblk albo polecenie działa w systemie innym niż Linux lub macOS.

ironflock os flash

Zapisuje IronFlockOS na nośniku (pendrivie USB, karcie SD, dysku zewnętrznym) i umieszcza plik .flock urządzenia na partycji IRONFLOCKOS nośnika, czyli partycji FAT32 o tej nazwie, którą ma każdy nośnik z IronFlockOS. Urządzenie rejestruje się z tym plikiem przy pierwszym rozruchu. Z --output zapisuje to samo do pliku obrazu dysku dla maszyny wirtualnej.

Ostrzeżenie: Wszystko na nośniku zostaje wymazane. Przed zapisem sprawdź nazwę nośnika poleceniem ironflock os drives. os flash nigdy sam nie wybiera nośnika.

ironflock os flash -c <device.flock> (-d <drive> | --output <file>) [flags]

Bez roota błąd podaje wiersz poleceń do wpisania, z sudo na początku. W macOS użytkownik, który może zapisywać surowe urządzenie nośnika, nie potrzebuje roota: to użytkownik, który podłączył obraz dysku, albo użytkownik, któremu właściciel maszyny przekazał nośnik, na przykład poleceniem sudo chown <user> /dev/disk4 /dev/rdisk4. Z --output polecenie nie potrzebuje roota. Zobacz też Uprawnienia roota.

Flagi

Flagi wspólne dla wszystkich poleceń opisuje strona Flagi, wyjście i kody wyjścia.

Co robi polecenie

1. Sprawdza nośnik. Ustala, na jaki nośnik wskazuje --drive, i odrzuca go z przyczyn, które podaje os drives, zanim cokolwiek odczyta, pobierze lub o cokolwiek zapyta. Bez --drive (i bez --output) wymienia nośniki, które może zapisać, i kończy się kodem wyjścia 2.
2. Odczytuje plik .flock. Musi to być plik o nazwie *.flock o rozmiarze najwyżej 5 MiB, zawierający obiekt JSON z polami secret i device_key, którego name i serial_number to zwykłe nazwy.
3. Wybiera obraz z podpisanego katalogu, który pobiera i weryfikuje tak jak os images. Bierze obraz wskazany przez --image, a w przeciwnym razie domyślny obraz (wariant base, jądro standardowe) dla sprzętu wskazanego w pliku .flock: według jego board.model, a w przeciwnym razie według jego architecture, gdy katalog ma dla niej jeden rodzaj sprzętu. Z --installer bierze pendrive instalacyjny tego sprzętu, który zawiera ten obraz.
4. Pokazuje plan na stderr: obraz, skąd pochodzi jego plik, plik .flock (tylko jego nazwę), sieć WiFi, nośnik oraz systemy plików nośnika, które odmontuje. Potem pyta. Wstępnie wybrana jest odpowiedź „Nie”, więc sam Enter niczego nie wymazuje.
5. Zdobywa plik obrazu: plik z --image-file, a w przeciwnym razie kopię z pamięci podręcznej, a w przeciwnym razie pobiera go do pamięci podręcznej, wznawiając od miejsca, w którym zatrzymało się wcześniejsze pobieranie. Gdy polecenie działa jako root, pamięcią podręczną jest /var/cache/ironflock/images w Linuksie i /var/root/Library/Caches/ironflock/images w macOS. Pobieranie trafia do pliku .part. Każdy plik jest zapisywany tylko wtedy, gdy jego rozmiar i SHA-256 zgadzają się z katalogiem. Próba pobrania, która przez minutę nie przynosi ani jednego bajtu, kończy się, a po trzech takich próbach z rzędu pobieranie zostaje zaniechane.
6. Ponownie sprawdza nośnik. Musi to być nośnik pokazany w planie i nadal nieodrzucany: to samo urządzenie, rozmiar, numer seryjny i włożony nośnik. W Linuksie obejmuje to producenta, model, magistralę i każdą partycję z jej systemem plików, etykietą, UUID i rozmiarem. W macOS, który nie podaje numeru seryjnego, jest to model, magistrala, miejsce w drzewie urządzeń i partycje z ich UUID. Pendrive wyjęty po pokazaniu planu zostawia swoją nazwę następnemu podłączonemu nośnikowi; taki nośnik nie jest zapisywany i nic nie jest odmontowywane. Następnie polecenie odmontowuje systemy plików wymienione w planie, i tylko je, oraz otwiera nośnik do zapisu na wyłączność. W macOS zapisuje przez surowe urządzenie (/dev/rdisk4), którego drugie os flash nie może w tym samym czasie otworzyć.
7. Zapisuje obraz, a potem ponownie odczytuje nośnik i porównuje.
8. Zapisuje plik .flock w folderze głównym partycji IRONFLOCKOS, bez jej montowania. Pendrive instalacyjny dostaje też installer.conf. Z --wifi-ssid kopia na nośniku wskazuje tę sieć; sam plik .flock się nie zmienia.
9. W macOS wysuwa nośnik (diskutil eject), aby można go było wyjąć. Gdy wysunięcie się nie powiedzie, nośnik i tak jest zapisany: polecenie ostrzega, a ty wysuwasz nośnik w Finderze, zanim go wyjmiesz.

Jako root polecenie używa folderu pamięci podręcznej tylko wtedy, gdy jest on folderem, a nie dowiązaniem, należy do roota i nikt inny nie może w nim zapisywać. Brakujący folder tworzy z trybem 0700, a przy każdym innym zatrzymuje się, zanim cokolwiek w nim odczyta, usunie lub pobierze. Zanim pobierze obraz z katalogu, usuwa z pamięci podręcznej pliki obrazów, których katalog już nie wymienia, oraz ich częściowe pobrania.

Obraz z --image przeznaczony dla innego sprzętu niż ten wskazany w pliku .flock jest zapisywany po ostrzeżeniu w planie: urządzenie nie uruchomiłoby swoich aplikacji. Na urządzeniu z IronFlockOS plan ostrzega tak jak os drives. Z --allow-internal plan ostrzega, że nośnik jest dyskiem wewnętrznym.

--yes odpowiada na pytanie „tak”. Bez terminala (potok, skrypt) i bez --yes polecenie nie pyta i kończy się kodem wyjścia 4. --json również o nic nie pyta, więc do zapisu nośnika potrzebuje --yes. Z --json plan nie jest wypisywany: stderr przenosi tylko zdarzenia postępu, a ostrzeżenia są w wyniku. Zobacz Pytania i potwierdzenie oraz Wyjście i JSON.

WiFi

Urządzenie dołącza do sieci WiFi wskazanej w swoim pliku .flock. --wifi-ssid przekazuje mu inną sieć. IronFlockOS dołącza tylko do sieci WiFi z hasłem, więc --wifi-ssid i --wifi-password-file zawsze występują razem. Hasło WiFi pochodzi z pliku lub potoku, nigdy z wiersza poleceń, gdzie pokazałyby je ps i historia powłoki. Polecenie nigdzie go nie wypisuje. Kopia pliku .flock na nośniku podaje sieć w polach wlanssid i password.

Uwaga: Gdy hasło WiFi przychodzi przez /dev/stdin, stdin nie jest terminalem, więc polecenie nie może zadać pytania. Dodaj --yes.

Pendrive instalacyjny

Z --installer nośnik staje się pendrive’em instalacyjnym dla komputera PC z UEFI (amd64-efi, arm64-efi); ironflock os images --variant installer wyświetla obrazy instalatora. Pendrive zawiera kilka obrazów swojego sprzętu; installer.conf na pendrivie wskazuje ten, który instaluje (payload, obraz wybrany jak w kroku 3), i przechowuje podane flagi --installer-*. Gdy komputer PC wystartuje z pendrive’a, instalator:

1. wybiera dysk według --installer-disk: największy dysk (domyślnie), dysk /dev/<name> lub dysk o identyfikatorze by-id:<id>. Dysk USB zapisuje tylko z --installer-allow-usb yes.
2. pyta na konsoli komputera PC przed zapisem, chyba że podano --installer-confirm no.
3. zapisuje na tym dysku obraz i plik .flock urządzenia.
4. wyłącza komputer PC (domyślnie) albo, z --installer-after reboot, go restartuje.

Wyjmij pendrive i uruchom komputer PC z jego dysku wewnętrznego. Urządzenie rejestruje się przy pierwszym rozruchu.

Ostrzeżenie: Pendrive zapisany z --installer-confirm no bez pytania wymazuje dysk każdego komputera PC, który z niego wystartuje. Oznacz taki pendrive i trzymaj go z dala od innych maszyn.

Aby zastąpić Linuksa działającej maszyny bez pendrive’a, zobacz Zastąpienie Linuksa systemem IronFlockOS.

Pobrany wcześniej plik obrazu

--image-file zapisuje plik obrazu pobrany wcześniej, na przykład dla maszyny, która sama nie może pobierać plików obrazów z katalogu. Adres pliku weź z pola url wyniku os images --json. Plik jest zapisywany tylko wtedy, gdy ma rozmiar i SHA-256, które katalog podaje dla tego obrazu.

Polecenie nadal potrzebuje podpisanego katalogu, aby sprawdzić plik. Pobiera katalog albo, gdy serwer pobierania jest nieosiągalny, używa kopii zachowanej przy ostatniej udanej weryfikacji katalogu z tego samego bazowego adresu pobierania. Ta kopia jest osobna dla każdego użytkownika: jako root polecenie używa kopii roota. Działa też własny serwer: z innym bazowym adresem pobierania (--download-base lub IRONFLOCK_DL_BASE) polecenie pobiera katalog z <download base>/ironflockos/manifest.json, a plik obrazu z <download base>/ironflockos/<version>/<file>.

Uwaga: Plik jest odczytywany jeszcze raz podczas zapisu, a jego SHA-256 jest ponownie znane dopiero po zapisie. Trzymaj plik tam, gdzie żaden inny użytkownik nie może go zmienić.

Plik obrazu dla maszyny wirtualnej

--output <file> zapisuje obraz i pliki urządzenia do zwykłego pliku zamiast na nośnik: do surowego obrazu dysku, z którego maszyna wirtualna startuje jak ze swojego dysku. Obraz, jego sprawdzenia i pliki na IRONFLOCKOS są takie same jak dla nośnika. Polecenie nie szuka nośnika, niczego nie odmontowuje ani nie otwiera, więc nie potrzebuje roota. --image, --image-file, --installer z jego flagami oraz --wifi-ssid działają tak samo jak z nośnikiem.

• Rozmiar — Plan podaje plik i jego rozmiar: rozmiar rozpakowanego obrazu. Gdy obraz trzeba jeszcze pobrać, ten wiersz pojawia się po pobraniu.
• Pytanie — Nowy plik niczego nie wymazuje, więc polecenie nie pyta. Istniejący plik jest zastępowany: plan o tym mówi, a polecenie najpierw pyta.
• Najpierw pod inną nazwą — Obraz trafia do nowego pliku w tym samym folderze, <file>.<number>.part. Nazwę <file> plik dostaje dopiero wtedy, gdy zawiera cały obraz, został ponownie odczytany i ma pliki urządzenia na swojej partycji IRONFLOCKOS. Zapis, który się nie powiedzie lub zostanie przerwany, usuwa plik .part, a pod docelową nazwą nie ma niczego albo jest niezmieniony plik, który już tam był. kill -9 lub utrata zasilania mogą zostawić plik .part.
• Prywatny — Plik zawiera sekret urządzenia, tak jak plik .flock. Dostaje tryb 0600, także gdy zastępuje plik z szerszymi uprawnieniami.
• Plik rzadki — Tam, gdzie obraz ma cały blok zer (bloki po 4 MiB), plik dostaje dziurę, jeśli system plików obsługuje dziury. Odczytuje się tak samo i zajmuje mniej miejsca.

# Zapisz plik obrazu dysku dla maszyny wirtualnej, bez roota
ironflock os flash -c device.flock --output device.img

IronFlockOS catalog of 2026-11-10T09:41:47Z, signed with key 036ef3bd.
Image:        ironflockos-amd64-efi-base 0.13.0, for x86-64 PC with UEFI
Image file:   https://instance-registry.ironflock.com/dl/ironflockos/0.13.0/ironflockos-amd64-efi-base-0.13.0.img.gz (638.1 MB), downloaded and checked against the catalog
Device file:  device.flock, for the device kitchen-pc
WiFi:         Office (from the .flock)
Output:       device.img, a new file: the image, unpacked; its size is known once the image is downloaded
(the progress of downloading, checking)
Unpacked, the image has 4.6 GB: the size of device.img.
(the progress of writing, reading back)
Done: IronFlockOS 0.13.0 (ironflockos-amd64-efi-base) is in device.img and read back, with device.flock in its IRONFLOCKOS partition.
Grow the file to the size of the virtual machine's disk before the machine starts from it (truncate -s 20G device.img): on its first boot IronFlockOS makes slot B and /data in that space, and the device enrolls as kitchen-pc.

Obraz zawiera partycję IRONFLOCKOS i pierwszy z dwóch slotów systemowych, które IronFlockOS aktualizuje na zmianę (slot A). Przy pierwszym rozruchu IronFlockOS tworzy slot B, tak duży jak slot A, oraz partycję danych /data na reszcie dysku. Powiększ plik, zanim maszyna wirtualna pierwszy raz z niego wystartuje: do co najmniej 10 GiB dla base i 18 GiB dla nvidia. To, o co plik się powiększa, to zera, które system plików przechowuje jako dziurę. Hiperwizor, który przyjmuje surowe dyski, używa pliku bez zmian. Dla innego formatu przekonwertuj powiększony plik, na przykład poleceniem qemu-img convert -f raw -O qcow2 device.img device.qcow2.

Obrazy amd64-efi i arm64-efi startują w QEMU; obraz dla Raspberry Pi (rpi-arm64) nie. Dla amd64-efi w Linuksie z KVM i firmware UEFI z pakietu ovmf (Debian, Ubuntu):

# Powiększ plik, skopiuj zmienne firmware i uruchom maszynę
truncate -s 20G device.img
cp /usr/share/OVMF/OVMF_VARS_4M.fd device-vars.fd
qemu-system-x86_64 -machine q35 -accel kvm -cpu host -m 2048 -smp 2 \
  -drive if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \
  -drive if=pflash,format=raw,unit=1,file=device-vars.fd \
  -drive file=device.img,format=raw,if=virtio \
  -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \
  -device i6300esb \
  -nographic

• -nographic kieruje pierwszy port szeregowy do terminala, w którym piszą GRUB i jądro. Ctrl-A X kończy QEMU.
• -device i6300esb to watchdog, przez który IronFlockOS restartuje maszynę, która się zawiesiła.
• -netdev user daje maszynie sieć hosta, przez którą urządzenie łączy się z IronFlock.
• Bez KVM (brak /dev/kvm albo host innej architektury) pomiń -accel kvm i użyj -cpu max. QEMU emuluje wtedy maszynę, co jest znacznie wolniejsze.

arm64-efi startuje z qemu-system-aarch64 -machine virt i firmware z pakietu qemu-efi-aarch64 (/usr/share/AAVMF/AAVMF_CODE.fd i kopia AAVMF_VARS.fd), bez watchdoga. Na Macu z Apple silicon uruchamia go QEMU z Homebrew, z -accel hvf -cpu host i firmware /opt/homebrew/share/qemu/edk2-aarch64-code.fd, z kopią edk2-arm-vars.fd.

Przykłady

# Zapisz domyślny obraz dla sprzętu z pliku .flock na pendrivie USB
sudo ironflock os flash -c device.flock -d /dev/sdb
# Zapisz pendrive instalacyjny, który instaluje obraz NVIDIA na komputerze PC
sudo ironflock os flash -c device.flock -d /dev/sdb --image amd64-efi-nvidia --installer
# Zapisz kartę SD dla urządzenia, które dołącza do sieci WiFi „Workshop”
sudo ironflock os flash -c device.flock -d /dev/mmcblk0 --wifi-ssid Workshop --wifi-password-file wifi.txt
# Zapisz pendrive na Macu
sudo ironflock os flash -c device.flock -d /dev/disk4

Wynik

Plan i postęp trafiają na stderr; ostatnie wiersze to wynik. W Linuksie:

IronFlockOS catalog of 2026-11-10T09:41:47Z, signed with key 036ef3bd.
Image:        ironflockos-amd64-efi-base 0.13.0, for x86-64 PC with UEFI
Image file:   https://instance-registry.ironflock.com/dl/ironflockos/0.13.0/ironflockos-amd64-efi-base-0.13.0.img.gz (638.1 MB), downloaded and checked against the catalog
Device file:  device.flock, for the device kitchen-pc
WiFi:         Office (from the .flock)
Drive:        /dev/sdb: SanDisk Ultra, 15.9 GB, usb, serial 4C530001230812115352
Everything on /dev/sdb is erased. Unmounted first: /media/anna/STICK.
(the progress of downloading, checking, writing, reading back)
Done: IronFlockOS 0.13.0 (ironflockos-amd64-efi-base) is on /dev/sdb and read back, with device.flock in its IRONFLOCKOS partition.
Start the device from it: it enrolls as kitchen-pc on its first boot.

Na Macu, najpierw bez roota, potem z sudo:

$ ironflock os flash -c pi.flock -d /dev/disk5
Error: "ironflock os flash" must run as root (sudo) to write a drive: sudo ironflock os flash -c pi.flock -d /dev/disk5
$ sudo ironflock os flash -c pi.flock -d /dev/disk5 --yes
IronFlockOS catalog of 2026-11-10T16:41:54Z, signed with key 036ef3bd.
Image:        ironflockos-rpi-arm64-base 0.14.0, for Raspberry Pi 4, 400 and CM4
Image file:   https://instance-registry.ironflock.com/dl/ironflockos/0.14.0/ironflockos-rpi-arm64-base-0.14.0.img.gz (640.1 MB), downloaded and checked against the catalog
Device file:  pi.flock, for the device pi-workshop
WiFi:         Office (from the .flock)
Drive:        /dev/disk5: Built In SDXC Reader, 15.9 GB, Secure Digital
Everything on /dev/disk5 is erased. Unmounted first: /Volumes/UNTITLED.
(the progress of downloading, checking, writing, reading back)
Done: IronFlockOS 0.14.0 (ironflockos-rpi-arm64-base) is on /dev/disk5 and read back, with pi.flock in its IRONFLOCKOS partition.
/dev/disk5 is ejected and can be taken out.
Start the device from it: it enrolls as pi-workshop on its first boot.

Z --json, tutaj dla pendrive’a instalacyjnego (--installer --installer-confirm no --yes --json):

{"action":"flashed","device":"kitchen-pc","device_file":"device.flock","hardware":"x86-64 PC with UEFI","image":{"image_id":"ironflockos-amd64-efi-installer","version":"0.13.0","file":"ironflockos-amd64-efi-installer-0.13.0.img.gz","url":"https://instance-registry.ironflock.com/dl/ironflockos/0.13.0/ironflockos-amd64-efi-installer-0.13.0.img.gz","size":2512345678,"sha256":"..."},"installer":{"payload":"ironflockos-amd64-efi-base","disk":"largest","confirm":"no","after":"poweroff","allow_usb":"no"},"wifi":{"ssid":"Office","from":"flock"},"drive":{"device":"/dev/sdb","size":15931539456,"bus":"usb","model":"SanDisk Ultra","serial":"4C530001230812115352","internal":false},"source":"download","unmounted":["/media/anna/STICK"],"bytes":6442450944,"verified":true,"ejected":false,"files":["device.flock","installer.conf"],"catalog":{"issued_at":"2026-11-10T09:41:47Z","key_id":"036ef3bd","from_cache":false,"notes":[]},"warnings":[]}

Z --output wynik ma pole output zamiast drive, na przykład "output":{"file":"/home/anna/device.img","replaced":true}.

Kiedy polecenie odmawia

Kod wyjścia 3, a nic nie zostaje zapisane:

• Nośnik jest jednym z tych, które odrzuca os drives; błąd podaje przyczynę, a --yes niczego nie zmienia. Jedynym wyjątkiem jest dysk wewnętrzny tej maszyny: --allow-internal go zapisuje, gdy wskazuje go --drive, a błąd podaje tę flagę, gdy pozwoliłaby zapisać nośnik. Flaga nie znosi żadnej innej odmowy i nie odpowiada na pytanie.
• Nośnik zmienił się między planem a zapisem albo jest wtedy odrzucany. Błąd mówi, co się zmieniło.
• Nośnik jest w użyciu w chwili otwarcia: zamontowany jest system plików, którego plan nie wymieniał, system plików nie daje się odmontować albo jakiś program trzyma nośnik.
• Polecenie nie działa jako root (lub, w macOS, jako użytkownik, który może zapisywać surowe urządzenie nośnika). Błąd podaje wiersz poleceń z sudo.
• Z --output: nazwa nie jest zwykłym plikiem (urządzenie, folder, potok nazwany lub jakiekolwiek dowiązanie symboliczne) albo jej folder nie istnieje; to sprawdzenie następuje, zanim cokolwiek zostanie odczytane lub pobrane. Folder, w którym nie można utworzyć nowego pliku (brak uprawnień, system plików tylko do odczytu), jest odrzucany po planie, a przed pobieraniem. Plik, który pojawił się pod tą nazwą podczas zapisu obrazu, choć plan zakładał nowy plik, nie jest zastępowany.

Kod wyjścia 2, błędny wiersz poleceń:

• Ani --drive, ani --output, także z --allow-internal. --output z --drive lub z --allow-internal, bez nazwy albo z -. --output, które wskazuje plik .flock z -c lub plik z --image-file.
• Flaga --installer-* bez --installer albo z wartością, której instalator nie przyjmuje.
• --wifi-ssid bez --wifi-password-file lub na odwrót.
• Plik .flock, który nie mówi, dla jakiego sprzętu jest przeznaczony; obraz wybiera wtedy --image.
• Obraz, którego nie ma w katalogu, pendrive instalacyjny, który nie zawiera danego obrazu, albo sprzęt bez pendrive’a instalacyjnego.
• Z --host: --image-file i --output, ponieważ --host nie kopiuje pliku obrazu na zdalną maszynę i nie przynosi z powrotem żadnego pliku. Uruchom polecenie tutaj bez --host albo na samej maszynie. Plik .flock i plik z hasłem WiFi trafiają tam razem z poleceniem.

Kod wyjścia 4: na pytanie odpowiedziano „nie” (sam Enter lub Esc) albo nie można było go zadać, a nie podano --yes.

Kod wyjścia 1, polecenie nie powiodło się:

• Plik .flock lub plik z hasłem WiFi nie jest prawidłowym plikiem tego rodzaju albo plik obrazu nie jest plikiem z katalogu.
• Nie można użyć katalogu, z tych samych przyczyn, z których kończy się błędem os images.
• Pobieranie, zapis lub ponowny odczyt się nie powiedzie. Zapis, który nie powiedzie się po pierwszym bloku (błąd we/wy, nośnik mniejszy niż obraz), mówi, że nośnik zawiera teraz część obrazu, z której nic nie wystartuje: zapisz go ponownie.
• Obraz jest na nośniku i został ponownie odczytany, ale nie udało się zapisać pliku .flock na partycji IRONFLOCKOS. Bez niego urządzenie się nie zarejestruje; to samo polecenie zapisze ponownie jedno i drugie.
• Z --output: system plików jest pełny, nie da się umieścić plików urządzenia w obrazie albo wpis pliku .part w folderze został zastąpiony podczas zapisu obrazu. Pod docelową nazwą jest wtedy to samo co przedtem.

Kod wyjścia 130: Ctrl-C podczas pobierania, zapisu lub ponownego odczytu obrazu. Przerwane pobieranie niczego jeszcze nie zapisało, a to samo polecenie je wznowi. Zapis lub ponowny odczyt zatrzymuje się na następnym bloku, a błąd mówi, co zawiera nośnik. Gdy ostatni blok zostanie już ponownie odczytany, polecenie wykonuje swoje ostatnie krótkie kroki i kończy się kodem 0. Drugie Ctrl-C kończy polecenie natychmiast; z --output może zostać plik .part.