업데이트, 롤백 및 재설정

이 명령은 IronFlockOS를 실행하는 디바이스를 관리합니다. os update는 릴리스를 설치하고, os rollback은 이전에 실행되던 릴리스로 되돌아가며, os reset은 디바이스를 다시 새로 쓴 상태로 만듭니다.

루트 슬롯과 데이터 파티션

IronFlockOS 디바이스의 디스크에는 다음이 있습니다:

• 두 루트 슬롯 A와 B — 각 슬롯에는 완전한 IronFlockOS 시스템이 들어 있습니다. 하나가 실행됩니다. 다른 하나에는 이전에 실행되던 시스템이 있으며, 새로 쓴 디바이스에서는 아직 아무것도 없습니다. IronFlockOS가 사용하는 업데이트 도구인 RAUC는 실행되지 않는 슬롯에 릴리스를 쓰고, 다음에 어느 슬롯이 시작될지 기록합니다.
• 데이터 파티션(/data) — 앱과 그 데이터, 그리고 디바이스 구성 파일(.flock)의 사본을 가진 디바이스 에이전트. 두 시스템이 모두 이 파티션을 사용하므로, 업데이트나 롤백을 해도 앱과 그 데이터는 그대로 남습니다.
• IRONFLOCKOS 파티션(/boot/efi에 마운트) — 작은 FAT 파티션. 디바이스는 시작할 때 이곳에서 찾은 .flock 파일로 등록되며, os reset은 이곳에 요청을 씁니다.

새 시스템은 스스로 정상임을 증명해야 합니다. 디바이스 에이전트가 새 시스템에서 IronFlock에 도달하고 그 시스템을 정상으로 표시하면 디바이스는 새 시스템을 유지합니다. 시작되지 않거나 IronFlock에 도달하지 못하는 시스템은 다음 재시작 때 이전에 실행되던 시스템으로 대체됩니다. ironflock status가 슬롯을 보여 줍니다:

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

명령이 실행되는 곳

세 명령은 IronFlockOS를 실행하는 디바이스에서 실행되며, root 권한이 필요하고, 동작하기 전에 묻습니다. 다른 시스템(macOS, IronFlockOS가 아닌 Linux, IronFlockOS 설치 USB 스틱)에서는 종료 코드 3으로 끝납니다.

• 디바이스에서 — 0.15.0 이후의 IronFlockOS 릴리스에는 ironflock이 들어 있습니다. 디바이스에 로그인하고 sudo로 명령을 실행하십시오.
• 다른 컴퓨터에서 — 0.15.0까지의 IronFlockOS 릴리스에는 ironflock이 없습니다. Linux 또는 macOS 컴퓨터에서 --host로, 디바이스의 SSH 사용자로 명령을 실행하십시오. SSH 사용자는 .flock 파일이 프로젝트 소유자용으로 설정하는 계정이며, 예에서는 operator입니다. --host는 실행을 위해 ironflock을 디바이스에 복사하고, 그곳에서 sudo를 통해 명령을 실행합니다.

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

os update와 os rollback은 --yes를 지정하면 여러 디바이스에서 동시에 실행됩니다(--host를 여러 번 지정하거나 --hosts 사용). os reset은 한 번에 디바이스 하나에서만 실행되며, 여러 디바이스에서는 종료 코드 2로 끝납니다. 전역 플래그는 플래그, 출력 및 종료 코드 페이지에 나와 있습니다.

ironflock os update

디바이스의 채널이 제공하는 IronFlockOS 릴리스를 실행 중이 아닌 루트 슬롯에 설치합니다. 새 시스템은 다음 재시작 때 시작되며, --reboot를 사용하면 즉시 시작됩니다.

ironflock os update [flags]

디바이스의 채널은 디바이스 에이전트가 따르는 채널로, 에이전트 .flock 파일의 environment에서 정해집니다. IronFlock 테스트 플랫폼에서는 test, 그 밖에는 production입니다. 카탈로그에 디바이스의 채널이 없으면 production입니다. 다운로드 베이스는 --download-base, 그다음 IRONFLOCK_DL_BASE, 그다음 에이전트 .flock 파일의 업데이트 서버(update_url)에서 가져오며(IronFlock 어플라이언스의 디바이스에서는 어플라이언스의 다운로드 미러로, 이런 디바이스가 도달할 수 있는 유일한 곳입니다), 모두 없으면 IronFlock 클라우드입니다.

