群晖深度优化设置-理顺盘序、休眠等

发表 admin at 2021年12月7日

类别

标签

2、内置16G安装引导的SSD需要隐藏、盘符顺序不对以及CPU信息不对3、休眠、WOL功能不能用4、计划开关机无法使用

（二）硬盘显示

针对问题2，硬盘盘符乱，这款B款蜗牛有两个SATA控制器，有6个SATA接口（包含一个mSATA接口）。处理器控制2个能引导的接口（内存旁边的一个和mSATA ），板载控制器控制4个硬盘架的接口但不能引导。

1、硬盘位的顺序

装好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 VMset sata_args='SataPortMap=1'......

修改完成后保存重启，我的硬盘是从左至右放在左边两个盘位中的所以是3号和4号位。
如果盘位顺序还是有误，需要把主板连接的SATA物理更换一下，交换位置就正常了。

简单解释下这两个值：

SataPortMap=24#配置系统有两个SATA控制器，第一个控制器有2个接口，第二个控制器有4个接口。

SataPortMap：定义每个控制器可使用的sata接口数量

SataPortMap=4，表示第一个控制器上有4个sata

SataPortMap=24，表示第一个控制器有2个sata，第二个有4个；这符合本矿难的板子，但实际上启动器已经识别对了，所以本次不修改这个参数

SataPortMap=NW，依此类推，没个控制器有N，W个sata，适合本身主板内置N个sata，然后通过PCIE扩出来W个sata的情况

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

2、用SSD引导后隐藏启动盘

直接把启动镜像写入到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 VMset sata_args='SataPortMap=24 DiskIdxMap=1000'# 将两项加在这后面（10，00都为16进制）......

3、信息中心显示的处理器的型号

装好DSM系统以后，信息中心显示的是白群晖机器的处理器信息，比如DS3617系统就显示的是Xeon D处理器的信息，很明显是直接写死的，强迫症患者看上去很不爽。

蜗牛用的是J1900的处理器就老老实实显示J1900的信息就好了。翻了下xpenolgy论坛，这位网友已经给出解决方案了，这里搬运一下，原文可以看这里。

1.下载ch_cpuinfo_en.tar在电脑上，【这里下载】

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信息；

（三）休眠

1、打开休眠调试日志

这个选项藏得比较深，在左上角菜单→技术支持中心→左边技术支持服务→启动系统休眠调试模式

2、等待触发休眠问题

保持 NAS 空闲到设定的时间即可。记得把 NAS 的网页和各种客户端都关掉，不然接下来的日志可能会很长没法分析。我自己是在睡觉之前打开日志，起来分析。睡觉的时候除了 NAS 和路由器就没有其他设备开机了，日志很准确。

3、分析日志

