UniFi 网络设备 USG 3P 网关更换内置系统 U 盘后刷机和升级固件

2026年04月03日

为什么要折腾这个

最近发现 USG-3P 的流量统计功能出了问题，DPI 数据严重缺失，特别是视频流数据几乎完全没有统计，这让网络审计功能失去了参考价值。SSH 登录后台检查后，发现是系统的 squashfs 镜像挂载异常，导致 /usr/sbin/ubnt-dpi-engine 等关键组件无法正常工作。

考虑到设备已经用了好几年，原装的 4GB U 盘可能存在物理坏道或文件系统错误，决定更换成更稳定的 8GB 闪迪酷豆 U 盘。不过 USG-3P 采用 MIPS64 架构，对引导分区标签和文件系统挂载逻辑要求很严格，不是简单的插拔就能解决的。

实际操作中遇到了不少问题，尝试了多种方法都没能完全解决 DPI 引擎的问题，最后还是换回了原装 U 盘。下面分享整个过程的经验和教训。

前期准备工作及注意事项

要折腾 USG-3P 换盘和固件升级，建议按这个清单备齐工具和文件，省得中途断网了抓瞎：

硬件工具

闪迪酷豆 (SanDisk Cruzer Fit) 8GB U盘：体积小且稳，USG 换盘的首选，3.0USB 测试不行。
十字螺丝刀：拆卸底壳螺丝（螺丝藏在防滑垫下面）。
Mac/电脑读卡器：用于在电脑上克隆初始镜像。
两根网线：一根连 LAN1 做调试，一根备用。

软件与文件

BalenaEtcher：最稳的镜像刻录工具，比 dd 命令直观。
USG-4.2.0-shipped.img：官方原始镜像，用来重建标准的 UNI-FI 分区标签。
USG3-4.4.55-Recovery.bin：备用升级包。
本地 TFTP 服务器：Mac 自带的功能但是我没线没折腾。

配置备份

.unf 备份文件：在 UniFi 控制台导出一份最新配置，防止重装后设置全丢。
PPPoE 账号密码：如果是拨号上网，一定要记在纸上，断网后查不到。
静态 IP 设置方案：提前记好 Mac 网口改 192.168.1.10 的路径。

U 盘刷写恢复固件

使用 Mac 终端刷写是一个更底层、更可靠的方法，因为它能避开许多第三方软件可能带来的权限或挂载干扰。

U 盘格式化 问题：不需要预先格式化。因为刷写命令（dd）是扇区级的操作，它会直接用镜像文件覆盖 U 盘上的所有数据，包括分区表和文件系统。

以下是逻辑清晰的终端刷写步骤：

第一步：识别 U 盘的设备路径

插入 U 盘后，在终端输入：

diskutil list

关键逻辑：

找到你的 U 盘（通常根据容量判断，比如 8GB 或 16GB）。
记住它的标识符，例如 /dev/disk4。
警告：千万不要选错成你的系统盘（通常是 disk0），否则会抹除电脑数据。

第二步：卸载 U 盘（解除挂载）

在写入之前，必须让 macOS 释放对该 U 盘的占用：

diskutil unmountDisk /dev/diskN

(将 N 替换为你的磁盘数字，如 disk4)

第三步：使用 `dd` 命令开始刷写

这是最核心的一步。为了提高速度，我们将设备名从 disk 改为 rdisk（原始磁盘模式），并设置缓冲区大小。

输入以下命令（需要输入你的 Mac 开机密码）：

sudo dd if=/Users/Carl/Downloads/USG-4_2_0-shipped.img of=/dev/rdiskN bs=1m status=progress

参数详解：

if=：输入文件路径（你的镜像）。
of=/dev/rdiskN：输出目标（务必确认 N 是正确的，使用 rdisk 比 disk 快很多）。
bs=1m：设置块大小为 1MB，加速写入。
status=progress：实时显示写入进度。

第四步：安全弹出