다음 순서로 동작합니다:

1. 서명된 IronFlockOS 카탈로그를 읽고, 채널(또는 --version)의 릴리스에서 디바이스 이미지의 업데이트 번들을 택합니다.
2. 어느 슬롯에서 어떤 릴리스가 실행 중인지, 어떤 릴리스를 어느 슬롯에 설치하는지, 그 슬롯에 지금 무엇이 있는지, 다운로드 크기를 알려 줍니다. 그런 다음 묻습니다.
3. 데이터 파티션에 있는 /var/cache/ironflockos로 번들을 다운로드합니다. 중단된 다운로드는 이어받습니다. 파일은 크기와 SHA-256이 카탈로그와 같을 때만 사용합니다.
4. RAUC가 실행 중이 아닌 슬롯에 번들을 설치하게 합니다. RAUC는 번들의 서명을 확인하고, 슬롯에 쓰고, 그 슬롯을 다음에 시작할 슬롯으로 지정합니다. 슬롯에 있던 내용은 덮어씁니다. 번들은 설치되면 제거됩니다.
5. --reboot를 사용하면 디바이스를 새 시스템으로 재시작합니다.

실행 중인 시스템은 재시작할 때까지 그대로입니다. 앱과 그 데이터는 그대로 남습니다. 지금 실행 중인 슬롯은 자신의 릴리스를 유지하며, 새 릴리스가 시작되지 않거나 IronFlock에 도달하지 못하면 디바이스는 이 슬롯으로 돌아갑니다.

디바이스가 이미 그 릴리스를 실행 중일 때, 그리고 릴리스가 이미 다른 슬롯에 설치되어 재시작을 기다리고 있을 때는 아무것도 설치하지 않으며 종료 코드는 0입니다. 두 번째 경우 --reboot를 사용하면 묻고 디바이스를 재시작합니다.

# 디바이스 채널의 릴리스 설치. 다음 재시작 때 시작됨
sudo ironflock os update
# 질문 없이 설치하고 새 시스템으로 재시작
sudo ironflock os update --reboot --yes
# 카탈로그의 더 오래된 릴리스 설치
sudo ironflock os update --version 0.13.0

진행 상황은 stderr에 나옵니다. 다운로드와 그 확인, 그다음 RAUC가 알리는 각 단계입니다. 슬롯 A에서 0.13.0을 실행하는 디바이스에서 os update --yes가 출력하는 내용:

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').

--json을 사용하면 설치는 퍼센트 단위의 진행 상황 단계 installing으로 나옵니다. 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}

거부하는 경우(종료 코드 3):

• root로 실행되지 않을 때, IronFlockOS를 실행하지 않는 머신에서, 그리고 설치 USB 스틱에서.
• RAUC가 이미 번들을 설치 중일 때. IronFlock Studio가 에이전트를 통해 시작했거나 다른 호출이 시작한 설치입니다. RAUC는 한 번에 하나만 설치합니다.
• 릴리스에 디바이스 이미지용 번들이 없을 때.
• 릴리스가 실행 중인 릴리스보다 오래되었을 때. 단, --version으로 지정하면 설치합니다. 다른 슬롯에 그 릴리스가 있으면 메시지가 os rollback을 알려 줍니다.
• /var/cache/ironflockos에 아직 다운로드할 내용을 위한 공간이 없을 때. 메시지는 폴더에 있는 이전 업데이트의 번들을 나열하며, 이 번들은 삭제해도 됩니다.

잘못된 명령줄(종료 코드 2): --channel과 --version을 함께 지정, 올바른 버전이 아닌 버전, 카탈로그에 없는 채널이나 릴리스.

실패하는 경우(종료 코드 1): 카탈로그가 검증되지 않거나 읽을 수 없을 때. 다운로드가 중단될 때(받은 부분은 /var/cache/ironflockos에 남으며, 같은 명령으로 이어받음). 다운로드한 파일이 카탈로그의 파일이 아닐 때. RAUC가 번들을 거부하거나 설치에 실패할 때. 오류는 RAUC가 밝힌 이유를 알려 줍니다. RAUC가 쓰기를 시작했다면 슬롯은 불량으로 표시되고 사용할 수 있는 시스템이 없으며, 디바이스는 계속 실행 중인 시스템으로 시작합니다. 번들은 다음 시도를 위해 캐시에 남습니다.

