俗话说常在河边走，哪有不湿鞋。放公司的两台群晖周末说有一台重启后连不上，被迫加班来搞，没想到最后是降级DSM救数据这样的结局。
其实怎么降级DSM 很简单，有很多文章，我用的方法大概就是，PE进去，格式化掉每个硬盘前两个小分区，每个大概4G，然后重新安装低版本系统。这样操作全部的设定是没了，但数据都在。在着急的环境下最直接最迅速的解决方案。
那为什么走到了降级呢…… 诶这说来话长：
- 故障原因，重启后卡在BIOS，没有引导进入loader，自然搜不到连不上。排除这个故障重启后以为解决了，可惜还是搜不到。。
- 想着是不是引导分区有问题，把硬盘拆到只剩一块，加载loader，还是搜不到。
- 当初安装的DSM 6.2 beta不爽很久了，干脆降级到6.1.7的稳定版本算了。拿出各种工具，一阵改PID VID，烧录启动盘猛如虎。然后进reinstall后。。。。还是搜不到。
- 想起来改grub.cfg文件的时候，MAC和序列号保持了默认没改，虽然当时也没改，但一直搜来搜去有点问题。会不会是冲突的问题？毕竟局域网里两台群晖的序列号和mac都是一样的，但安装的时候分别安装再启动的，IP直连肯定不影响，但find.synology.com和群晖助手可就不一定了。
- 搜索了下，果然提到序列号一样没啥，但mac不能一样会冲突。好吧当年自己作下的死。
- 再次重做loader u盘，插了一块最不重要的硬盘进去reinstall，成功搜索到并安装上DSM 6.1.7
- 按别人重做的经验，其他几块盘只要塞进去重启就行了。照做了，尼玛 又启动不了了！
- 这个时候由于反复重启搜索等待，已经Debug到2小时了。干脆五块硬盘一起格式化掉前两个分区，一起塞进去reinstall，不成功便成仁！！
- 然而这次还是一样根本没法搜索到并reinstall。痛定思痛，排查问题。
- 搜索到一篇文章说，如果高版本的群晖系统用低版本的loader去启动，不但会造成没法引导，还会导致loader本身被修改，需要重新烧录。确认是此问题。因为临时盘盘位在8，1-4插入的都是之前没格式化掉分区的老数据盘。在7那一步其实优先加载了1号盘位的DSM 6.2的引导扇区，导致无法启动并污染了loader。
- 再次PE确认分区干净后，重做loader，再次引导，这次塞入了1-4号重要数据盘。还好一次引导成功，并正常安装了DSM 6.1.7系统（finally
- 进入系统后，所有共享文件夹都在，权限依旧，但各类配置 计划任务 Docker 套件都丢了。
TLDR时间：
- 群晖loader启动时候有可能识别不到\卡在选择界面\根本没进入loader，所以一块方便的便携debug屏幕还是必要的。
- 内网有两台以上群晖记得修改PID VID同时，MAC和序列号也要改成不一致。
- loader安装流程是u盘启动后直接准备响应find.synology.com，但loader启动流程是会调用第一块正常群晖硬盘的引导扇区，故如果降级过程中，至少要保持一号盘是空扇区或者降级后的对应系统。
- 高版本的DSM引导扇区不但无法启动，还会修改loader本身，导致再起不能，必须重新刷写。
感觉我这次直接把群晖安装能踩的坑踩了个全，那么就这样。
Fin.