写入完成后，终端会返回记录数。此时 macOS 可能会提示“此磁盘无法读取”（因为 USG 的 Linux 分区 Mac 识别不了），点击“忽略”。

然后在终端执行：

diskutil eject /dev/diskN

提醒与逻辑确认

关于分区恢复：正如你之前看到的 fdisk -d 数据，dd 命令会将那几行“分区指令”和对应的数据完全同步到 U 盘。刷完后，你的 U 盘就会自动拥有：

扇区 2048 开始的引导分区。
扇区 292864 开始的系统分区。

物理兼容性：USG-3P 内部空间非常狭窄。如果你的 U 盘太长或太厚，建议拆掉 U 盘的塑料壳，直接把里面的 PCBA 电路板插到 USG 主板上的 USB 口。
上电自检：插好新 U 盘后给 USG 加电。如果一切正常，你会看到指示灯经历：无灯 -> 白灯闪烁（引导中） -> 白色常亮（等待采用）。

验证是否成功

既然已经完成了 dd 刷写并准备上电，逻辑上我们需要验证的是：硬件引导是否成功 以及 系统层级的功能模块（尤其是 DPI 引擎）是否挂载正确。

由于现在没有 Console 线，所有的检测必须通过 SSH 远程登录后完成。

第一步：接入与登录

物理连接：将电脑连接到 USG-3P 的 LAN1 口。
获取 IP：USG 恢复出厂镜像后，默认 IP 通常是 192.168.1.1。确保电脑网卡在同一网段（例如 192.168.1.10）。
SSH 登录：

在 Mac 终端输入：

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa ubnt@192.168.1.1

默认密码：ubnt

刷入的 4.2.0 镜像是非常早期的版本，它使用的 SSH 加密算法（ssh-rsa 和 ssh-dss）在现代操作系统（如 macOS 的新版本）中由于安全漏洞已被默认禁用。Mac 拒绝与使用这些陈旧算法的设备建立连接。

命令解析：

-o HostKeyAlgorithms=+ssh-rsa：告诉 Mac 接受设备提供的 ssh-rsa 密钥指纹。
-o PubkeyAcceptedAlgorithms=+ssh-rsa：允许使用 ssh-rsa 算法进行登录认证。

❯ ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa ubnt@192.168.1.1

The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is SHA256:fVBqcpkQO5s6O5qEvnzvcdbLk69eviZVGr94tTMG4eE.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

ubnt@192.168.1.1's password: 

Linux ubnt 3.4.27-UBNT #1 SMP Tue Aug 12 17:54:01 PDT 2014 mips64
Welcome to EdgeOS

第二步：深度检测逻辑

进入系统后，依次执行命令及以下补充命令来确认“分区与文件完善度”：

1. 验证分区挂载与只读映像 (SquashFS)

USG 的系统运行逻辑是：从 U 盘读取一个压缩的 squashfs 文件并挂载为只读根目录（/ro），然后通过 unionfs 叠加一个可写层。

mount | grep squashfs

正常输出：应该看到 /dev/loop0 on /ro type squashfs (ro,relatime)。
逻辑意义：如果没有这一行，说明系统未能正确加载核心镜像包，此时系统可能运行在内存的应急模式，重启后配置会丢失。

2. 验证磁盘空间分配 (分区完整性)

通过 dd 刷入后，分区表应该自动生效。

df -h

检查重点：查看 /（根目录）和 /config 的容量。
如果 /config 分区显示正常（通常几十 MB 到几百 MB），说明你的分区 3（持久化分区）已成功识别。

3. 验证 DPI (深度数据包检测) 引擎

DPI 是 USG 的核心功能。如果镜像损坏或 U 盘扇区读取错误，DPI 组件经常率先崩溃。

检查文件是否存在：

ls -l /usr/sbin/ubnt-dpi-engine

检查运行状态：

show system statistics dpi

注意：如果这是刚刷完的空机，没有流量经过，这个命令可能返回“DPI is not enabled”或空数据。你需要确认命令能执行而不报错。

4. 验证硬件信息（确认 U 盘识别）