다운로드 중이나 다운로드 직후에 Ctrl-C를 누르면 아무것도 설치하거나 재시작하기 전에 명령이 종료 코드 130으로 끝나며, 같은 명령으로 다운로드를 이어받습니다. 질문에 아니요로 답하면 종료 코드 4로 끝납니다.

ironflock os rollback

다른 루트 슬롯을 시작할 슬롯으로 지정하고, 디바이스를 그 슬롯으로 재시작합니다. 즉 마지막 업데이트 전에 실행되던 시스템으로 돌아갑니다. 시작은 되지만 제대로 동작하지 않는 시스템에 사용하십시오. 시작되지 않거나 IronFlock에 도달하지 못하는 시스템은 다음 재시작 때 IronFlockOS가 스스로 버리고 이전 시스템으로 돌아갑니다.

ironflock os rollback [flags]

이 명령에는 자체 플래그가 없습니다. 항상 디바이스를 재시작합니다. 재시작 없는 롤백은 다음 재시작 때까지 아무것도 바꾸지 않기 때문입니다.

이 디바이스에서 시스템이 시작된 적이 있는 슬롯만 대상이 됩니다:

• 실행되는 동안 시스템이 정상으로 표시되었고, 그 뒤로 다시 시도되지 않은 슬롯. 시도되었지만 한 번도 정상으로 표시되지 않은 슬롯은 대상이 아닙니다.
• 디바이스를 쓸 때 사용된 슬롯(A). 단, 그 슬롯에 아무것도 설치되지 않았고 불량으로 표시되지 않은 동안만입니다.

두 시스템이 같은 데이터 파티션을 사용하므로 앱과 그 데이터는 그대로 남습니다. 실행되던 슬롯은 자신의 릴리스를 유지합니다. 재시작 후 이전 시스템은 다시 스스로 정상임을 증명해야 합니다. 디바이스 에이전트가 그 시스템에서 IronFlock에 도달하면 디바이스는 그 시스템을 유지합니다. UEFI 머신에서는 전에 이를 증명한 슬롯이라면 2분 동안 실행되어도 유지됩니다. 그때까지는 재시작하면 더 새로운 시스템으로 돌아갈 수 있습니다. IronFlock Studio는 채널의 릴리스를 다시 제공하며, os update가 이를 설치합니다.

# 질문 후 다른 슬롯의 시스템으로 되돌아가기
sudo ironflock os rollback
# 질문 없이
sudo ironflock os rollback --yes

슬롯 B에서 0.14.0을 실행하는 디바이스에서 os rollback --yes가 출력하는 내용:

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.

--json을 사용하면 slot과 version은 시작할 슬롯과 그 릴리스(읽을 수 없으면 비어 있음)이고, from_slot과 from_version은 실행되던 시스템입니다:

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

거부하는 경우(종료 코드 3). 그 이유를 알려 줍니다:

• root로 실행되지 않을 때, IronFlockOS를 실행하지 않는 머신에서, 설치 USB 스틱에서, 그리고 RAUC가 번들을 설치하는 동안.
• 디바이스의 부트로더를 명령이 모를 때. 명령은 GRUB(UEFI 머신)과 Raspberry Pi의 부트로더를 압니다.
• 다른 슬롯에 아직 아무것도 없거나(새로 쓴 디바이스), 시도되었지만 정상으로 표시되지 않은 시스템이 있거나, 설치가 끝나지 않아 사용할 수 있는 시스템이 없거나, 불량으로 표시되었을 때.
• 설치된 업데이트나 재시작하지 않은 롤백 후, 다른 슬롯이 다음 재시작을 기다리고 있을 때. sudo reboot로 그 슬롯을 시작하거나, sudo rauc status mark-bad other로 취소할 수 있습니다.

실패하는 경우(종료 코드 1): RAUC가 그 슬롯을 시작할 슬롯으로 지정할 수 없을 때(아무것도 변경되지 않음). 재시작이 실패할 때(이 경우 슬롯은 다음 재시작 때 시작됨). 질문에 아니요로 답하면 종료 코드 4로 끝납니다.

ironflock os reset

IronFlockOS의 공장 초기화를 요청하고 디바이스를 재시작합니다. 다음 부팅 때 디바이스는 소유자, 앱, 등록이 남긴 것을 지우고 새로 쓴 디바이스로 시작합니다. -c를 사용하면 새 .flock 파일의 디바이스로 등록됩니다.

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

