ATT&CK红队评估实战靶场二

最近在两台 Dell PowerEdge R730xd 上遇到同一个问题：

- PERC H730 Mini 工作正常
- 物理硬盘状态正常
- iDRAC Web 无法正常创建 RAID
- 使用 RACADM 可以成功创建 RAID
- Job Queue 中存在 `SYS044`
- Web 侧会出现 `STOR026`、`LC062`

本文记录完整排查过程。

> 如果只想直接解决问题：
>
> [直接跳转到解决方案](#solution)

---

## 1. 问题现象

在 iDRAC Web 页面创建虚拟磁盘时，会出现：

```text
STOR026: 无法创建配置作业，因为该设备没有挂起的配置更改。
```

有时还会出现：

```text
LC062: 导出或导入服务器配置文件操作已在运行。
```

但通过 SSH 登录 iDRAC 后，使用 RACADM 可以正常创建 RAID。

这说明问题不在 RAID 功能本身，而更可能出现在：

```text
iDRAC Web
    ↓
Lifecycle Controller
    ↓
Pending Configuration
    ↓
Configuration Job
    ↓
PERC
```

---

## 2. SSH 登录 iDRAC

直接 SSH 登录 iDRAC：

```bash
ssh root@192.168.1.245
```

登录后进入 RACADM Shell：

```text
/admin1->
```

查看物理硬盘：

```bash
racadm storage get pdisks
```

得到：

```text
Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1
Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1
Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1
Disk.Bay.3:Enclosure.Internal.0-1:RAID.Integrated.1-1
Disk.Bay.12:Enclosure.Internal.0-1:RAID.Integrated.1-1
```

本次计划使用：

```text
Bay 0
Bay 1
Bay 2
Bay 3
```

四块盘创建 RAID6。

---

## 3. 查看当前虚拟磁盘

执行：

```bash
racadm storage get vdisks
```

异常情况下可能直接出现：

```text
ERROR: STOR0104 : No virtual disks are displayed.
Check if the server has power, physical disks are available, and virtual
disks are created.
```

如果本身还没有创建任何 Virtual Disk，这个提示不一定表示 PERC 故障。

---

## 4. 使用 RACADM 创建 RAID6

既然 Web 无法正常完成配置，可以直接使用 RACADM 创建 RAID。

完整命令：

```bash
racadm storage createvd:RAID.Integrated.1-1 -rl r6 -ss 256k -wp wb -rp ra -pdkey:Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.3:Enclosure.Internal.0-1:RAID.Integrated.1-1 -name RAID6_0_3
```

参数说明：

```text
-rl r6        RAID6
-ss 256k      Stripe Size 256KB
-wp wb        Write Back
-rp ra        Read Ahead
-pdkey        指定参与阵列的物理硬盘
-name         Virtual Disk 名称
```

执行后成功：

```text
STOR094 : The storage configuration operation is successfully completed
and the change is in pending state.

To apply the configuration operation immediately, create a configuration job
using the --realtime option.
```

这说明：

> PERC 已经接受 RAID6 配置，阵列卡本身可以正常工作。

此时配置只是处于 Pending 状态，还需要提交。

---

## 5. 提交 Pending RAID 配置

执行：

```bash
racadm jobqueue create RAID.Integrated.1-1 --realtime
```

返回：

```text
RAC1024: Successfully scheduled a job.
Verify the job status using "racadm jobqueue view -i JID_xxxxx" command.

Commit JID = JID_895745421911
```

查看任务：

```bash
racadm jobqueue view
```

可以看到：

```text
[Job ID=JID_895745421911]

Job Name=Configure: RAID.Integrated.1-1
Status=Running
Start Time=[Now]
Expiration Time=[Not Applicable]
Message=[PR20: Job in progress.]
Percent Complete=[1]
```

等待任务完成后应变成：

```text
Status=Completed
Message=[PR19: Job completed successfully.]
Percent Complete=[100]
```

至此 RAID6 创建完成。

---

## 6. 发现 Export System Configuration 异常

在查看 Job Queue 时，还发现一个关键异常：

```text
[Job ID=JID_290143924436]

Job Name=Export: System configuration XML file
Status=Failed
Start Time=[Not Applicable]
Expiration Time=[Not Applicable]
Message=[SYS044: Unable to export one or more component configurations.]
Percent Complete=[100]
```

也就是说：

```text
Export System Configuration
        ↓
      Failed
        ↓
     SYS044
```

但 iDRAC Web 有时却提示：

```text
LC062:
导出或导入服务器配置文件操作已在运行
```

这里存在明显的状态不一致：

```text
Job Queue：
Export Job 已经 Failed

Web / Lifecycle Controller：
仍然认为 Export / Import 操作正在进行
```

这说明 Lifecycle Controller 内部可能存在状态残留，或者 Web 与 LC 的状态没有完全同步。

---

## 7. 查看 Lifecycle Controller 状态

执行：

```bash
racadm get LifecycleController.LCAttributes
```

得到：

```text
AutoBackup=Disabled
#AutoDiscovery=Off
AutoUpdate=Enabled
BIOSRTDRequested=False
CollectSystemInventoryOnRestart=Enabled
#DiscoveryFactoryDefaults=Off
IPChangeNotifyPS=Off
#Licensed=Yes
LifecycleControllerState=Enabled
PartConfigurationUpdate=Apply always
PartFirmwareUpdate=Match firmware of replaced part
ProvisioningServer=
#SystemID=627
VirtualAddressManagementApplication=
```

关键参数：

```text
CollectSystemInventoryOnRestart=Enabled
LifecycleControllerState=Enabled
```

说明：

- Lifecycle Controller 已启用
- CSIOR 已启用
- 问题并不是 Lifecycle Controller 被关闭导致的

---

## 8. 查看 iDRAC 和 Lifecycle Controller 版本

执行：

```bash
racadm getversion
```

结果：

```text
Bios Version                     = 2.13.0

iDRAC Version                    = 2.21.21.21

Lifecycle Controller Version     = 2.21.21.21
```

这里可以确认：

```text
iDRAC / LC = 2.21.21.21
```

版本非常老。

而这台机器上的 PERC H730 Mini 固件明显更新得多。

---

## 9. Lifecycle Log 显示阵列卡被更换过

查看日志：

```bash
racadm lclog view
```

需要注意，iDRAC 自带 RACADM Shell 不是标准 Linux Shell，类似下面这种写法不能直接使用：

```bash
racadm lclog view | grep RAID
```

会报：

```text
ERROR: The syntax of the command specified is not correct.
```

因此只能直接读取完整日志。

日志中出现：

```text
Message ID      = PR1
Category        = Config
AgentID         = iDRAC
Severity        = Information

Message         = A replacement part was detected for device:
                  PERC H330 Mini(Embedded)

FQDD            = RAID.Integrated.1-1
```

随后：

```text
Message ID      = PR8
Category        = Config
Severity        = Warning

Message         = Device not detected:
                  PERC H330 Mini(Embedded)
```

紧接着：

```text
Message ID      = PR7
Category        = Config
Severity        = Information

Message         = New device detected:
                  PERC H730 Mini(Embedded)

FQDD            = RAID.Integrated.1-1
```

可以确认这台机器之前使用的是：

```text
PERC H330 Mini
```

后来更换成：

```text
PERC H730 Mini
```

这意味着 Lifecycle Controller 中的硬件 Inventory 曾经发生过比较大的变化。

---

## 10. PERC 固件也发生过变化

Lifecycle Log 中还有：

```text
Message ID      = PR36
Category        = Config
AgentID         = DE
Severity        = Information

Message         = Version change detected for PERC H730 Mini firmware.

Previous version: 25.2.2-0004
Current version: 25.4.0.0015
```

也就是说这台服务器同时经历过：

```text
H330 Mini
    ↓
H730 Mini
```

以及：

```text
H730 Firmware
25.2.2-0004
    ↓
25.4.0.0015
```

而 iDRAC / Lifecycle Controller 仍然停留在：

```text
2.21.21.21
```

这进一步增加了 Lifecycle Controller Inventory 与当前硬件状态不一致的可能性。

---

## 11. RAID Controller 配置还被 Reset 过

Lifecycle Log 中还能看到：

```text
Message ID      = CTL11
Category        = Storage
AgentID         = iDRAC
Severity        = Information

Message         = Configuration on Integrated RAID Controller 1 was reset.

FQDD            = RAID.Integrated.1-1
```

之后 Bay 0-3 的硬盘经历过：

```text
READY
  ↓
Non-RAID
```

例如：

```text
Message ID      = PDR77

Message         = Disk 0 in Backplane 1 of Integrated RAID Controller 1
                  state changed from READY to Non-RAID.
```

其他三块盘也一样：

```text
Disk 1 READY → Non-RAID
Disk 2 READY → Non-RAID
Disk 3 READY → Non-RAID
```

之后又陆续恢复：

```text
Message ID      = PDR4

Message         = Disk 0 in Backplane 1 of Integrated RAID Controller 1
                  returned to a ready state.
```

最终：

```text
Disk 0 → READY
Disk 1 → READY
Disk 2 → READY
Disk 3 → READY
```

这说明 Lifecycle Controller 确实重新处理过 RAID Controller 和这些 Physical Disk 的状态。

---

## 12. RACADM 创建 RAID 后日志正常

最终通过 RACADM 创建 RAID6 后，日志正常。

四块硬盘上线：

```text
Message ID      = PDR26

Message         = Disk 0 in Backplane 1 of Integrated RAID Controller 1 is online.
```

随后：

```text
Disk 1 is online
Disk 2 is online
Disk 3 is online
```

Virtual Disk 成功创建：

```text
Message ID      = VDR4
Category        = Storage
AgentID         = iDRAC
Severity        = Information

Message         = Virtual Disk 0 on Integrated RAID Controller 1 was created.

FQDD            = Disk.Virtual.0:RAID.Integrated.1-1
```

随后开始 Background Initialization：

```text
Message ID      = VDR32

Message         = Background initialization has started for
                  Virtual Disk 0 on Integrated RAID Controller 1.
```

最后：

```text
Message ID      = PR19
Category        = Config
AgentID         = iDRAC
Severity        = Information

Message         = Job completed successfully.

Message Arg 1   = RAID.Integrated.1-1
```

因此可以基本排除：

- PERC H730 Mini 本身故障
- 物理硬盘故障
- RAID6 本身无法创建
- Configuration Job 无法执行

---

## 13. 为什么 Web 创建失败，但 RACADM 可以？

iDRAC Web 创建 RAID，大致要经过：

```text
iDRAC Web
    ↓
Lifecycle Controller
    ↓
读取 Hardware Inventory
    ↓
创建 Pending Configuration
    ↓
创建 Configuration Job
    ↓
PERC
    ↓
应用配置
```

而使用 RACADM：

```bash
racadm storage createvd ...
```

相当于更加直接地告诉 Storage Provider：

```text
指定 Controller
指定 Physical Disk
指定 RAID Level
        ↓
创建 Pending Configuration
```

然后再手动执行：

```bash
racadm jobqueue create RAID.Integrated.1-1 --realtime
```

流程变成：

```text
RACADM
   ↓
Storage Provider
   ↓
Pending Configuration
   ↓
手动创建 Configuration Job
   ↓
PERC
```

所以即使 Web 上层的 Inventory 或状态管理异常，底层 PERC 仍然可以正常完成 RAID 配置。

---

## 14. STOR026 不是根本原因

Web 之前出现：

```text
STOR026:
Unable to create configuration job because
there are no pending configuration changes.
```

它表达的实际含义是：

```text
Lifecycle Controller：
当前没有 Pending Configuration，
因此无法创建 Configuration Job。
```

但 Web 页面刚刚执行过 RAID 创建操作。

这说明有可能出现：

```text
Web
↓
认为已经创建 Pending Configuration

Lifecycle Controller
↓
实际上没有正确记录或同步 Pending Configuration

Web
↓
继续提交 Configuration Job

Lifecycle Controller
↓
返回 STOR026
```

所以 `STOR026` 更像是状态不同步后的结果，而不是根因。

---

## 15. LC062 同样说明状态可能残留

另一个错误：

```text
LC062:
Export or Import Server Configuration Profile operation is already running.
```

但 Job Queue 中对应任务实际上是：

```text
Export: System configuration XML file
Status=Failed
```

一种合理的故障链路是：

```text
Export Job
    ↓
执行失败
    ↓
Job Queue 标记为 Failed
    ↓
Lifecycle Controller 内部状态未完全释放
    ↓
Web 再次发起配置操作
    ↓
LC 判断仍有 Export / Import 正在运行
    ↓
LC062
```

这类问题本质上更接近：

```text
stale state
```

或者：

```text
stale lock
```

---

## 16. 根因判断

结合目前的日志，问题更可能是多个条件叠加导致：

```text
较旧的 iDRAC / LC 2.21.21.21
                +
RAID Controller 从 H330 更换成 H730
                +
Lifecycle Controller 检测到 Replacement Part
                +
H730 Firmware 发生升级
                +
RAID Controller Configuration 被 Reset
                +
Hardware Inventory 多次变化
                ↓
Lifecycle Controller Inventory / 状态异常
                ↓
System Configuration Export SYS044
                ↓
Web Storage 状态与 PERC Pending 状态不同步
                ↓
LC062 / STOR026
```

目前可以基本确认：

### PERC H730 Mini 正常

因为：

```bash
racadm storage createvd
```

可以正常创建 Pending Configuration。

### 物理硬盘正常

最终日志中：

```text
Disk 0 Online
Disk 1 Online
Disk 2 Online
Disk 3 Online
```

### Configuration Job 正常

最终出现：

```text
PR19: Job completed successfully.
```

### RAID6 正常

Virtual Disk 成功创建，并开始 Background Initialization。

---

<a id="solution"></a>

# 解决方案

如果目标只是解决 iDRAC Web 无法创建 RAID 的问题，可以直接通过 RACADM 创建阵列。

---

## 1. SSH 登录 iDRAC

```bash
ssh root@192.168.1.245
```

---

## 2. 查看物理硬盘

```bash
racadm storage get pdisks
```

示例：

```text
Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1
Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1
Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1
Disk.Bay.3:Enclosure.Internal.0-1:RAID.Integrated.1-1
```

---

## 3. 创建 RAID6

Bay 0-3 创建 RAID6：

```bash
racadm storage createvd:RAID.Integrated.1-1 -rl r6 -ss 256k -wp wb -rp ra -pdkey:Disk.Bay.0:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.1:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.2:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.3:Enclosure.Internal.0-1:RAID.Integrated.1-1 -name RAID6_0_3
```

成功后会返回：

```text
STOR094 : The storage configuration operation is successfully completed
and the change is in pending state.
```

---

## 4. 提交配置

立即应用：

```bash
racadm jobqueue create RAID.Integrated.1-1 --realtime
```

---

## 5. 查看 Job 状态

```bash
racadm jobqueue view
```

正常完成：

```text
Job Name=Configure: RAID.Integrated.1-1
Status=Completed
Message=[PR19: Job completed successfully.]
Percent Complete=[100]
```

---

## 6. 查看虚拟磁盘

```bash
racadm storage get vdisks
```

查看详细信息：

```bash
racadm storage get vdisks -o
```

---

## 7. 清理失败 Job

确认没有正在运行的重要任务后，可以查看：

```bash
racadm jobqueue view
```

删除指定失败任务：

```bash
racadm jobqueue delete -i JID_xxxxxxxxxxxx
```

如果 Job Queue 已经明显异常，也可以考虑：

```bash
racadm jobqueue delete -i JID_CLEARALL_FORCE
```

注意：

> `JID_CLEARALL_FORCE` 会清空整个 Lifecycle Controller Job Queue。  
> 如果存在 BIOS、RAID、Firmware Pending Job，不要直接执行。

---

## 8. 重启 iDRAC

如果怀疑 iDRAC / LC 状态残留：

```bash
racadm racreset soft
```

这个操作只会重启 iDRAC，不会重启服务器操作系统。

SSH 会断开几分钟，等待 iDRAC 恢复即可。

---

## 17. 后续维护建议

目前 RAID 已经正常建立，后续建议继续处理管理固件和 Inventory 状态。

### 17.1 升级 iDRAC / Lifecycle Controller

当前版本：

```text
iDRAC               2.21.21.21
Lifecycle Controller 2.21.21.21
```

版本较老。

建议确认 Dell 官方升级路径后，再逐步升级到较新的 iDRAC8 / LC 版本。

不建议在没有确认升级路径的情况下直接跨多个大版本升级。

---

### 17.2 检查完整固件版本

建议确认：

```text
BIOS
iDRAC
Lifecycle Controller
PERC H730 Mini
Backplane
NIC
CPLD
PSU
```

尽量让服务器整体 Firmware Baseline 保持在合理范围。

---

### 17.3 完整重启并重新收集 Inventory

当前：

```text
CollectSystemInventoryOnRestart=Enabled
```

因此完整重启后，Lifecycle Controller 会重新进行 Hardware Inventory。

可以借此重新确认：

```text
System
Controller
Physical Disk
Virtual Disk
Firmware
```

等组件状态。

---

## 18. RAID10 RACADM 补充

另一台相同型号的 R730xd 上还测试了 4 块盘 RAID10。

使用：

```bash
racadm storage createvd:RAID.Integrated.1-1 -rl r10 -sc 2 ...
```

出现：

```text
STOR090 : Unable to create a virtual disk because an invalid combination
of span count or number of disks was entered for the RAID level selected.
```

最终改为：

```text
-sc 0
```

成功。

示例：

```bash
racadm storage createvd:RAID.Integrated.1-1 -rl r10 -sc 0 -ss 256k -wp wb -rp ra -pdkey:Disk.Bay.8:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.9:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.10:Enclosure.Internal.0-1:RAID.Integrated.1-1,Disk.Bay.11:Enclosure.Internal.0-1:RAID.Integrated.1-1 -name RAID10_8_11
```

返回：

```text
STOR094 : The storage configuration operation is successfully completed
and the change is in pending state.
```

提交方式相同：

```bash
racadm jobqueue create RAID.Integrated.1-1 --realtime
```

---

## 19. 常用排查命令

查看版本：

```bash
racadm getversion
```

查看 Lifecycle Controller：

```bash
racadm get LifecycleController.LCAttributes
```

查看 Job Queue：

```bash
racadm jobqueue view
```

查看物理盘：

```bash
racadm storage get pdisks
```

查看虚拟盘：

```bash
racadm storage get vdisks
```

查看虚拟盘详细信息：

```bash
racadm storage get vdisks -o
```

查看 Lifecycle Log：

```bash
racadm lclog view
```

重启 iDRAC：

```bash
racadm racreset soft
```

---

## 20. 总结

本次故障表面上表现为：

```text
iDRAC Web 无法创建 RAID
```

但实际测试结果是：

```text
RACADM 创建 Pending Configuration 成功
Configuration Job 提交成功
PERC 创建 Virtual Disk 成功
物理硬盘全部 Online
Background Initialization 正常
```

因此可以排除 PERC 和硬盘本身的主要故障。

结合日志：

```text
H330 → H730
PERC Firmware 发生变化
RAID Controller Configuration 被 Reset
SYS044
LC062
STOR026
```

以及较旧的：

```text
iDRAC / LC 2.21.21.21
```

更可能的问题点位于：

```text
iDRAC Web
Lifecycle Controller
Hardware Inventory
Pending Configuration
Job Queue
```

之后如果遇到类似问题，可以优先执行：

```bash
racadm getversion
racadm jobqueue view
racadm storage get pdisks
racadm storage get vdisks
racadm get LifecycleController.LCAttributes
racadm lclog view
```

如果出现：

```text
Web 不行
RACADM 正常
```

应优先检查：

```text
Lifecycle Controller Inventory
Job Queue
Pending Configuration
System Configuration Export
iDRAC / LC Firmware
```

而不是直接判断 PERC 或物理硬盘故障。


Dell R730xd iDRAC 无法创建 RAID

## 环境

- 机型:ASUS ROG Strix G733ZM(RTX 3060 Mobile,i9-12900H)
- 系统:Ubuntu 26.04,Wayland
- 内核:`7.0.0-14-generic`
- 桌面:KDE Plasma

## 为什么折腾

Linux 下需要替代 Armoury Crate 的工具:风扇曲线和 RGB 控制。`asusctl` 是社区主导的 ASUS Linux 控制工具,主流发行版有包,Ubuntu 标记为 "Officially unsupported"。我是ubuntu 信徒，我拒绝在我想稳定使用的电脑上安装arch

`asusctl` 仅支持 Wayland。`asus-armoury` 驱动要求内核 ≥ 6.19。两项均满足。

## 先确认硬件匹配

```bash
cat /sys/class/dmi/id/sys_vendor
# ASUSTeK COMPUTER INC.

lsusb | grep -i asus
# 0b05:19b6 ASUSTek Computer, Inc. N-KEY Device
```

`0b05:19b6` 命中 N-KEY 设备列表。`asus-armoury`、`asus_nb_wmi`、`hid_asus` 已加载。

## 编译

Ubuntu 仓库的 Rust 版本低于项目要求,需 rustup:

```bash
sudo apt install -y git cmake clang pkg-config \
    libclang-dev libudev-dev libxkbcommon-dev \
    libzip-dev libssl-dev libgtk-3-dev \
    libpcre2-dev libzstd-dev libexpat1-dev \
    build-essential

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"

git clone https://github.com/OpenGamingCollective/asusctl.git
cd asusctl
cargo build --release
```

安装二进制与 udev 规则:

```bash
sudo cp target/release/asusd /usr/bin/
sudo cp target/release/asusctl /usr/bin/
sudo cp data/asusd.rules /lib/udev/rules.d/
sudo udevadm control --reload-rules && sudo udevadm trigger
```

## 问题 1 D-Bus 策略

按 README 执行 `systemctl enable --now asusd.service`:

```
The unit files have no installation config (WantedBy=, RequiredBy=, UpheldBy=,
Also=, or Alias= settings in the [Install] section, and DefaultInstance= for
template units). ...
Job for asusd.service failed because the control process exited with error code.
```

`asusd.service` 为 `Type=dbus`,无 `[Install]` 段。`enable` 警告可忽略。

daemon 启动失败。`journalctl`:

```
Connection ":1.144" is not allowed to own the service "xyz.ljones.Asusd"
  due to security policies in the configuration file
```

daemon 注册 D-Bus 总线名 `xyz.ljones.Asusd`。Ubuntu 的 dbus-daemon 默认拒绝未知名字的所有权声明。

安装 `data/asusd.conf`:

```bash
sudo cp data/asusd.conf /etc/dbus-1/system.d/
sudo systemctl reset-failed asusd.service
sudo systemctl start asusd.service
```

验证:

```bash
busctl list | grep asusd
```

输出 `xyz.ljones.Asusd` 表示 D-Bus 名称注册成功。

`asusd.service` 与 `asus-shutdown.service` 需手动 copy。Arch 用户的 PKGBUILD 自动处理 systemctl、udev、D-Bus 配置。

```bash
sudo cp data/asusd.service /etc/systemd/system/
sudo cp data/asus-shutdown.service /etc/systemd/system/
sudo systemctl daemon-reload
```

`asusd` 由 D-Bus 激活,不需 `enable`。`asus-shutdown` 有 `[Install]` 段。

## CLI 测试

```bash
$ asusctl profile list
Silent
Balanced
Performance

$ asusctl profile -P Performance
$ asusctl led-mode static -c red
```

风扇曲线配置:`/etc/asusd/fan_curves.ron`,切到 `Custom` 即生效。

```bash
asusctl fan-mode --fan-diag
```

输出 CPU、GPU 风扇识别。

CLI 命令:profile、led-mode、fan-mode、充电阈值、GPU 模式、TDP 限制。

## 问题 2 rog-control-center 缺图标

`rog-control-center` 使用 Slint。启动时 panic:

```
thread 'tokio-rt-worker' panicked at rog-control-center/src/tray.rs:39:29:
Missing icon: "/usr/share/icons/hicolor/512x512/apps/asus_notif_red.png"
```

源码 `tray.rs:33`:

```rust
let mut file = OpenOptions::new()
    .read(true)
    .open(&path)
    .unwrap_or_else(|_| panic!("Missing icon: {:?}", path));
```

资源路径硬编码,缺失直接 `panic!`。

安装 6 个通知图标:

```bash
sudo install -D -m 644 ~/asusctl/data/icons/asus_notif_*.png \
                  -t /usr/share/icons/hicolor/512x512/apps/
```

再次启动:

```
Missing icon: "/usr/share/icons/hicolor/512x512/apps/rog-control-center.png"
```

`rog-control-center.png` 不在仓库中,仅有 `data/icons/scalable/rog-logo.svg`。

SVG 转 PNG:

```bash
sudo apt install -y librsvg2-bin
rsvg-convert -w 512 -h 512 ~/asusctl/data/icons/scalable/rog-logo.svg \
             -o /tmp/rog-control-center.png
sudo install -m 644 /tmp/rog-control-center.png \
                /usr/share/icons/hicolor/512x512/apps/rog-control-center.png
```

第三次启动成功。


## 遇到 的问题

1. **D-Bus 所有权**:`xyz.ljones.Asusd` 需在 `/etc/dbus-1/system.d/*.conf` 显式声明。`asusd.conf` 为必需文件。
2. **Slint 资源路径硬编码**:缺失时 `panic!`,无 fallback。源码编译需手动 copy 资源。
3. **`Type=dbus` service**:无 `[Install]` 段,由 D-Bus 激活。`enable` 警告可忽略。
4. **README 面向 Arch**:AUR 的 PKGBUILD 自动处理 service、udev、D-Bus 配置。Ubuntu 源码编译需手动补齐。
5. **崩溃栈作为文档**:`tray.rs:39` 等行号直接定位项目结构和资源约定。

## 小结

- Ubuntu 26.04 + `asusctl`:可用,需源码编译。
- 手动步骤:`asusd.service`、`asusd.conf`、6 个 `asus_notif_*.png`、`rog-control-center.png`。

Ubuntu 26.04 编译 asusctl

# Ubuntu 26.04 装 NVIDIA 580 Secure Boot MOK 签名

## 环境

- Ubuntu 26.04 LTS,内核 `7.0.0-27-generic`
- GPU: RTX 2080 Ti
- 驱动: `nvidia-driver-580` (580.159.03)

## 现象

驱动包正常装上(`dpkg -l` 能看到 `nvidia-driver-580`,`modinfo nvidia` 也能查到模块信息),但 `nvidia-smi` 报错:

```
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.
Make sure that the latest NVIDIA driver is installed and running.
```

## 排查过程

先按常规思路排除了几个常见坑:

1. **nouveau 冲突** —— `lsmod | grep nouveau` 无输出,排除。
2. **内核版本不匹配** —— `uname -r` 与 dkms 编译目标内核一致,排除。
3. **手动加载模块看真实报错**:
   ```bash
   sudo modprobe nvidia
   ```
   输出:
   ```
   modprobe: ERROR: could not insert 'nvidia': Key was rejected by service
   ```

这行报错才是关键。`Key was rejected by service` 是 **Secure Boot** 在拦截未注册签名的内核模块 —— 驱动本身没问题,是系统不信任这个 out-of-tree 模块的签名。

确认:
```bash
mokutil --sb-state
# SecureBoot enabled
```

## 解决方法

装驱动时(尤其是 dkms 方式)会生成一个本地签名密钥用于给内核模块签名,但如果安装过程中弹出的 MOK 注册蓝屏被跳过或没注意到,密钥就没有被系统信任,导致模块加载时被拒。

补救办法是手动重新注册 MOK:

```bash
sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
# 设置一个临时密码(输入两次)
sudo reboot
```

重启后,在 GRUB 之后、系统正常启动前,会出现一个**蓝色的 MOK Manager 界面**(这一步很容易一闪而过被忽略,需要盯着屏幕):

1. `Enroll MOK`
2. `Continue`
3. `Yes`
4. 输入刚才设置的密码确认

完成后系统会继续正常启动。登录后验证:

```bash
sudo modprobe nvidia
nvidia-smi
```

`nvidia-smi` 正常输出驱动版本、GPU 型号和显存信息即代表成功。

## 一个无关的报错

排查过程中在 `dmesg` 里看到一堆:

```
nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
ucsi_ccg 6-0008: i2c_transfer failed -110
ucsi_ccg 6-0008: ucsi_ccg_init failed -110
ucsi_ccg 6-0008: probe with driver ucsi_ccg failed with error -110
```

这个是显卡 **USB-C VirtualLink 接口上的 Cypress CCG 控制器** i2c 握手超时,和主驱动加载完全无关,不影响 GPU 计算功能,可以忽略。

## 小结

- 如果 `nvidia-driver` 包装好了但 `nvidia-smi` 找不到驱动,先别急着重装,用 `sudo modprobe nvidia` 看真实报错。
- 报错是 `Key was rejected by service`,基本可以断定是 **Secure Boot 没信任 dkms 签名密钥**。
- 两种解法:
  - 重新走一遍 MOK 注册流程(保留 Secure Boot)
  - 直接在 BIOS 里关掉 Secure Boot(homelab/本地机器可以这么偷懒)
- 无关的 `ucsi_ccg` / i2c timeout 报错可以无视,不影响驱动加载。

Ubuntu 26.04 装 NVIDIA 580 

> 占位符约定：生产机 A `192.168.1.10`、备份机 B `192.168.1.20`、数据库机 `192.168.1.30`、告警邮箱 `you@example.com`。请按自己环境替换。

## 背景

内网一台机器上跑着 Forgejo（用 Docker，rootless 镜像），数据库是**另一台机器**上的 PostgreSQL，同机还有 Nexus、certimate 等服务。目标很简单：**把 Forgejo 备份到内网另一台 Linux 机器**，最好顺手把框架做得能复用给其它服务。

听起来是一条 `rsync` 的事，真做起来有几个不踩不知道的坑。这篇把思路、实现和踩坑都记下来。

## 三个设计决定

### 1. 拉取模式（Pull），不是推送

让**备份机 B 主动去拉**生产机 A，而不是 A 推给 B。原因是安全姿态：B 持有一把只读 SSH key 去访问 A，A 不持有任何能写 B 的凭据。这样即使 A 被入侵或勒索，攻击者也动不了 B 上的历史备份。备份的第一要务是「攻破生产不等于攻破备份」。

### 2. 数据库必须 dump，不能只 rsync 文件

这是最容易错的一点。直接 `rsync` 正在运行的数据库数据文件得到的是**崩溃一致**的副本，恢复时大概率坏掉。正确做法是用 `pg_dump`（MySQL 则 `mysqldump`）导出逻辑快照。而且——

> Git 仓库的**内容**在磁盘上，**元数据**（用户、组织、Issue、PR、权限、Webhook…）在数据库里。只备文件不备库，恢复出来是个空壳；只备库不备文件，仓库内容全没。两者都要。

### 3. 硬链接快照 + GFS，而不是每次全量压缩

很多备份脚本每次跑都 `tar` 压缩成一个全量归档，保留 N 份。问题是 N 份各占一份全量、每次还很吃 CPU。这里改用 **rsync 到常驻 mirror + `cp -al` 硬链接快照**：未变化的文件在快照间共享 inode，每天的快照几乎只占增量。保留策略用 GFS（日 7 / 周 8 / 月 12）。

## 架构

```
[A 生产机 192.168.1.10]                    [DB 机 192.168.1.30]
  forgejo (rootless) ──连接──────────────────> PostgreSQL :5432
  数据(bind mount):
    /data/docker/forgejo/forgejo  (仓库/附件/app.ini)
    /hdd/forgejo/git/lfs          (LFS，单独大盘)
  pre-hook: pg_dump -> /opt/forgejo-backup/db/
                                          ▲
                                          │  B ssh 拉取（pull）
[B 备份机 192.168.1.20]                    │
  main.sh + engine.sh + conf/ ────────────┘
    /data/backups/forgejo/mirror/      最新镜像
    /data/backups/forgejo/<日期>/      硬链接快照(GFS)
```

## 先搞清楚数据在哪

用的是 **rootless** 镜像，路径和普通镜像不一样，先确认：

```bash
# 数据库类型与配置路径
docker exec forgejo sh -c 'cat ${GITEA_APP_INI:-/etc/gitea/app.ini} | grep -iA8 "\[database\]"'
# 卷在宿主机的真实位置
docker inspect forgejo --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}'
```

得到的事实：数据库是外部 PostgreSQL（不在容器里）；主数据 bind mount 在 `/data/docker/forgejo/forgejo`；LFS 在独立盘 `/hdd/forgejo/git/lfs`。

一个小细节：LFS 是**第二个 bind mount**，挂在容器内 `…/git/lfs`，但在宿主机上它是另一条路径。所以 rsync 宿主机的主数据目录**天然不会带上 LFS**——如果你的 LFS 是上游镜像、可重新拉取，正好不用备它。

## 实现

### A 机：数据库导出（pre-hook）

`forgejo-backup.sh`，由备份机通过 SSH 触发，在 A 上生成 dump。口令放在 A 本地的 `forgejo-backup.env`（600），不下放到 B。

```bash
#!/usr/bin/env bash
set -euo pipefail
FORGEJO_CT="forgejo"
DB_HOST="192.168.1.30"; DB_PORT="5432"; DB_USER="forgejo"; DB_NAME="forgejo"
PG_IMAGE="postgres:17"                       # pg_dump 客户端；报版本不匹配就升 tag
ENV_FILE="/opt/scripts/forgejo-backup.env"   # 只含一行 PGPASSWORD=...，chmod 600
APPINI_HOST="/data/docker/forgejo/forgejo/custom/conf/app.ini"
COMPOSE_DIR="/data/docker/forgejo"
DEST="/opt/forgejo-backup/db"; KEEP=7

mkdir -p "$DEST"; TS=$(date +%F_%H%M); DUMP="$DEST/forgejo_$TS.dump"
docker exec "$FORGEJO_CT" forgejo manager flush-queues || true
docker run --rm --env-file "$ENV_FILE" "$PG_IMAGE" \
  pg_dump -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -Fc "$DB_NAME" > "$DUMP"
[ -s "$DUMP" ] || { echo "ERROR: dump 为空"; rm -f "$DUMP"; exit 1; }
cp -f "$APPINI_HOST" "$DEST/app.ini.bak" 2>/dev/null || true
cp -f "$COMPOSE_DIR"/docker-compose.y*ml "$DEST/" 2>/dev/null || true
( cd "$DEST" && sha256sum "forgejo_$TS.dump" > "forgejo_$TS.dump.sha256" )
ls -1t "$DEST"/forgejo_*.dump | tail -n +$((KEEP+1)) | while read -r f; do rm -f "$f" "$f.sha256"; done
echo "完成: $DUMP"
```

> 用 `-Fc`（自定义格式）压缩、可灵活恢复。一个反直觉的点：dump 通常很小（几 MB），因为**库里只有元数据**，仓库内容根本不在库里——别被小体积吓到。

### B 机：引擎 `engine.sh`

读一个 conf，跑「pre-hook → rsync → 校验 → 硬链接快照 → GFS 清理」。

```bash
#!/usr/bin/env bash
set -euo pipefail
CONF="$1"; NAME="$(basename "${CONF%.conf}")"
SSH_HOST=""; SSH_USER="root"; SSH_PORT=22; SSH_KEY=""
PRE_CMD=""; BWLIMIT=0; NICE=15
SRC_DIRS=(); EXCLUDES=()
KEEP_DAILY=7; KEEP_WEEKLY=8; KEEP_MONTHLY=12
BACKUP_ROOT="${BACKUP_ROOT:-/data/backups}"
source "$CONF"
[ -n "$SSH_HOST" ] || { echo "[$NAME] 缺 SSH_HOST"; exit 2; }
[ "${#SRC_DIRS[@]}" -gt 0 ] || { echo "[$NAME] 缺 SRC_DIRS"; exit 2; }

BASE="$BACKUP_ROOT/$NAME"; MIRROR="$BASE/mirror"; SNAP="$BASE/$(date +%F)"; mkdir -p "$MIRROR"
SSH_OPT=(ssh -p "$SSH_PORT" -o BatchMode=yes -o StrictHostKeyChecking=accept-new)
[ -n "$SSH_KEY" ] && SSH_OPT+=(-i "$SSH_KEY"); REMOTE="$SSH_USER@$SSH_HOST"

# 1) 远程 pre-hook（如 pg_dump）
[ -n "$PRE_CMD" ] && { echo "[$NAME] pre-hook"; "${SSH_OPT[@]}" "$REMOTE" "$PRE_CMD"; }

# 2) 逐个源目录增量拉取  SRC_DIRS=("label:/remote/path" ...)
RS_EXCL=(); for e in "${EXCLUDES[@]:-}"; do [ -n "$e" ] && RS_EXCL+=(--exclude "$e"); done
for entry in "${SRC_DIRS[@]}"; do
  label="${entry%%:*}"; path="${entry#*:}"
  [ "$label" != "$entry" ] || { echo "[$NAME] SRC_DIRS 须为 label:/path: $entry"; exit 2; }
  mkdir -p "$MIRROR/$label"
  nice -n "$NICE" rsync -a --delete --bwlimit="$BWLIMIT" "${RS_EXCL[@]}" \
    -e "${SSH_OPT[*]}" "$REMOTE:$path/" "$MIRROR/$label/"
done

# 3) 可选校验：conf 定义 verify() 即生效
if declare -F verify >/dev/null; then ( cd "$MIRROR" && verify ) || { echo "[$NAME] 校验失败"; exit 1; }; fi

# 4) 硬链接快照
rm -rf "$SNAP"; cp -al "$MIRROR" "$SNAP"

# 5) GFS 保留
find "$BASE" -maxdepth 1 -type d -regextype posix-extended -regex '.*/[0-9]{4}-[0-9]{2}-[0-9]{2}$' | while read -r d; do
  day=$(basename "$d"); age=$(( ($(date +%s)-$(date -d "$day" +%s))/86400 ))
  dow=$(date -d "$day" +%u); dom=$(date -d "$day" +%d); keep=0
  [ "$age" -le "$KEEP_DAILY" ] && keep=1
  { [ "$dow" = 7 ] && [ "$age" -le $((KEEP_WEEKLY*7)) ]; } && keep=1
  { [ "$dom" = 01 ] && [ "$age" -le $((KEEP_MONTHLY*31)) ]; } && keep=1
  if [ "$keep" = 0 ]; then echo "[$NAME] purge $day"; rm -rf "$d"; fi
done
echo "[$NAME] done: $SNAP"
```

### B 机：入口 `main.sh`

```bash
#!/usr/bin/env bash
set -uo pipefail
DIR="$(cd "$(dirname "$0")" && pwd)"
export BACKUP_ROOT="${BACKUP_ROOT:-/data/backups}"
LOG_DIR="$DIR/logs"; mkdir -p "$LOG_DIR"

# 防并发：同一时刻只跑一个备份
if command -v flock >/dev/null 2>&1; then
  exec 9>"$DIR/.lock"; flock -n 9 || { echo "已有备份在运行"; exit 0; }
fi

run_one() {
  local conf="$1" name; name="$(basename "${conf%.conf}")"
  [ -s "$conf" ] || { echo "跳过 $conf"; return 1; }
  echo "===== $(date '+%F %T') 备份 [$name] ====="
  bash "$DIR/engine.sh" "$conf" 2>&1 | tee -a "$LOG_DIR/${name}_$(date +%F).log"
  local rc=${PIPESTATUS[0]}; [ "$rc" = 0 ] && echo "[$name] OK" || echo "[$name] 失败 rc=$rc"; return "$rc"
}
if [ "${1:-}" ]; then run_one "$DIR/conf/${1%.conf}.conf"; exit $?; fi
fail=0; for c in "$DIR"/conf/*.conf; do run_one "$c" || fail=1; done; exit $fail
```

### 一个服务一个 conf

`conf/forgejo.conf`：

```bash
SSH_HOST=192.168.1.10
SSH_USER=root
SSH_KEY=/opt/serverbackup/sshkey/a_host
PRE_CMD='bash -lc /opt/scripts/forgejo-backup.sh'   # bash -lc 保证 ssh 下能找到 docker
SRC_DIRS=(
  "data:/data/docker/forgejo/forgejo"   # 仓库/附件/app.ini（LFS 在 /hdd，不在此树）
  "db:/opt/forgejo-backup/db"           # pg_dump + app.ini + compose
)
EXCLUDES=( 'git/lfs/' 'log/' 'data/tmp/' )
verify() {
  local latest; latest=$(ls -1t db/forgejo_*.dump 2>/dev/null | head -1)
  [ -n "$latest" ] || return 1
  ( cd db && sha256sum -c "$(basename "$latest").sha256" ) || return 1
}
```

加一个新服务，就复制一个 conf、改 `SRC_DIRS`（必要时加 `PRE_CMD`/`verify`）即可，`main.sh` 自动纳入。

## 定时 + 失败告警

cron 自己不发 SMTP，它把信交给本机的 `sendmail`。装 `msmtp` 当 MTA，中转到你邮箱的 SMTP（QQ/163/Gmail 等都行，密码用**授权码/应用专用密码**，不是登录密码）：

```bash
apt install msmtp msmtp-mta
```

`/etc/msmtprc`（以 QQ 邮箱为例，`chmod 600`）：

```
defaults
logfile /var/log/msmtp.log
account default
auth on
host smtp.qq.com
port 465
tls on
tls_starttls off
from you@example.com
user you@example.com
password <SMTP授权码>
```

**关键点**：cron 的 `MAILTO` 只在任务**有输出**时才发信；如果你把输出重定向进日志（`>> cron.log 2>&1`），cron 就永远收不到、也不发信。所以用「**只在失败时发信**」的写法更实用：

```cron
0 4 * * * /opt/serverbackup/main.sh >> /opt/serverbackup/logs/cron.log 2>&1 || printf 'Subject: [backup] 失败 %s\n\n%s\n' "$(hostname)" "$(tail -n 30 /opt/serverbackup/logs/cron.log)" | msmtp you@example.com
```

失败把最后 30 行日志发给你。要发给多人就在 `msmtp` 后并列多个地址。

## 踩过的坑

1. **`set -e` + `pipefail` 把成功跑成 rc=1。** GFS 清理用了 `[ "$keep" = 0 ] && { rm ...; }`，当快照要**保留**（keep=1）时这句返回非 0，经 `pipefail` 让整个 `find | while` 管道失败、触发 `set -e`，于是每次成功备份都误报失败。改成 `if [ "$keep" = 0 ]; then …; fi` 即可。
2. **rootless 镜像路径不同。** 配置在 `/etc/gitea/app.ini` 或 `…/custom/conf/app.ini`，数据在 `/var/lib/gitea`，容器本身以 `git`(1000) 运行，别套用普通镜像的 `/data/...`。
3. **口令差点进 git。** 恢复手册里写了真实 PG 口令，差点 `git push` 上去。处理：从文件里脱敏成 `-e PGPASSWORD` 透传；如果含密的提交还没推送，**改写它**（`git commit --amend`）让口令从将推送的历史里消失；已经推过就只能改写远端 + 轮换口令。并补一个 `.gitignore` 忽略 `sshkey/`、`logs/`、`*.env`、真实 `*.conf`。
4. **conf 是被 `source` 的**，等同执行脚本。设 600、别写不可信内容。
5. **恢复演练不能省。** 没演练过的备份不算备份。

## 恢复（要点）

```bash
SNAP=/data/backups/forgejo/2026-06-17
# 1) 文件
rsync -a "$SNAP/data/" /data/docker/forgejo/forgejo/
chown -R 1000:1000 /data/docker/forgejo/forgejo      # rootless 容器内 git 用户
# 2) 数据库（-Fc 用 pg_restore；口令用环境变量传，别写进命令）
export PGPASSWORD='<数据库口令>'
DUMP=$(ls -1t "$SNAP"/db/forgejo_*.dump | head -1)
docker run --rm -i -e PGPASSWORD postgres:17 \
  pg_restore --create --clean --if-exists -h 192.168.1.30 -U forgejo -d postgres < "$DUMP"
# 3) 起服务并验证：能登录、能 clone、Issue/PR/附件正常
docker compose up -d
```

## 小结

- **拉取模式**保护备份不被生产端连累；
- **数据库 dump + 文件 rsync**两条腿，缺一不可；
- **硬链接快照 + GFS** 比每次全量压缩省太多；
- **conf 驱动**让加服务变成加一个文件；。

内网异机备份 conf 驱动

如果你有机会到好望角，请在海边的石头上刻下我的故事👨‍💻