show hardware cpu
show hardware flash

通过 show hardware flash 可以看到系统识别到的内置 USB 存储设备信息，确认它不是处于“Read-only”状态。

还是不行升级最新固件测速

既然已经确认刷入的是官方早期全盘镜像，且分区表（2048, 292864, 3710976）已经正确写入，那么逻辑上的瓶颈就在于：这个早期镜像的“系统逻辑”与后期版本有本质区别。

USG-3P 的系统本质上是一个基于 Debian 修改的 EdgeOS (Vyatta)。它的运行机制与普通电脑不同，采用的是分层镜像挂载技术。

如果刷入的是极其早期的版本（如 4.2.x 或更早），Ubiquiti 当时的设计可能确实没有采用后来的 SquashFS + UnionFS 架构，或者该镜像只是一个“出厂预装环境（Factory Staging）”，它的任务是能连上网，然后通过 UniFi Controller 下发真正的固件升级。

既然 SSH 已经通了，现在拥有一个基础的 Linux 环境，最好的办法是通过 手动推送固件包 来重建分区逻辑。

1. 下载官方的完整固件 (.tar)

不能一次更新跨度太大，先更新低版本再升级高版本。

在你的 Mac 终端上，下载官方最新的 USG-3P 固件（注意是 .tar 后缀，不是 .img）：

版本：v4.4.55 (目前最稳定的版本之一)
链接：UGW3.v4.4.55.5377096.tar

2. 将固件传送到 USG

在 Mac 终端执行 scp 命令（将文件推送到 USG 的临时目录）：

scp -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa /你的文件路径/upgrade.tar ubnt@192.168.1.1:/tmp/upgrade.tar

3. 执行强制“重写”命令

在 Mac 终端输入：

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa ubnt@192.168.1.1

默认密码：ubnt

# 进入管理员模式
sudo -i

# 执行升级
sudo /usr/bin/syswrapper.sh upgrade /tmp/upgrade.tar

syswrapper.sh 是 Ubiquiti 固件中最底层的封装脚本，它不依赖于高级的 Vyatta 命令集。

它会自行解析 .tar 包，提取 squashfs.img，并将其写回 U 盘的分区 2（即 /dev/sda2）。

它会处理“分区不完整”问题，因为它在写入后会强制刷新 initrd 引导。

USG-3P 终端

root@ubnt:~# 
root@ubnt:~# sudo /usr/bin/syswrapper.sh upgrade /tmp/upgrade.tar
+ cmd=upgrade
+ shift
+ case $cmd in
+ exit_if_fake upgrade /tmp/upgrade.tar
++ uname -a
++ grep mips
+ '[' 'Linux ubnt 3.4.27-UBNT #1 SMP Tue Aug 12 17:54:01 PDT 2014 mips64 GNU/Linux' = '' -o -f /tmp/FAKE ']'
+ state_lock
+ lockfile /var/run/system.state
+ TEMPFILE=/var/run/system.state.4125
+ LOCKFILE=/var/run/system.state.lock
+ ln /var/run/system.state.4125 /var/run/system.state.lock
+ rm -f /var/run/system.state.4125
+ return 0
+ do_upgrade /tmp/upgrade.tar
+ set_state upgrading
+ echo upgrading
+ echo 120
+ echo 12
+ /usr/bin/ubnt-upgrade --upgrade-noprompt /tmp/upgrade.tar
+ ret=0
+ set_state_ready
+ prune_old_config
+ find /root.dev/ -type d -iname 'w.????????' -exec rm -rf '{}' ';'
+ set_state ready
+ echo ready
+ state_reload
+ state=init
+ uplink=unknown
+ default=true
+ locating=false
+ '[' -f /proc/ubnthal/status/IsDefault ']'
++ cat /proc/ubnthal/status/IsDefault
+ default=true
+ '[' -f /proc/ubnthal/status/IsLocated ']'
++ cat /proc/ubnthal/status/IsLocated
+ locating=false
+ '[' -f /var/run/system.state ']'
++ cat /var/run/system.state
+ state=ready
+ '[' -f /var/run/system.uplink ']'
+ '[' ready == upgrading ']'
+ '[' false == true ']'
+ '[' true == true ']'
+ set_led 2 120
+ locating=false
+ '[' -f /proc/ubnthal/status/IsLocated ']'
++ cat /proc/ubnthal/status/IsLocated
+ locating=false
+ '[' -f /config/mgmt ']'
+ '[' -z '' ']'
+ '[' -z '' ']'
+ echo 2
+ '[' -z '' ']'
+ echo 120
+ return
+ return 0
+ ret=0
+ state_unlock
+ /bin/rm -f /var/run/system.state.lock
+ '[' 0 -ne 0 ']'
+ /sbin/reboot