IronFlockOS 0.15.0은 공장 초기화가 포함된 첫 릴리스입니다. 이전 릴리스에서는 명령이 거부하며, os update로 더 새로운 릴리스를 설치할 수 있습니다.

재설정은 데이터 파티션과 두 루트 슬롯에서 다음을 지웁니다:

• 앱과 그 데이터, 그리고 Docker의 컨테이너, 이미지, 볼륨.
• IronFlock에서의 디바이스 ID: .flock 파일 사본, 데이터베이스, 서비스를 포함한 디바이스 에이전트. 호스트 이름은 ironflockos로 돌아가고, 머신 ID는 새로 만들어집니다.
• SSH 사용자와 그 밖의 모든 사용자 계정, 그리고 그 홈 폴더와 sudo 규칙.
• 로그, SSH 호스트 키, 다운로드한 업데이트, 실시간 튜닝.
• --keep-network가 없으면: 네트워크 프로필(WiFi 포함), 프록시 설정(proxy.conf), PTP 설정(ptp.conf).

루트 슬롯의 IronFlockOS 시스템, 즉 실행 중인 시스템과 다른 슬롯에 시스템이 있으면 그 시스템, 그리고 이에 대한 RAUC의 기록은 유지하므로, 업데이트와 롤백은 이전과 같이 동작합니다. --keep-network를 사용하면 위의 네트워크 설정도 유지합니다. 패키지나 /etc의 파일처럼 시스템 자체에서 직접 변경한 내용은 되돌리지 않습니다. 이를 되돌리려면 os flash로 IronFlockOS를 디스크에 새로 쓰십시오.

다음 순서로 동작합니다:

1. 디바이스가 요청대로 수행하지 않을 경우를 거부하고(아래 참조), -c의 .flock 파일을 확인합니다: 이름이 *.flock이고 최대 5 MiB인 파일이어야 하며, secret과 device_key가 있는 JSON 객체이고, name과 serial_number가 일반 이름이어야 합니다.
2. stderr에 무엇이 지워지고, 무엇이 남고, 디바이스가 어떻게 돌아오며, 마지막 재설정이 어떻게 되었는지 알린 다음, 디바이스의 이름을 입력하라고 요구합니다. 이름은 ironflock status가 보여 주는 에이전트 .flock 파일의 이름, 또는 등록되지 않은 디바이스라면 호스트 이름입니다. 그 밖의 입력은 Enter만 누른 경우를 포함해 모두 아니요로 처리됩니다.
3. 디바이스 자체의 검사가 요청을 받아들이면 IRONFLOCKOS 파티션에 요청을 씁니다. 이미 있는 요청은 교체되며, 이번 요청은 자체 시도 횟수 세 번을 가진 새 요청입니다.
4. -c를 사용하면, 디바이스가 가장 새로운 .flock 파일로 등록되므로 파티션에서 다른 .flock 파일을 모두 제거하고, 새 .flock 파일을 그곳에 씁니다. 이 단계가 실패하면 요청이 다시 제거됩니다.
5. 디바이스를 재시작합니다. 다음 시작 때 디바이스는 몇 초(느린 SD 카드에서는 몇 분) 만에 스스로 재설정하고, 한 번 더 재시작한 뒤, 새 SSH 호스트 키를 가진 새로 쓴 디바이스로 시작합니다.

재설정 후 -c를 사용했다면 디바이스는 그 .flock 파일의 디바이스로 등록되며, 그 SSH 사용자로 SSH 접속할 수 있습니다. -c가 없으면 디바이스는 IRONFLOCKOS 파티션에 .flock 파일이 생기기를 기다리며, 콘솔에서만 접근할 수 있습니다. SSH 사용자도 IronFlock 연결도 없습니다. 디바이스에 대한 SSH 연결은 --host의 연결을 포함해 재시작과 함께 끊어지며, -c가 없으면 다시 연결되지 않습니다.

참고: 네트워크로만 디바이스에 접근할 수 있다면 -c로 새 .flock 파일을 지정하십시오. 그렇지 않으면 누군가 디바이스 앞에서 디바이스를 다시 온라인으로 만들어야 합니다.

