Linux를 IronFlockOS로 교체

ironflock os install은 실행 중인 머신이 시작된 Linux를 같은 디스크에서 IronFlockOS로 교체하고, 머신을 디바이스 구성 파일(.flock)의 IronFlock 디바이스로 만듭니다. 머신에서 직접 실행하거나, 다른 컴퓨터에서 SSH로 실행합니다.

경고: 머신이 시작된 디스크의 모든 내용이 사라집니다. 실행 중인 시스템, 그 패키지와 설정, 사용자 계정, 모든 데이터가 사라지며 되돌릴 방법은 없습니다. 먼저 --dry-run으로 명령을 실행하고 계획을 읽으십시오.

사용하는 경우

Debian, Ubuntu 또는 systemd를 사용하는 다른 Linux가 이미 실행 중이고, USB 스틱으로 시작할 수 없거나 그렇게 하고 싶지 않은 머신에 os install을 사용하십시오. 예를 들어 제어반 안의 PC, 클라우드의 가상 머신, SSH로만 접속할 수 있는 머신입니다. --host를 사용하면 Mac을 포함한 자신의 컴퓨터에서 명령을 실행할 수 있으며, 명령은 머신이 IronFlock 디바이스로 온라인이 될 때까지 기다립니다.

다음 경우에는 다른 명령을 사용하십시오:

• 머신을 드라이브로 시작할 수 있는 경우 — ironflock os flash는 IronFlockOS를 USB 스틱, SD 카드 또는 외장 디스크에 씁니다. --installer를 사용하면 설치 USB 스틱을 쓰며, 이 스틱은 스틱으로 시작하는 PC의 내부 디스크에 IronFlockOS를 설치합니다. os install이 거부하는 대부분의 머신에도 설치 USB 스틱이 해결책입니다.
• 머신이 Raspberry Pi인 경우 — os install은 UEFI 머신용 이미지(타깃 amd64-efi와 arm64-efi)만 설치합니다. Raspberry Pi의 SD 카드는 os flash로 쓰십시오.
• 머신에서 이미 IronFlockOS가 실행 중인 경우 — os install은 이를 거부합니다. 그곳에서는 ironflock os update가 다른 릴리스를 설치합니다.
• 머신의 Linux를 유지하려는 경우 — ironflock agent install은 머신을 그대로 IronFlock에 연결합니다.

ironflock os install

머신을 검사하고, 교체 계획을 보여 주고, 묻습니다. 그런 다음 IronFlockOS를 메모리에 스테이징하고 머신을 재시작합니다. 머신은 종료 과정의 마지막에 IronFlockOS를 디스크에 쓰고 IronFlockOS를 시작합니다.

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

macOS에서는 아무것도 살펴보기 전에 종료 코드 3으로 끝나므로, 그곳에서는 --host로 실행하십시오. 한 번에 머신 하나에서만 실행됩니다. --host를 여러 번 지정하거나 --hosts를 사용하면 종료 코드 2로 끝납니다. 전역 플래그는 플래그, 출력 및 종료 코드 페이지에 나와 있습니다.

플래그

프록시 플래그는 agent install에서와 똑같이 동작합니다. 플래그가 없으면 명령은 환경에서 HTTP_PROXY, HTTPS_PROXY, NO_PROXY를 가져옵니다. 비밀번호가 들어 있는 프록시 URL은 잘못된 명령줄입니다(종료 코드 2). 시크릿을 참조하십시오.

머신의 요구 사항