Broadcast message from root@ubnt (pts/0) (Wed Jun  1 10:17:23 2011):

The system is going down for reboot NOW!
root@ubnt:~#

逻辑分析

关键指令执行成功：/usr/bin/ubnt-upgrade 返回了 ret=0。这意味着系统已经成功解析了 /tmp/upgrade.tar，并将其中完整的 squashfs.img（系统灵魂）和 vmlinux.64（内核）写入到了 U 盘的物理分区。
清理与就绪：日志显示 prune_old_config 执行了清理，并移除了旧的 w.???????? 挂载目录。这是重构 OverlayFS（覆盖文件系统）的标准动作。
状态翻转：set_state ready 和 set_led 2 120 表明固件更新脚本认为系统已经准备好以“正式版”身份重启。
自动重启：系统发出了 reboot 信号。

再次验证“完全体”系统

重启过程大约需要 3-5 分钟（因为它需要重新挂载新的只读层并建立可写层）。请在系统重启后，再次通过 SSH 登录并执行校验：

# 先清理旧的连接数据
ssh-keygen -R 192.168.1.1

# 现在系统更新了可以直接使用这个命令
ssh ubnt@192.168.1.1

1. 验证分区与 Overlay 架构

执行：mount | grep squashfs

期望结果：必须看到类似 /dev/loop0 on /ro type squashfs 的输出。这证明你的系统不再是一个简单的“壳子”，而是拥有了正式的只读镜像层。

2. 验证文件系统利用率

执行：df -h

期望结果：/ 根目录应该挂载在 unionfs 下，且容量和路径会比之前那个 157MB 的环境丰富得多。

3. 验证功能组件（DPI 引擎）

执行：

ls -l /usr/sbin/ubnt-dpi-engine
show system statistics dpi

期望结果：ls 应该能看到文件，show 命令应该可以正常运行（即使显示没有统计数据）。

结果如下：

❯ ssh ubnt@192.168.1.1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:3eubecS9Id7cnkB+2jS3Ov3O+CQU+WmdFkxEHXpmCPI.
Please contact your system administrator.
Add correct host key in /Users/Carl/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/Carl/.ssh/known_hosts:11
Host key for 192.168.1.1 has changed and you have requested strict checking.
Host key verification failed.
❯ ssh-keygen -R 192.168.1.1
# Host 192.168.1.1 found: line 11
/Users/Carl/.ssh/known_hosts updated.
Original contents retained as /Users/Carl/.ssh/known_hosts.old
❯ ssh ubnt@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ED25519 key fingerprint is SHA256:3eubecS9Id7cnkB+2jS3Ov3O+CQU+WmdFkxEHXpmCPI.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

ubnt@192.168.1.1's password: 
Linux ubnt 3.10.107-UBNT #1 SMP Fri Feb 12 11:26:18 UTC 2021 mips64

  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2021
 |   |  |   |  \  ||  \   |  |   Ubiquiti, Inc.
 |______|___|  /__||__/   |__|
            |_/                  https://www.ui.com

      Welcome to EdgeOS on UniFi Security Gateway!


 **********************  WARNING!  **********************
 * Configuration changes made here are not persistent.  *
 * They will be overwritten by the controller on next   *
 * provision. Configuration must be done in controller. *
 ********************************************************

