Skip to Content
IoT 应用开发IronFlock CLI用 IronFlockOS 替换 Linux

用 IronFlockOS 替换 Linux

ironflock os install 在同一块磁盘上用 IronFlockOS 替换正在运行的机器启动时所用的 Linux,并使机器成为某个设备配置文件(.flock)所对应的 IronFlock 设备。您可以在机器本身上运行它,也可以从另一台电脑通过 SSH 运行。

警告:机器启动所用磁盘上的所有内容都会丢失:正在运行的系统、其软件包和设置、其用户账户以及所有数据。没有回头路。请先带 --dry-run 运行该命令,并阅读计划。

适用场景

对于已经运行 Debian、Ubuntu 或其他带 systemd 的 Linux,且您无法或不想让它从 U 盘启动的机器,请使用 os install:例如控制柜中的 PC、云中的虚拟机、只能通过 SSH 访问的机器。借助 --host,您可以从自己的电脑(包括 Mac)运行该命令,它会一直等待,直到机器作为 IronFlock 设备上线。

在以下情况下,请使用其他命令:

  • 您可以让机器从驱动器启动 — ironflock os flash 将 IronFlockOS 写入 U 盘、SD 卡或外置磁盘。带 --installer 时,它写入安装 U 盘,该 U 盘会将 IronFlockOS 安装到从它启动的 PC 的内部磁盘上。对于大多数被 os install 拒绝的机器,安装 U 盘也是解决办法。
  • 机器是 Raspberry Pi — os install 只安装适用于 UEFI 机器的镜像(硬件目标 amd64-efi 和 arm64-efi)。请用 os flash 写入 Raspberry Pi 的 SD 卡。
  • 机器已经运行 IronFlockOS — os install 会拒绝它。在那里,ironflock os update 可以安装其他发布版本。
  • 您想保留机器上的 Linux — ironflock agent install 按机器现状将其连接到 IronFlock。

ironflock os install

检查机器,显示替换计划并询问。然后它在内存中暂存 IronFlockOS 并重启机器;机器在关机过程的最后将 IronFlockOS 写入磁盘,然后启动它。

ironflock os install [-c <device.flock>] [--disk <disk>] [--dry-run] [flags]
运行平台Root询问
带 systemd 的 Linux。借助 --host 可从 Linux 或 macOS 运行需要是:您需要输入机器的主机名。--yes 只有与 --disk 一起使用时才会作答

在 macOS 上,该命令会在检查任何内容之前以退出码 3 结束;请在那里借助 --host 运行它。它一次只在一台机器上运行:多次给出 --host 或使用 --hosts 会以退出码 2 结束。全局标志参见标志、输出与退出码。

标志

标志含义
-c、--config <file>设备的 .flock 文件。默认:机器上已安装的设备代理程序的 .flock 文件,这样机器在 IronFlock 中仍是同一台设备
--disk <disk>要替换的磁盘,例如 /dev/sda,或者指向它的链接,例如 /dev/disk/by-id 下的链接。它必须是固件启动系统所用的磁盘。--yes 需要它
--image <id>要安装的镜像,可带或不带 ironflockos-,例如 amd64-efi-nvidia。默认:机器硬件目标(amd64-efi 或 arm64-efi)的带标准内核的基础镜像
--dry-run显示计划,不做任何更改
--no-wait带 --host 时:移交后即结束,不等待机器以 IronFlockOS 的身份重新上线
--allow-unencrypted即使 IronFlockOS 以不加密的方式存储其数据,也替换加密的系统。在这样的系统上,--yes 需要它
--http-proxy <url>用于下载和新系统的 HTTP 代理,例如 http://proxy:3128,或不带密码的 http://user@proxy:3128。默认:取自环境
--https-proxy <url>用于下载和新系统的 HTTPS 代理,形式相同。默认:取自环境
--no-proxy <hosts>不经过代理的主机,以逗号分隔
--proxy-password-file <file>一个文件或管道(/dev/stdin),其唯一的一行是代理 URL 中用户的密码

代理标志的作用与 agent install 中的相同。没有这些标志时,命令从环境中获取 HTTP_PROXY、HTTPS_PROXY 和 NO_PROXY。带密码的代理 URL 属于错误的命令行(退出码 2);参见机密信息。

