Aktualizacja, wycofanie i reset

Te polecenia obsługują urządzenie z IronFlockOS. os update instaluje wydanie, os rollback wraca do wydania, które działało wcześniej, a os reset przywraca urządzenie do stanu świeżo zapisanego.

Sloty systemowe i partycja danych

Dysk urządzenia z IronFlockOS zawiera:

• Dwa sloty systemowe, A i B — każdy zawiera kompletny system IronFlockOS. Jeden działa. Drugi zawiera system, który działał wcześniej, albo, na świeżo zapisanym urządzeniu, jeszcze nic. RAUC, narzędzie aktualizacji używane przez IronFlockOS, zapisuje wydanie w slocie, który nie działa, i odnotowuje, który slot startuje jako następny.
• Partycja danych (/data) — aplikacje i ich dane oraz agent urządzenia z jego kopią pliku konfiguracji urządzenia (.flock). Korzystają z niej oba systemy, więc aktualizacja lub wycofanie pozostawia aplikacje i ich dane bez zmian.
• Partycja IRONFLOCKOS (zamontowana w /boot/efi) — mała partycja FAT. Urządzenie rejestruje się przy starcie z plikiem .flock, który tam znajdzie, a os reset zapisuje tam swoje żądanie.

Nowy system musi się sprawdzić: urządzenie go zachowuje, gdy agent urządzenia dotrze z niego do IronFlock i oznaczy go jako dobry. System, który nie startuje albo nie dociera do IronFlock, przy następnym restarcie ustępuje systemowi, który działał wcześniej. ironflock status pokazuje sloty:

System:        IronFlockOS 0.13.0 (amd64-efi, base)
  Image:       ironflockos-amd64-efi-base (build 20261105T120000Z-g1a2b3c4)
  Slot A:      inactive, good
  Slot B:      booted, good, 0.13.0 installed 2026-11-05T14:00:00Z
  Next boot:   slot B

Gdzie działają polecenia

Te trzy polecenia działają na urządzeniu z IronFlockOS, wymagają roota i pytają, zanim cokolwiek zrobią. W innym systemie (macOS, Linux inny niż IronFlockOS, pendrive instalacyjny IronFlockOS) kończą się kodem wyjścia 3.

• Na urządzeniu — wydania IronFlockOS nowsze niż 0.15.0 zawierają ironflock. Zaloguj się na urządzeniu i uruchom polecenie z sudo.
• Z innego komputera — wydania IronFlockOS do 0.15.0 włącznie nie zawierają ironflock. Uruchom polecenie z komputera z Linuksem lub macOS z --host, jako użytkownik SSH urządzenia: konto, które plik .flock konfiguruje dla właściciela projektu, w przykładach operator. --host kopiuje ironflock na urządzenie na czas uruchomienia i uruchamia tam polecenie przez sudo.

ironflock --host operator@kitchen-pc os update --reboot --yes

os update i os rollback działają na kilku urządzeniach jednocześnie (--host podane więcej niż raz albo --hosts), gdy podano --yes. os reset działa na jednym urządzeniu naraz; na kilku kończy się kodem wyjścia 2. Flagi globalne opisuje strona Flagi, wyjście i kody wyjścia.

ironflock os update

Instaluje wydanie IronFlockOS oferowane przez kanał urządzenia w slocie systemowym, który nie działa. Nowy system startuje przy następnym restarcie albo od razu z --reboot.

ironflock os update [flags]

Kanał urządzenia to kanał, za którym podąża jego agent urządzenia, według pola environment z pliku .flock agenta: test na platformie testowej IronFlock, a w przeciwnym razie production. Gdy katalog nie ma kanału urządzenia, jest nim production. Bazowy adres pobierania pochodzi z --download-base, potem z IRONFLOCK_DL_BASE, potem z serwera aktualizacji (update_url) z pliku .flock agenta (na urządzeniu IronFlock Appliance jest to kopia lustrzana pobierania Appliance, jedyne miejsce, do którego takie urządzenie może docierać), a w przeciwnym razie jest to chmura IronFlock.

