近来入手的黑群晖安装了DS918+，但有一些问题，具体如下：
1、需要洗白 2、内置16G安装引导的SSD需要隐藏、盘符顺序不对以及CPU信息不对 3、休眠、WOL功能不能用 4、计划开关机无法使用
逛了一些论坛，查了一些资料，有网友提出了一些解决方法，这里总结一下。
申明：
此方法整理自网络，并非原创，
首先应明白洗白是否必要，洗白有两个作用，一是可以使用QuickConnect；二是可以使用Video Station解码。
洗白需要找到正确的`MAC`及`S/N`码，至于其来源有各种途径，一是有算号器；二是利用退换货政策的漏洞。但是有风险，群晖如果发现同一个`MAC/SN`两个同时在线，可能会封号。
如果不使用上述两个功能，可以不洗白。
要修改MAC/SN,需要修改启动配置文件grub.cfg，有两种方法：
1.直接PE启动，然后加载ssd第一个分区就能找到文件
2.SSH在线修改
个人觉得SSH在线修改更方便，具体操作如下：
在控制面板里面—>终端机和SNMP 下，启动SSH功能。
用ssh工具如putty连接到群晖的ip地址，用创建群晖的管理用户登陆。
例如，用户名：admin 密码 123456
输入如下命令：
sudo -i //获取root超级权限 mkdir -p /tmp/boot //在/tmp目录下创建一个临时目录，名字随意，如：boot cd /dev //切换到dev目录 mount -t vfat synoboot1 /tmp/boot/ //将synoboot1 分区挂载到boot cd /tmp/boot/grub //切换到grub目录 vim grub.cfg //修改grub.cfg文件
按键盘上的 i 键（小写状态），进入文档编辑模式，此时就可以输入新的SN，MAC1的新值，删除旧值。修改完成后，
按键盘上的Esc键，返回到命令模式，输入 :wq ，然后回车保存并退出。如果修改乱了，想不保存并退出，则是输入 :q，然后回车。
此时可以再 vi grub.cfg 进去看看是否修改成功。
最后重启主机即可：
reboot
针对问题2，硬盘盘符乱，这款B款蜗牛有两个SATA控制器，有6个SATA接口（包含一个mSATA接口）。处理器控制2个能引导的接口（内存旁边的一个和mSATA ），板载控制器控制4个硬盘架的接口但不能引导。
装好DSM后硬盘顺序应该是处理器控制的两个接口在前（假设为1、2），控制硬盘架上的四个接口在后(假设为3、4、5、6)。所以只要是放在硬盘架上的硬盘在DSM都会标识在3号到6号盘之间。
若需要将硬盘架上的顺序改为1、2、3、4号标识，可以修改引导盘里的grub.conf配置文件来实现。
修改盘序号需要在extra_args_918变量里增加两个值SataPortMap=24和DiskIdxMap=0400。
# /grub/grub.conf # 从第31行开始 ...... set extra_args_918='SataPortMap=24 DiskIdxMap=0400' #将两项加在这后面 set common_args_918='syno_hdd_powerup_seq=0 HddHotplug=0 syno_hw_version=DS918+ vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet syno_port_thaw=1' # for testing on VM set sata_args='SataPortMap=1' ......
修改完成后保存重启，我的硬盘是从左至右放在左边两个盘位中的所以是3号和4号位。
如果盘位顺序还是有误，需要把主板连接的SATA物理更换一下，交换位置就正常了。
简单解释下这两个值：
SataPortMap=24 #配置系统有两个SATA控制器，第一个控制器有2个接口，第二个控制器有4个接口。
SataPortMap： 定义每个控制器可使用的sata接口数量
SataPortMap=4，表示第一个控制器上有4个sata
SataPortMap=24，表示第一个控制器有2个sata，第二个有4个；这符合本矿难的板子，但实际上启动器已经识别对了，所以本次不修改这个参数
DiskIdxMap=0400 #将第一个SATA控制器的接口序号设置为从5开始，第二个SATA控制器的接口号从1开始（04和00都为16进制）。
DiskIdxMap： 定义每个控制器第一个sata接口映射到的索引位置，本段从0
DiskIdxMap=0400，2位16进制一组来看04 代表第一个控制器的sata接口从4开始计数，00代表第二组sata从0开始计数，假设原来 （A，B）（C，D，E，F）的顺序就会变成（C，D，E，F）（A，B）
DiskIdxMap=0F00，同样的（A，B）（C，D，E，F）就变成 （C，D，E，F）（——）（——）（——）（A，B），然而A和B的位置已经超过了最大盘数，这两个盘就不会显示，这就是隐藏内置SSD盘的原理
sata_remap：重新调整每个sata接口的顺序
sata_remap=0>4:4>0，交换第一个和第五个sata接口的顺序，原来A，B，C，D，E的顺序就变成 E，B，C，D，A
直接把启动镜像写入到mSATA盘里面，存储空间管理员里面会有一个14G左右的盘始于未使用状态，就是mSATA盘里除开启动分区后的剩余空间，像下面一样。
可以将其初始化并利用起来，但14G的空间利用起来也没什么价值，且本来自带的SSD就很弱，用来存资料也有一定崩盘的风险。为了防止看着碍眼，可以用上面的方法把这个盘隐藏掉。
还是需要通过修改引导盘里的grub.conf配置文件来实现。
需要在sata_args变量里增加DiskIdxMap=1000这个值，且在启动时选择第三项启动项（VMware/ESXI）启动。
# /grub/grub.conf # 从第31行开始 ...... set extra_args_918='' set common_args_918='syno_hdd_powerup_seq=0 HddHotplug=0 syno_hw_version=DS918+ vender_format_version=2 console=ttyS0,115200n8 withefi elevator=elevator quiet syno_port_thaw=1' # for testing on VM set sata_args='SataPortMap=24 DiskIdxMap=1000'# 将两项加在这后面（10，00都为16进制） ......
2.通过FileStation将下载好的文件上传到DSM上
3.用Putty或者其他SSH工具连接上DSM
4.在SSH工具中操作
# 切换到root账户； sudo -i # 打开ch_cpuinfo.tar文件所在目录； cd /volume1/tmp # 解压ch_cpuinfo.tar文件； tar xvf ch_cpuinfo.tar # 运行ch_cpuinfo文件； ./ch_cpuinfo # 运行后，按“1”选择“First Run”，再按“y”键； # 关闭SSH工具，重新登陆后信息中心显示J1900信息；
这个选项藏得比较深，在 左上角菜单→技术支持中心→左边技术支持服务→启动系统休眠调试模式
保持 NAS 空闲到设定的时间即可。记得把 NAS 的网页和各种客户端都关掉，不然接下来的日志可能会很长没法分析。我自己是在睡觉之前打开日志，起来分析。睡觉的时候除了 NAS 和路由器就没有其他设备开机了，日志很准确。
会产生两份日志，分别是 /var/log/hibernation.log 和 /var/log/hibernationFull.log. 后者是原始数据，前者是去除了一些无价值“连锁性”操作的精简版，但它有的时候会精简过头，所以我这里以后者为例来分析。
首先，将脏块写入磁盘的日志手动排除掉。通常内核不会自发进行大量的磁盘操作，大多数 write block 是用户态 dirty block 导致的结果，因此可以把包含 WRITE block 和 sync 的行删除，节省大量的版面。
其次，将非硬盘的写入排除掉。将包含 on tmpfs 或 on proc 的行删除即可，剩下的非硬盘文件系统肉眼忽略。
剩下的条目可以进入分析了。比如我这里在午睡时每段记录都差不多是这个样子：
[141535.914470] awk(16782): dirtied inode 11177 (libm-2.20-2014.11.so) on md0 [141542.431766] syno_hibernatio(25655): dirtied inode 5885 (hibernationFull.log) on md0 [141542.431778] syno_hibernatio(25655): dirtied inode 5885 (hibernationFull.log) on md0 [141542.431781] syno_hibernatio(25655): dirtied inode 5885 (hibernationFull.log) on md0 [141542.944314] syno_hibernatio(25655): dirtied inode 5348 (hibernation.log) on md0 [141542.944322] syno_hibernatio(25655): dirtied inode 5348 (hibernation.log) on md0 [141542.944324] syno_hibernatio(25655): dirtied inode 5348 (hibernation.log) on md0 [142073.169495] btsync(15253): dirtied inode 11404 (sync.log) on md2 [142073.169512] btsync(15253): dirtied inode 11404 (sync.log) on md2 [142073.169515] btsync(15253): dirtied inode 11404 (sync.log) on md2 [142078.947137] syno_hibernatio(25655): dirtied inode 5885 (hibernationFull.log) on md0 [142078.947150] syno_hibernatio(25655): dirtied inode 5885 (hibernationFull.log) on md0 [142078.947152] syno_hibernatio(25655): dirtied inode 5885 (hibernationFull.log) on md0 uptime : [142078.753468] ======Idle 536 seconds====== Sat Oct 27 14:34:19 CST 2018
进程不多，逐个判断：
btsync：BTSync 套件，sync.log 顾名思义好了。这样看来，它频繁写日志是一个很明显的阻碍休眠的原因。我反正只是装着，没配置它，可以把它删掉。
syno_hibernatio：ps | grep 看一下发现全称是 syno_hibernation_debug，加之操作的文件名，确定是记录休眠日志的工具自身，以后关了就没了
synologrotated：应该是记录系统日志的工具，如果正经休眠了应该就不会有日志了，这也是个被动来源
dhclient 和 dhclient-script：DHCP 客户端常规操作，阻挡不了
那么这一轮下来只能得出需要停止 BTSync 的结论。先这么做了再说。休眠日志可以不急着关掉。
再放一天试试。查看系统日志：
从日志来看，上面的操作是有效的，硬盘终于能进入休眠了，出现了很多“Internal disks woke up from hibernation”。但是这每半小时一条，相当于休眠没几秒又被唤醒了。这还不如不休眠……
于是继续分析休眠日志：
***********Clear********* [236666.547745] syslog-ng(4331): dirtied inode 18 (scemd.log) on md0 [236687.650564] syslog-ng(13085): dirtied inode 18 (scemd.log) on md0 [236687.650585] syslog-ng(13085): dirtied inode 18 (scemd.log) on md0 [236687.650592] syslog-ng(13085): dirtied inode 18 (scemd.log) on md0 [236687.658884] syslog-ng(5016): dirtied inode 28581 (.SYNOSYSDB-shm) on md0 [236687.658893] syslog-ng(5016): dirtied inode 28581 (.SYNOSYSDB-shm) on md0 [236687.658946] syslog-ng(5016): dirtied inode 24584 (.SYNOSYSDB-wal) on md0 [236687.658952] syslog-ng(5016): dirtied inode 24584 (.SYNOSYSDB-wal) on md0 [236687.658954] syslog-ng(5016): dirtied inode 24584 (.SYNOSYSDB-wal) on md0 [236687.664164] logrotate(13090): dirtied inode 41594 (synolog) on md0 [236687.666146] logrotate(13090): dirtied inode 6900 (logrotate.status) on md0 [236687.671082] logrotate(13090): dirtied inode 7905 (logrotate.status.tmp) on md0 [236689.662143] synologaccd(4840): dirtied inode 22952 (.SYNOACCOUNTDB) on md0 [236689.662355] synologaccd(4840): dirtied inode 6900 (.SYNOACCOUNTDB-wal) on md0 [236689.662383] synologaccd(4840): dirtied inode 21526 (.SYNOACCOUNTDB-shm) on md0 [236689.763593] synologaccd(4840): dirtied inode 22952 (.SYNOACCOUNTDB) on md0 [236689.763629] synologaccd(4840): dirtied inode 22952 (.SYNOACCOUNTDB) on md0 [236691.547334] synologrotated(5000): dirtied inode 28581 (.SYNOSYSDB-shm) on md0 [236691.547681] synologrotated(5000): dirtied inode 23485 (.SYNOCONNDB-wal) on md0 [236691.547695] synologrotated(5000): dirtied inode 24677 (.SYNOCONNDB-shm) on md0 [238511.431135] syslog-ng(4331): dirtied inode 18 (scemd.log) on md0 uptime : [238516.475108] ======Idle 1807 seconds====== Wed Oct 24 03:52:06 CST 2018 ##################################################### Only idle 44 seconds, pass Wed Oct 24 03:52:51 CST 2018 ##################################################### ***********Clear********* [238522.209123] synologrotated(5000): dirtied inode 24584 (.SYNOSYSDB-wal) on md0 [238522.209173] synologrotated(5000): dirtied inode 28581 (.SYNOSYSDB-shm) on md0 [238522.210082] synologrotated(5000): dirtied inode 23485 (.SYNOCONNDB-wal) on md0 [238522.210122] synologrotated(5000): dirtied inode 24677 (.SYNOCONNDB-shm) on md0 [238522.224252] logrotate(19321): dirtied inode 41594 (synolog) on md0 [238522.229880] logrotate(19321): dirtied inode 7905 (logrotate.status) on md0 [238522.244528] logrotate(19321): dirtied inode 6900 (logrotate.status.tmp) on md0 [238531.967854] syslog-ng(19324): dirtied inode 18 (scemd.log) on md0 [238531.967874] syslog-ng(19324): dirtied inode 18 (scemd.log) on md0 [238531.967882] syslog-ng(19324): dirtied inode 18 (scemd.log) on md0 [238531.990488] logrotate(19329): dirtied inode 6900 (logrotate.status.tmp) on md0 [238533.979174] synologaccd(4840): dirtied inode 22952 (.SYNOACCOUNTDB) on md0 [238533.979348] synologaccd(4840): dirtied inode 7905 (.SYNOACCOUNTDB-wal) on md0 [238533.979378] synologaccd(4840): dirtied inode 21526 (.SYNOACCOUNTDB-shm) on md0 [238534.076345] synologaccd(4840): dirtied inode 22952 (.SYNOACCOUNTDB) on md0 [238534.076385] synologaccd(4840): dirtied inode 22952 (.SYNOACCOUNTDB) on md0 [240368.320927] syslog-ng(4331): dirtied inode 18 (scemd.log) on md0 uptime : [240374.147000] ======Idle 1811 seconds====== Wed Oct 24 04:23:02 CST 2018
synocrond：听起来像是任务计划程序，里面有个 DSM 自动更新检查，触发频率不高，应该不太影响
builtin-synodat：不知道是什么
logrotate：大概也是个日志程序
synologaccd：继续是日志程序
syslog-ng：我也不知道为什么群晖有那么多日志管理程序
单次日志看不出来什么，但是连着好几块都符合刚一休眠就被唤醒（空闲时间是设定的 30 分钟加十几秒），且最后一条都是对 (/var/log/)scemd.log 的写入。这就有点意思了，打开看看里面是什么：
2018-10-24T07:00:13+08:00 Hamster-DS scemd: led/led_brightness.c:244 Fail to read /usr/sbin/i2cget 2018-10-24T07:00:13+08:00 Hamster-DS scemd: led.c:35 SYNOGetLedBrightness fail() 2018-10-24T07:00:34+08:00 Hamster-DS scemd: event_disk_hibernation_handler.c:42 The internal disks wake up, hibernate from [Oct 24 07:00:11] 2018-10-24T07:31:09+08:00 Hamster-DS scemd: led/led_brightness.c:244 Fail to read /usr/sbin/i2cget 2018-10-24T07:31:09+08:00 Hamster-DS scemd: led.c:35 SYNOGetLedBrightness fail() 2018-10-24T07:31:30+08:00 Hamster-DS scemd: event_disk_hibernation_handler.c:42 The internal disks wake up, hibernate from [Oct 24 07:31:07] 2018-10-24T08:01:53+08:00 Hamster-DS scemd: led/led_brightness.c:244 Fail to read /usr/sbin/i2cget 2018-10-24T08:01:53+08:00 Hamster-DS scemd: led.c:35 SYNOGetLedBrightness fail() 2018-10-24T08:02:14+08:00 Hamster-DS scemd: event_disk_hibernation_handler.c:42 The internal disks wake up, hibernate from [Oct 24 08:01:53] 2018-10-24T08:32:37+08:00 Hamster-DS scemd: led/led_brightness.c:244 Fail to read /usr/sbin/i2cget 2018-10-24T08:32:37+08:00 Hamster-DS scemd: led.c:35 SYNOGetLedBrightness fail() 2018-10-24T08:32:59+08:00 Hamster-DS scemd: event_disk_hibernation_handler.c:42 The internal disks wake up, hibernate from [Oct 24 08:32:37]
清晰地表明了这就是休眠后立即唤醒的原因：由于黑群没有 I2C 设备，于是 DSM 在休眠后尝试更改 LED 亮度（或者颜色、闪烁规律？）时读取 i2c 设备节点就会出错，scemd 把这条错误信息记到自己的日志里，触发了硬盘写入，硬盘就在休眠十几秒后被唤醒了。
根本上修复的话，得硬件上 I2C 适配器，甚至还能顺便给黑群加上白群的那么多灯。但这是不现实的，那么我们就只能采取主流方法：解决提出问题的日志。预想方案是把这个日志文件指向内存，让 scemd 往内存里写，就不会唤醒硬盘了。
找到文件：
vim /etc.defaults/syslog-ng/patterndb.d/scemd.conf
修改
destination d_scemd { file(“/var/log/scemd.log”); };
为
destination d_scemd { file(“/tmp/scemd.log”); };
重启系统即可完美休眠。
原文链接：https://www.ruoyer.com/blackdsm.html?ivk_sa=1024320u