• 시스템 — PID 1이 systemd인 Linux(예: Debian, Ubuntu)이며, 컨테이너 안이 아니어야 합니다. IronFlockOS와 ReswarmOS는 거부됩니다.
• 펌웨어 — amd64 또는 arm64의 64비트 UEFI. EFI 변수가 마운트되어 있고(efivarfs) 쓰기 가능해야 합니다. BIOS와 32비트 UEFI는 거부됩니다. Secure Boot는 켜져 있어도 됩니다. Secure Boot를 참조하십시오.
• 디스크 — 펌웨어가 시스템을 시작한 디스크: GPT(GUID 파티션 테이블)와 512바이트 논리 섹터를 사용하는, 그 자체로 독립된 디스크. 루트 파일 시스템이 직접 또는 LVM이나 LUKS를 통해 이 디스크에만 있어야 합니다. 디스크 크기는 이미지의 최소 디스크 크기 이상이어야 합니다: 카탈로그가 지정하는 크기, 없으면 10 GiB, nvidia 이미지는 18 GiB.
• 메모리 — 압축된 이미지, ironflock 바이너리, 그리고 추가 512 MiB를 담을 수 있는 사용 가능한 메모리(MemAvailable). base 이미지라면 약 2 GiB 메모리의 머신이면 됩니다.
• 도구 — lsblk, 그리고 iproute2의 ip.
• 네트워크 — 새 시스템이 사용할 수 있는 네트워크를 통해, 직접 또는 프록시를 거쳐 다운로드 서버에 도달할 수 있어야 합니다(새 시스템이 받는 것). IronFlock 어플라이언스의 디바이스에서는 어플라이언스의 다운로드 미러일 수 있습니다(파일을 가져오는 곳).
• .flock 파일 — -c의 파일, 또는 머신에 설치된 디바이스 에이전트의 파일.

파일을 가져오는 곳

명령에는 서명된 IronFlockOS 카탈로그, 이미지, 그리고 이미지의 하드웨어 목록이 필요합니다. 명령은 이것들을 다음 순서로 가져옵니다:

1. --download-base, 없으면 IRONFLOCK_DL_BASE: 그 서버에서만 가져옵니다.
2. 그 밖에는 .flock 파일이 업데이트 서버로 지정하는 IronFlock 어플라이언스의 다운로드 미러. 즉 그 update_url이며, 호스트가 IronFlock 클라우드의 호스트가 아닌 절대 http 또는 https URL일 때입니다. 예: https://registry.<domain>/dl 또는 http://<host>:<port>/dl. stderr에 Download base: ... (from the device's .flock)가 나옵니다. 어플라이언스에는 접근할 수 있지만 ironflock.com에는 접근할 수 없는 머신은 이 방법으로 전환됩니다. IronFlock 클라우드의 .flock 파일은 클라우드를 사용합니다.
3. 그 밖에는 IronFlock 클라우드 https://instance-registry.ironflock.com/dl.

어플라이언스의 미러를 사용하면 파일은 먼저 미러에서 가져오고, 미러가 제공하지 않는 파일은 IronFlock 클라우드에서 가져옵니다:

• 카탈로그 <mirror>/ironflockos/manifest.json — 미러가 지금 카탈로그를 제공하지 않으면(접근할 수 없음, 오류로 응답, 또는 마지막 카탈로그의 보관된 사본만 대신할 수 있는 경우) 어플라이언스가 없을 때와 마찬가지로 모든 것을 클라우드에서 가져옵니다. 미러가 제공한 카탈로그가 거부되면(서명, 보관된 사본보다 오래됨, 너무 큼) 다른 서버에서와 마찬가지로 명령이 실패합니다.
• 이미지 <mirror>/ironflockos/<version>/<file> — 미러가 이미지를 제공하지 않으면(접근할 수 없음, 파일이 아닌 것으로 응답, 또는 보낸 내용이 이미지의 시작 부분이 아님) 서명된 카탈로그가 지정하는 URL에서 가져옵니다. os flash 캐시의 파일은 어느 쪽에도 묻지 않습니다.
• 하드웨어 목록 <mirror>/ironflockos/<version>/<image>-<version>.modules.alias.gz — 같은 규칙이 따로 적용됩니다.