Co robi polecenie, w tej kolejności:

1. Odczytuje podpisany katalog IronFlockOS i bierze pakiet aktualizacji dla obrazu urządzenia z wydania kanału (lub z --version).
2. Mówi, które wydanie działa w którym slocie, które wydanie zainstaluje i w którym slocie, co ten slot zawiera teraz i ile wynosi rozmiar pobierania. Potem pyta.
3. Pobiera pakiet aktualizacji do /var/cache/ironflockos na partycji danych. Przerwane pobieranie jest wznawiane. Plik jest używany tylko wtedy, gdy jego rozmiar i SHA-256 zgadzają się z katalogiem.
4. Zleca RAUC instalację pakietu aktualizacji w slocie, który nie działa. RAUC sprawdza podpis pakietu aktualizacji, zapisuje slot i ustawia go jako slot startujący następnym razem. To, co slot zawierał wcześniej, zostaje nadpisane. Pakiet aktualizacji jest usuwany po zainstalowaniu.
5. Z --reboot restartuje urządzenie do nowego systemu.

Działający system pozostaje bez zmian aż do restartu. Aplikacje i ich dane pozostają. Slot, który działa teraz, zachowuje swoje wydanie, a urządzenie wraca do niego, gdy nowe wydanie nie wystartuje lub nie dotrze do IronFlock.

Nic nie jest instalowane, a kod wyjścia wynosi 0, gdy urządzenie już działa w tym wydaniu oraz gdy wydanie jest już zainstalowane w drugim slocie i czeka na restart. W drugim przypadku --reboot pyta i restartuje urządzenie.

# Zainstaluj wydanie z kanału urządzenia; wystartuje przy następnym restarcie
sudo ironflock os update
# Zainstaluj je i zrestartuj do niego urządzenie, bez pytania
sudo ironflock os update --reboot --yes
# Zainstaluj starsze wydanie z katalogu
sudo ironflock os update --version 0.13.0

Postęp trafia na stderr: pobieranie i jego sprawdzenie, a potem każdy krok, który podaje RAUC. Co wypisuje os update --yes na urządzeniu, na którym działa 0.13.0 ze slotu A:

Download base: https://instance-registry.ironflock.com/dl (from default)
IronFlockOS catalog of 2026-11-20T09:00:00Z, signed with key 036ef3bd: production 0.14.0, test 0.14.0.
This device runs IronFlockOS 0.13.0 (ironflockos-amd64-efi-base) from slot A.
IronFlockOS 0.14.0, the release of the production channel, is installed into slot B, which holds nothing yet:
  - the bundle (580.2 MB) is downloaded into /var/cache/ironflockos
  - RAUC checks its signature and writes it into slot B
  - it starts with the next restart
Slot A keeps IronFlockOS 0.13.0: the device goes back to it when 0.14.0 does not start or does not reach IronFlock. Apps and their data stay.
Downloading: 0% (0 B of 580.2 MB)
...
Installing IronFlockOS 0.14.0 into slot B.
Installing:   0% Installing
...
Installing:  82% Copying image to rootfs.1
...
Installing: 100% Installing done.
IronFlockOS 0.14.0, the release of the production channel, is installed in slot B and starts with the next restart ('sudo reboot').

Z --json instalacja jest fazą postępu installing, w procentach. Wynik os update --reboot --yes --json:

{"action":"installed","image":"ironflockos-amd64-efi-base","channel":"production","version":"0.14.0","running_version":"0.13.0","slot":"B","up_to_date":false,"reboot":true}

Odmawia działania z kodem wyjścia 3, gdy:

• nie działa jako root, działa na maszynie bez IronFlockOS albo na pendrivie instalacyjnym.
• RAUC już instaluje pakiet aktualizacji, uruchomiony przez IronFlock Studio za pośrednictwem agenta lub w inny sposób. RAUC instaluje jeden pakiet naraz.
• wydanie nie ma pakietu aktualizacji dla obrazu urządzenia.
• wydanie jest starsze niż to, które działa, chyba że wskazuje je --version. Gdy drugi slot zawiera to wydanie, komunikat wskazuje os rollback.
• w /var/cache/ironflockos brakuje miejsca na to, co zostało do pobrania. Komunikat wymienia leżące w tym folderze pakiety aktualizacji z wcześniejszych aktualizacji, które możesz usunąć.

Błędne wiersze poleceń, kod wyjścia 2: --channel razem z --version, wartość, która nie jest numerem wersji, kanał lub wydanie, których nie ma w katalogu.

Kończy się błędem z kodem wyjścia 1, gdy: katalog nie przechodzi weryfikacji lub nie da się go odczytać; pobieranie się urywa (to, co dotarło, zostaje w /var/cache/ironflockos, a to samo polecenie wznawia pobieranie); pobrany plik nie jest plikiem z katalogu; RAUC odrzuca pakiet aktualizacji lub nie zdoła go zainstalować. Błąd podaje przyczynę od RAUC. Gdy RAUC zaczął już zapisywać, slot zostaje oznaczony jako zły i nie zawiera użytecznego systemu, a urządzenie nadal uruchamia działający system. Pakiet aktualizacji zostaje w pamięci podręcznej na następną próbę.

Ctrl-C podczas pobierania lub tuż po nim kończy polecenie kodem wyjścia 130, zanim cokolwiek zostanie zainstalowane lub zrestartowane; to samo polecenie wznawia pobieranie. Odpowiedź „nie” na pytanie kończy polecenie kodem wyjścia 4.

ironflock os rollback

Ustawia drugi slot systemowy jako slot startowy i restartuje do niego urządzenie: to powrót do systemu, który działał przed ostatnią aktualizacją. Używaj go dla systemu, który startuje, ale działa nieprawidłowo. System, który nie startuje albo nie dociera do IronFlock, IronFlockOS sam porzuca przy następnym restarcie.

ironflock os rollback [flags]

Polecenie nie ma własnych flag. Zawsze restartuje urządzenie: wycofanie bez restartu niczego by nie zmieniło aż do następnego restartu.

Kwalifikuje się tylko slot, którego system wystartował na tym urządzeniu:

• slot, którego system został oznaczony jako dobry, gdy działał, i od tego czasu nie był ponownie wypróbowywany. Slot, który był wypróbowywany i nigdy nie został oznaczony jako dobry, się nie kwalifikuje.
• slot, z którym urządzenie zostało zapisane (A), dopóki nic w nim nie zainstalowano i nie został oznaczony jako zły.

Aplikacje i ich dane pozostają, ponieważ oba systemy korzystają z tej samej partycji danych. Slot, który działał, zachowuje swoje wydanie. Po restarcie starszy system musi ponownie się sprawdzić: urządzenie go zachowuje, gdy agent urządzenia dotrze z niego do IronFlock. Na maszynie z UEFI slot, który już wcześniej się sprawdził, jest zachowywany także wtedy, gdy działa od dwóch minut. Do tego czasu restart może przywrócić nowszy system. IronFlock Studio ponownie oferuje wydanie z kanału, a os update je instaluje.

# Wróć do systemu w drugim slocie, po pytaniu
sudo ironflock os rollback
# Bez pytania
sudo ironflock os rollback --yes

Co wypisuje os rollback --yes na urządzeniu, na którym działa 0.14.0 ze slotu B:

This device runs IronFlockOS 0.14.0 from slot B.
Slot A holds IronFlockOS 0.13.0, which ran on this device before. The rollback makes slot A the one that starts and restarts the device now.
Slot B keeps IronFlockOS 0.14.0. Apps and their data stay: both systems use the same data partition.
The device keeps IronFlockOS 0.13.0 once it has proven itself again (the device agent reaches IronFlock from it); until then a restart can bring back 0.14.0.
Rolled back to IronFlockOS 0.13.0 in slot A: the device restarts now.

