Unraid 7.3 Internal Boot 迁移实录：从 NVMe 故障、Btrfs 降级，到 TPM 许可与 HBA 启动问题

一、背景

最近在折腾 Unraid 7.3 的 Internal Boot，也就是从传统 USB 启动迁移到内部 SSD 启动。

原本的目标很简单：

用一块企业级 SATA SSD 替代 U 盘，作为 Unraid 的内部启动盘，提高稳定性。

但实际迁移过程中，顺带暴露出了一堆隐藏问题：

1. Cache Pool 中一块 NVMe 已经出现真实介质错误；
2. Btrfs RAID1 虽然能自修复，但并不代表硬盘健康；
3. 512G 临时盘无法直接 replace 1T cache 盘；
4. Btrfs allocated chunk 和实际 used 不是一回事；
5. Internal Boot 写入成功后，BIOS 仍然无法从 SSD 启动；
6. LSI SAS2308 HBA 卡上的 SSD 无法被 BIOS 当作启动盘；
7. TPM 许可迁移后出现多个 key 文件冲突；
8. 迁移后 License 页面显示过期时间，引发对 legacy lifetime updates 的疑问。

这篇文章记录完整处理过程，供后续折腾 Unraid 7.3 Internal Boot、Btrfs cache pool 和 TPM license 的人参考。

---

二、原始环境

当前机器大致结构如下：

设备	用途
USB 启动盘	原 Unraid 启动盘
240G 企业级 SATA SSD	准备作为 Internal Boot
1T NVMe	原 cache pool 成员之一，健康
1T NVMe	原 cache pool 成员之一，后续确认故障
512G NVMe	临时用于替换故障 cache 盘
多块 HDD	Unraid Array 数据盘
LSI SAS2308 HBA	连接部分 SATA/SAS 设备

---

三、第一次发现问题：Btrfs scrub 报错但可修复

一开始执行 cache pool 的 Btrfs scrub：

btrfs scrub start -B /mnt/cache

第一次结果出现大量错误：

Error summary: read=256 verify=20 csum=2937
Corrected: 3213
Uncorrectable: 0
Unverified: 0

第二次 scrub 又变成：

Error summary: no errors found

表面看似没问题，因为：

• Corrected 不为 0；
• Uncorrectable = 0；
• 第二次 scrub 已经无错误。

但这其实只是说明：

Btrfs RAID1 成功从另一块健康盘读取正确副本，并修复了错误数据。

这不代表故障盘健康。

---

四、真正的硬盘故障证据：device stats 和 dmesg

继续查看 Btrfs device stats：

btrfs device stats /mnt/cache

结果非常明显：

[/dev/nvme1n1p1].write_io_errs    29513266
[/dev/nvme1n1p1].read_io_errs     88468
[/dev/nvme1n1p1].flush_io_errs    1244217
[/dev/nvme1n1p1].corruption_errs  38172
[/dev/nvme1n1p1].generation_errs  5

[/dev/nvme0n1p1].write_io_errs    0
[/dev/nvme0n1p1].read_io_errs     0
[/dev/nvme0n1p1].flush_io_errs    0
[/dev/nvme0n1p1].corruption_errs  0
[/dev/nvme0n1p1].generation_errs  0

可以确认：

/dev/nvme1n1p1 是故障盘，/dev/nvme0n1p1 是健康盘。

再看 dmesg：

dmesg | grep -i nvme

其中出现了关键错误：

critical medium error, dev nvme1n1
I/O Error (sct 0x2 / sc 0x81)

这类错误已经不是 APST、省电、驱动、PCIe reset 之类的问题，而是典型的：

SSD 介质 / 数据完整性错误。

即使 Windows 下 SMART 显示“健康”，只要出现：

Media and Data Integrity Errors > 0

就不能再把它当作可靠盘使用。

这块故障 NVMe 后续拆下来重新查看，SMART 中也能看到：

Media and Data Integrity Errors = 36

这个值正常应该是 0。

---

五、关于 SMART 的一个误区

这次有一个很典型的误区：

Windows 工具显示“健康”不代表盘真的适合继续做 NAS cache。

