JackieWu

重装中文语言包，参考：

/tmp/plugins/pluginPending 这个目录会存放 pending 中的插件，你可以删除里面的文件来解决 pending 问题。

我想起我之前也也有遇到关于 RCU 的报错，我那个时候是由于内存造成的，贪便宜买了杂牌内存，用了一段时间后出现了系统不稳定的状况且排查不出来问题，最后发现是内存问题，更换了内存之后就解决了。所以你可以尝试检测一下内存，具体的方法可以参考之前在论坛上的相关帖子：

日志里面有大量且重复的内核报错（但不清楚具体是什么原因）： Feb 20 18:34:03 Tower kernel: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 1-.... } 8672325 jiffies s: 169877 root: 0x2/. Feb 20 18:34:03 Tower kernel: rcu: blocking rcu_node structures (internal RCU debug): Feb 20 18:34:03 Tower kernel: Sending NMI from CPU 0 to CPUs 1: Feb 20 18:34:03 Tower kernel: NMI backtrace for cpu 1 Feb 20 18:34:03 Tower kernel: CPU: 1 PID: 9986 Comm: kworker/u4:4 Tainted: P B W O 6.1.74-Unraid #1 Feb 20 18:34:03 Tower kernel: Hardware name: abit AB-B760-ITX/AB-B760-ITX, BIOS Ver:003 04/18/2023 Feb 20 18:34:03 Tower kernel: Workqueue: writeback wb_workfn (flush-0:42) Feb 20 18:34:03 Tower kernel: RIP: 0010:xa_is_sibling+0x17/0x1e Feb 20 18:34:03 Tower kernel: Code: 94 c0 48 81 ff 00 10 00 00 0f 97 c2 21 d0 c3 cc cc cc cc 48 89 f8 83 e0 03 48 83 f8 02 0f 94 c0 48 81 ff fd 00 00 00 0f 96 c2 <21> d0 c3 cc cc cc cc 40 f6 c7 03 0f 95 c0 48 85 ff 0f 94 c2 09 d0 Feb 20 18:34:03 Tower kernel: RSP: 0018:ffffc90008e079d8 EFLAGS: 00000292 Feb 20 18:34:03 Tower kernel: RAX: 0000000000000001 RBX: 0000000000000228 RCX: 0000000000000004 Feb 20 18:34:03 Tower kernel: RDX: ffff88803f577d00 RSI: 0000000000000004 RDI: ffff88813a8efdaa Feb 20 18:34:03 Tower kernel: RBP: ffff88803f577da8 R08: ffffc90008e07a30 R09: ffffffffffffffff Feb 20 18:34:03 Tower kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff88803f577fd0 Feb 20 18:34:03 Tower kernel: R13: 0000000000000000 R14: ffffc90008e07af8 R15: 000000000000000f Feb 20 18:34:03 Tower kernel: FS: 0000000000000000(0000) GS:ffff88846f700000(0000) knlGS:0000000000000000 Feb 20 18:34:03 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Feb 20 18:34:03 Tower kernel: CR2: 00007fcf37cfa748 CR3: 000000000420a000 CR4: 0000000000752ee0 Feb 20 18:34:03 Tower kernel: PKRU: 55555554 Feb 20 18:34:03 Tower kernel: Call Trace: Feb 20 18:34:03 Tower kernel: <NMI> Feb 20 18:34:03 Tower kernel: ? nmi_cpu_backtrace+0xd3/0x104 Feb 20 18:34:03 Tower kernel: ? nmi_cpu_backtrace_handler+0xd/0x15 Feb 20 18:34:03 Tower kernel: ? nmi_handle+0x54/0x131 Feb 20 18:34:03 Tower kernel: ? xa_is_sibling+0x17/0x1e Feb 20 18:34:03 Tower kernel: ? default_do_nmi+0x66/0x15b Feb 20 18:34:03 Tower kernel: ? exc_nmi+0xbf/0x130 Feb 20 18:34:03 Tower kernel: ? end_repeat_nmi+0x16/0x67 Feb 20 18:34:03 Tower kernel: ? xa_is_sibling+0x17/0x1e Feb 20 18:34:03 Tower kernel: ? xa_is_sibling+0x17/0x1e Feb 20 18:34:03 Tower kernel: ? xa_is_sibling+0x17/0x1e Feb 20 18:34:03 Tower kernel: </NMI> Feb 20 18:34:03 Tower kernel: <TASK> Feb 20 18:34:03 Tower kernel: xas_find_marked+0x113/0x1ed Feb 20 18:34:03 Tower kernel: find_get_entry+0x30/0x85 Feb 20 18:34:03 Tower kernel: find_get_pages_range_tag+0x88/0xee Feb 20 18:34:03 Tower kernel: pagevec_lookup_range_tag+0x24/0x2f Feb 20 18:34:03 Tower kernel: write_cache_pages+0x10d/0x2d9 Feb 20 18:34:03 Tower kernel: ? fuse_writepages+0x114/0x114 Feb 20 18:34:03 Tower kernel: ? slab_post_alloc_hook+0x4d/0x15e Feb 20 18:34:03 Tower kernel: ? fuse_writepages+0x92/0x114 Feb 20 18:34:03 Tower kernel: ? __kmem_cache_alloc_node+0x118/0x147 Feb 20 18:34:03 Tower kernel: ? fuse_writepages+0x92/0x114 Feb 20 18:34:03 Tower kernel: fuse_writepages+0xb1/0x114 Feb 20 18:34:03 Tower kernel: do_writepages+0xb8/0x124 Feb 20 18:34:03 Tower kernel: __writeback_single_inode+0x7a/0x2cb Feb 20 18:34:03 Tower kernel: writeback_sb_inodes+0x24f/0x40f Feb 20 18:34:03 Tower kernel: __writeback_inodes_wb+0x82/0xc0 Feb 20 18:34:03 Tower kernel: wb_writeback+0x135/0x24a Feb 20 18:34:03 Tower kernel: wb_workfn+0x25a/0x39e Feb 20 18:34:03 Tower kernel: ? check_preempt_curr+0x49/0x5a Feb 20 18:34:03 Tower kernel: ? ttwu_do_wakeup+0x24/0xf2 Feb 20 18:34:03 Tower kernel: process_one_work+0x1a8/0x295 Feb 20 18:34:03 Tower kernel: worker_thread+0x18b/0x244 Feb 20 18:34:03 Tower kernel: ? rescuer_thread+0x281/0x281 Feb 20 18:34:03 Tower kernel: kthread+0xe4/0xef Feb 20 18:34:03 Tower kernel: ? kthread_complete_and_exit+0x1b/0x1b Feb 20 18:34:03 Tower kernel: ret_from_fork+0x1f/0x30 Feb 20 18:34:03 Tower kernel: </TASK> 另外还有大量关于 macvlan 的报错信息，建议你可以先解决 macvlan 的问题，参考：

