首先感谢老骥伏枥大侠的文章，通过认真学习，基本上明白了黑群晖6.1以上使用GRUB2，脱离U盘，由硬盘引导黑群晖，我使用和后续文字介绍均是老骥伏枥大侠原始版本：ds3617xs_v612b，见帖子：http://www.nasyun.com/forum.php?mod=viewthread&tid=31655

最终几天折腾下来，发现这个版本建立的硬盘引导只能最高到3617DX-617-15284，但是我的黑群晖版本已经是3617_6.2_103B引导3617-622-24922了；我就得尝试让它引导622-24922的系统里！

建立引导的过程就不详细说明了，参考老骥伏枥大侠的文章，简单操作为：

1、首先将黑群安装好3617-617-15284，U盘引导并能够正常使用；

2、在硬盘上建立共享文件夹boot，然后将老骥伏枥大侠提供的ds3617xs_v612b解压后，上传到boot中，并ssh到root，执行写硬盘操作（具体请阅老骥伏枥大侠的文章）；

3、由于老骥伏枥大侠提供的ds3617xs_v612b是61-15047的，不能引导617-15284，所以就他介绍的方法，取下黑群晖里面打算做引导的硬盘（我使用的是2.5寸的sdd）使用硬盘盒子通过USB插到PC机上，打开DiskGuines，可以看见“本地磁盘E”上的boot文件夹和grud.cfg文件了；

4、删除硬盘boot/grud里面的zImage、 rd.gz、 extra.lzma三个文件，将启动U盘里面的三个文件替换进去，再修改boot/grud.cfg中关于sn和mac后，将硬盘插回到黑群中，重启黑群，可以看见已经不需要U盘，而直接是硬盘引导里，版本为3617DX-617-15284，简直爽歪歪！

（用目标版本的文件替换掉图中红勾的文件）

但是：

以上是我用一块单独的硬盘测试的情况，一切正常；

现在我正常使用的黑群系统已经升级到了 3617-622-24922，有许多的配置和应用不想重新安装，所以我再继续用单独的硬盘测试；

首先安装3617-622-24922并能够通过U盘启动，正常使用后，再用3617-622-24922引导U盘里面的三个文件替换黑群晖启动硬盘里面的三个文件，启动黑群，系统的提示不是久违的“就绪”，而是提示系统可还原。

，尝试重新安装对应的pat文件包，但是不管后续怎么操作，重新安装pat文件，大约到进度60%左右会提示文件损坏（12）或者（13），都不能正常进黑群了。

疑问：

琢磨里很久也没有找到办法，按照逻辑操作方法是正确里，老骥伏枥大侠提供的思路应该是正确的，替换boot里面的三个文件，大侠提供的ds3617xs_v612b应该是使用Jun’s 的3617-102B的制作的，我替换成103B的引导zImage，应该也没有问题呀，难道620以上版本的群晖系统又有其他的变化？

文件vmlinuz等是关键文件，也存在版本的区别？难道需要替换成622的？

跟我发的帖子问题 需求是一样的 目前没找到问题在哪，等大神的回答呢~！

askyanan 发表于 2020-1-13 17:02
跟我发的帖子问题 需求是一样的 目前没找到问题在哪，等大神的回答呢~！

本来我也是3617-617用的好好的，手贱，升级到了622-24922，貌似也没有多大的改变，还感觉617的局域网速度更快一些！

askyanan 发表于 2020-1-13 17:02
跟我发的帖子问题 需求是一样的 目前没找到问题在哪，等大神的回答呢~！

今天研究了下Jun的103B版本，它包含的群晖启动文件应该最低为62-23739版本，老骥伏枥大侠的使用的102B貌似不支持，另外，我尝试替换boot/grup/i386-pc下的core.img等文件后，系统不能正常启动，我感觉估计是这里的原因！

aepub88 发表于 2020-1-13 20:30
今天研究了下Jun的103B版本，它包含的群晖启动文件应该最低为62-23739版本，老骥伏枥大侠的使用的102B貌 ...