很多 SMART 工具主要看：

Critical Warning

只要它是 0，就显示“健康”。

但对 NAS / Btrfs / ZFS 来说，更重要的是：

指标	要求
Media and Data Integrity Errors	必须为 0
Error Information Log Entries	越少越好，需看具体类型
Reallocated / Pending / Uncorrectable	必须为 0
Btrfs corruption_errs	必须为 0
scrub uncorrectable	必须为 0

这次坏盘的问题就是：

• Windows 健康状态正常；
• 但 Btrfs 已经发现大量读写、flush、corruption 错误；
• dmesg 已经出现 critical medium error；
• SMART 里 Media and Data Integrity Errors 已经不是 0。

所以结论很明确：

这块盘还能亮、还能读，不等于还能作为 cache / appdata / docker / VM 盘继续使用。

---

六、512G 替换 1T cache 盘为什么失败？

手边刚好有一块 512G NVMe，于是想直接替换故障的 1T 1T NVMe。

一开始查看：

btrfs filesystem show

看到 cache pool：

Total devices 2 FS bytes used 372.30GiB
devid 1 size 953.87GiB used 375.03GiB path /dev/nvme1n1p1
devid 2 size 953.87GiB used 375.03GiB path /dev/nvme0n1p1

这里有一个关键点：

FS bytes used 只有 372GiB，说明真实逻辑数据量并不大。

理论上 512G 应该够。

但在 Unraid GUI 或 Btrfs replace 时提示：

wrong pool state
replace device too small

原因在于：

Btrfs replace 看的不只是实际 used，还会受到 allocated chunk 的影响。

也就是说，Btrfs 可能只用了 372G 数据，但已经分配了更大的 chunk。此前 usage 中曾看到：

Device allocated: 741.06GiB

所以直接用 512G 替换会失败。

---

七、解决办法：先降级为单盘，再清理 RAID1 allocation

拆掉故障盘后，Btrfs pool 进入 degraded 状态：

btrfs filesystem show

显示：

warning, device 1 is missing

Label: none uuid: 1d44c14b...
Total devices 2 FS bytes used 372.28GiB
devid 2 size 953.87GiB used 375.03GiB path /dev/nvme0n1p1
*** Some devices missing

此时需要先手动 degraded mount：

mkdir -p /mnt/recovery
mount -o degraded /dev/nvme0n1p1 /mnt/recovery

确认数据还能看到后，开始 balance，把 RAID1 profile 转成 single：

btrfs balance start -dconvert=single -mconvert=dup /mnt/cache

最终状态变成：

pool status: ONLINE
Device size: 953.87GiB
Device allocated: 379.06GiB
Used: 373.54GiB
Data ratio: 1.00
Metadata ratio: 2.00
Multiple profiles: no

Data single
Metadata DUP
System DUP

这说明：

• cache pool 已经从 RAID1 降级为单盘；
• 不再 missing device；
• allocated 已经降到 379G；
• 未来再加 512G 重新转 RAID1 就可行了。

当前状态下，其实已经安全很多：

项目	状态
pool	ONLINE
数据	single
metadata	DUP
corruption errors	0
missing device	无
allocated	379G

---

八、为什么没有立刻把 512G 加回 RAID1？

虽然现在可以加回 512G，但我最后没有急着操作。

原因是：

1. 当前 cache 已经稳定为单盘；
2. 512G 是国产消费级 NVMe；
3. 刚经历一次故障和大量 balance，不宜立刻继续重 IO；
4. 后续计划等 SSD 价格回落后，换 1T 企业 SATA / 企业 NVMe 更合适。

如果后面要重新加回 512G RAID1，可以在 GUI 中把 512G 加入 pool，然后执行：

btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/cache

但当前更稳妥的是：

先单盘稳定运行，建立 appdata 备份，再决定是否恢复 RAID1。

---

九、240G S4610 做 Internal Boot 是否合适？

这次准备作为 Internal Boot 的盘是：

<ENTERPRISE-SATA-SSD-MODEL-REDACTED>
240G 企业级 SATA SSD