대체할 때마다 계획에 미러, 파일, 이유가 담긴 경고가 나오며, --json을 사용하면 warnings에 나옵니다. 계획은 각 파일의 출처를 한 번 정합니다. 스테이징은 계획의 image.url에서 이미지를 다운로드하며 다시 대체하지 않습니다. 미러도 클라우드도 파일을 제공하지 않으면 명령은 두 출처와 두 이유를 모두 알려 주는 오류 하나로 실패합니다(neither the appliance's mirror ... nor the IronFlock cloud gives ...).

agent install과 마찬가지로 미러에는 직접, 클라우드에는 프록시를 거쳐 접근합니다. 어플라이언스 자체 CA의 인증서를 쓰는 HTTPS 미러는 머신의 시스템이 그 CA를 신뢰할 때만 작동합니다. 어플라이언스가 응답하면 새 시스템은 어플라이언스에 접근한 네트워크 카드를 유지합니다(새 시스템이 받는 것).

변경 전 검사

명령은 다음 순서로 머신을 검사합니다. 처음으로 실패한 검사에서 거부하며, 종료 코드 3과 함께 원인과, 해결책이 있으면 해결책까지 알려 주는 한 문장을 출력합니다. 이 시점까지는 아무것도 변경되지 않았습니다.

1. 시스템 — PID 1이 systemd이고, 컨테이너가 아니며, IronFlockOS나 ReswarmOS가 아님.
2. 펌웨어 — 64비트 UEFI, 쓰기 가능한 EFI 변수, 그리고 Secure Boot가 켜져 있으면 펌웨어가 시작할 이미지의 부팅 체인(Secure Boot).
3. 이미지 — os images가 나열하는 것처럼 서명된 IronFlockOS 카탈로그에서: --image의 이미지, 없으면 머신 타깃의 기본 이미지. 명령은 이미지 파일의 처음 몇 MiB를 읽습니다. 파일이 os flash의 캐시에 있으면 그곳에서, 없으면 다운로드 서버에서 읽습니다(어플라이언스의 미러가 먼저입니다. 파일을 가져오는 곳 참조). 다른 하드웨어용 .flock 파일은 경고만 합니다.
4. 디스크 — 펌웨어의 현재 부팅 옵션이 지정하는 파티션이 있는 디스크. 없으면 /boot/efi 또는 /efi에 마운트된 EFI 시스템 파티션이 있는 디스크. 그것도 없으면 --disk가 지정하는 디스크. 시스템이 시작된 디스크와 다른 디스크를 지정하는 --disk는 거부됩니다. 그 자체로 독립된 디스크가 아닌 디스크도 거부됩니다: MD RAID 어레이(Intel RST가 만든 것도 포함), device-mapper, 루프 또는 네트워크 블록 디바이스, 메모리 안의 디스크.
5. 디스크 위에 구성된 것 — 파티션, 선형 볼륨을 사용하는 LVM, 그리고 cryptsetup이 암호화용으로 설정하는 것(LUKS, plain dm-crypt, BitLocker, FileVault, TrueCrypt). 그 밖의 모든 것은 거부됩니다: MD RAID, bcache, multipath, ZFS 풀, LVM 씬 풀, 스냅샷, 캐시, RAID와 미러, dm-verity, dm-integrity. 다른 디스크는 그대로 남으므로, 이 디스크와 다른 디스크 양쪽에 멤버가 있는 btrfs 파일 시스템이나 LVM 볼륨 그룹은 거부됩니다. 디스크를 교체하면 양쪽 모두에서 그것이 파괴되기 때문입니다. IRONFLOCKOS, rootfs-a, rootfs-b 또는 data라는 이름의 파티션이 있는 다른 디스크가 달린 머신도 거부됩니다. IronFlockOS는 이 이름으로 자신의 파티션을 찾기 때문입니다.
6. 메모리 — 위와 같음.
7. .flock 파일, 네트워크, 프록시, 드라이버 — .flock 파일은 os flash와 같은 방식으로 읽으며, 그 SSH 키가 유효해야 합니다. 네트워크와 프록시는 새 시스템이 받는 것에 설명된 대로 검사합니다. 드라이버는 디스크와 네트워크 카드로 가는 경로에 있는 디바이스(디스크, 카드, 그 컨트롤러와 버스)를 이미지의 하드웨어 목록에서 찾아봅니다. 이미지에 그중 하나의 드라이버가 없다고 목록에 나와 있을 때만 거부합니다. 판단할 수 없는 디바이스는 경고 drivers not checked에 나옵니다. 하드웨어 목록이 없는 릴리스(0.14.0까지)에서는 이 경고에 모든 디바이스가 나옵니다.
8. 계획과 질문 — 아래를 참조하십시오.

명령이 이미지의 앞부분을 읽는 동안 Ctrl-C를 누르면 종료 코드 130으로 끝나며, 계획이 표시되거나 질문이 대기하는 동안 터미널이 끊겨도 마찬가지입니다. 이때는 아무것도 변경되지 않았습니다.

계획과 --dry-run

계획은 stderr에 나옵니다. 머신과 그 펌웨어, 디스크와 그 디스크를 찾은 방법, 이미지와 이미지 파일의 출처, 메모리가 나옵니다. 디스크의 모든 내용이 사라진다는 것, 새 시스템이 받는 것과 받지 못하는 것, 경고도 나옵니다. --dry-run은 계획을 보여 주고, 아무것도 변경하지 않으며, 종료 코드 0으로 끝납니다. --dry-run과 함께라면 --yes에 --disk가 필요 없습니다.

Compute Engine VM에서는 계획이 Google의 게스트 환경이 사라진다고 경고합니다. gcloud compute ssh, OS Login, 메타데이터 SSH 키가 더 이상 동작하지 않으며, 시리얼 콘솔은 남습니다.

새 시스템이 받는 것

새 시스템이 받는 것은 다음과 같습니다:

• 디바이스의 ID — .flock 파일의 ID이며, 이 파일은 IRONFLOCKOS 파티션에 들어갑니다. 디바이스는 첫 시작 때 이 파일로 등록됩니다.
• 네트워크 — 이미지 다운로드가 다운로드 서버나 프록시로 갈 때 거친 네트워크 카드의 네트워크. 다운로드 베이스가 .flock 파일의 어플라이언스 미러이고 미러가 카탈로그 요청에 어떻게든 응답했다면(404도 포함), 파일을 어디서 가져왔든 대신 미러에 연결한 카드의 네트워크입니다. 새 디바이스는 어플라이언스에 연결하기 때문입니다. DHCP를 사용하는 유선 연결은 아무것도 옮길 필요가 없습니다. 고정 주소(수명이 없는 주소, 직접 설정한 게이트웨이와 경로, systemd-resolved 또는 /etc/resolv.conf의 DNS 서버)는 영구 MAC 주소로 카드를 찾는 NetworkManager 프로필이 됩니다. DHCP나 SLAAC과 함께 쓰는 고정 주소는 DHCP를 유지하고 고정 주소를 추가합니다. WiFi에서는 .flock 파일의 네트워크라면 아무것도 필요 없습니다. NetworkManager의 WPA-PSK 또는 WPA3-SAE 프로필이 있는 다른 네트워크는 숨겨져 있든 아니든 그 프로필을 받습니다. 다른 카드의 주소는 옮겨지지 않으며, 계획이 경고합니다.
• 프록시 — 다운로드에 사용한 프록시가 사용자와 비밀번호, no_proxy와 함께 IronFlockOS의 프록시 설정(IRONFLOCKOS 파티션의 proxy.conf)이 됩니다. 머신 자체에 있는 프록시(127.0.0.1)는 새 시스템에 없으므로 거부됩니다. 머신의 루프백에서 응답하는 미러도 마찬가지입니다. 어플라이언스 자체 호스트의 에이전트처럼 update_url이 localhost를 지정하는 .flock 파일이 이에 해당합니다. proxy.conf가 받지 않는 문자가 들어 있는 프록시 URL은 거부되며, 거부 메시지가 해당 부분을 알려 줍니다.
• SSH — 모든 IronFlockOS 디바이스와 마찬가지로, .flock 파일의 키를 사용하는 프로젝트 소유자의 계정.

IronFlockOS 0.15.0 이상은 IRONFLOCKOS 파티션에서 네트워크 프로필과 프록시 설정을 가져옵니다. 이전 릴리스의 이미지를 사용하면, 네트워크에 프로필이 필요하거나 다운로드가 프록시를 거치는 머신은 거부됩니다. 거부 메시지는 카드, 그 고정 주소나 WiFi, 그리고 대신 할 일을 알려 줍니다.

새 시스템은 이전 시스템의 사용자 계정과 그 비밀번호 및 SSH 키, SSH 호스트 키(SSH 클라이언트는 새 호스트 키를 보게 됨), 패키지, 설정, 데이터를 받지 않습니다. 디바이스의 앱은 IronFlock에서 다시 설치되지만, 이 머신에 있던 앱의 데이터는 돌아오지 않습니다.

질문

명령은 질문에 표시되는 머신의 짧은 호스트 이름을 입력하라고 요구합니다. 커널에 전체 이름이 있는 머신(Compute Engine의 Ubuntu 이미지)에서는 전체 이름도 받습니다. 그 밖의 입력은 Enter만 누른 경우를 포함해 모두 아니요로 처리됩니다(종료 코드 4). 질문과 확인을 참조하십시오.

--yes는 --disk가 디스크를 지정할 때만 질문에 답합니다. 암호화된 시스템에서 --yes에는 --allow-unencrypted도 필요하며, 없으면 명령은 종료 코드 4로 끝납니다. 터미널이 없거나 --json을 사용하면 질문할 수 없으므로, --yes가 없으면 명령은 종료 코드 4로 끝납니다.

질문 이후: 스테이징과 인계

재시작 전에는 디스크에 아무것도 쓰지 않습니다. 명령은 교체를 메모리에 스테이징합니다:

1. 메모리 안의 파일 시스템이 이미지를 받습니다. 계획이 os flash 캐시에서 이미지를 읽었다면 그 캐시의 파일을, 아니면 다운로드한 파일(Downloading으로 표시)을 받으며, 서명된 카탈로그와 대조해 확인합니다(Checking). 이미지를 한 번 풀고(Preparing) 계획이 읽은 내용과 비교합니다. IRONFLOCKOS 파티션에 넣을 파일을 준비합니다.
2. IronFlockOS용 부팅 옵션이 펌웨어 부팅 순서의 맨 끝, 실행 중인 시스템의 부팅 옵션 뒤에 추가됩니다. 디스크에 쓰기 전까지는 실행 중인 시스템이 여전히 먼저 시작됩니다.
3. stderr의 Staged:가 새 부팅 옵션과, 쓰기 후 삭제될 이전 시스템의 부팅 옵션을 알려 줍니다.
4. 명령이 인계합니다. 머신은 즉시 재시작하거나, 명령이 SSH 세션에서 실행되면(sudo와 --host를 통한 경우도 포함) 결과가 먼저 세션에 도달하도록 명령이 끝나고 10초 후에 재시작합니다. stdout에 Handed over: ...가 나오고, 명령은 종료 코드 0으로 끝납니다.

질문부터 인계까지 Ctrl-C나 SIGTERM을 받으면 스테이징을 되돌립니다. 명령은 종료 코드 130으로 끝나며, 머신은 원래 상태 그대로입니다. 질문 이후에는 터미널이나 SSH 세션이 끊겨도 명령이 더 이상 멈추지 않습니다. 스테이징은 계속되며, 인계와 재시작이 이루어집니다. 재시작이 인계된 뒤에는 Ctrl-C가 명령을 끝내지만, 재시작은 계속 진행됩니다.

재시작과 쓰기

종료 과정의 마지막에 ironflock이 메모리의 이미지를 디스크에 씁니다. 머신의 콘솔에 ironflock-install:로 시작하는 줄이 표시됩니다. 그런 다음 머신이 IronFlockOS를 시작하며, 디바이스는 약 10분 안에 IronFlock에 나타납니다. 쓰기 로그는 새 시스템의 IRONFLOCKOS 파티션에 있는 ironflock-install.log입니다.

이전 시스템이 다시 시작되는 경우

쓰기 전에 ironflock은 디스크를 한 번 더 검사합니다. 조건이 맞지 않으면 이전 시스템이 변경되지 않은 채 다시 시작됩니다. 디스크가 사용 중이거나 읽기 전용인 경우, 계획의 디스크가 아닌 경우, 스테이징된 이미지가 손상된 경우, 쓰기 전 단계가 2분보다 오래 걸리는 경우입니다. 이유는 EFI 변수 IronFlockInstall에 있습니다. ironflock status는 root 없이 이를 OS install: 줄에 보여 줍니다:

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

# 머신에서
ironflock status
# 다른 컴퓨터에서
ironflock --host admin@machine status
# ironflock 없이: 단계, 시각, 이유를 출력
tail -c +5 /sys/firmware/efi/efivars/IronFlockInstall-7b2f7cb6-eb8f-4acd-b7fd-e92df1a035a0

--host를 통한 실행

ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes는 --host를 통한 다른 모든 명령과 마찬가지로 그 머신에서 명령을 실행합니다. 바이너리와 .flock 파일이 그곳으로 전달되고, 검사, 계획, 질문이 그곳에서 실행되며, 그 출력이 돌아옵니다. 바이너리와 .flock 파일 사본이 든 폴더는 그곳의 명령이 끝나면 제거되며, 거부나 인터럽트 뒤에도 마찬가지입니다. --dry-run은 그 폴더 외에는 머신에서 아무것도 변경하지 않습니다.

재시작은 명령이 끝나고 10초 후에 이루어지므로, 결과가 먼저 이쪽에 도달합니다. 질문 이후에는 연결이 끊겨도 그곳의 명령이 더 이상 멈추지 않습니다. 연결이 끊기면 이쪽의 명령은 종료 코드 255로 끝나며, 머신이 혼자서 계속 진행한다고 알려 줍니다.

인계 후 명령은 머신이 IronFlockOS로 돌아올 때까지 최대 15분 동안 기다립니다:

• 15초마다 같은 주소에 .flock 파일의 SSH 사용자로, .flock 파일의 키를 사용해 로그인합니다. 키는 본인만 읽을 수 있는 새 폴더의 파일에 들어가며, 대기가 끝나면 폴더가 제거됩니다. 키는 SSH 에이전트에 들어가지 않습니다.
• 새 시스템의 호스트 키를 어디에도 기록하지 않고 받아들입니다. known_hosts는 그대로 유지됩니다.
• 시스템이 무엇을 실행하는지, 그리고 시작 후 디바이스 에이전트가 IronFlock에 연결했는지 읽습니다.
• 그동안 이전 시스템에도 EFI 변수 IronFlockInstall을 묻습니다. 단, known_hosts에 있는 호스트 키일 때만 묻습니다. 이전 시스템으로 돌아온 머신은 대기를 즉시 끝냅니다.

머신이 IronFlockOS를 실행하고 디바이스 에이전트가 연결되어 있으면 대기는 종료 코드 0으로 끝납니다. 머신이 IronFlockOS를 실행하지만 에이전트가 연결되지 않았거나, 이전 시스템으로 돌아왔거나, 15분 안에 IronFlockOS로 응답하지 않으면 1로 끝납니다. DHCP가 주소를 바꾸면 이 확인은 동작하지 않습니다. 이때 메시지는 IronFlock의 디바이스와 머신의 콘솔을 확인하라고 안내합니다. Ctrl-C는 대기를 130으로 끝내며, 머신은 혼자서 계속 진행합니다.

새 시스템의 호스트 키는 이쪽에서 처음 보는 키이므로, 대기는 그 주소에서 어떤 머신이 응답하는지 구별할 수 없습니다. 증거는 IronFlock에 연결된 것으로 표시되는 디바이스입니다.

대기에는 이쪽에 .flock 파일이 있어야 합니다. -c가 없거나 SSH 사용자를 설정하지 않는 .flock 파일이면, --no-wait를 지정하지 않는 한 명령은 머신에 아무것도 보내기 전에 종료 코드 2로 끝납니다. --no-wait는 인계한 뒤 머신에서 실행된 명령의 종료 코드로 끝납니다.

Secure Boot

Secure Boot가 켜져 있으면 명령은 펌웨어가 이미지의 부팅 체인, 즉 shim과 그다음 GRUB을 시작할지 검사합니다:

• 이미지 shim의 서명이 함께 제공되는 인증서를 거쳐 펌웨어의 서명 데이터베이스(db)에 있는 인증서로 이어지고, 금지 데이터베이스(dbx)가 그중 어느 것도 폐기하지 않음. 또는 db에 shim의 해시가 있음.
• dbx와 이 머신의 shim 금지 목록(MokListX) 어느 쪽에도 이미지의 shim이나 GRUB, 또는 GRUB 서명에 사용된 인증서가 없음.
• 머신의 SBAT 수준(SbatLevelRT)이 shim도 GRUB도 폐기하지 않음.

펌웨어가 이미지를 시작하지 않을 경우 명령은 거부합니다. 펌웨어 설정에서 Secure Boot를 끌 수 있으며, IronFlockOS는 Secure Boot 없이도 시작됩니다. shim을 통해 시작되지 않은 시스템에서는 계획이 SBAT 수준과 MokListX를 검사하지 않았다고 경고합니다. 명령은 shim의 서명 값을 검증하거나 커널을 살펴보지 않습니다. 서명된 카탈로그가 이를 보증합니다. --json을 사용하면 machine.secure_boot.ca가 shim의 서명이 이어지는 db의 인증서를 알려 줍니다. 예: Microsoft UEFI CA 2023.

예시

# 설치된 에이전트의 디바이스에 대한 계획을 보여 주고, 아무것도 변경하지 않음
sudo ironflock os install --dry-run
# 새 디바이스의 계획을 JSON으로
sudo ironflock os install -c device.flock --dry-run --json
# 질문 없이 시스템 교체
sudo ironflock os install -c device.flock --disk /dev/sda --yes
# 다른 컴퓨터에서 실행하고, 디바이스가 온라인이 될 때까지 대기
ironflock --host admin@machine os install -c device.flock --disk /dev/sda --yes

결과

sudo ironflock os install -c device.flock --dry-run의 계획(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.

sudo ironflock os install -c device.flock --disk /dev/sda --yes를 실행하면 같은 계획을 보여 준 다음, 스테이징과 인계가 이어집니다:

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.

--json을 사용하면 결과는 하나의 JSON 객체로 된 계획입니다. --dry-run을 사용하면 즉시 나오고, 사용하지 않으면 인계 후에 dry_run이 false이고 staging이 추가된 채로 나오며, --host를 통해 실행하면 대기 후에 wait까지 추가된 채로 나옵니다. stderr에는 진행 상황이 JSON 줄로만 나옵니다(출력과 JSON). 어떤 필드에도 시크릿은 없습니다. IRONFLOCKOS 파티션에 넣을 파일은 이름과 크기로 표시되며, 프록시 URL은 비밀번호 없이 표시됩니다. 다음은 위 드라이 런의 결과에 줄바꿈을 넣은 것입니다(명령은 한 줄로 쓰며, ...은 예에서 생략한 부분입니다):

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

거부하는 경우

다음 경우에 명령은 종료 코드 3으로 거부하며, 아무것도 변경되지 않습니다:

• 컨테이너, PID 1이 systemd가 아닌 시스템, IronFlockOS(그곳에서는 os update가 릴리스를 설치함), ReswarmOS.
• BIOS, 32비트 UEFI, 이미지가 없는 아키텍처, 마운트되지 않은 EFI 변수(거부 메시지가 mount 명령을 알려 줌) 또는 읽기 전용으로 마운트된 EFI 변수(mount -o remount,rw를 알려 줌).
• 이미지의 shim이나 GRUB을 시작하지 않을 Secure Boot.
• 명령이 알아낼 수 없는 디스크(--disk로 지정하십시오), 시스템이 시작된 디스크가 아닌 --disk, 파티션, 디스크 없음. 그 자체로 독립된 디스크가 아니거나 lsblk가 나열하지 않는 디스크. GPT가 없는 디스크.
• 다른 디스크에 있거나, 여러 디스크에 걸쳐 있거나, ZFS에 있거나, 어떤 디스크에도 없는(라이브 시스템) 루트 파일 시스템.
• 512바이트가 아닌 논리 섹터, 너무 작은 디스크, 명령이 분해하지 않는 스토리지 스택, 이 디스크와 다른 디스크에 걸친 btrfs 파일 시스템이나 LVM 볼륨 그룹, IronFlockOS의 파티션 이름을 가진 다른 디스크.
• 너무 적은 메모리.
• 명령이 옮기지 않는 네트워크, 머신 자체에 있는 프록시 또는 머신의 루프백에 있는 어플라이언스의 미러, proxy.conf를 받지 않는 이미지에서 쓰는 프록시 또는 proxy.conf가 받지 않는 문자가 들어 있는 프록시, 읽을 수 없는 활성 NetworkManager 프로필.
• 디스크나 네트워크 카드의 디바이스용 드라이버가 이미지에 없다고 나와 있는 릴리스의 하드웨어 목록.
• 실행되지 않는 iproute2의 ip: 네트워크를 읽을 수 없음.
• 질문 이후, 스테이징이 무언가를 변경하기 전: 더 이상 계획의 디스크가 아닌 디스크, 이미 마운트 지점인 /run/initramfs, 그대로 실행할 수 없는 계획.

다음은 잘못된 명령줄이며(종료 코드 2), 무언가를 변경하기 전에 검사합니다:

• --dry-run 없이 --disk도 없이 쓴 --yes.
• 디바이스 에이전트가 설치되지 않은 머신에서 -c 없음. --host를 통해 --no-wait 없이 실행할 때 -c가 없거나 SSH 사용자를 설정하지 않는 .flock 파일.
• 카탈로그에 없는 --image, 머신과 다른 타깃용 이미지, 또는 설치 USB 스틱(os flash --installer가 씀).
• 비밀번호가 들어 있는 프록시 URL, 그리고 agent install이 거부하는 그 밖의 프록시 플래그.
• 여러 머신(--host를 여러 번 지정, --hosts).

실패하는 경우

다음 경우에 명령은 종료 코드 1로 실패하며, 아무것도 변경되지 않습니다:

• .flock 파일이 유효하지 않거나, 그 SSH 키가 유효하지 않은 경우.
• os images에서와 마찬가지로 카탈로그가 검증되지 않거나 가져올 수 없는 경우. 어플라이언스의 미러를 사용할 때는 미러에서도 클라우드에서도 가져올 수 없는 경우.
• 이미지 파일의 앞부분을 다운로드할 수 없거나(getting the image ..., 어플라이언스의 미러를 사용할 때는 미러에서도 클라우드에서도), 명령이 아는 IronFlockOS 이미지가 아닌 경우. 미러가 카탈로그를 제공하지 않아 카탈로그를 클라우드에서 가져왔다면, 오류는 카탈로그의 경고 the appliance's mirror ... gives no IronFlockOS catalog now (...)로 시작하며 두 서버를 모두 알려 줍니다.
• 다운로드의 로컬 주소가 어떤 네트워크 카드에도 속하지 않는 경우. 마운트 테이블, 블록 디바이스 또는 메모리를 읽을 수 없는 경우. EFI 변수를 파싱할 수 없는 경우.
• 질문 이후: 이미지 파일이 카탈로그의 파일이 아니거나 계획이 읽은 내용과 다르거나(메시지에 두 값이 나옴), 다운로드가 실패하거나, 펌웨어가 부팅 옵션을 받지 않거나, 재시작을 시작할 수 없는 경우. 스테이징은 되돌려집니다. 되돌리기도 실패하면 메시지가 재시작을 요청하며, 재시작하면 남은 것이 제거됩니다.

어떤 URL도 그 안에 있을 수 있는 사용자와 비밀번호를 포함한 채로 출력되지 않습니다.

종료 코드

모든 명령에 대한 각 코드의 의미는 플래그, 출력 및 종료 코드 페이지에 나와 있습니다.