실패한 시도는 디바이스를 재시작하지 않습니다. 디바이스는 그 상태 그대로 올라오며, 사람이나 업데이트에 의한 다음 시작 때 다시 시도합니다. 세 번 실패하면 재설정은 포기하고, 디바이스는 있는 그대로 시작합니다. 이전 데이터가 있는 디바이스는 원래의 디바이스로 남아 이전 ID로 온라인 상태가 되며, 요청과 함께 온 .flock 파일과 프록시 설정은 제거됩니다. 완료되었든 포기되었든 끝난 요청은 어느 슬롯에서든, 어떤 업데이트 후에든 다시 실행되지 않습니다. 응답하지 않는 디스크는 한 번의 시도를 최대 25분까지 붙잡아 둘 수 있습니다. ironflock status는 실패했거나 포기된 재설정을 Last reset: 줄에 보여 줍니다.

명령은 묻기 전에 디바이스가 기록한 마지막 재설정을 보여 줍니다:

# 디바이스 재설정. 이후 .flock 파일을 기다림
sudo ironflock os reset
# 재설정하고 new-device.flock의 디바이스로 만듦
sudo ironflock os reset -c new-device.flock
# 네트워크 설정을 유지하고 질문 없이 재설정
sudo ironflock os reset --keep-network --yes
# 다른 컴퓨터에서 실행(IronFlockOS 0.15.0)
ironflock --host operator@edge-01 os reset -c new-device.flock

마지막 재설정이 포기된 디바이스 edge-01에서, 질문에 이름을 입력했을 때 os reset -c kitchen-pi.flock이 출력하는 내용:

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.

os reset --keep-network --yes --json의 결과:

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

거부하는 경우(종료 코드 3). 그 이유와 할 일을 알려 줍니다:

• root로 실행되지 않을 때, IronFlockOS를 실행하지 않는 머신에서, 설치 USB 스틱에서, 그리고 RAUC가 번들을 설치하는 동안.
• IronFlockOS에 공장 초기화 기능이 없을 때. 더 새로운 릴리스에 있으며, os update로 설치합니다.
• /boot/efi가 마운트된 IRONFLOCKOS 파티션이 아닐 때: 그곳에 아무것도 마운트되어 있지 않거나, FAT가 아닌 파일 시스템이 마운트되어 있음.
• 재설정이 이미 시작되었을 때. 다음 시작 때 계속 진행되며, 그때까지는 아무것도 변경하지 않아야 합니다. 메시지는 마지막 시도를 알려 줍니다.
• -c 없이 실행했는데 IRONFLOCKOS 파티션에 .flock 파일이 있을 때. 재설정 후 디바이스가 .flock 파일을 기다리지 않고 이 파일로 등록되기 때문입니다.
• 다음에 시작될 시스템이 정상으로 표시된 실행 중인 시스템이 아닐 때. 업데이트나 롤백이 재시작을 기다리고 있다면 sudo reboot로 시작하거나 sudo rauc status mark-bad other로 취소할 수 있습니다. 또는 실행 중인 시스템이 아직 정상으로 표시되지 않았다면 sudo rauc status mark-good으로 유지하거나 os rollback으로 되돌아갈 수 있습니다.
• 디바이스 자체의 검사가 요청을 받아들이지 않을 때. 아무것도 요청되지 않으며, 메시지가 디바이스가 밝힌 이유를 알려 줍니다.

실패하는 경우(종료 코드 1):

• 마운트 테이블을 읽을 수 없어 /boot/efi가 IRONFLOCKOS 파티션인지 알 수 없을 때. 아무것도 쓰지 않습니다.
• -c의 .flock 파일이 유효하지 않을 때.
• 요청이나 .flock 파일을 쓸 수 없거나, 다른 .flock 파일을 제거할 수 없을 때. 요청은 철회되며, 오류는 무엇이 사라졌는지 알려 줍니다.
• 재시작이 실패할 때. 이 경우 디바이스는 다음 시작 때 스스로 재설정합니다. IRONFLOCKOS 파티션에서 /boot/efi/factory-reset.conf와 .flock 파일을 제거하면 재설정이 취소됩니다.

명령이 요청을 쓰는 동안 Ctrl-C나 SIGTERM을 받거나 SSH 세션이 끊기면 명령은 요청을 철회합니다. 종료 코드 130으로 끝나며, 디바이스는 재시작하지 않습니다. 질문에 이름을 잘못 입력하면 종료 코드 4로 끝납니다.

모든 명령의 종료 코드는 플래그, 출력 및 종료 코드 페이지에서 설명합니다. --host를 통해 실행할 때 종료 코드 255는 SSH 연결이 실패했다는 뜻입니다.