机器的要求

  • 系统 — 以 systemd 为 PID 1 的 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。
  • 内存 — 可用内存(MemAvailable)要容纳压缩的镜像和 ironflock 二进制文件,另加 512 MiB:对于 base 镜像,大约需要 2 GiB 内存的机器。
  • 工具 — lsblk 和 iproute2 的 ip。
  • 网络 — 能直接或通过代理访问下载服务器,且所经由的网络是新系统可以使用的网络(新系统会得到什么)。对于 IronFlock Appliance 的设备,下载服务器可以是 Appliance 的下载镜像站(文件从哪里来)。
  • .flock 文件 — 来自 -c,或来自机器上已安装的设备代理程序。

文件从哪里来

命令需要已签名的 IronFlockOS 目录、镜像以及镜像的硬件列表。它按以下顺序获取它们:

  1. --download-base,否则 IRONFLOCK_DL_BASE:只用该服务器。
  2. 否则,用 .flock 文件指定为更新服务器的 IronFlock Appliance 的下载镜像站:即其 update_url,前提是它是绝对的 http 或 https URL,且主机不属于 IronFlock 云,例如 https://registry.<domain>/dl 或 http://<host>:<port>/dl。stderr 上会输出 Download base: ... (from the device's .flock)。能访问 Appliance、但无法访问 ironflock.com 的机器就是这样转换的。IronFlock 云的 .flock 文件使用云。
  3. 否则,用 IronFlock 云 https://instance-registry.ironflock.com/dl。

使用 Appliance 的镜像站时,文件先从镜像站获取;镜像站没有提供的文件,从 IronFlock 云获取:

  • 目录,<mirror>/ironflockos/manifest.json — 镜像站当前不提供(无法访问、返回错误,或者只能用其上一次目录的保留副本代替)时,一切都从云获取,与没有 Appliance 时相同。镜像站提供了目录、但目录被拒绝(签名不符、比保留的副本旧、过大)时,命令失败,与任何服务器的情况相同。
  • 镜像,<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 相同。使用 Appliance 自有 CA 签发证书的 HTTPS 镜像站,只有在机器的系统信任该 CA 时才能使用。Appliance 有应答时,新系统保留访问它所用的网卡(新系统会得到什么)。

做出任何更改之前

命令按以下顺序检查机器。第一个失败的检查项会导致拒绝执行,退出码为 3,并给出一句话,说明原因以及(如果有的话)解决办法。此时没有做出任何更改。

  1. 系统 — systemd 是 PID 1,系统不是容器,也不是 IronFlockOS 或 ReswarmOS。
  2. 固件 — 64 位 UEFI、可写的 EFI 变量;开启 Secure Boot 时,还要求固件会启动镜像的启动链(Secure Boot)。
  3. 镜像 — 来自已签名的 IronFlockOS 目录,与 os images 所列的相同:--image 的镜像,否则为机器硬件目标的基础镜像。命令读取镜像文件的前几 MiB:文件在 os flash 的缓存中时从缓存读取,否则从下载服务器读取(先从 Appliance 的镜像站读取,参见文件从哪里来)。适用于其他硬件的 .flock 文件只会引发警告。
  4. 磁盘 — 固件当前启动项所指分区所在的磁盘;否则为 EFI 系统分区挂载在 /boot/efi 或 /efi 的磁盘;再否则为 --disk 所指定的磁盘。如果 --disk 指定的磁盘不是系统启动所用的磁盘,会被拒绝。不是独立完整磁盘的磁盘同样会被拒绝:MD RAID 阵列(包括 Intel RST 创建的阵列)、device-mapper 设备、loop 设备或网络块设备、内存中的磁盘。
  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 密钥将无法使用,串行控制台则保留。

新系统会得到什么