Z --json slot i version to slot, który startuje, i jego wydanie (puste, gdy nie da się go odczytać), a from_slot i from_version to system, który działał:

{"action":"rolled_back","slot":"A","version":"0.13.0","from_slot":"B","from_version":"0.14.0"}

Odmawia działania z kodem wyjścia 3 i podaje przyczynę, gdy:

• nie działa jako root, działa na maszynie bez IronFlockOS albo na pendrivie instalacyjnym oraz gdy RAUC instaluje pakiet aktualizacji.
• urządzenie ma bootloader, którego polecenie nie zna: zna GRUB (maszyny z UEFI) i bootloader Raspberry Pi.
• drugi slot nie zawiera jeszcze niczego (świeżo zapisane urządzenie), zawiera system, który był wypróbowywany i nie został oznaczony jako dobry, nie zawiera użytecznego systemu, ponieważ jego instalacja się nie zakończyła, albo jest oznaczony jako zły.
• drugi slot czeka na następny restart, po zainstalowanej aktualizacji lub wycofaniu bez restartu. sudo reboot go uruchamia, a sudo rauc status mark-bad other go porzuca.

Kończy się błędem z kodem wyjścia 1, gdy: RAUC nie może ustawić slotu jako slotu startowego (nic nie zostało zmienione); restart się nie powiedzie (slot wystartuje wtedy przy następnym restarcie). Odpowiedź „nie” na pytanie kończy polecenie kodem wyjścia 4.

ironflock os reset

Zgłasza żądanie resetu IronFlockOS do ustawień fabrycznych i restartuje urządzenie. Podczas następnego rozruchu urządzenie usuwa to, co zostawili jego właściciel, jego aplikacje i rejestracja, i startuje jak świeżo zapisane urządzenie; z -c rejestruje się jako urządzenie z nowego pliku .flock.

ironflock os reset [-c <new.flock>] [flags]

IronFlockOS 0.15.0 to pierwsze wydanie z resetem do ustawień fabrycznych. Na starszym wydaniu polecenie odmawia działania; os update instaluje nowsze.

Reset usuwa, na partycji danych i w obu slotach systemowych:

• aplikacje z ich danymi oraz kontenery, obrazy i woluminy Dockera.
• tożsamość urządzenia w IronFlock: agenta urządzenia z jego kopią pliku .flock, jego bazą danych i jego usługą. Nazwa hosta wraca do ironflockos, a identyfikator maszyny (machine ID) jest tworzony od nowa.
• użytkownika SSH i każde inne konto użytkownika, z ich folderami domowymi i regułami sudo.
• logi, klucze hosta SSH, pobrane aktualizacje i dostrojenie czasu rzeczywistego.
• bez --keep-network: profile sieciowe (w tym WiFi), ustawienie proxy (proxy.conf) i ustawienie PTP (ptp.conf).

Zachowuje systemy IronFlockOS w slotach systemowych, działający i drugi, jeśli zawiera system, oraz wpis RAUC o nich, więc aktualizacje i wycofania działają jak wcześniej. Z --keep-network zachowuje także powyższe ustawienia sieciowe. Nie cofa tego, co zmieniono ręcznie w samym systemie, na przykład pakietu lub pliku w /etc; robi to dopiero ponowny zapis IronFlockOS na dysku poleceniem os flash.

Co robi polecenie, w tej kolejności:

1. Odmawia działania w sytuacjach, w których urządzenie nie wykonałoby resetu zgodnie z żądaniem (poniżej), i sprawdza plik .flock z -c: 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.
2. Mówi na stderr, co zniknie, co zostanie, jak urządzenie wróci i co zrobił jego ostatni reset, a potem prosi o wpisanie nazwy urządzenia: jego nazwy z pliku .flock agenta, tak jak pokazuje ją ironflock status, albo nazwy hosta urządzenia, które nie jest zarejestrowane. Każda inna odpowiedź, także sam Enter, oznacza „nie”.
3. Zapisuje żądanie na partycji IRONFLOCKOS, gdy własne sprawdzenie urządzenia je zaakceptuje. Żądanie, które już tam jest, zostaje zastąpione; nowe żądanie ma własne trzy próby.
4. Z -c usuwa z partycji wszystkie inne pliki .flock, ponieważ urządzenie rejestruje się z najnowszym, i zapisuje tam nowy plik .flock. Gdy to się nie powiedzie, żądanie jest z powrotem usuwane.
5. Restartuje urządzenie. Podczas następnego startu urządzenie resetuje się w ciągu kilku sekund (minut na wolnej karcie SD), restartuje się jeszcze raz i startuje jak świeżo zapisane urządzenie, z nowymi kluczami hosta SSH.

Po resecie, z -c, urządzenie rejestruje się jako urządzenie z tego pliku .flock i jest dostępne przez SSH jako jego użytkownik SSH. Bez -c czeka na plik .flock na swojej partycji IRONFLOCKOS i jest dostępne tylko przez swoją konsolę: nie ma użytkownika SSH ani połączenia z IronFlock. Połączenie SSH z urządzeniem, także to z --host, kończy się wraz z restartem; bez -c żadne nie wraca.

Uwaga: Jeśli masz dostęp do urządzenia tylko przez sieć, podaj nowy plik .flock przez -c. Bez niego ktoś musi być przy urządzeniu, aby znów było online.

Nieudana próba nie restartuje urządzenia: urządzenie startuje w obecnym stanie, a jego następny start, wywołany przez człowieka lub przez aktualizację, próbuje ponownie. Po trzech nieudanych próbach reset zostaje zaniechany, a urządzenie startuje z tym, co jest. Ze swoimi starymi danymi pozostaje urządzeniem, którym było, online ze swoją starą tożsamością, a plik .flock i ustawienie proxy, które przyszły z żądaniem, są usuwane. Żądanie, które się zakończyło, wykonane lub zaniechane, nigdy nie zostanie wykonane ponownie, w żadnym slocie i po żadnej aktualizacji. Dysk, który nie odpowiada, może wstrzymać próbę do 25 minut. ironflock status pokazuje nieudany lub zaniechany reset w wierszu Last reset:.

Zanim zapyta, polecenie pokazuje ostatni reset odnotowany przez urządzenie:

# Zresetuj urządzenie; potem czeka ono na plik .flock
sudo ironflock os reset
# Zresetuj je i zmień w urządzenie z new-device.flock
sudo ironflock os reset -c new-device.flock
# Zachowaj ustawienia sieciowe, bez pytania
sudo ironflock os reset --keep-network --yes
# Z innego komputera, na IronFlockOS 0.15.0
ironflock --host operator@edge-01 os reset -c new-device.flock

Co wypisuje os reset -c kitchen-pi.flock na urządzeniu edge-01, którego ostatni reset został zaniechany, gdy w odpowiedzi na pytanie wpisano nazwę urządzenia:

This device runs IronFlockOS 0.15.0 from slot B and is the IronFlock device edge-01.
The last factory reset of this device: gave up after 3 attempts at 2026-11-11T09:00:00Z: the data partition is not the partition named data on the disk of the root slot; /data holds the old data; left of the old owner: the data partition, the booted root slot, the other root slot; the device stayed the device it was, online with its old identity, and the .flock and proxy.conf that came with the request were removed.
What can be done: request the reset again, as this command does now, with three new attempts; or write IronFlockOS to the device's disk anew ('ironflock os flash'), which clears everything.
The factory reset restarts the device now. During the next boot the device resets itself, in seconds (minutes on a slow SD card), and restarts once more. It clears:
  - the apps with their data, and Docker's containers, images and volumes
  - the device's identity at IronFlock: the agent with its copy of the .flock and its database; the hostname goes back to ironflockos
  - the SSH user and every other user account, with their home folders
  - the logs, the SSH host keys and the downloaded updates
  - the network profiles (the WiFi among them), the proxy setting and the PTP setting