SMART 状态如下：

Reallocated sector count = 0
Current pending sector = 0
Offline uncorrectable = 0
CRC error count = 0
Program fail count total = 0
Erase fail count total = 0
Percent life remaining = 100%
Power on hours = 41479
Temperature = 27℃

虽然通电时间已经 4.7 年，但对企业 SATA SSD 来说不算夸张。

而且它的关键指标很干净：

• 无重映射；
• 无 pending；
• 无 uncorrectable；
• 无 CRC；
• PLP 相关项正常；
• 剩余寿命 100%。

这类企业 SATA 盘做 Unraid Internal Boot 非常合适，因为 Unraid boot 盘主要存：

• config；
• license；
• plugins；
• docker templates；
• 系统启动文件。

并不承载高频 appdata / database / VM 写入。

所以 240G 甚至是非常富裕的容量。

---

十、Internal Boot 页面中“专用启动池”和“启动 + 数据池”的区别

Unraid 7.3 Internal Boot 创建时，会让你选择池模式：

1. 专用启动池；
2. 启动 + 数据池。

二者区别如下：

模式	说明	是否推荐
专用启动池	SSD 只做 Unraid boot	推荐
启动 + 数据池	SSD 同时做 boot 和普通 data pool	不推荐当前环境使用

我的选择是：

专用启动池。

原因很简单：

• Boot 和 cache 应该隔离；
• 启动盘不应承载 Docker / appdata / VM；
• 一旦启动盘坏，不应影响普通数据池；
• 这种结构更接近传统 USB boot + 独立 cache 的稳定模型。

最终设计：

设备	用途
240G S4610	Internal Boot
1T Toshiba NVMe	Cache
512G NVMe	临时备用 / 未来 mirror
HDD Array	主数据

---

十一、Internal Boot 写入成功，但拔 U 盘无法启动

Internal Boot 创建成功后，lsblk -f 显示：

sdc
├─sdc1
├─sdc2 vfat FAT32 EFI
├─sdc3 zfs_member flash
└─sdc4

说明：

• EFI 分区存在；
• ZFS flash boot pool 存在；
• Internal Boot 本身已经写入成功。

进一步检查 EFI 文件：

mkdir -p /mnt/bootssd
mount /dev/sdc2 /mnt/bootssd
find /mnt/bootssd

输出：

/mnt/bootssd
/mnt/bootssd/EFI
/mnt/bootssd/EFI/BOOT
/mnt/bootssd/EFI/BOOT/BOOTX64.EFI

这说明 EFI fallback 文件也存在。

然后通过 efibootmgr 手动创建 EFI 启动项：

efibootmgr -c -d /dev/sdc -p 2 -L "UnraidSSD" -l '\EFI\BOOT\BOOTX64.EFI'
efibootmgr -o 0000

最终：

BootCurrent: 0001
BootOrder: 0000
Boot0000* UnraidSSD
Boot0001* UEFI: USB-Boot-Device, Partition 1

看起来已经正确。

但拔掉 U 盘后，机器仍然直接进入 BIOS，Boot 页面看不到这个 SSD。

---

十二、最终确认：问题出在 LSI SAS2308 HBA 启动支持

最后发现一个关键事实：

这块 S4610 是通过 LSI SAS2308 HBA 连接到主板的。

这就解释了所有现象。

系统启动后，Linux 能看到 SSD：

sdc 223.6G <ENTERPRISE-SATA-SSD-MODEL-REDACTED>

但 BIOS 阶段看不到启动项。

这是典型的：

HBA 在操作系统里可识别，但 BIOS / UEFI 阶段不提供可启动路径。

LSI SAS2308 这类 HBA 分几个部分：

部分	作用
IT Firmware	操作系统识别磁盘
Legacy BIOS ROM	Legacy 启动
UEFI ROM	UEFI 启动

很多二手 HBA 卡只刷了 IT firmware，没有刷 UEFI boot ROM，或者主板 BIOS 不支持从这张卡启动。

所以现象就是：