新系统会得到:

  • 设备的身份 — 来自 .flock 文件,该文件会放到 IRONFLOCKOS 分区上。设备在首次启动时用它注册。
  • 网络 — 下载镜像时所经由的网卡(通往下载服务器或代理)的网络设置。如果下载基址是 .flock 文件中 Appliance 的镜像站,且镜像站对目录请求作出了应答(404 也算),则改为通往镜像站的连接所用的网卡,无论文件来自哪里:新设备要连接的正是 Appliance。使用 DHCP 的有线网络无需任何设置。静态地址(没有有效期的地址、手动设置的网关和路由、systemd-resolved 或 /etc/resolv.conf 中的 DNS 服务器)会变成一个 NetworkManager 配置文件,该配置文件按网卡的永久 MAC 地址匹配网卡。DHCP 或 SLAAC 之外另有静态地址时,保留 DHCP 并加上该静态地址。在 WiFi 上,.flock 文件中的网络无需任何设置;其他网络如果有 NetworkManager 的 WPA-PSK 或 WPA3-SAE 配置文件(无论是否隐藏),会得到该配置文件。其他网卡的地址不会带过去,计划会给出警告。
  • 代理 — 下载所用的代理成为 IronFlockOS 的代理设置(IRONFLOCKOS 分区上的 proxy.conf),包括用户和密码,以及 no_proxy。位于机器本身上的代理(127.0.0.1)会被拒绝,因为新系统中没有它。在机器的回环地址上应答的镜像站同样会被拒绝:即 .flock 文件的 update_url 指定 localhost 的情况,Appliance 自身主机上的代理程序就是如此。代理 URL 中含有 proxy.conf 不接受的字符时会被拒绝,拒绝信息会指出该部分。
  • SSH — 项目所有者的账户,带 .flock 文件中的密钥,与每台 IronFlockOS 设备一样。

IronFlockOS 0.15.0 及更高版本从 IRONFLOCKOS 分区获取网络配置文件和代理设置。使用更早发布版本的镜像时,网络需要配置文件或者下载需经过代理的机器会被拒绝;拒绝信息会指出网卡、其静态地址或其 WiFi,以及应该怎么做。

新系统不会得到旧系统的用户账户及其密码和 SSH 密钥、SSH 主机密钥(SSH 客户端会看到新的主机密钥),以及软件包、设置和数据。设备的应用会从 IronFlock 恢复;它们在这台机器上的数据则不会。

询问

命令要求您输入机器的短主机名,询问中会显示该名称。如果机器的内核中保存的是完整名称(Compute Engine 上的 Ubuntu 镜像),完整名称同样可以。输入其他任何内容(包括直接按 Enter)都视为回答“否”:退出码 4。参见询问与确认。

只有当 --disk 指定了磁盘时,--yes 才会回答询问。在加密的系统上,--yes 还需要 --allow-unencrypted,否则命令以退出码 4 结束。没有终端时,以及使用 --json 时,无法询问:没有 --yes 时,命令以退出码 4 结束。

询问之后:暂存与移交

重启之前,不会向磁盘写入任何内容。命令在内存中暂存替换所需的内容:

  1. 内存中的一个文件系统接收镜像:如果计划是从 os flash 缓存中读取的,就使用缓存中的文件,否则进行下载(显示为 Downloading),并对照已签名的目录进行检查(Checking)。镜像被解包一次(Preparing),并与计划所读取的内容进行比较。IRONFLOCKOS 分区所需的文件也会准备好。
  2. IronFlockOS 的启动项被添加到固件启动顺序的末尾,排在正在运行的系统之后。在写入磁盘之前,正在运行的系统仍然最先启动。
  3. stderr 上的 Staged: 给出新的启动项以及旧系统的启动项,后者会在写入之后被删除。
  4. 命令进行移交:机器立即重启;如果命令在 SSH 会话中运行(包括经由 sudo 和 --host),则在命令结束十秒之后重启,以便结果先到达会话。stdout 输出 Handed over: ...,命令以退出码 0 结束。

从询问到移交期间,Ctrl-C 或 SIGTERM 会撤回暂存:命令以退出码 130 结束,机器保持原样。询问之后,终端或 SSH 会话丢失不再能停止命令:暂存会继续进行,移交和重启都会发生。重启一旦移交,Ctrl-C 会结束命令,而重启照常进行。

重启与写入

在关机过程的最后,ironflock 将镜像从内存写入磁盘。机器的控制台会显示相应的输出行,这些行以 ironflock-install: 开头。然后机器启动 IronFlockOS,设备会在大约十分钟内出现在 IronFlock 中。写入的日志是新系统 IRONFLOCKOS 分区上的 ironflock-install.log。

旧系统再次启动的情况

写入之前,ironflock 会再次检查磁盘。如果某项条件不满足,旧系统会再次启动,保持不变:磁盘繁忙或只读、不是计划中的磁盘、暂存的镜像已损坏,或者写入之前的步骤耗时超过两分钟。原因记录在 EFI 变量 IronFlockInstall 中。ironflock status 会在其 OS install: 这一行中显示原因,无需 root:

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 不会更改机器上的任何内容。