It keeps IronFlockOS 0.15.0 in slot B, which runs, and IronFlockOS 0.14.0 in slot A, so updates and rollbacks work as before.
It does not undo what was changed by hand in the system itself, such as a package or a file in /etc.
Then the device starts as a freshly written one with kitchen-pi.flock, which goes onto its IRONFLOCKOS partition: it enrolls as kitchen-pi and can be reached over SSH as operator, with the device key of that .flock and new SSH host keys.
An attempt that fails does not restart the device: it comes up as it is, and its next start tries again; after three failed attempts the reset gives up, and the device starts with what is there. 'ironflock status' shows a failed or given-up reset.
An SSH connection to the device, also the one of --host, ends with the restart.
? Type the device's name, edge-01, to reset it: edge-01
Factory reset requested: the device restarts now, resets itself and enrolls as kitchen-pi.

Wynik os reset --keep-network --yes --json:

{"action":"reset","device":"edge-01","keep_network":true}

Odmawia działania z kodem wyjścia 3 i podaje przyczynę oraz to, co zrobić, gdy:

• nie działa jako root, działa na maszynie bez IronFlockOS albo na pendrivie instalacyjnym oraz gdy RAUC instaluje pakiet aktualizacji.
• dany IronFlockOS nie ma resetu do ustawień fabrycznych: przynosi go nowsze wydanie, które instaluje os update.
• /boot/efi nie jest zamontowaną partycją IRONFLOCKOS: nic tam nie jest zamontowane albo jest tam system plików inny niż FAT.
• reset już się zaczął: będzie kontynuowany przy następnym starcie, a do tego czasu nic nie powinno się zmieniać. Komunikat podaje ostatnią próbę.
• bez -c na partycji IRONFLOCKOS leży plik .flock: po resecie urządzenie zarejestrowałoby się z nim, zamiast czekać na plik.
• następnym startem nie byłby działający system oznaczony jako dobry. Aktualizacja lub wycofanie czeka na swój restart: sudo reboot go uruchamia, sudo rauc status mark-bad other go porzuca. Albo działający system nie został jeszcze oznaczony jako dobry: sudo rauc status mark-good go zachowuje, os rollback wraca do poprzedniego.
• własne sprawdzenie urządzenia nie przyjmuje żądania: nic nie zostaje zażądane, a komunikat podaje przyczynę wskazaną przez urządzenie.

Kończy się błędem z kodem wyjścia 1, gdy:

• nie da się odczytać tabeli montowań, więc polecenie nie może ustalić, czy /boot/efi jest partycją IRONFLOCKOS. Nic nie zostaje zapisane.
• plik .flock z -c nie jest prawidłowy.
• nie da się zapisać żądania lub pliku .flock albo usunąć innego pliku .flock. Żądanie zostaje wycofane, a błąd mówi, czego już nie ma.
• restart się nie powiedzie. Urządzenie zresetuje się wtedy przy następnym starcie; usunięcie /boot/efi/factory-reset.conf i pliku .flock z partycji IRONFLOCKOS anuluje reset.

Ctrl-C, SIGTERM lub utracona sesja SSH w trakcie zapisu żądania sprawiają, że polecenie wycofuje żądanie: kończy się kodem wyjścia 130, a urządzenie się nie restartuje. Błędnie wpisana nazwa w odpowiedzi na pytanie kończy polecenie kodem wyjścia 4.

Kody wyjścia wszystkich poleceń objaśnia strona Flagi, wyjście i kody wyjścia. Przez --host kod wyjścia 255 oznacza, że połączenie SSH nie powiodło się.