阶段	状态
Unraid 启动后	能看到 SSD
EFI 分区	正常
BOOTX64.EFI	正常
efibootmgr	能创建 entry
BIOS 启动阶段	看不到 SSD / 无法启动

最终结论：

Internal Boot 本身没有问题，问题在于启动 SSD 挂在 HBA 后，主板 BIOS 无法从该 HBA 上的 SATA SSD 启动。

解决方案有两个：

方案 A：启动 SSD 接板载 SATA

这是最推荐方案。

设备	连接方式
S4610 Boot SSD	板载 SATA
HDD 数据盘	LSI SAS2308
NVMe cache	主板 M.2

这是最稳、最少玄学的方案。

方案 B：给 SAS2308 HBA 补刷 UEFI ROM

理论可行，但不推荐作为首选。

原因：

• 有刷错风险；
• 不同 OEM 卡兼容性不同；
• 主板 BIOS 仍可能不认；
• HBA 初始化会拖慢启动；
• 启动盘挂 HBA 本身就不如接板载 SATA 稳。

---

十三、BIOS 设置踩坑

过程中也排查过华硕 BIOS 设置。

关键设置如下：

项目	推荐值
Secure Boot / OS Type	Other OS
Launch CSM	Disabled
Boot from Storage Devices	UEFI only
Fast Boot	Disabled
AMI Native NVMe Driver Support	On

其中：

• Secure Boot 不关，Unraid EFI 可能无法启动；
• CSM 开启时，有些华硕 BIOS 不扫描 Linux EFI；
• Fast Boot 可能跳过部分存储扫描；
• 但这些都调整后仍不行，最终才确认是 HBA 启动支持问题。

---

十四、TPM 许可迁移后的多个 key 文件问题

Internal Boot 成功后，Unraid 进入注册页面，提示：

存在多个许可证密钥
License key type: Invalid

检查：

