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


重装系统后，开发环境往往需要重新整理：Node.js 装在哪里，多个 Python 版本怎么切换，缓存能不能放到其他盘，不同项目又该如何固定版本？

这次我选择用 mise 管理语言和工具版本，在 PowerShell 7 中使用，并让 uv 负责 Python 项目的虚拟环境与依赖。

本文记录一次实际配置过程。文中的版本号是安装时的结果，不代表读者安装时的最新版本。

## 1. 先明确各个工具的职责

| 工具 | 负责什么 |
| --- | --- |
| mise | 安装、选择和切换 Node.js、Python 等语言及工具的版本 |
| uv | 创建 Python 虚拟环境、安装依赖、管理项目依赖与锁文件 |
| PowerShell 7 | 执行命令的 Shell |
| Windows Terminal | 承载 PowerShell 等 Shell 的终端应用 |
| Oh My Posh | 美化命令提示符，可选 |

mise 不会自动恢复项目依赖。安装了 Python，不等于安装了项目需要的 Python 包；安装了 Node.js，也不等于安装了项目的 `node_modules`。

Oh My Posh 与 mise 可以同时使用。本文已有 Oh My Posh 配置，只需追加 mise 的激活代码。

## 2. 规划安装与缓存目录

我采用下面的布局：

| 内容 | 位置 |
| --- | --- |
| mise 程序本身 | 由 winget 管理安装位置 |
| mise 安装的语言和工具 | `D:\Dev\mise` |
| mise 缓存 | `E:\DevCache\mise` |
| mise 全局配置 | `$HOME\.config\mise\config.toml` |
| 项目代码 | `E:\code\项目名` |
| Python 项目虚拟环境 | 项目内的 `.venv` |
| uv 缓存 | `E:\DevCache\uv` |

盘符可以按自己的情况调整，重点是：**安装语言之前先设置目录，工具数据和缓存使用不同目录。**

`MISE_DATA_DIR` 控制 mise 管理的工具数据位置，不是 mise 程序本身的安装位置。全局配置留在用户目录，不会因此让语言也装回 C 盘。

uv 缓存和项目虚拟环境放在同一文件系统上，有利于复用文件，避免跨文件系统时退回复制操作。