主要是不太懂 文件结构等只能用替换法试试了 ，你找到解决办法了嘛，搞定的话麻烦跟我也说下方法哈

也同样测试了6.2.2、不能正常引导进入系统、显示可转移

17558760 发表于 2020-1-14 17:36
也同样测试了6.2.2、不能正常引导进入系统、显示可转移

不想折腾了，把黑群降级换成了617-15284，但是出现使用U盘已经洗白，硬盘启动洗白失效的情况，登陆QC提示错误！

最近翻看了xpenology论坛的帖子，感觉可能基本无解了！
原帖地址https://xpenology.com/forum/topic/9392-general-faq/
大概翻译后是这样的！
11-为什么最新版本的DSM（6.2.x）会出现所有问题，以及可以使用哪些选项来缓解这些问题？

Jun的加载程序试图愚弄Synology代码，以为用户硬件实际上是Synology的平台硬件。除Jun以外，大多数人都无法从技术上实现这一目标，但是无论其工作方式如何，它都会对DSM运行时环境产生影响。有些问题是无害的（系统日志中的虚假错误，无法利用CPU加速和休眠等硬件功能等），但其他问题则可能导致不稳定，驱动程序和内核崩溃。

到目前为止，最稳定的组合（即与最大数量的硬件兼容）是Jun的加载程序1.02b和DSM6.1.x。 Jun表示1.02b的目标平台是DS3615，并且DS3617足够兼容以使用相同的加载程序。但是，某些硬件组合上的DS3617会导致内核崩溃。否则，DS3615和DS3617在功能上没有区别，因此建议使用DS3615。

DSM 6.2引入了更严格的新Synology硬件检查，Jun提出了另一种绕过它们的方法。虽然加载程序确实可以在最佳硬件上工作，但在许多系统上  ，6.2加载程序通常会导致内核可加载模块崩溃和内核崩溃。许多人还注意到，与以前的版本相比，磁盘I / O性能明显较差。



已经对DSM的嵌入式NIC驱动程序进行了盘点和记录，但由于1.03b加载程序使DSM 6.2.1及更高版本上的少数几个驱动程序崩溃，因此该目录中的大部分都没有用。而且，使用新硬件的用户经常会发现很少的功能网络驱动程序不支持其板载芯片的最新版本。同样，1.04b加载程序明确添加了对英特尔图形（i915）驱动程序的支持，但是升级到6.2.2会使它在某些英特尔图形硬件修订版（例如Apollo Lake J系列系统）上崩溃。 大量论坛帖子可以归因于寻求安装DSM 6.2.x并遇到这两个重要问题之一的用户。

ESXi或其他虚拟化平台可能是减轻XPEnology和DSM 6.2.x上硬件支持限制的最佳策略。如果您的目标是部署最新的DSM版本并与Synology补丁保持同步，则明智地建议您此时不要部署裸机XPEnology安装。不幸的是，这对于希望使用裸机解决方案在DSM中启用硬件加速视频编码支持的人来说是一个障碍。
应当指出，许多XPEnology超级用户，论坛管理员和开发人员继续将ESXi，Jun 1.02b和DS3615 DSM 6.1.7的强大组合用于关键任务工作，并且无意进行升级。就是说，一旦系统正常运行，就没有太多理由保持最新状态。DSM 7.0迫在眉睫，并且实际上可以保证当前的装载机无法与其一起使用。而且，每个新的6.2点版本都客观地带来了新的兼容性问题和崩溃，几乎没有或根本没有功能/增量优势。

aepub88 发表于 2020-1-15 22:23
最近翻看了xpenology论坛的帖子，感觉可能基本无解了！
原帖地址https://xpenology.com/forum/topic/9392- ...

参考了老骥伏枥的文章：ISO启动盘导入群晖的pat包出错(13)停止安装的解决办法
http://www.nasyun.com/thread-32092-1-1.html
对于引导3617-622的安装无效！

3615/17的6.22引导是新的启动引导方式，文件识别没那么简单。二合一的6.22,3615版本我早就做了，只是我没有放出来，在我的群里面，有兴趣你可以进群去下载下来研究