ubnt@ubnt:~$ 
ubnt@ubnt:~$ mount | grep squashfs
ubnt@ubnt:~$ df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.6G    258.3M      1.3G  17% /root.dev
aufs                      1.6G    258.3M      1.3G  17% /
tmpfs                   242.0M    180.0K    241.8M   0% /run
tmpfs                   242.0M    180.0K    241.8M   0% /run
tmpfs                   242.0M     56.0K    241.9M   0% /var/log
tmpfs                   242.0M         0    242.0M   0% /dev/shm
tmpfs                   242.0M      8.0K    241.9M   0% /tmp
none                    242.0M    504.0K    241.5M   0% /opt/vyatta/config
/dev/sda3                 1.7G     34.7M      1.6G   2% /root.dev/ugw
unionfs                 242.0M      8.0K    241.9M   0% /opt/vyatta/config/tmp/new_config_7aae4bb0efd372ff478ff3096e
ubnt@ubnt:~$ ls -l /usr/sbin/ubnt-dpi-engine
ls: /usr/sbin/ubnt-dpi-engine: No such file or directory
ubnt@ubnt:~$ show system statistics dpi
Invalid command
ubnt@ubnt:~$

关于 DPI 引擎的说明

经过多次尝试，发现 USG-3P 确实有 DPI 引擎，但：

文件名可能不同：USG-3P 上的 DPI 工具可能是 ubnt-dpi-util 而不是 ubnt-dpi-engine
需要在控制器中启用：必须在 UniFi Network 控制器里打开 "Traffic & Device Identification"，控制器才会下发配置，启动 DPI 引擎
文件系统结构不同：USG 使用的是 aufs + rootsqimg 结构，而不是 UDM 的 squashfs + /ro 结构

要验证 DPI 引擎是否存在，可以执行：

ls /usr/sbin/ | grep -E 'dpi|ubnt'

控制器接管

更换 U 盘或重刷固件后，USG 会恢复到出厂默认状态，需要重新让控制器接管：

清理 SSH 缓存

ssh-keygen -R 192.168.1.1

配置网段

浏览器访问 https://192.168.1.1（默认账号密码：ubnt / ubnt）
将 LAN IP 修改为你的目标网关地址（比如 192.168.2.1）
保存后，将电脑 IP 改为对应网段或直接将 USG 接入原有网络

删除旧设备记录

在 UniFi 控制器中删除旧的 USG 设备记录：

打开控制器界面
在 Devices 列表中找到显示 Offline 的旧 USG
进入 Settings -> Manage Device，点击 Forget 删除

手动引导 Adoption

SSH 登录新 IP：

ssh ubnt@192.168.2.1

推送 Inform 地址：

set-inform http://192.168.2.20:8080/inform

（协议头是 http，端口固定为 8080）

完成接管

回到控制器页面，点击 Adopt 接管设备，等待指示灯从白色常亮变为蓝色常亮。

最终结论

经过多次尝试，发现 USG-3P 的固件对 U 盘有特殊要求，更换非原装 U 盘可能会导致 DPI 引擎等功能异常。如果不是特别需要，建议还是使用原装 U 盘。

如果确实需要更换 U 盘，建议：

使用官方指定的 U 盘型号或兼容型号
确保刷入完整的官方固件
在控制器中正确配置和启用相关功能
耐心测试各项功能是否正常

经验教训

备份重要数据：操作前一定要备份配置和重要数据
准备充分：备齐工具和文件，避免中途因缺少东西而中断
耐心测试：每一步操作后都要验证系统状态
了解设备特性：不同设备的固件和文件系统结构可能不同，不要盲目参考其他设备的教程
社区资源：遇到问题时，社区论坛是很好的参考来源

虽然这次折腾没有完全成功，但也学到了不少关于 USG-3P 系统结构和固件升级的知识，希望这些经验能对遇到类似问题的朋友有所帮助。

装回并控制器接管