参考：[mise 目录说明](https://mise.jdx.dev/directories.html)、[uv 缓存说明](https://docs.astral.sh/uv/concepts/cache/)。

## 3. 安装 mise

在 PowerShell 7 中运行：

```powershell
winget install --id jdx.mise --exact --source winget
```

这是 mise 官方推荐的 Windows 安装方式。安装完成后重新打开终端，检查：

```powershell
mise --version
```

本次安装的 mise 版本为 `2026.10.12`。

参考：[mise 官方安装说明](https://mise.jdx.dev/installing-mise.html)。

## 4. 设置数据与缓存目录

在安装 Node.js、Python 等工具之前执行：

```powershell
# 持久保存到当前用户的环境变量
[Environment]::SetEnvironmentVariable('MISE_DATA_DIR', 'D:\Dev\mise', 'User')
[Environment]::SetEnvironmentVariable('MISE_CACHE_DIR', 'E:\DevCache\mise', 'User')

# 同时让当前 PowerShell 窗口立即生效
$env:MISE_DATA_DIR = 'D:\Dev\mise'
$env:MISE_CACHE_DIR = 'E:\DevCache\mise'
```

这两组命令有不同作用：用户环境变量负责持久保存，`$env:` 赋值负责更新当前进程。仅保存用户环境变量，已经打开的窗口可能仍保留旧值。

目录变量应设置在启动 mise 的环境中，不要放进项目 `mise.toml` 的 `[env]`：mise 在读取项目配置之前就需要决定使用哪些目录。

如果已经在默认目录安装过工具，修改变量不会自动搬迁旧安装。本文是在安装语言前完成设置。

## 5. 接入 PowerShell 7

打开 PowerShell 启动配置：

```powershell
notepad $PROFILE
```

如果启动配置尚不存在，可以先创建，避免覆盖已有文件：

```powershell
New-Item -ItemType Directory -Path (Split-Path $PROFILE) -Force | Out-Null
if (-not (Test-Path $PROFILE)) {
    New-Item -ItemType File -Path $PROFILE | Out-Null
}
notepad $PROFILE
```

在现有配置末尾加入一次：

```powershell
if (Get-Command mise -ErrorAction SilentlyContinue) {
    (& mise activate pwsh) | Out-String | Invoke-Expression
}
```

已有的 Oh My Posh、PSReadLine 等配置继续保留，不要用上面的代码覆盖整个文件。

当前窗口可以直接执行一次激活：

```powershell
(& mise activate pwsh) | Out-String | Invoke-Expression
mise doctor
```

之后完全退出 Windows Terminal 再重新打开，确认新窗口也能生效。

激活会让交互式 PowerShell 随项目目录更新工具环境。脚本或自动化任务可以使用 `mise exec -- 命令`，不必依赖交互式启动配置。

参考：[PowerShell 激活说明](https://mise.jdx.dev/cli/activate.html)。

## 6. 用 mise doctor 检查配置

初次检查时，我看到：

```text
shell:
  (unknown)

dirs:
  cache: ~\AppData\Local\Temp\mise
  data: ~\AppData\Local\mise

env_vars:
  (none)
```

这说明当前窗口还没有读到目录变量，也没有完成 PowerShell 集成。

完成设置后，检查结果应能识别 `pwsh`，并显示规划的目录。本次最终输出的关键部分是：

```text
shell:
  pwsh
  PowerShell 7.6.7

dirs:
  cache: E:\DevCache\mise
  data: D:\Dev\mise
  shims: D:\Dev\mise\shims

env_vars:
  MISE_CACHE_DIR=E:\DevCache\mise
  MISE_DATA_DIR=D:\Dev\mise
  MISE_SHELL=pwsh

No problems found
```

关于 shims：它们是转发到 mise 管理工具的命令入口，适合未执行交互式激活的使用场景。PowerShell 使用 `mise activate pwsh` 时，不要仅为了消除初次检查提示，就把尚未调整的 C 盘 shims 路径写死到 PATH。先完成目录设置与激活，再检查结果。

参考：[mise Shell 设置](https://mise.jdx.dev/shell-setup.html)。

## 7. 安装 Node.js 和 Python

为了兼容已有项目，我先选择 Node 22 和 Python 3.12：

```powershell
mise use -g node@22 python@3.12
```

`-g` 表示设置个人全局默认。没有项目配置覆盖时，就使用这些版本。

安装后验证：

```powershell
node --version
npm --version
python --version
mise current
mise which node
mise which python
```

本次结果为：

```text
Node.js  v22.23.3
npm      10.9.9
Python   3.12.15
```

实际程序位于：

```text
D:\Dev\mise\installs\node\22.23.3\node.exe
D:\Dev\mise\installs\python\3.12.15\python.exe
```

不同版本或布局下路径可能变化，应以 `mise which` 的输出为准，不要在脚本中长期写死安装子目录。

## 8. 区分“版本规则”和“当前安装版本”

本次执行 `mise use -g node@22 python@3.12` 后，全局配置实际保存的是：

```toml
[tools]
node = "22"
python = "3.12"
```

因此需要区分：

- `22`、`3.12` 是配置中的版本规则。
- `22.23.3`、`3.12.15` 是本次解析并安装的具体版本。
- 版本规则不等于精确锁定，也不代表每次打开终端都会自动升级。

对于项目，建议在项目根目录固定具体版本：

```powershell
cd E:\code\my-project
mise use --pin node@22 python@3.12
```

`--pin` 会将解析出的具体版本写进项目的 `mise.toml`。只添加项目实际需要的语言即可；纯 Python 项目不需要同时声明 Node。

项目配置可以提交到 Git。进入项目时，它会覆盖对应工具的全局默认选择。

拿到已有项目后，先查看 `mise.toml`，确认可信，再执行：

```powershell
mise trust
mise install
```

参考：[mise use](https://mise.jdx.dev/cli/use.html)、[mise trust](https://mise.jdx.dev/cli/trust.html)。

## 9. 通过 mise 安装 uv

继续用 mise 管理 uv 程序本身：

```powershell
mise use -g uv@latest
```

本次安装得到 `uv 0.13.1`。`latest` 是版本选择规则，并非固定版本；需要固定时也可以使用 `--pin`。

接着设置缓存，并关闭 uv 自动下载 Python：

```powershell
[Environment]::SetEnvironmentVariable('UV_CACHE_DIR', 'E:\DevCache\uv', 'User')
[Environment]::SetEnvironmentVariable('UV_PYTHON_DOWNLOADS', 'never', 'User')

$env:UV_CACHE_DIR = 'E:\DevCache\uv'
$env:UV_PYTHON_DOWNLOADS = 'never'
```

这样约定职责：mise 安装 Python，uv 管理项目环境和依赖。缺少匹配的 Python 时，先通过 mise 安装，而不是让 uv 自动再下载一套。

注意：禁用下载并不保证 uv 永远选中 mise 的解释器。机器上有多个 Python 时，可通过 `--python (mise which python)` 显式指定。

验证：

```powershell
uv --version
uv cache dir
uv python find
```

本次缓存目录为 `E:\DevCache\uv`，找到的解释器为 mise 安装的 Python 3.12.15。

参考：[uv 环境变量](https://docs.astral.sh/uv/configuration/environment/)、[uv 命令说明](https://docs.astral.sh/uv/reference/cli/)。

## 10. Python 项目的日常用法

### 已有 requirements.txt 的项目

进入项目目录，为项目选择 Python，然后创建虚拟环境：

```powershell
cd E:\code\my-project
mise use --pin python@3.12
uv venv --python (mise which python)
uv pip install -r requirements.txt
```

运行脚本时，可以直接使用虚拟环境中的解释器：

```powershell
.\.venv\Scripts\python.exe main.py
```

也可以先激活环境：

```powershell
.\.venv\Scripts\Activate.ps1
python main.py

# 使用完毕后退出
deactivate
```

### 已有 pyproject.toml 和 uv.lock 的项目

先按项目要求通过 mise 选择 Python，再同步依赖：

```powershell
uv sync --python (mise which python)
uv run main.py
```

这类项目使用 uv 的项目工作流管理依赖。不要在未确认项目 Python 要求的情况下，直接将所有项目都改成同一版本。

## 11. 常用命令速查

| 操作 | 命令 |
| --- | --- |
| 检查 mise 配置 | `mise doctor` |
| 查看工具和版本 | `mise ls` |
| 查看当前目录生效版本 | `mise current` |
| 查询可安装的 Node 版本 | `mise ls-remote node` |
| 只安装某个版本 | `mise install node@22` |
| 设置全局默认版本 | `mise use -g node@22` |
| 固定项目版本 | `mise use --pin node@22` |
| 安装项目声明的工具 | `mise install` |
| 查看实际 Python 路径 | `mise which python` |
| 在 mise 环境里执行命令 | `mise exec -- python --version` |
| 查看 uv 缓存位置 | `uv cache dir` |

如果版本与预期不一致，先检查实际命令来源：

```powershell
Get-Command node,python,uv -All
mise current
mise which python
```

旧版 NVM、独立安装的 Python、虚拟环境以及 IDE 的解释器设置，都可能影响实际使用的版本。桌面 IDE 也未必读取 PowerShell 的启动配置，应在 IDE 中确认项目解释器，Python 项目通常选择项目的 `.venv`。

## 12. 重装时需要保留什么

优先备份这些配置与项目文件：

- 全局配置：`$HOME\.config\mise\config.toml`。
- 每个项目的 `mise.toml`，以及项目已经使用的 mise 锁文件。
- Python 项目的 `pyproject.toml`、`uv.lock` 或 `requirements.txt`。
- Node 项目的 `package.json` 和对应包管理器的锁文件。
- PowerShell 启动配置，以及本文设置的环境变量记录。

缓存通常可以重新生成。重装后先恢复目录变量和配置，再用 `mise install` 恢复工具，用项目自己的包管理器恢复依赖。不要把跨机器复制整个语言安装目录，当作通用恢复方案。


Windows 下使用 mise 管理开发环境

最近在两台 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 

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