不确定是不是由于 BIOS 的问题，你可以尝试在 BIOS 中将网卡的 Option ROM 启动策略修改为 Legacy（传统），： 另外还可以尝试更换 Unraid 的版本进行尝试。

个人建议还是修改网关的形式去让 Unraid 使用代理，把网关修改为 openwrt 或者是其他透明代理网关。

请上传诊断信息资料，需要更多的信息才好判断是什么问题，方法参考：

请具体描述一下你遇到的问题。 另外建议不要将 Unraid 暴露到公网上面，很容易被爆破。

你可以尝试在 APPS 里面搜索 Nuvoton NCT6687 Driver 插件进行安装，看看能不能解决你的问题。 另外你还可以在内核启动参数中添加下面的参数（应用之后重启 Unraid）： acpi_enforce_resources=lax

这个是新版本下面的 IPV6 绑定不正确问题，你可以参考这里：

这个只是 docker-compose 插件的显示问题，根据开发者描述，由 docker-compose 所创建出来的容器，它们的“应用更新”状态提示并不集成到 DockerMan 的 UI 中（也就是 Docker 原本的管理界面），所以会一直提示你镜像可以进行更新： 另外我看到某些网友表示可以通过修改一些配置文件来解决一直提示更新的问题，但是我没有试过，你可以参考这里的资料去了解看看：

参考：

6.12.8 是正式版，你在这个版本上面无法安装应用商店吗？一般无法安装的原因基本都是网络问题，建议你可以给 unraid 挂代理来进行安装。 或者你也可以使用下面的命令手动安装应用商店（不是最新的）： https://gitee.com/jackiewuu/unraid/raw/master/plugins/community.applications/2023.09.30/community.applications.plg 参考资料：常用插件下载（国内镜像手动安装）