重启在命令结束十秒之后进行,因此其结果会先到达您这一端。询问之后,连接丢失不再能停止那里的命令:连接中断时,您这一端的命令以退出码 255 结束,并说明机器会自行继续。

移交之后,命令最多等待 15 分钟,等机器以 IronFlockOS 的身份重新上线:

  • 每隔 15 秒,它以 .flock 文件的 SSH 用户身份、用 .flock 文件中的密钥登录同一地址。密钥写入一个只有您能读取的新文件夹中的文件,等待结束时该文件夹会被删除。密钥不会加入 SSH agent。
  • 它接受新系统的主机密钥,但不将其写入任何地方:known_hosts 保持原样。
  • 它读取系统运行的是什么,以及设备代理程序自启动以来是否已连接到 IronFlock。
  • 在此期间,它会向旧系统查询 EFI 变量 IronFlockInstall,但只在主机密钥已在 known_hosts 中时才这样做:如果机器以旧系统重新上线,等待会立即结束。

当机器运行 IronFlockOS 且设备代理程序已连接时,等待以退出码 0 结束。当机器运行 IronFlockOS 但代理程序未连接、机器以旧系统重新上线,或者在 15 分钟内没有以 IronFlockOS 的身份应答时,等待以 1 结束。如果 DHCP 改变了地址,这项检查就会失效;此时消息会指向 IronFlock 中的设备以及机器的控制台。Ctrl-C 以 130 结束等待,机器会自行继续。

等待无法判断是哪台机器在该地址上应答,因为新系统的主机密钥对您这一端来说是新的。证据是 IronFlock 中显示为已连接的设备。

等待需要您这一端有 .flock 文件。不带 -c,或者 .flock 文件不设置 SSH 用户时,命令会在向机器发送任何内容之前以退出码 2 结束,除非您给出 --no-wait。--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 同样能启动。在不是经由 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":[...]}
字段取值
dry_run使用 --dry-run 时为 true;移交之后为 false
machinehostname(询问所要求的短名称)、fqdn(内核中的完整名称,如果有)、os、architecture(amd64、arm64)、secure_boot(enabled;开启时还有 ca 和 sbat_level)、以字节为单位的 memory_available 和 memory_needed
disk被替换的磁盘:device、devnum、以字节为单位的 size、model、serial、sysfs、guid(其 GPT 的 GUID)、found_by(boot_option、esp、disk_flag)、esp、storage(partitions、lvm、luks、crypt)、encrypted
imageimage_id、version,压缩文件的 file、url、size 和 sha256,source(cache、download)、raw_size、min_disk_size、guid、ironflockos(其 IRONFLOCKOS 分区)、shim_sha256,以及 head_size 和 head_sha256:计划所读取的镜像部分,暂存时会与之比较
device、device_file、flock设备的名称、其 .flock 文件在 IRONFLOCKOS 分区上的名称,以及读取 .flock 文件的位置
networkinterface、mac、kind(wired、wifi)、addressing(dhcp、static、dhcp_and_static)、WiFi 时的 ssid、carried(nothing、flock、profile)、静态设置的 addresses、gateways 和 dns,以及 profile
proxy没有代理时为 null;否则为 http、https、no_proxy、password(true:代理设置中含有密码)、from(flags、environment)
ssh_user新系统的 SSH 账户;.flock 文件不设置 SSH 账户时为 null
filesIRONFLOCKOS 分区所需的文件,带 path 和 size
driverschecked,以及 devices,每个设备带 for(disk、network)、device、modalias、driver、module、modules、check(matched、built_in、not_checked)
not_carried_over新系统不会得到的内容
delayed_reboottrue:命令通过 SSH 运行,重启在它结束十秒之后进行
warnings计划中的警告,其中包括每个来自 IronFlock 云、而不是 Appliance 镜像站的文件
staging不带 --dry-run 时:handed_over(true)、boot_option、old_boot_options(name、description)、unreadable_boot_options(保留不删)、restart_in(0,在 SSH 会话中为 10)
wait通过 --host 运行时,在等待之后:result(connected、not_connected、no_answer、stopped、not_run、interrupted)、自移交起的 seconds、os(机器没有以 IronFlockOS 的身份应答时为 null)、connected、reason、last

拒绝执行的情况