ls /boot/config/*.key

发现：

/boot/config/Basic.key
/boot/config/Plus.key

也就是 /boot/config 下有多个 key 文件。

Unraid 7.3 TPM licensing 对 key 文件更严格，只能保留一个有效 key。

最终删除旧的 Basic.key：

rm /boot/config/Basic.key
sync
reboot

然后重新更新密钥，许可恢复。

---

十五、License Expires After 是什么？

迁移 TPM license 后，页面显示：

Unraid Plus License
GUID: <LICENSE-GUID-REDACTED>
License Expires After: 2025-09-11

这个地方容易误解。

它不是说系统到期不能用了。

Unraid 新许可体系里：

• License 本身是永久的；
• Expire 通常指更新资格；
• 到期后当前版本仍可继续使用；
• 但是否能继续享受 lifetime updates，要看账号里 Manage Purchases 的状态。

本次账号的 Manage Purchases 中显示：

OS Updates: Lifetime

因此这里需要向 Unraid support 确认：

TPM 迁移后，legacy Plus license 是否仍然保留 lifetime OS updates，以及页面中的 expires after 是否只是显示问题或迁移后的兼容字段。

---

十六、最终状态

目前处理后的状态：

项目	状态
故障 1T NVMe	已拆除，不再用于生产数据
Cache pool	单盘 online，Data single，Metadata DUP
Btrfs corruption	归零
512G NVMe	可作为后续临时 mirror
240G S4610	Internal Boot 已创建成功
Internal Boot EFI	正常存在
BIOS 启动失败原因	HBA 不支持 / 未提供 UEFI boot
License 多 key 问题	已定位并处理
TPM License	已迁移，但 lifetime updates 状态需向官方确认

---

十七、这次折腾的经验总结

1. Btrfs scrub 能修复，不代表硬盘健康

如果 scrub 出现 corrected，而不是 uncorrectable，只说明镜像起作用了。

真正要看：

btrfs device stats /mnt/cache
dmesg | grep -i nvme
smartctl -a /dev/nvmeXn1

尤其是：

Media and Data Integrity Errors
critical medium error
corruption_errs

这些才是判断硬盘是否可靠的关键。

---

2. Windows SMART 健康状态不能作为 NAS 可靠性判断

“健康 / 优秀”只适合普通用户粗略参考。

NAS / Btrfs / ZFS 环境应该更严格：

• Media Errors 必须为 0；
• corruption 必须为 0；
• pending / uncorrectable 必须为 0；
• scrub 不应反复 corrected。

---

3. Btrfs 的 used 和 allocated 不是一回事

这次最大坑之一是：

FS bytes used 372G

但 replace 512G 仍然失败。

原因是：

Device allocated

过高。

Btrfs replace / shrink / balance 过程中，allocated chunk 非常关键。

---

4. 降容量 replace 很麻烦，重建 pool 有时反而更干净

从 1T RAID1 换到 512G RAID1，理论上只要 used 足够小就行。

但实际会受：

• allocated chunk；
• metadata；
• profile；
• balance 状态；

影响。

如果数据量可控，有时备份 appdata 后重建 cache pool 反而更简单。

---

5. Internal Boot 最适合用“专用启动池”

不建议把 boot SSD 同时当普通 data pool 使用。

更稳结构是：

小企业 SATA SSD = 专用 Internal Boot
NVMe / SSD = cache
HDD = array

---

6. 企业 SATA SSD 做 boot 很合适

240G S4610 这种盘虽然不新，但做 Unraid Boot 非常合适：

• 稳定；
• 有 SMART；
• 有 PLP；
• 发热低；
• 写入压力小；
• 比 USB 盘可靠得多。

---

7. HBA 上能被 Linux 识别，不代表能被 BIOS 启动

这是这次 Internal Boot 最大的坑。

LSI SAS2308 这类 HBA：

• 进系统后识别磁盘没问题；
• 但 BIOS 阶段不一定能从它启动；
• 取决于是否有 UEFI ROM、主板 BIOS 是否支持。

如果启动盘接在 HBA 上，遇到 BIOS 看不到启动项，优先怀疑 HBA boot support。

最稳方案：

启动盘接板载 SATA，HBA 只管数据盘。

---

8. TPM license 迁移后，注意 /boot/config 下只能留一个 key

如果出现：

存在多个许可证密钥
License key type: Invalid

检查：

ls /boot/config/*.key

只保留当前有效的 key，删除旧 key。

---

9. Legacy Plus 用户迁移 TPM 后，要确认 lifetime updates 状态

如果页面显示：

License Expires After

但账号里显示：

OS Updates: Lifetime

建议联系 Unraid support 确认。

尤其是 legacy Basic / Plus / Pro 用户，理论上应保留 lifetime updates。

---

十八、最终推荐架构

基于这次踩坑，比较稳的 Unraid 7.3 架构是：

层级	推荐设备
Boot	板载 SATA 上的小企业 SSD
Cache	企业 SATA / 企业 NVMe / 可靠消费 NVMe
Cache 冗余	Btrfs RAID1 或 ZFS mirror
Array	HDD + parity
HBA	只接数据盘，不接启动盘
Backup	定期备份 appdata + boot config

当前更合理的最终结构应该是：

S4610 240G       → 板载 SATA，Internal Boot
1T NVMe  → Cache
512G NVMe        → 临时备用 / 后续 mirror
HDD Array        → 主数据
LSI SAS2308      → 只接 HDD 数据盘

---

十九、结语

这次迁移本来只是想把 Unraid 从 U 盘启动改成内部 SSD 启动，但实际过程中暴露出的问题远比预期多。

最终最大的收获是：

存储系统里，“能识别”和“可靠运行”是两回事；
“SMART 健康”和“适合 NAS 长期使用”也是两回事；
“EFI 文件存在”和“BIOS 能启动”仍然是两回事。

Unraid 7.3 的 Internal Boot 是一个很好的方向，但如果启动盘挂在 HBA / 扩展卡上，仍然可能踩 BIOS 启动支持的坑。

最稳的做法仍然是：

启动盘接板载控制器，数据盘交给 HBA，cache 做好备份和定期 scrub。

这次虽然过程很折腾，但也顺手发现并处理了一块已经开始出问题的 NVMe。某种意义上，Btrfs RAID1 和 scrub 算是提前救了一次数据。