Thanks for sharing ! @yin1217168205 你可以参考上面 ich777 的资料去了解一下，我自己没试过使用脚本去控制风扇（也没研究），因为我设备上的风扇无法使用 autofan 插件进行控制（插件比较老了，所以不支持也是正常的），所以我都是通过主板 BIOS 去设置风扇转速来根据温度进行自动调整。

有接上显示器吗，如果可以接显示器先接上显示器看看有没有什么报错信息。 如果无法接上显示器，能不能 SSH 登录到系统内部，如果可以登录上去，在命令行界面输入 diagnostics 命令生成诊断信息压缩包，这个压缩包会存放到 U 盘，你可以把诊断包上传上来。 如果以上方法都无法实现，那么你可以尝试重新安装一下系统，因为如果在系统升级之后出现系统问题，那么有可能是由于系统文件损坏了，你可以参考这篇文章的内容来进行处理以及了解相关的原理：常见问题-3：如何安装/重装/更换unRAID系统（附安装包下载地址）。

你是指左上角那个版本号标识吗？

是支持的，但我没有尝试过，你可以尝试通过下面的这个帖子去参考如何添加： 应该是会有的，目前 6.12 整个版本下来都没有比较完整的 ZFS WebUI 操作界面，因为一开始 6.12 出来的时候开发团队就说了会分两个大版本来一点点去完整 ZFS 的功能，所以不出意外的话 6.13 版本就会有更完善的 ZFS 用户操作界面了。 不能。你可以参考这里的一篇文章来了解：ZFS是否该启用ZIL和L2ARC

谢谢反馈，这对后面遇到相同问题的朋友会有帮助。

命令语法也是一样没有设置正确，如果镜像源用不了那就删掉吧。 # Docker Mirror mkdir -p /etc/docker tee /etc/docker/daemon.json <<- 'EOF' { "registry-mirrors" : ["https://hub-mirror.c.163.com","https://docker.mirrors.ustc.edu.cn"] } EOF 你可以注册一个阿里云账号，阿里云提供镜像加速：

跟系统版本没关系，那你可以尝试使用下面的命令创建一个，命令执行完成之后重启一下 Unraid 。 注意，请你先备份一下 Unraid 系统文件： 执行以下命令手动生成 network-rules.cfg 文件，里面的参数我已经修改成对应你网卡参数的配置了（如果成功了，那么 eth0 对应的就是你的 PCIE 网卡，板载网卡对应 eth1 ，你需要接上 PCIE 网卡的网线之后才能进入 UNRAID ）： tee /boot/config/network-rules.cfg <<- EOF > # PCI device 0x10ec:8125 (r8125) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="22:25:6c:08:03:21", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" # PCI device 0x10ec:8125 (r8125) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:4c:68:84:54", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" > EOF 如果说这么做之后进不去系统，你可以将 U 盘插上你的电脑，然后删除 U 盘 config 文件夹内的 network-rules.cfg 文件，然后再插上设备开机。

需要给官方发邮件，具体细节参考：

我估计是由于你的板载网卡和 PICE 网卡的设备 ID 相同导致的，Unraid 因此无法正常指定 eth0 （或其他 ethX）所对应的网卡。 你可以在下面的图片里面看到板载网卡和 PCIE 网卡的设备 ID （10ec:8125）以及其他的信息都是一样的（除了 PCIE BUS 地址）： 你需要将你的 network-rules.cfg 内容贴上来（使用下面的命令将输出信息复制粘贴上来），我帮你尝试手动修改来解决： cat /boot/config/network-rules.cfg

你的 /etc/docker/daemon.json 文件没有配置正确，建议你先删掉原有的 daemon.json 看看能不能启动（你可以通过下面的命令删除，删除之后重启一下 docker 服务），如果可以那就是这里的问题了。 rm /etc/docker/daemon.json 另外你需要修改一下 go 文件里面的命令：

你的观点我都了解了，我保留我的观点，其他的不多做评价了。 另外虽然你用了“可能”，但请不要假设一个我的观点然后基于这个观点来阐述你的观点，我没有表达过这个想法。

调整网络设置里面的“接口规则”就行：