在以下情况下,命令以退出码 3 拒绝执行,不做任何更改:

  • 容器、不以 systemd 为 PID 1 的系统、IronFlockOS(在那里由 os update 安装发布版本)、ReswarmOS。
  • BIOS、32 位 UEFI、没有对应镜像的架构、未挂载的 EFI 变量(拒绝信息会给出 mount 命令)或以只读方式挂载的 EFI 变量(会给出 mount -o remount,rw)。
  • 不会启动镜像的 shim 或 GRUB 的 Secure Boot。
  • 命令无法确定的磁盘(请用 --disk 指定)、不是系统启动所用磁盘的 --disk、分区、没有磁盘;不是独立完整磁盘的磁盘,或者 lsblk 未列出的磁盘;没有 GPT 的磁盘。
  • 位于另一块磁盘上、跨越多块磁盘、位于 ZFS 上或不在任何磁盘上(Live 系统)的根文件系统。
  • 逻辑扇区不是 512 字节、磁盘太小、命令无法拆解的存储栈、跨越这块磁盘和另一块磁盘的 btrfs 文件系统或 LVM 卷组、另一块磁盘上有 IronFlockOS 的分区名称。
  • 内存太少。
  • 命令无法带过去的网络、位于机器本身上的代理或位于机器回环地址上的 Appliance 镜像站、镜像不接受 proxy.conf 时的代理或含有 proxy.conf 不接受的字符的代理、无法读取的活动 NetworkManager 配置文件。
  • 发布版本的硬件列表表明镜像缺少磁盘或网卡上某个设备的驱动程序。
  • iproute2 的 ip 无法运行:无法读取网络。
  • 询问之后、暂存更改任何内容之前:磁盘已不再是计划中的磁盘、/run/initramfs 已经是挂载点、计划无法按原样执行。

以下属于错误的命令行,退出码为 2,在做出任何更改之前检查:

  • 不带 --dry-run 时,有 --yes 却没有 --disk。
  • 在没有安装设备代理程序的机器上不带 -c;通过 --host 运行且不带 --no-wait 时,不带 -c,或者 .flock 文件不设置 SSH 用户。
  • 目录中没有的 --image、适用于与机器不同的硬件目标的 --image,或者安装 U 盘(它由 os flash --installer 写入)。
  • 带密码的代理 URL,以及 agent install 会拒绝的其他代理标志。
  • 多台机器(多次给出 --host,或使用 --hosts)。

失败的情况

在以下情况下,命令以退出码 1 失败,不做任何更改:

  • .flock 文件无效,或者其 SSH 密钥无效。
  • 目录验证不通过或无法获取,与 os images 的情况相同;使用 Appliance 的镜像站时,镜像站和云都无法提供。
  • 无法下载镜像文件的开头部分(getting the image ...;使用 Appliance 的镜像站时,镜像站和云都无法提供),或者它不是命令所认识的 IronFlockOS 镜像。如果目录因镜像站未提供而来自云,错误会以目录的警告 the appliance's mirror ... gives no IronFlockOS catalog now (...) 开头,并指出两台服务器。
  • 下载所用的本地地址不属于任何网卡;无法读取挂载表、块设备或内存;无法解析 EFI 变量。
  • 询问之后:镜像文件不是目录中的文件,或者与计划所读取的不一致(消息会给出两个值)、下载失败、固件不接受启动项,或者无法发起重启。暂存会被撤回。如果撤回也失败,消息会要求重启,重启会清除残留的内容。

任何 URL 输出时都不会带上其中可能包含的用户和密码。

退出码

代码含义
0已显示计划(--dry-run),或者机器已完成暂存并已移交重启。通过 --host 运行并等待时:机器运行 IronFlockOS,且设备代理程序已连接
1命令失败,未做任何更改。通过 --host 运行并等待时:代理程序没有连接、机器以旧系统重新上线,或者没有在 15 分钟内以 IronFlockOS 的身份应答
2命令行有误,未改动任何内容
3机器被拒绝,未做任何更改
4询问的回答不是主机名,或者无法询问且未给出 --yes,或者在加密的系统上给出 --yes 而没有 --allow-unencrypted
130在移交之前被中断,机器保持原样;或者 Ctrl-C 结束了通过 --host 进行的等待,机器会自行继续。通过 --host 运行时,130 加上“may still run there”表示机器没有确认命令已结束:它可能已继续执行到重启
255--host 的 SSH 连接失败。询问一旦得到回答,机器会自行继续

每个退出码对所有命令的含义参见标志、输出与退出码。

Last updated on