更换 U 盘或底层重刷固件后，USG-3P 会恢复到出厂默认状态（192.168.1.1）。要让它无缝接回原有的 192.168.2.x 网段并让控制器重新“认主”，请严格按照以下步骤操作。

初始化登录与环境清理

由于系统指纹（Host Key）已变，你的 Mac 会因为安全机制拒绝连接。

清理 SSH 缓存：

在 Mac 终端运行，防止“身份变更”报警：

ssh-keygen -R 192.168.1.1

物理连接：

用网线直连 Mac 和 USG 的 LAN1 口，手动设置 Mac 的 IP 为 192.168.1.10。
初次登录：

浏览器访问 https://192.168.1.1（默认账号密码：ubnt / ubnt）。

配置网段，对齐生产环境

为了能让 USG 顺利接入你原本的 192.168.2.x 网络并找到控制器，必须先修改它的 LAN 口网段。

修改 IP： 在 USG 本地管理界面，将 LAN IP 修改为你的目标网关地址（例如 192.168.2.1）。
注意： 保存后，连接会立即断开。此时你需要：

将 Mac 的手动 IP 改为 192.168.2.x 网段。
或者直接将 USG 接入原有的交换机网络。

控制器端的“断舍离”

这是最容易被忽略的一步： 在重新接管之前，你必须先在 UniFi 控制器中删除这台设备的“前世记忆”。

打开控制器界面（通常是你的 NAS 或 CloudKey）。
在 Devices 列表中找到那台显示 Offline 或 Disconnected 的旧 USG。
进入 Settings -> Manage Device，点击 Forget（删除）。只有彻底删除旧记录，新系统才能顺利发起 Adoption 请求。

手动引导 Adoption

由于 USG 目前还不知道控制器的具体位置，我们需要手动给它“指路”。

也可以直接打开网页 192.168.2.1 进行设置，更方便。

SSH 登录新 IP：

ssh ubnt@192.168.2.1

推送 Inform 地址：

输入以下指令，告知控制器位置（假设控制器 IP 为 192.168.2.20）：

set-inform http://192.168.2.20:8080/inform

注意： 协议头是 http 而非 https，端口固定为 8080。d

如果不能发现并接管

如果依然无法发现，可能是之前的配置残余干扰了接管，输入以下命令，执行后 USG 会重启并彻底清空所有设置。

set-default

完成最后的“握手”

回到控制器页面： 你会看到 USG 状态变为 Pending Adoption。
点击 Adopt： 稍等片刻，USG 的指示灯会从白色常亮变为蓝色常亮。
回到 USG 本地管理页： 点击 Confirm 确认 Inform URL 已生效。

UniFi 网络设备 USG 3P 网关更换内置系统 U 盘后刷机和升级固件

为什么要折腾这个

前期准备工作及注意事项

U 盘刷写恢复固件

第一步：识别 U 盘的设备路径

第二步：卸载 U 盘（解除挂载）

第三步：使用 dd 命令开始刷写

第四步：安全弹出

提醒与逻辑确认

验证是否成功

第一步：接入与登录

第二步：深度检测逻辑

1. 验证分区挂载与只读映像 (SquashFS)

2. 验证磁盘空间分配 (分区完整性)

3. 验证 DPI (深度数据包检测) 引擎

4. 验证硬件信息（确认 U 盘识别）

还是不行升级最新固件测速

1. 下载官方的完整固件 (.tar)

2. 将固件传送到 USG

3. 执行强制“重写”命令

再次验证“完全体”系统

1. 验证分区与 Overlay 架构

2. 验证文件系统利用率

3. 验证功能组件（DPI 引擎）

关于 DPI 引擎的说明

控制器接管

清理 SSH 缓存

配置网段

删除旧设备记录

手动引导 Adoption

完成接管

最终结论

经验教训

装回并控制器接管

初始化登录与环境清理

配置网段，对齐生产环境

控制器端的“断舍离”

手动引导 Adoption

完成最后的“握手”

第三步：使用 `dd` 命令开始刷写