十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

群晖 DSM 更新反复失败的修复:系统分区扩容全记录 黑群晖 DSM 更新反复失败的修复系统分区扩容全记录黑群晖 DS918DSM 系统更新反复失败几个月下载正常重启安装就报错回滚。根因系统分区是 RAID1被老盘 2.4G 的小系统分区拖累更新空间不够。解决逐个把老盘重分区到 8G。本文记录全过程和踩过的坑。一、症状与根因症状DSM 更新反复失败更新包下载正常 → 重启安装卡住/报错/回滚。换版本、重试都没用。一直怀疑是 rr 引导问题排查了很久最后 SSH 进去才发现是系统分区空间不够。根因群晖会把系统装到每一块盘上任意盘坏都能启动所有盘的第一分区组成 md0 这个 RAID1DSM 系统跑在 md0 上。RAID1 容量取最小成员。我的盘是两块老盘4T、8T 一块新盘12T盘系统分区md0 成员4Tsda老盘2.4G旧版 DSM 标准12Tsdb新盘8G8Tsdd老盘2.4G旧版 DSM 标准两块老盘都是从旧版本群晖带过来的系统分区只有 2.4G。RAID1 取最小成员 →整个系统分区 2.4Gdf-h/dev/md0# /dev/md0 2.4G 1.9G 5.9G 25% / ← DSM 自己占 1.9G2.4G 装完系统只剩 500M更新时要下载、解压、写临时文件空间根本不够 → 必然失败。这是典型的木桶效应一块老盘拖垮整个系统升级能力。二、方案把每块老盘的系统分区重建为新标准 8G让 md0 扩容到 8G。逐盘操作每盘流程相同迁移数据 → 删分区 → 重建 → 验证。三、操作经过Day 14T 盘第一块老盘迁数据4T 盘数据全部拷到 12T 盘确认无误删分区存储管理器删除 4T 存储池重建新建存储池选Basic单盘场景SHR/JBOD 都是多盘设计数据已备份不需要冗余重建后系统分区自动变为 8G/dev/sda:3.7TiB ├── sda1: 8G ← 系统分区2.4G → 8G ✅ ├── sda2: 2G ← swap └── sda3:3.6T ← 数据分区Day 28T 盘第二块老盘同样流程删池 → 重建 → 系统分区 2.4G → 8G。踩坑重分区后 SSH 连不上了。端口通nc 测试正常但 banner 超时折腾半天发现重建系统分区会清空/root/.ssh/authorized_keysSSH 公钥登录直接失效加上域名解析到公网 IPv6host 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约 422Msudotarcf - /volume1/appdata|tarxf --C/volume2/backup/# 2. Docker 容器配置导出端口映射、环境变量、卷映射dockerinspect kcptun peerbanhelper flexget shadowsocksall-containers.jsondockerimagesdocker-images.txt# 3. MariaDB 数据库导出DSM 内置 mysqldumpsocket 连接免密mysqldump-S/run/mysqld/mysqld10.sock-uroot --all-databasesmysql-all.sql# 4. 容器持久化数据目录cp-a/volume1/docker/flexget /volume2/backup/cp-a/volume1/peerbanhelper /volume2/backup/重建套件中心停用所有套件防止占用存储管理器删除固态存储池 → 重建存储池、存储空间套件中心重装全部套件ContainerManager、MariaDB10、DDNS-GO、AList、qBittorrent、DownloadStation……恢复把备份的appdata覆盖回原位再按需导入数据套件恢复方式结果DDNS-GO覆盖配置✅ 域名解析恢复AList 网盘data.db config.json✅ 网盘账号都在qBittorrent覆盖配置✅ 种子列表完整MariaDB 10导入 mysql-all.sql✅ 数据库全量恢复Docker 容器按 inspect 信息重建✅ kcptun / shadowsocks / flexget / peerbanhelper 全恢复四、结果所有套件恢复后DSM 控制面板执行更新7.3.2 → 7.3.3 一次成功。反复失败几个月的噩梦结束。项目操作前操作后系统分区 md02.4G两块老盘拖累8GDSM 更新反复失败一次成功五、经验教训DSM 更新失败先查系统分区df -h /dev/md0小于 4G 大概率就是空间不足别先怀疑引导、怀疑版本群晖系统分区是 RAID1容量取最小成员新老盘混用时老盘 2.4G 分区会拖累整个 md0。根治办法是把老盘逐个重建为新标准重分区会清空 SSH 公钥authorized_keys 没了提前备好密码登录方式重分区前必须处理套件套件装在哪块盘重建那块盘套件就全没了。备份三件套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 再说。
返回列表