会产生两份日志，分别是 /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 md0uptime : [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 md0uptime : [238516.475108]======Idle 1807 seconds======Wed Oct 24 03:52:06 CST 2018#####################################################Only idle 44 seconds, passWed 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 md0uptime : [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/i2cget2018-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/i2cget2018-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/i2cget2018-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/i2cget2018-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 把这条错误信息记到自己的日志里，触发了硬盘写入，硬盘就在休眠十几秒后被唤醒了。

4、修复

根本上修复的话，得硬件上 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"); };

重启系统即可完美休眠。

当 GRUB 屏幕出现时，您可以按 e 键来编辑命令。
在 syno_port_thaw=1 之后
添加 DiskIdxMap=00 SataPortMap=1 SasIdxMap=0
然后按F10启动
即可完美解决

按照@jhoughten的介绍，

The command line changes are not saved when you reboot, so you may want to make them permanent and rebuild the image file once everything is working.
The initial reboot after installing DSM did not require them, so, I have not done that yet.

本文所有的经验总结自：
https://gugucomputing.wordpress.com/2018/11/11/experiment-on-sata_args-in-grub-cfg/
这篇文章里面有各种参数组合的一个测试结果，这里就不一一测试了。可以自己去看。
前提概要总结：
PS1：群辉系统默认一个控制器只能有9个接口，这里意味着你填写SataPortMap=A的时候，A的范围是在：0-9，0则默认屏蔽这个控制器。
（注：无法通过设为0来隐藏引导加载分区所在磁盘，会导致直接该磁盘不识别，群辉系统无法正常加载，隐藏引导分区所在磁盘只能通过修改DiskIdxMap，让引导磁盘所在的盘序超过当前最大磁盘数，即可实现隐藏(原理：系统无法显示大于磁盘数的磁盘)）
PS2：SataPortMap=ABCD,后面的数值定义，ABCD表示4个控制器；
SataPortMap=4234，表明第一个控制器有4个接口，第二个有2个，第三个有3个，第四个有4个。这里具体的控制器数量限制未知，经测试4个控制器X9的接口，36个盘还是可以认的到的
(注：需配合系统硬盘数修改，不然识别了不显示可参考群教程：04、群辉各种教程-----黑裙获取root权限及硬盘数量更改教程.docx)
PS3：DiskIdxMap=09070400 这个参数项，2位数为一个控制器的盘序表示，这两位数为16进制数，超过9的，ABCDEF前面还需要加个0，不可忽略。
这里的09070400的意思是，第一个控制器的盘序从9开始往后排，第二个驱动器位7-8，第三个驱动器为4-6，第一个驱动器为0-3。
这里有个小技巧，可以将控制器的盘序设置超过当前最大磁盘数量，例如一共有20个盘，你盘序设置成15(十进制21)，这个盘系统里面就看不到。
注：默认的纯引导分区磁盘，如U盘，VM,esxi挂载的单独的引导盘，无数据存储分区的，群辉系统内默认是不显示的，即不显示在磁盘列表里面。只有那种不全是引导分区，即像二合一系统一样，同SSD上有引导分区和数据分区的这种，群辉系统里面才能认的出来。但是实际是占用了控制器接口数的。
教程
首先你需要修改img引导文件中第一个分区文件中的gruf.cfg
找到gruf.cfg文件中的：
set extra_args_3617= （DS918中会是set extra_args_918=）
set sata_args=
如何修改，修改的要点
首先，你要先确定自身的一个需求：
自己一共需要多少个盘，自己有多少个控制器。主板默认sata控制器有几个口。扩展的sata控制器有几个，每个分别是几个口。
举例：
主板：华擎Z370M itx/ac 主板自带6口sata
扩展卡：JMB585 M2转5口sata （用M2主板BIOS默认屏蔽sata_0，但是群辉默认检测的是sata控制器的口数所以sata_0还是能检测到的，所以后续还需要做相应的一个盘序调整。）
需求：我一共需要11个盘，并保证JMB585的盘序靠前，主板的靠后。
这里一共2个控制器，所以：
SataPortMap=65
这里的数值为十进制。数值范围0-9，0为屏蔽该控制器，最大数值9表明一个控制器最多用9个sata口挂载设备。
其中首位群辉默认标识的主板sata控制器，这里的6标识该控制器一共有6个sata口，第二位为第二个控制器即JMB585扩展卡，这里的5标识该控制器一共有5个sata口。
DiskIdxMap=0500
这里的数值为十六进制，2位数标识一个sata控制器的盘序排列。
其中00标识第二个控制器即jmb585的盘序从00开始，到04，00-04对应系统中的1-5，群辉系统默认控制器的盘序检测是从0开始，但是系统内的硬盘排序是从1开始。
其中05标识主板控制器盘序从05开始，05以后直到10都是主板控制器的盘，对应系统中的6-11。
Sata_remap=05>10:10>05
这里的数值是十六进制，前面提到主板使用M2会屏蔽掉sata_0接口，所以为了让系统内盘序看着更加连贯一下，而不是出现第6个为空的情况。这里的05>10:10>05表示05和10的盘序进行调换，即主板控制器的sata_0口检测盘序为10，对应系统中的11位；原来的盘序10检测为盘序5，系统内识别第6位。这样系统内盘序就看着顺眼多了，不至于出现中间空出一格的情况。
SasIdxMap=0
这个参数的目的是让硬盘处于正确的排序，默认加上就行了。
正确的参数修改填写应该如下：
set extra_args_3617='SasIdxMap=0 DiskIdxMap=0500 SataPortMap=65 sata_remap=05>10:10>05'
set sata_args=' SasIdxMap=0 DiskIdxMap=0500 SataPortMap=65 sata_remap=05>10:10>05'
注意：DS3617中set sata_args='’默认还多了3个参数项：（DS918+中无这三项）
sata_uid=1
sata_pcislot=5
synoboot_satadom=1
如不删除这三个删除项，会导致盘序无法正常工作。经过测试全删和单独保留第一个或第二个参数项能正常工作，单独添加第三个参数项，系统失联。更多的信息未知，你也可以执行研究。
最后将修改好的gruf.cfg直接替换引导盘中的gruf.cfg，然后拿去装系统即可。
总结
该方法适用于VM、esxi、pve等虚拟机和实体物理机
需要注意的，虚拟机在分配磁盘的时候应当选择sata控制器。并保证每个控制器的sata的口数不能超过9（引导盘(以现有硬盘模式挂在的磁盘)默认不算进盘序，系统内不显示，但是会占用sata控制器一个接口）。
从6.2.3开始，黑群辉DS918+、DS3617对阵列卡的驱动支持开始变得不是那么完美。
经过测试LSI9207 在DS918+中使用extra.lzma版本v13.3 无法看到smart；使用v12.1,能看到smart但是无法正常休眠启动，容易造成硬盘掉盘，为正常启动出现数据丢失，严重的会导致硬盘出现物理坏道。
DS3617中 LSI6207直接无法识别到硬盘。
在此Xpenology的管理员,extra.lzma第三方编译的作者IG-88建议，请大家采用sata控制器扩展卡，例如jmb585，尽量不要使用mtp2-sas mtp3-sas驱动的阵列直通卡。

启动参数说明（可以不看）

参考此处网址

SataPortMap：定义每个控制器可使用的sata接口数量

SataPortMap=4，表示第一个控制器上有4个sata
SataPortMap=24，表示第一个控制器有2个sata，第二个有4个；这符合本矿难的板子，但实际上启动器已经识别对了，所以本次不修改这个参数
SataPortMap=NW，依此类推，没个控制器有N，W个sata，适合本身主板内置N个sata，然后通过PCIE扩出来W个sata的情况

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

这是我在各处扒下的留存资料，要根据主板的实际情况去处理！不知你是新装还是旧系统升级
如果新装很简单啊u盘引导，只挂一块硬盘
在 syno_port_thaw=1 之后
添加 DiskIdxMap=00 SataPortMap=1 SasIdxMap=0直接安装，装完进系统后关机，把U盘引导添加的删除，挂其它硬盘进系统！会提示你发现新硬盘然后你慢慢配置即可。
如果是升级，我就是6.23升级的板载6sata用了4个raid5+乐扩4sata也是raid5，共计8盘位，我就是拔掉扩展卡，u盘添加 DiskIdxMap=00 SataPortMap=1 SasIdxMap=0，引导提示可迁移安装过程中选设置套件一并迁移，装完后不要做任何设置关机，改引导，插扩展卡，开机会有提示前四个盘中三个有问题直接修复就可，扩展卡挂的四个好像是在其它位置上有题示好像都是在存储管理里面也可以修复（这个时间有点长）修复完成后会提示套件出错，也是套件中心修复，不能修复的就卸载再装一下!

发表回复取消回复

要发表评论，您必须先登录。