企业官网建设流程全解析

黑群晖 DSM 更新反复失败的修复：系统分区扩容全记录

黑群晖 DS918+，DSM 系统更新反复失败几个月：下载正常，重启安装就报错回滚。
根因：系统分区是 RAID1，被老盘 2.4G 的小系统分区拖累，更新空间不够。
解决：逐个把老盘重分区到 8G。本文记录全过程和踩过的坑。

一、症状与根因

症状

DSM 更新反复失败：更新包下载正常 → 重启安装卡住/报错/回滚。换版本、重试都没用。一直怀疑是 rr 引导问题，排查了很久，最后 SSH 进去才发现是系统分区空间不够。

根因

群晖会把系统装到每一块盘上（任意盘坏都能启动），所有盘的第一分区组成 md0 这个 RAID1，DSM 系统跑在 md0 上。RAID1 容量取最小成员。

我的盘是两块老盘（4T、8T）+ 一块新盘（12T）：

两块老盘都是从旧版本群晖带过来的，系统分区只有 2.4G。RAID1 取最小成员 →整个系统分区 2.4G：

df-h/dev/md0# /dev/md0 2.4G 1.9G 5.9G 25% / ← DSM 自己占 1.9G

2.4G 装完系统只剩 500M，更新时要下载、解压、写临时文件，空间根本不够 → 必然失败。这是典型的"木桶效应"：一块老盘拖垮整个系统升级能力。

二、方案

把每块老盘的系统分区重建为新标准 8G，让 md0 扩容到 8G。逐盘操作，每盘流程相同：迁移数据 → 删分区 → 重建 → 验证。

三、操作经过

Day 1：4T 盘（第一块老盘）

1. 迁数据：4T 盘数据全部拷到 12T 盘，确认无误
2. 删分区：存储管理器删除 4T 存储池
3. 重建：新建存储池选Basic（单盘场景，SHR/JBOD 都是多盘设计；数据已备份不需要冗余），重建后系统分区自动变为 8G

/dev/sda:3.7TiB ├── sda1: 8G ← 系统分区2.4G → 8G ✅ ├── sda2: 2G ← swap └── sda3:3.6T ← 数据分区

Day 2：8T 盘（第二块老盘）

同样流程：删池 → 重建 → 系统分区 2.4G → 8G。

踩坑：重分区后 SSH 连不上了。端口通（nc 测试正常）但 banner 超时，折腾半天发现：

• 重建系统分区会清空/root/.ssh/authorized_keys，SSH 公钥登录直接失效
• 加上域名解析到公网 IPv6，host key 和局域网不一致，更容易误判
• 最终改用用户名 + 密码登录解决（Could not chdir to home directory就是用户目录还没重建好的信号）

⚠️教训：重分区前先确认能进系统。密钥会丢，提前导好公钥或备好密码登录方式，别等重分区完再抓瞎。

两天后 md0 扩容完成：

md0:active raid1 sdd1[2]sda1[1]sdb1[0]8388544blocks[16/3][UUU_____________]←2.4G → 8G ✅

Day 3：固态上的套件（绕不开的一环）

系统分区扩容本身和固态无关（固态没参与 md0 RAID）。但有一件事必须处理：Docker、MariaDB、HomeAssistant 等 20+ 个套件都装在固态上。

这里有个通用问题：套件装在哪块盘，重建那块盘时套件就全没了。这次是固态重建触发的，换成机械盘重分区也一样——套件迁移/备份恢复这套流程跑不掉。所以流程记下来，谁重分区谁用得上：

备份（重建前）：

# 1. 套件配置全量备份（@appdata，约 422M）sudotarcf - /volume1/@appdata|tarxf --C/volume2/backup/# 2. Docker 容器配置导出（端口映射、环境变量、卷映射）dockerinspect kcptun peerbanhelper flexget shadowsocks>all-containers.jsondockerimages>docker-images.txt# 3. MariaDB 数据库导出（DSM 内置 mysqldump，socket 连接免密）mysqldump-S/run/mysqld/mysqld10.sock-uroot --all-databases>mysql-all.sql# 4. 容器持久化数据目录cp-a/volume1/docker/flexget /volume2/backup/cp-a/volume1/peerbanhelper /volume2/backup/

重建：

1. 套件中心停用所有套件（防止占用）
2. 存储管理器删除固态存储池 → 重建存储池、存储空间
3. 套件中心重装全部套件（ContainerManager、MariaDB10、DDNS-GO、AList、qBittorrent、DownloadStation……）

恢复：

把备份的@appdata覆盖回原位，再按需导入数据：

四、结果

所有套件恢复后，DSM 控制面板执行更新：7.3.2 → 7.3.3 一次成功。反复失败几个月的噩梦结束。

五、经验教训

1. DSM 更新失败先查系统分区：df -h /dev/md0，小于 4G 大概率就是空间不足，别先怀疑引导、怀疑版本
2. 群晖系统分区是 RAID1，容量取最小成员：新老盘混用时，老盘 2.4G 分区会拖累整个 md0。根治办法是把老盘逐个重建为新标准
3. 重分区会清空 SSH 公钥（authorized_keys 没了），提前备好密码登录方式
4. 重分区前必须处理套件：套件装在哪块盘，重建那块盘套件就全没了。备份三件套（@appdata、docker inspect、mysqldump）+ 停用 + 重装 + 恢复，这个流程对任何盘的重分区都适用

附：诊断命令速查

cat/proc/mdstat# 系统分区 RAID 组成、容量df-h/dev/md0# 系统分区剩余空间sudofdisk-l/dev/sda# 单盘分区表sudomdadm--detail/dev/md0# RAID 详情mount|grepvolume# 各卷挂载情况

如果你的 DSM 也"下载正常、安装回滚"，先跑前两条命令——系统分区小于 4G 就是病根。别急着换引导、刷机，把老盘的系统分区扩容到 8G 再说。