本文档完整记录 openEuler 25.09 + UKUI + VNC 环境下 fcitx5 输入法不可用、无法切换五笔等问题的排查过程、根因、修复步骤与验证方法,供后续维护参考。

1. 环境

2. 问题现象

1. VNC 登录后 fcitx5 输入法不可用 / 时好时坏;

2. 出现 fcitx5 托盘窗口,但点击无法切换输入法(无法切到五笔);

3. 日志中出现 Failed to open xim, retrying。

3. 根因分析

3.1 双实例 + 会话 D-Bus 分裂(切换失效的根本原因)

/root/.vnc/xstartup 原先写法:

unset DBUS_SESSION_BUS_ADDRESS
DISPLAY=:1 fcitx5 -d --replace >/dev/null 2>&1 &   # 提前、无总线启动
lightdm &
ukui-session &

问题链:

1. unset DBUS_SESSION_BUS_ADDRESS 后启动的 fcitx5 运行在私有会话总线上;

2. 桌面应用(ukui-session 启动的)各自跑在桌面会话总线上,看不到 fcitx5;

3. 桌面总线上的应用请求 org.fcitx.Fcitx5 时,D-Bus 自动激活出第二个 fcitx5 实例;

4. 两个 fcitx5 实例争抢 XIM 槽位 → Failed to open xim, retrying → 输入法失灵、切换无效。

3.2 托盘图标(次要)

• fcitx5 托盘图标由 notificationitem 插件(StatusNotifierItem,SNI)提供;

• 本 openEuler 5.1.12 构建里 GlobalConfig 的 DisabledAddons=notificationitem 配置运行时实际不生效(插件仍被加载,/proc/<pid>/maps 可证);

• 本机 ukui-panel 虽有 StatusNotifierWatcher,但 fcitx5 的 StatusNotifierItem 未注册(总线 ListNames 中无 org.kde.StatusNotifierItem-*),因此实际不显示托盘图标;

• 窗口树中的 "Fcitx5 Input Window" 是候选词输入窗口(打字必需),不是托盘,勿混淆。

4. 修复步骤

4.1 现场修复(杀掉双实例,在同一桌面总线上重启单个 fcitx5)

# 1) 获取桌面会话总线地址(来自 ukui-session / dbus-launch 进程环境)
tr '\0' '\n' < /proc/$(pgrep -f 'dbus-launch --exit-with-session' | head -1)/environ \
  | grep '^DBUS_SESSION_BUS_ADDRESS='        # 形如 unix:path=/tmp/dbus-XXXX,guid=...
​
# 2) 杀掉全部 fcitx5 实例
kill $(pgrep -x fcitx5); sleep 2
​
# 3) 携带桌面总线地址重启单个 fcitx5
DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/dbus-XXXX,guid=...' \
  DISPLAY=:1 fcitx5 -d --replace >/dev/null 2>&1 &

4.2 修改 /root/.vnc/xstartup(保证登录时正确启动,最终内容)

#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
export GTK_IM_MODULE='fcitx'
export QT_IM_MODULE='fcitx'
export XMODIFIERS='@im=fcitx'
lightdm &
ukui-session &
# 等待桌面会话总线就绪后,再在同一 D-Bus 上启动 fcitx5,避免桌面总线自动拉起第二个实例
i=0
while [ $i -lt 20 ]; do
    BUS=
    for PID in $(pgrep -x ukui-session; pgrep -f 'dbus-launch --exit-with-session'); do
        BUS=$(tr '\0' '\n' < /proc/$PID/environ 2>/dev/null | sed -n 's/^DBUS_SESSION_BUS_ADDRESS=//p')
        [ -n "$BUS" ] && break 2
    done
    i=$((i+1))
    sleep 1
done
[ -n "$BUS" ] && export DBUS_SESSION_BUS_ADDRESS="$BUS"
DISPLAY=:1 fcitx5 -d --replace >/dev/null 2>&1 &

要点:

• 必须遍历所有 ukui-session 进程再取 DBUS_SESSION_BUS_ADDRESS:pgrep -x ukui-session | head -n1 会命中没有该变量的进程(真正的变量在 dbus-launch 的子进程上),导致取不到地址、等待 20 秒超时后 fcitx5 又在无总线状态下启动(即又回到 3.1 的坑);

• fcitx5 必须与桌面应用共用同一会话总线,否则 D-Bus 会再次自动拉起第二个实例。

4.3 禁用托盘图标配置(尽力而为)

~/.config/fcitx5/config 的 [Behavior] 节:

[Behavior]
# Force Disabled Addons
DisabledAddons=notificationitem

⚠️ 如实说明:本构建中该配置未真正生效(见 3.2),但本机 SNI 本就未注册,实际观察结果即"无托盘图标"。若日后托盘图标出现,可考虑面板侧隐藏或更换 fcitx5 版本再查。

4.4 验证

export DISPLAY=:1
# 环境变量带桌面总线(按 4.1 取到的值)
​
# 1) 实例数应为 1
pgrep -a -x fcitx5; pgrep -c -x fcitx5
​
# 2) 切换五笔/英文
fcitx5-remote -s wbpy; fcitx5-remote -n        # 应输出 wbpy
fcitx5-remote -s keyboard-us; fcitx5-remote -n # 应输出 keyboard-us
​
# 3) XIM 已注册
xprop -root | grep XIM_SERVERS                # 应含 @server=fcitx
​
# 4) 无托盘图标(SNI 未注册,计数为 0)
dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus \
  org.freedesktop.DBus.ListNames | grep -c StatusNotifierItem
​
# 5) 窗口检查(需先安装:dnf install -y xwininfo)
xwininfo -root -tree | grep -iE 'fcitx'       # 只应有 Fcitx5 Input Window(候选词窗)

已验证结果:单实例 ✅、wbpy ↔ keyboard-us 切换正常 ✅、XIM 已注册 ✅、无托盘窗口 ✅。

5. 日常使用

若某个已打开的应用仍打不出中文:重启该应用即可(应用会重新连接 XIM/输入法服务),新打开的窗口不受影响。

6. 注意事项与坑(备忘)

1. 不要在 unset DBUS_SESSION_BUS_ADDRESS 后单独启动 fcitx5 —— 会导致桌面总线 D-Bus 自动激活第二个实例争抢 XIM(双实例坑),输入法失灵。

2. 取总线地址必须遍历所有 ukui-session 进程:pgrep -x ukui-session | head -n1 会命中没有 DBUS_SESSION_BUS_ADDRESS 的进程,导致取不到地址;等待循环超时后 fcitx5 又会在无总线状态下启动(坑会复发)。

3. DisabledAddons=notificationitem 在本 openEuler 5.1.12 构建中不生效(运行时仍加载 notificationitem 插件);托盘图标由该插件(SNI)提供,本机 SNI 未注册故实际无托盘图标。

4. "Fcitx5 Input Window" 是候选词窗口,不是托盘,不要误当作托盘去禁用。

5. 诊断命令需要 DISPLAY=:1 和桌面 DBUS_SESSION_BUS_ADDRESS,否则 fcitx5-remote/dbus-send 报 Failed to create dbus connection。

6. 窗口排查依赖 xwininfo(已安装:dnf install -y xwininfo);fcitx5-diagnose 可检查插件与输入法配置。

7. 默认输入法为五笔拼音 wbpy(profile:DefaultIM=wbpy),码表位于 /usr/share/libime/wbpy.main.dict。

7. 附录:关键文件与常用诊断命令

常用诊断命令速查:

# 进程 / 环境
ps aux | grep -E 'fcitx|Xvnc'
pgrep -a -x fcitx5
tr '\0' '\n' < /proc/<fcitx5-pid>/environ | grep -E 'DISPLAY|DBUS_SESSION_BUS_ADDRESS|XMODIFIERS'
​
# 会话总线
pgrep -a dbus-daemon
ls -la /tmp/dbus-*
​
# 输入法诊断 / XIM / 运行时插件加载
DISPLAY=:1 fcitx5-diagnose
xprop -root | grep XIM_SERVERS                    # 应含 @server=fcitx
grep -c libnotificationitem /proc/<fcitx5-pid>/maps   # 0 = 插件未加载
​
# 切换测试(需先 export DISPLAY=:1 与桌面总线地址)
fcitx5-remote -s wbpy; fcitx5-remote -n           # 应输出 wbpy
fcitx5-remote -s keyboard-us; fcitx5-remote -n    # 应输出 keyboard-us

记录日期：2026-08-04

1. 问题描述

在 锁屏界面 或 用户登录界面（greeter） 下按电源键无任何反应，无法关机；仅桌面正常会话下可关机。

2. 系统环境

3. 根因分析

/etc/systemd/logind.conf.d/power-ignore.conf 这个 drop-in 将电源键处理设置为：

[Login]
HandlePowerKey=ignore

而 systemd 的 drop-in 配置优先级高于主配置文件 /etc/systemd/logind.conf 中的 HandlePowerKey=poweroff，因此 logind 实际生效的电源键策略为 ignore（忽略），表现为按电源键无响应。

排查确认过程：

1. 主配置 /etc/systemd/logind.conf 已正确配置 HandlePowerKey=poweroff，acpid 未运行（不会与 logind 冲突）。
2. systemd-analyze cat-config systemd/logind.conf 显示 drop-in 覆盖了主配置，生效值为 ignore。
3. 通过 D-Bus 查询确认生效值：busctl get-property ... HandlePowerKey → s "ignore"。
4. loginctl（经 D-Bus ListInhibitors）确认无任何进程持有 handle-power-key 类型 inhibitor，排除进程拦截因素，纯属配置问题。

4. 修复步骤

修改 /etc/systemd/logind.conf.d/power-ignore.conf：

[Login]
# 电源键关机：修复锁屏/登录界面无法关机的问题（原为 ignore，覆盖了主配置的 poweroff）
HandlePowerKey=poweroff
# 即使有进程（如锁屏组件）声明抑制电源键，也执行关机，保证锁屏/登录界面可用
PowerKeyIgnoreInhibited=yes

重启 logind 使配置生效：

systemctl restart systemd-logind

5. 验证结果

检查项	结果
生效的 HandlePowerKey（D-Bus）	s "poweroff"
生效配置合并（cat-config）	HandlePowerKey=poweroff、PowerKeyIgnoreInhibited=yes
logind 监听电源键	日志出现 Watching system buttons on /dev/input/event0 (Power Button)
systemd-logind 服务状态	active，无报错
会话状态	正常，未受影响

6. 说明与回滚

• PowerKeyIgnoreInhibited=yes 保证即使锁屏组件（如 ukui-screensaver-backend）将来声明抑制电源键，logind 仍会执行关机；代价是桌面环境下会跳过应用/桌面环境的"关机确认对话框"直接关机。

openEuler 25.09 升级内核至 kernel 7.2.0（源码编译安装）

环境信息

编译与安装过程

1. 解压源码：linux-7.2.tar.gz（约 260MB，解压后 1.8G）→ linux-7.2/
2. 内核配置：复用当前运行内核配置（/proc/config.gz）→ .config，再执行 make olddefconfig 适配 7.2
3. 并发编译：make -j3（按需求限制并发为 3，防止系统死机；全量编译约 2.5 小时，产出 15000+ 目标文件）
4. 安装模块：make modules_install → /lib/modules/7.2.0
5. 安装内核：make install → /boot/vmlinuz-7.2.0、System.map-7.2.0、initramfs-7.2.0.img（dracut 生成）
6. 更新引导：grub 自动生成 openEuler (7.2.0) 25.09 菜单项，并通过 grub2-set-default 将默认启动项切换为 7.2.0

安装结果验证

• /boot/vmlinuz-7.2.0（13.8MB）、System.map-7.2.0、initramfs-7.2.0.img 均已生成
• /lib/modules/7.2.0 模块目录完整
• grub 默认项：saved_entry=openEuler (7.2.0) 25.09

NVIDIA 闭源驱动适配（580.159.04）

内核源码不包含 NVIDIA 闭源驱动（仅含开源 amdgpu/i915/nouveau，且 nouveau 被系统 blacklist）。为使 7.2.0 重启后显卡可用，通过 DKMS 为 7.2.0 重新编译安装闭源驱动 nvidia/580.159.04，过程中修复了 3 类内核 7.2 兼容问题：

1. strncpy 被内核 7.2 彻底移除

内核 7.2 的 lib/string.c 已无 strncpy 实现，驱动直接调用会报"隐式声明"错误。将驱动 4 个文件中 7 处 strncpy 替换为 strscpy：

• nvidia/os-interface.c
• nvidia/linux_nvswitch.c
• nvidia-modeset/nvidia-modeset-linux.c
• nvidia-uvm/uvm_pmm_gpu.c

2. DRM atomic API 重构（drm_atomic_state → drm_atomic_commit）

内核 7.2 彻底移除了 struct drm_atomic_state 类型，重构为 struct drm_atomic_commit，相关 API 同步改名。对 nvidia-drm 模块做批量适配：

• 类型替换：struct drm_atomic_state → struct drm_atomic_commit（约 22 处，5 个源文件）
• 函数改名：drm_atomic_state_alloc/put/init/default_clear/default_release → 对应 drm_atomic_commit_*（8 处）
• 注意保留驱动自有函数 nv_drm_atomic_state_* 不被误改（用词边界正则）

3. conftest.sh 签名检测过时

驱动构建时通过 conftest.sh 检测内核 atomic_check 回调签名以选择代码分支，但检测代码仍使用旧类型 struct drm_atomic_state，在 7.2 内核下检测失败导致走错分支。将两处检测函数参数改为 struct drm_atomic_commit *state 后恢复正常。

并发限制

• /usr/src/nvidia-580.159.04/dkms.conf：-j6 → -j3
• /etc/dkms/framework.conf：parallel_jobs=3

驱动安装验证

$ dkms status
nvidia/580.159.04, 7.1.2, x86_64: installed
nvidia/580.159.04, 7.2.0, x86_64: installed

• DKMS 退出码 0；5 个模块（nvidia / nvidia-uvm / nvidia-modeset / nvidia-drm / nvidia-peermem）已装入 /lib/modules/7.2.0/kernel/drivers/video/
• initramfs 已重建并包含 nvidia 模块加载配置

重启后验证命令

uname -r                    # 应为 7.2.0
lsmod | grep nvidia         # 应有 nvidia、nvidia_drm 等
nvidia-smi                  # 应正常显示 GTX 750

回滚方案

grub 菜单保留旧内核项 openEuler (7.1.2) 25.09。若 7.2.0 异常，可在开机菜单选择旧内核启动；或执行 grub2-set-default 'openEuler (7.1.2) 25.09' 恢复默认。

备注

• 源码目录中的 kernel-install.sh 为编译安装流水线脚本（等待编译→安装模块→安装内核），可删除
• 全部编译安装操作并发均 ≤ 3，避免系统负载过高死机

zblog-php版本使用 ly_ueditor_plus编辑器插件，复制的文章内容不支持自动换行解决方法。
针对「从网上复制文章/终端内容，粘贴进 UEditorPlus 编辑器后换行丢失、代码黏成一行」问题的完整分析、修复与验证记录。

一、问题现象

在 UEditorPlus（v2.0.0）编辑器里粘贴以下内容时，换行全部丢失，所有代码黏成一行：

• 从网页复制的代码块（<pre> / <pre><code> / <span class="token …"> 高亮结构）
• 从终端 / 纯文本文件复制的多行命令脚本（# 注释、\ 续行、空行）

典型表现：…libfastjson# （关键：…、/root/rpmbuild/RPMS/x86_64rpm -Uvh … 直接粘连。

二、根因分析（三层叠加，缺一不可）

粘贴管线（UE.plugins.paste）处理顺序为：

pastebin innerHTML → UE.filterWord → 换行转换(本次新增) → UE.htmlparser → filterInputRule → insertHtml

根因 1：UE.filterWord 折叠全量换行

filterWord 内部 t() 函数第一行执行 .replace(/[\t\r\n]+/g," ")，会把**整段 HTML（含 <pre> 内部）**的换行/制表符折叠成空格。

• 触发条件：内容匹配 Word 特征（class="?Mso / mso- 样式 / w:WordDocument / lang= 等），带 lang= 属性的网页很常见；
• 原代码无任何 <pre> 保护，代码块换行被无差别压平。

根因 2：纯文本粘贴的 \n 无换行渲染

从终端/文本文件复制时，剪贴板只有 text/plain。Chrome 将多行内容作为单个含 \n 的文本节点插入编辑器，而正文 white-space: normal 会把文本节点里的 \n 渲染折叠成空格 → 视觉上一行。

根因 3：UE.htmlparser 剥除标签相邻换行（最终真凶）

网页代码块普遍是 <pre><code><span class="token …">行内容</span>\n…</code></pre> 结构，换行符其实都在。但 htmlparser 的空白清理正则

[\r\t\n ]*</?(\w+)…>[ \t\r\n]*

会把 span/code/pre/br 等白名单标签两侧的 \n\r 全部剥掉（</span>\n<span>、</code>\n 等位置的换行被吞），且此清理发生在解析阶段，后续任何处理都无法找回。

三者关系：修复 1 只管 Word 样式内容；修复 2 覆盖纯文本；但即使前两者都通过，只要换行以 \n 形式进入 htmlparser 且紧贴 span/code 标签，仍会被根因 3 剥除——这正是历次修复后线上仍失败的原因。

三、修复方案（ueditor-plus/ueditor.all.js 粘贴插件，共 4 处）

修复 A：filterWord 保护 <pre> 块

UE.filterWord 内部 t() 函数开头摘出所有 <pre>…</pre> 块（占位符 \u0000UEPRE{n}\u0000），完成 Word 清理链后再原样还原：

function t(t){var a=[];return t=t.replace(/<pre[\s\S]*?<\/pre>/gi,function(e){    return a.push(e),"\u0000UEPRE"+(a.length-1)+"\u0000"}), t.replace(/[\t\r\n]+/g," ") /* …原 Word 清理链… */  .replace(/\u0000UEPRE(\d+)\u0000/g,function(e,i){return a[i]});}

修复 B：粘贴时读取剪贴板 text/plain 回退恢复

来源网页若连 \n 都不给（行间无换行符渲染），HTML 已无法自愈。修复在粘贴事件里读取 clipboardData.getData("text/plain")（纯文本永远带换行），当 <pre> 内换行数明显少于纯文本行数、且两者去空白后内容一致时，用纯文本按行重建 pre：

// 事件监听处i(e, t.clipboardData && t.clipboardData.getData ? t.clipboardData.getData("text/plain") : "")// i(e,p) 内:恢复逻辑(实体解码、空白不敏感匹配、$1/$& 替换符用函数回调防吞)

修复 C：<pre> 内 \n 直接转为 <br/>（关键）

把换行转换中的 pre 处理从「占位保护再还原」改为直接替换，让 \n 根本不出现在 htmlparser 输入里，从而根除根因 3：

i = i.replace(/\r\n?/g,"\n")     .replace(/<pre[\s\S]*?<\/pre>/gi, function(e){ return e.replace(/\n/g,"<br/>"); }) // pre 内 \n→<br/>     .replace(/<[^>]*>/g, function(e){ return e.replace(/\n/g,"\u0002"); })             // 标签内换行安全清理     .replace(/([^<>\u0001\u0002])(\n+)(?=[^<>\u0001\u0002])/g, /*文本内换行→等量<br/>*/)     .replace(/\n/g,"").replace(/\u0002/g,"");                                            // 标签间残留清理

<br/> 是 UEditor 代码块的天然换行格式（自带「插入代码」功能即以此存储），htmlparser 不再有 \n 可剥。

修复 D：纯文本（无 pre）换行 → <br/>

修复 C 中第三段正则同时覆盖普通文本节点：line1\nline2 → line1<br/>line2，空行 \n\n → 双 <br/>；段落间 </p>\n<p> 因 \n 紧贴标签而自动忽略，不产生多余 <br>。

四、验证结果

仿真方法：Node 环境加载真实 ueditor.all.js，从文件中抽取注入的转换/恢复表达式，全链路复刻 恢复 → filterWord → 换行转换 → htmlparser → filterInputRule → toHtml，断言最终 insertHtml 内容。测试脚本：test_paste_pipeline.js（工作区根目录，可随时重跑复验）。

五、部署与缓存

改动涉及两个文件，必须同时上传：

上传后 Ctrl+F5 强刷编辑页。若仍有异常，可用 paste_diagnose.html（上传到插件目录后浏览器打开）——它直接读取剪贴板 text/html 与 text/plain，并逐步复刻粘贴管线，红色步骤即换行丢失点。

六、文件变更清单

ueditor-plus/ueditor.all.js        粘贴插件修复(4处)+filterWord pre 保护ly_ueditor_plus_core.php           版本号 ?0309→?0313paste_diagnose.html                诊断页(捕获剪贴板双格式+管线分步)test_paste_pipeline.js             Node 全链路仿真测试(13 用例)

rsyslog 8.2312.0 重建修复记录

修复 glibc 2.44 升级后 rsyslogd SIGSEGV 崩溃循环的完整工程归档

 目录

• 一、项目简介
• 二、问题背景
• 三、根因分析
• 四、修复方案
• 五、验证结果
• 六、仓库结构
• 七、快速开始（重建步骤）
• 八、相关仓库
• 九、遗留事项
• 十、经验总结
• 许可协议

一、项目简介

本仓库归档了 rsyslog 8.2312.0 在 openEuler 2509（含 Kylin 组件）主机上，
因自编译 glibc 2.44 升级引发的 rsyslogd SIGSEGV 崩溃循环 的完整修复过程：

•  发行版源码包（src.rpm）、spec、上游源码与全部补丁
•  可复现的构建脚本（与 libfastjson 一致的 build_ldflags，保持 ABI 一致）
•  重建后的 RPM 产物
•  实际生效的配置文件（rsyslog.conf、haproxy.conf、systemd 单元等）
•  问题根因、修复方案、验证结果

依赖：必须先重建并安装 libfastjson（修复 modf IFUNC 预取崩溃），详见
micoder/libfastjson(#八相关仓库)。

二、问题背景

升级 glibc 2.44 后，rsyslog.service 陷入崩溃循环，每次重启后约 2 秒即再次崩溃：

rsyslog.service: Main process exited, code=dumped, status=11/SEGV
rsyslogd: Relink `/usr/lib64/libfastjson.so.4' with `/usr/lib64/libm.so.6' for IFUNC symbol `modf'
rsyslogd[xxxxx]: segfault at 9f ip ... in libm.so.6[46d52,...] error 4

影响范围：

• 系统日志服务不可用：/var/log/messages、secure、cron 等全部停写
• journald 被崩溃信息刷屏（近 3 天 7018 条 err 日志几乎全是崩溃循环）
• 堆积 33,473 个 coredump，占用 4.1GB 磁盘（已清理，见第九节）

三、根因分析

崩溃的直接触发点是 libfastjson.so.4，而非 rsyslog 本体：

1. rsyslogd -N1 配置测试即段错误（exit=139），gdb 回溯定位到
   ld-linux 调用 libm.so.6 内 modf IFUNC 解析器时崩溃。

2. 反汇编 modf@@GLIBC_2.2.5 解析器（libm+0x46d40）：

   46d44: mov  0xca285(%rip),%rax   ; 取 GOT 槽 0x110fd0（_rtld_global_ro@GLIBC_PRIVATE）
   46d52: testb $0x10, 0x9f(%rax)   ; <<< %rax==NULL，读 0x9f 崩溃
   

3. libfastjson.so.4 的 DT_NEEDED 只有 libc.so.6，缺少 libm.so.6：
   libc 也导出 modf（弱 IFUNC），链接期 --as-needed 因此丢弃了 -lm。

4. 运行时 libfastjson 的 modf 引用经全局作用域预取绑定到 libm 的 IFUNC，
   该预取路径下解析器读取 _rtld_global_ro GOT 槽时为 NULL → SIGSEGV。

5. 对照实验：直接 gcc test.c -lm 调用 modf 正常（exit=0），证明 glibc 2.44
   的 modf 本身没有坏，是链接/预取方式的问题。

修复方向由动态链接器直接给出：“Relink libfastjson.so.4 with libm.so.6 for
IFUNC symbol modf”。详细证据链见 REPORT.md。

四、修复方案

保留 glibc 2.44，分两步重建：

rsyslog 重建命令：

rpmbuild --rebuild --nocheck \
    --define 'dist .oe2509' \
    --define 'build_ldflags -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/generic-hardened-ld -Wl,--no-as-needed -lm' \
    rsyslog-8.2312.0-8.oe2509.src.rpm

五、验证结果

六、仓库结构

rsyslog/
├── README.md                    # 本文件（项目总览）
├── REPORT.md                    # 完整修复总结报告
├── build.sh                     # 可复现构建脚本（含关键参数说明）
├── SOURCES/
│   ├── rsyslog-8.2312.0.tar.gz        # 上游源码包
│   ├── rsyslog-doc-8.2312.0.tar.gz    # 上游文档源码包
│   ├── rsyslog.spec                   # 发行版 spec（未改动）
│   ├── *.patch                        # 发行版携带的补丁（backport/bugfix）
│   └── *.sh                           # 发行版附带脚本（时区检查、日志轮转等）
├── SRPMS/
│   └── rsyslog-8.2312.0-8.oe2509.src.rpm   # 发行版源码 RPM
├── RPMS/
│   ├── rsyslog-8.2312.0-8.oe2509.x86_64.rpm        # 重建后的主包（修复产物）
│   ├── rsyslog-help-8.2312.0-8.oe2509.noarch.rpm   # 帮助文档包
│   └── rsyslog-{crypto,elasticsearch,gnutls,gssapi,hiredis,kafka,mmaudit,mmjsonparse,mmkubernetes,mmnormalize,mmsnmptrapd,mmtaghostname,mongodb,mysql,omamqp1,pgsql,rabbitmq,relp,snmp,udpspoof}-8.2312.0-8.oe2509.x86_64.rpm   # 20 个功能子包（模块产物）
└── CONFIG/
    ├── rsyslog.conf                 # 实际生效的主配置（/etc/rsyslog.conf）
    ├── rsyslog.d/
    │   └── haproxy.conf             # 附加配置（haproxy 日志）
    ├── rsyslog.service              # systemd 单元文件
    └── rsyslog.sysconfig            # sysconfig 配置

说明：重建过程共生成 20 个功能子包（mysql / mongodb / kafka / relp /
gnutls / elasticsearch 等模块），本次修复只需基础包（系统仅安装了基础包，
子包未安装），但全部子包产物已随本仓库归档，可按需安装。

七、快速开始（重建步骤）

# 0. 前置：先按 micoder/libfastjson 仓库重建并安装 libfastjson
#    （关键：DT_NEEDED 包含 libm.so.6，modf IFUNC 直接绑定）

# 1. 环境准备（确保 source 仓库已启用）
dnf repolist --enabled | grep -i source

# 2. 获取源码包并安装构建依赖
cd /root/rpmbuild/SRPMS
dnf download --source rsyslog
dnf builddep -y rsyslog-8.2312.0-8.oe2509.src.rpm

# 3. 重建 RPM（--nocheck 跳过耗时测试；关键参数见 build.sh 注释）
rpmbuild --rebuild --nocheck \
    --define 'dist .oe2509' \
    --define 'build_ldflags -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/generic-hardened-ld -Wl,--no-as-needed -lm' \
    rsyslog-8.2312.0-8.oe2509.src.rpm

# 4. 安装重建后的基础 RPM（同版本替换）
cd /root/rpmbuild/RPMS/x86_64
rpm -Uvh --replacepkgs rsyslog-8.2312.0-8.oe2509.x86_64.rpm

# 5. 验证
rsyslogd -N1                          # 应 exit=0
systemctl start rsyslog && systemctl is-active rsyslog   # 应 active
logger "verification" && tail -3 /var/log/messages       # 应恢复写入

完整脚本见 build.sh，可直接执行。

八、相关仓库

九、遗留事项

1. coredump 清理：已删除 /var/lib/systemd/coredump/*（33,473 个文件，
   释放约 4GB 磁盘）。若生产环境需保留事故现场，可先归档再清理。
2. openssh 10.5p1：本机同为自编译（依赖新 glibc），当前 sshd 运行正常；
   若日后出现类似 IFUNC 崩溃，可套用本方案（--no-as-needed -lm）重建。
3. glibc 2.44 为无签名自编译包：RPM 数据库层面建议保留 src.rpm 备份，
   避免后续 dnf 升级时被系统 glibc 意外覆盖造成版本错乱。

十、经验总结

1. 自编译 glibc 替换系统 glibc 影响面极大，IFUNC / symbol preemption 是
   最容易踩坑的路径；升级后必须全量回归常驻服务（日志、网络、数据库等）。
2. 动态链接器的 “Relink X with Y for IFUNC symbol S” 警告是直接可用的修复
   指引——把引用方与被引用库直接链接即可。
3. 排查手法沉淀：dmesg 定位段错误 → gdb 回溯 → 反汇编崩溃地址 →
   readelf -d 检查 DT_NEEDED → 最小程序对照验证。
4. 版本化 RPM 重建（--define 'dist' + 同版本替换）可保证系统可回退、
   可审计，优于直接覆盖二进制。

许可协议

本仓库内容遵循上游项目的 GPLv3+ 与 ASL 2.0（见 [rsyslog.spec]SOURCES/rsyslog.spec
License: (GPLv3+ and ASL 2.0)）。重建产物 RPM 均基于 openEuler 发行版源码包
构建，构建产物的许可遵循对应上游与发行版约定。

libfastjson 1.2304.0 重建修复记录

适配自编译 glibc 2.44 的 IFUNC modf 崩溃修复工程归档

 目录

• 一、项目简介
• 二、问题背景
• 三、根因分析
• 四、修复方案
• 五、验证结果
• 六、仓库结构
• 七、快速开始（重建步骤）
• 八、相关仓库
• 九、遗留事项
• 十、经验总结
• 许可协议

一、项目简介

本仓库归档了 libfastjson 1.2304.0 在 openEuler 2509（含 Kylin 组件）主机上，
因自编译 glibc 2.44 升级引发的 rsyslogd SIGSEGV 崩溃循环 的完整修复过程：

• 发行版源码包（src.rpm）、spec 与上游源码
•  可复现的构建脚本（关键参数：-Wl,--no-as-needed -lm 强制直接链接 libm.so.6）
•  重建后的 RPM 产物
• 问题根因、反汇编证据、验证结果

背景：2026-08-22 主机手动构建并安装了 glibc 2.44-1（无签名，替代发行版
glibc 2.38-71.oe2509），随后 rsyslog 服务崩溃循环，系统日志收集中断。

二、问题背景

升级 glibc 2.44 后，rsyslog.service 陷入崩溃循环：

rsyslog.service: Main process exited, code=dumped, status=11/SEGV
rsyslogd: Relink `/usr/lib64/libfastjson.so.4' with `/usr/lib64/libm.so.6' for IFUNC symbol `modf'
rsyslogd[xxxxx]: segfault at 9f ip ... in libm.so.6[46d52,...] error 4

影响范围：

• 每 1.5~2 秒崩溃一次（SIGSEGV），systemd 无限自动重启
• /var/log/messages、secure、cron 等全部停写
• journald 被崩溃信息刷屏（近 3 天 7018 条 err 日志）
• 堆积 33,473 个 coredump，占用 4.1GB 磁盘

三、根因分析

3.1 崩溃定位链

1. rsyslogd -N1 配置测试直接段错误（exit=139）；gdb 回溯显示崩溃发生在
   动态链接器 ld-linux-x86-64.so.2 调用 libm.so.6 内 IFUNC 解析器期间。

2. 反汇编 libm.so.6 + 0x46d52（即 modf@@GLIBC_2.2.5 IFUNC 解析器）：

   46d40:  endbr64
   46d44:  mov  0xca285(%rip),%rax   ; 取 GOT 槽 0x110fd0 内容
   46d52:  testb $0x10, 0x9f(%rax)   ; <<< 崩溃：%rax == 0，读地址 0x9f
   

   解析器从 GOT 槽读取 _rtld_global_ro@GLIBC_PRIVATE 指针（CPU 特性数据），
   运行时该 GOT 槽为 NULL。

3. libfastjson.so.4 的 DT_NEEDED 只有 libc.so.6，缺少 libm.so.6：
   libc.so.6 也导出 modf（弱 IFUNC），链接期 --as-needed 把 -lm 丢弃。

4. 运行时 libfastjson 的 modf 引用经全局作用域预取（symbol preemption）
   绑定到 libm 的 IFUNC；该路径下解析器执行时 _rtld_global_ro GOT 槽
   尚未正确填充 → NULL 解引用 → SIGSEGV。

3.2 关键对照实验

结论：问题不是 glibc 2.44 的 modf 本身损坏，而是 libfastjson 未直接链接
libm 导致的 IFUNC 预取路径问题。动态链接器给出的提示正是修复方向：
“Relink libfastjson.so.4 with libm.so.6 for IFUNC symbol modf”。

四、修复方案

保留 glibc 2.44，重建 libfastjson，强制其直接链接 libm.so.6：

rpmbuild --rebuild \
    --define 'dist .oe2509' \
    --define 'build_ldflags -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/generic-hardened-ld -Wl,--no-as-needed -lm' \
    libfastjson-1.2304.0-2.oe2509.src.rpm

五、验证结果

六、仓库结构

libfastjson/
├── README.md                    # 本文件（项目总览）
├── REPORT.md                    # 完整修复总结报告
├── build.sh                     # 可复现构建脚本（含关键参数说明）
├── SOURCES/
│   ├── libfastjson-1.2304.0.tar.gz   # 上游源码包
│   └── libfastjson.spec               # 发行版 spec（未改动）
├── SRPMS/
│   └── libfastjson-1.2304.0-2.oe2509.src.rpm   # 发行版源码 RPM
└── RPMS/
    ├── libfastjson-1.2304.0-2.oe2509.x86_64.rpm        # 重建后的主包（修复产物）
    ├── libfastjson-devel-1.2304.0-2.oe2509.x86_64.rpm  # 开发头文件包
    ├── libfastjson-debuginfo-1.2304.0-2.oe2509.x86_64.rpm    # 调试信息包
    └── libfastjson-debugsource-1.2304.0-2.oe2509.x86_64.rpm  # 调试源码包

七、快速开始（重建步骤）

# 1. 环境准备（确保 source 仓库已启用、构建工具链就绪）
dnf repolist --enabled | grep -i source
dnf install -y gcc make cmake rpm-build

# 2. 获取源码包并安装构建依赖
cd /root/rpmbuild/SRPMS
dnf download --source libfastjson
dnf builddep -y libfastjson-1.2304.0-2.oe2509.src.rpm

# 3. 重建 RPM（关键参数见 build.sh 注释）
rpmbuild --rebuild \
    --define 'dist .oe2509' \
    --define 'build_ldflags -Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/generic-hardened-ld -Wl,--no-as-needed -lm' \
    libfastjson-1.2304.0-2.oe2509.src.rpm

# 4. 安装重建后的 RPM（同版本替换）
cd /root/rpmbuild/RPMS/x86_64
rpm -Uvh --replacepkgs \
    libfastjson-1.2304.0-2.oe2509.x86_64.rpm \
    libfastjson-devel-1.2304.0-2.oe2509.x86_64.rpm

# 5. 验证
readelf -d /usr/lib64/libfastjson.so.4 | grep NEEDED   # 应包含 libm.so.6
rsyslogd -N1                                           # 应 exit=0

完整脚本见 build.sh，可直接执行。

八、相关仓库

九、遗留事项

1. coredump 清理：已删除 /var/lib/systemd/coredump/*（33,473 个文件，释放约 4GB）。
   生产环境如需保留事故现场，可先归档再清理。
2. openssh 10.5p1：本机同为自编译（依赖新 glibc），当前 sshd 运行正常；
   若日后出现类似 IFUNC 崩溃，可套用本方案（--no-as-needed -lm）重建。
3. glibc 2.44 为无签名自编译包：建议保留 src.rpm 备份，避免 dnf 升级时被
   系统 glibc 意外覆盖造成版本错乱。

十、经验总结

1. 自编译 glibc 替换系统 glibc 影响面极大：所有发行版二进制都按旧 glibc ABI
   构建，IFUNC / symbol preemption 路径最容易踩坑；升级后必须全量回归常驻服务
   （日志、网络、数据库等）。
2. 动态链接器的 “Relink X with Y for IFUNC symbol S” 警告是直接可用的修复
   指引——把引用方与被引用库直接链接即可。
3. 排查手法沉淀：dmesg 定位段错误 → gdb 回溯 → 反汇编崩溃地址 →
   readelf -d 检查 DT_NEEDED → 最小程序对照验证。
4. 版本化 RPM 重建（--define 'dist' + 同版本替换）可保证系统可回退、
   可审计，优于直接覆盖二进制。

许可协议

本仓库内容遵循上游项目的 MIT License（见 libfastjson.spec(SOURCES/libfastjson.spec)
License: MIT）。重建产物 RPM 均基于 openEuler 发行版源码包构建，构建产物
的许可遵循对应上游与发行版约定。

项目简介

本仓库为在 openEuler 2509 系统中以 RPM 方式打包构建 glibc-2.44 的工程文件。

项目由原 glibc-2.38 补丁集仓库经过架构过滤、补丁适用性审计、spec 适配后升级而来，最终保留 4 个可应用于 glibc-2.44 的厂商定制/兼容性补丁。

仓库结构

glibc.spec                                    主打包配置（Version 2.44 / Release 1）
glibc.yaml                                    OBS 构建配置（version_control）
glibc-2.44.tar.gz                             上游源码包（本地保留，未纳入 git）
.patch × 4                                    厂商定制/兼容性补丁（见下）
bench.mk / glibc-bench-compare                benchtests 相关（Source3/4）
LanguageList                                  locale 语言列表（Source5，%install 使用）
nscd.conf / nsswitch.conf                     Source1/2，安装至 /etc
replace_same_file_to_hard_link.py             Source7，locale 硬链接处理
testsuite_whitelist                           Source8，%check 测试白名单
.gitignore                                    排除 glibc-2.44.tar.gz

保留的补丁（Patch0~Patch3）

主要变更记录

1. 补丁裁剪：370 → 4

原仓库 370 个补丁，历经两轮清理：

• 架构过滤：仅保留 x86（x86_64/i386）与 arm（aarch64）相关补丁，删除 LoongArch、Sw64、S390、PowerPC、SPARC 等其他架构补丁及通用补丁（370 → 123）
• 2.44 适用性审计：将 123 个补丁按 spec 顺序对 glibc-2.44 源码逐一 git apply --check，并做纯净树复检交叉验证——
  • 117 个不适用（绝大多数为 2.38 时代的上游 backport，2.44 已包含）→ 删除
  • 2 个经源码对照判定失效/冗余 → 删除：
    • AArch64-Use-prefer_sve_ifuncs-for-SVE-memset.patch：prefer_sve_ifuncs 变量在 2.44 已被上游移除（memcpy.c 重构），引用会导致编译失败
    • 0002-x86-Lower-non-temporal-copy-threshold-for-Hygon.patch：Hygon 3/8 非时序拷贝阈值功能已被 2.44 上游以更优形式包含
  • 最终保留 4 个可干净应用且功能仍需要的厂商定制/兼容补丁

2. spec 适配（2.38 → 2.44）

%autosetup -n %{name}-%{version} -p1 随 Version 自动适配解包目录。

3. 文件清理

• 删除：其他架构补丁、通用补丁、不适用/失效补丁（共 366 个）、旧源码包 glibc-2.38.tar.xz、未使用的 LicenseList（Source6 声明但从未引用）
• 保留：全部被 spec 引用的 Source 文件与辅助配置

补丁适用性审计方法

1. 解包 glibc-2.44.tar.gz 得到纯净源码树
2. 按 spec 中 Patch 声明顺序，逐一对每个补丁执行 git apply --check -p1（可应用则 git apply 继续），模拟 %autosetup 行为
3. 对失败补丁在纯净树复检，排除"前序补丁导致的时序冲突"误判
4. 对文本可应用的补丁再做源码对照：确认改动未被 2.44 上游包含、引用的变量/宏仍存在、构建机制（如 relro-LDFLAGS）仍生效

构建方法（openEuler 2509）

# 1. 安装构建依赖
dnf install -y gcc gcc-c++ binutils make >= 4.0 bison >= 2.7 gawk gettext \
    texinfo audit-libs-devel libcap-devel procps-ng util-linux \
    systemtap-sdt-devel systemd python3 m4 chrpath libselinux-devel \
    elfutils libidn2 gd-devel libpng-devel zlib-devel kernel-headers

# 2. 准备源码包（Source0 由 URL 下载，或使用本地 glibc-2.44.tar.gz）
curl -O https://ftp.gnu.org/gnu/glibc/glibc-2.44.tar.gz

# 3. 本地构建
rpmbuild -ba glibc.spec

# 4. 或通过 OBS 构建（glibc.yaml 提供版本控制信息）

备注

• 源码包不纳入 git：glibc-2.44.tar.gz（约 39 MiB）超过 gitcode 单文件 10 MiB 限制，且远端项目未启用 Git LFS（project lfs not enabled），故保留本地、由 .gitignore 排除，构建时由 Source0 URL 下载
• 本地已安装 git-lfs（3.6.1），若日后在 gitcode 启用 LFS，可将源码包迁移为 LFS 跟踪
• 补丁适用性审计为静态验证（git apply --check + 源码对照）；已在 openEuler 25.09 本机完成一次完整 rpmbuild 构建验证（见下节）

本机 RPM 构建验证（2026-08-22）

在 openEuler 25.09 本机成功完成 glibc-2.44 的 RPM 构建。

构建环境：gcc 12.3.1、binutils 2.41、make 4.4.1、python 3.11.13，均满足 2.44 INSTALL 工具链要求。

构建命令（4 核限制避免主机过载，跳过测试套件）：

rpmbuild -ba --without testsuite --define "_smp_mflags -j4" SPECS/glibc.spec

构建中修复的错误：

brp 阶段的 find/grep/xargs symbol lookup error（系统工具加载构建树内新 libc）为非致命警告，不影响产物。

构建产物（15 个）：14 个二进制 RPM + 1 个 SRPM

• 二进制：glibc、glibc-common、glibc-devel、glibc-all-langpacks、glibc-locale-archive、glibc-locale-source、glibc-help、nscd、libnsl、nss_modules、glibc-nss-devel、glibc-debugutils、glibc-debuginfo、glibc-debugsource
• 源码：SRPMS/glibc-2.44-1.src.rpm

验证：主包元数据 glibc-2.44-1.x86_64 正确；/lib64/libc.so.6、/lib64/ld-linux-x86-64.so.2、/lib64/libm.so.6 均在包内；产物清单与构建日志"已写至"完全一致。

EulerMaker（openEuler 2403）构建问题修复（2026-08-22）

在 EulerMaker 平台使用 openEuler 2403 构建时，%install 阶段报 rpath 检查错误：

ERROR 0020: file '/usr/lib64/gconv/IBM1162.so' contains a rpath referencing '..' of an absolute path [/usr/lib/gcc/x86_64-openEuler-linux/12/../../../../lib64/]

根因：glibc-2.44 链接 gconv 模块与 sotruss-lib.so 等共享库时注入 -Wl,-rpath，其中包含 gcc 默认库路径（/usr/lib/gcc/.../12/../../../../lib64/，含 .. 非规范路径）；openEuler 2403 的 brp rpath 检查（ERROR 0020）拒绝此类路径导致 %install 失败。spec 原有 removeLoadPath() 仅匹配 $ORIGIN 开头的 rpath（为 2.38 时代设计），未覆盖 gcc 路径 rpath。本地 25.09 构建不受影响（其 rpath 检查不致命）。

修复（提交 7f07460）：

验证：本地重建后检查新包——253 个 gconv 模块及全部 277 个真实 ELF 文件均无 rpath；构建产物完整（15 个）。

EulerMaker %check 修复与构建成功（2026-08-22）

问题：EulerMaker（openeuler:24.03-lts-sp4-amd64）构建在 %check 阶段失败，两次失败原因不同：

1. 无 -k 中止：math/elf 子目录测试失败（openEuler 24.03 环境相关，本地 25.09 全部通过）导致 make check 中止 → 顶层 tests.sum 未生成 → test -s tests.sum 在 set -e 下失败 → %check 退出
2. Summary 检查误判：加 -k 后子目录测试失败时顶层 tests target not remade → tests.sum 与 Summary 行均不生成 → 原 Summary 检查将测试失败误判为"测试套件构建失败"→ exit 1

修复（两个提交）：

验证：rpmspec -P 解析、%check 段 bash -n、三场景逻辑模拟（EulerMaker 实况不中止 / 全部通过不中止 / 真构建失败仍致命）均通过。

结果：EulerMaker 平台 rpmbuild 构建 RPM 成功（2026-08-22）。

OpenSSH 10.5p1 - openEuler RPM 打包项目

openssh/
├── openssh-10.5p1.tar.gz          # OpenSSH 10.5p1 源码包
├── openssh.spec                   # RPM 规范文件（当前版本：10.5p1）
├── openssh-10.4p1.spec            # RPM 规范文件（历史版本：10.4p1）
├── openssh-v10.3p1.spec           # RPM 规范文件（历史版本：10.3p1）
├── openssh-v10.2p1.spec           # RPM 规范文件（历史版本：10.2p1）
├── build.sh                       # 自动构建脚本
├── sshd.pam                       # PAM 配置
├── sshd.service                   # Systemd 服务单元
├── sshd.sysconfig                 # 服务环境变量配置
├── sshd_config                    # 自定义 SSH 服务端配置
└── README.md                      # 本文档

# 以 root 身份运行
sudo bash build.sh

# 1. 安装构建依赖
sudo dnf install -y rpm-build autoconf automake make gcc gcc-c++ \
    dos2unix groff util-linux perl-interpreter perl-generators \
    perl-podlators zlib-devel openssl-devel pam-devel \
    libselinux-devel audit-libs-devel krb5-devel systemd-devel \
    p11-kit-devel openldap-devel gtk2-devel libX11-devel \
    libedit-devel ncurses-devel xauth gnupg2

# 2. 设置 RPM 构建目录
mkdir -p ~/rpmbuild/{SOURCES,SPECS,SRPMS,RPMS,BUILD,BUILDROOT}

# 3. 拷贝源码和辅助文件
cp openssh-10.5p1.tar.gz ~/rpmbuild/SOURCES/
cp sshd.pam sshd.sysconfig sshd.service sshd_config ~/rpmbuild/SOURCES/
cp openssh.spec ~/rpmbuild/SPECS/

# 4. 构建
rpmbuild -ba ~/rpmbuild/SPECS/openssh.spec

# 安装所有包
sudo rpm -Uvh ~/rpmbuild/RPMS/*/openssh-*.rpm

# 或使用 dnf
sudo dnf localinstall ~/rpmbuild/RPMS/*/openssh-*.rpm

# 启动服务
sudo systemctl start sshd

# 设置开机自启
sudo systemctl enable sshd

# 查看状态
sudo systemctl status sshd

# 重启服务（重新加载配置）
sudo systemctl restart sshd

# 发行版标识（dist 宏）：默认留空（不传 dist 参数）；仅本机打包时填写，如 .oe2509
DIST=""

# 根据 DIST 是否填写构造 rpmbuild 参数（为空则不添加 --define "dist ..."）
DIST_ARGS=()
if [ -n "$DIST" ]; then
    DIST_ARGS=(--define "dist $DIST")
fi

# systemd RPM 宏（systemd_post 等）来源：openEuler 25.09+ 提供独立的
# systemd-rpm-macros 包；22.03/24.03 等低版本由 systemd 包提供，按版本选择依赖
%global oe_major %(sed 's/^openEuler release //' /etc/openEuler-release 2>/dev/null | cut -d. -f1 || echo 0)
%if 0%{oe_major} >= 25
BuildRequires:  systemd-rpm-macros
%else
BuildRequires:  systemd
%endif

gotcper TCP调试助手：一个基于 Go + Walk 编写的图形化 TCP 调试工具，纯 Go 编译（CGO 关闭，无需 C/C++ 工具链），Windows 原生界面，零运行时依赖。

项目地址：gotcper:基于 Go + Walk 的图形化 TCP 调试助手项目 - AtomGit

伟迪捷（Videojet）打码机的通讯协议中所指的“Unicode协议”，具体编码方式为 UTF-16LE（小端序）。

这个信息非常关键，也直接解释了之前你遇到的乱码问题：

• 当调试助手用 UTF-8 或 ANSI/GBK 发送中文时，服务端（打码机）按 UTF-16LE 去解析，字节长度和对位完全不同，自然会产生乱码。

• 只有将发送端的字符编码也明确设置为 UTF-16LE，服务端才能正确识别。

后续在配置调试助手或编写通讯程序时，务必在字符编码选项中选择 UTF-16LE（有些软件可能写作 Unicode（小端） 或 UCS-2 LE）。如果需要发送包含中文的指令，按此编码发送即可。

安装日期:2026-08-14
系统:openEuler 25.09(x86_64)
安装方式:RPM 包安装(RPM-based Installation)

1. 安装结果总览

2. 环境信息

系统版本  : openEuler 25.09
内核      : 6.6.0-102.0.0.8.oe2509.x86_64
架构      : x86_64
内存      : 30 GB
CPU       : 6 核
磁盘      : / 分区 295G(可用约 129G)

3. 安装步骤记录

3.1 预装包安装(含依赖处理)

预装包为 el10(RHEL 10)构建,openEuler 25.09 部分依赖无法直接满足,处理过程如下:

1. 依赖缺失诊断:首次 rpm -ivh 报依赖失败:

   • /etc/redhat-release 缺失(openEuler 无此文件)
   • glibc >= 2.39(系统为 2.38)、glibc-devel >= 2.39
   • libgcc >= 14.2.1、libstdc++ >= 14.2.1(系统为 12.3.1)
   • ksh、sysstat >= 12.7.6、libxcrypt-compat >= 4.4.36 未安装

2. 解决措施:

   # 创建 /etc/redhat-release(openEuler 无此文件)
   echo "openEuler release 25.09 (RHEL-compatible)" > /etc/redhat-release
   
   # 从 openEuler 源补装可满足的依赖(ksh、sysstat 12.7.7、libxcrypt 4.4.38)
   dnf install -y ksh sysstat libxcrypt
   
   # glibc/libgcc/libstdc++ 版本要求及 libxcrypt-compat 仅为 RPM 元数据校验,
   # 包内脚本实际运行不依赖,故 --nodeps 安装
   rpm -ivh --nodeps oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm
   

3. 配置生效:该包无安装脚本,实际配置由包内 /usr/bin/oracle-ai-database-preinstall-26ai-verify 执行(或安装时 posttrans 自动调用),已应用:

   • 用户与组(依据包内 .param 文件):

     • oracle 用户:uid 54321,主组 oinstall
     • 组:oinstall(54321)、dba(54322)、oper(54323)、backupdba(54324)、dgdba(54325)、kmdba(54326)、racdba(54330)

   • 内核参数(/etc/sysctl.d/99-oracle-ai-database-preinstall-26ai-sysctl.conf,已 sysctl 生效):

     参数	值
     fs.file-max	6815744
     kernel.sem	250 32000 100 128
     kernel.shmmni	4096
     kernel.shmall	1073741824
     kernel.shmmax	4398046511104
     kernel.panic	10
     net.core.rmem_default / rmem_max	262144 / 4194304
     net.core.wmem_default / wmem_max	262144 / 1048576
     net.ipv4.conf.all/default.rp_filter	2
     fs.aio-max-nr	1048576
     net.ipv4.ip_local_port_range	9000 65535
     vm.hugetlb_shm_group	54321(oinstall gid)

   • 用户限额(/etc/security/limits.d/oracle-ai-database-preinstall-26ai.conf):

     项	soft	hard
     nofile	1024	65536
     nproc	16384	16384
     stack	10240 KB	32768 KB
     memlock	134217728 KB	134217728 KB
     data	unlimited	unlimited

   • 引导参数(重启后生效,已写入 /etc/default/grub):

     • numa=off、transparent_hugepage=madvise
     • 已执行 grub2-mkconfig 更新全部内核条目

3.2 数据库软件安装

1. 介质校验:首次下载的 oracle-ai-database-ee-26ai 包仅 18.8MB,rpm -K 报 Payload SHA256: BAD(下载截断);重新下载 2.1GB 完整包后校验通过:

   rpm -Kv oracle-ai-database-ee-26ai-1.0-1.el10.x86_64.rpm
   # 头 SHA256/SHA1 OK,Payload SHA256/MD5 OK
   

2. 属主修正:安装时 %pre 脚本报 ORACLE_BASE(/opt/oracle)非 oracle 用户所有,修正后安装成功:

   chown oracle:oinstall /opt/oracle
   yum -y localinstall oracle-ai-database-ee-26ai-1.0-1.el10.x86_64.rpm
   

3. 安装产物:

   • Oracle Home:/opt/oracle/product/26ai/dbhome_1(安装后约 5.8G)
   • 服务脚本:/etc/init.d/oracledb_ORCLCDB-26ai
   • 配置文件:/etc/sysconfig/oracledb_ORCLCDB-26ai.conf

3.3 建库(configure)

使用 RPM 自带配置脚本,创建 CDB + 1 个 PDB:

/etc/init.d/oracledb_ORCLCDB-26ai configure

内部实际执行:

dbca -silent -createDatabase
  -gdbName ORCLCDB -templateName General_Purpose.dbc
  -characterSet AL32UTF8 -createAsContainerDatabase true
  -numberOfPDBs 1 -pdbName ORCLPDB1
  -createListener LISTENER:1521
  -datafileDestination /opt/oracle/oradata -sid ORCLCDB
  -autoGeneratePasswords

配置参数(/etc/sysconfig/oracledb_ORCLCDB-26ai.conf):

LISTENER_PORT=1521
CHARSET=AL32UTF8
ORACLE_DATA_LOCATION=/opt/oracle/oradata
CONFIGURE_TDE=false

建库耗时约 15 分钟,最终输出 Database configuration completed successfully,日志位于 /opt/oracle/cfgtoollogs/dbca/ORCLCDB/。

4. 验证结果

SQL> select name, open_mode from v$database;
ORCLCDB   READ WRITE

SQL> select con_id, name, open_mode from v$pdbs;
 2  PDB$SEED  READ ONLY
 3  ORCLPDB1  READ WRITE

Listener: Service "ORCLCDB" has 1 instance(s), status READY

5. 使用说明

5.1 连接数据库(密码为自动生成,首次需修改)

su - oracle
export ORACLE_HOME=/opt/oracle/product/26ai/dbhome_1
export ORACLE_SID=ORCLCDB
export PATH=$ORACLE_HOME/bin:$PATH

# 以 sysdba 登录并修改密码
sqlplus / as sysdba
SQL> alter user sys identified by <新密码>;
SQL> alter user system identified by <新密码>;

5.2 连接串

• CDB:ORCLCDB=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<主机名/IP>)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCLCDB)))
• PDB:ORCLPDB1=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<主机名/IP>)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCLPDB1)))

5.3 服务管理

# 启动/停止/状态(作为 root)
/etc/init.d/oracledb_ORCLCDB-26ai start|stop|status

实例配置为开机自启动。

5.4 注意事项

1. 引导参数需重启一次系统才完全生效(numa=off、transparent_hugepage=madvise)。
2. 密码为 configure 时自动生成,必须首次登录后立即修改。
3. 26ai 版本 V$VERSION 视图列名与旧版有差异(查询 version 列报 ORA-00904),属版本正常变化。
4. 预装包依赖处理使用了 --nodeps,仅跳过了纯元数据校验项,不影响功能;若后续在正式 RHEL 10 环境部署,建议直接用官方依赖完整安装。
5. 日志位置:
   • 安装日志:/var/log/oracle-ai-database-ee-26ai/results/oraInstall.log
   • 预装校验日志:/var/log/oracle-ai-database-preinstall-26ai/results/
   • 建库日志:/opt/oracle/cfgtoollogs/dbca/ORCLCDB/
   • 告警日志:/opt/oracle/diag/rdbms/orclcdb/ORCLCDB/trace/alert_ORCLCDB.log

6. 安装介质

此openssh.spec打包文件在openeuler2203与openeuler2403环境打包成功，测试安装正常。

支持 X11转发与ssh-copy-id命令。

RPM包下载地址：

https://gitcode.com/micoder/openssh/tree/main/openssh10.3p1-openEuler2203 

源码安装参考以下内容：

install -v -g sys -m700 -d /var/lib/sshd &&

groupadd -g 50 sshd        &&
useradd  -c 'sshd PrivSep' \
         -d /var/lib/sshd  \
         -g sshd           \
         -s /bin/false     \
         -u 50 sshd

./configure --prefix=/usr                            \
            --sysconfdir=/etc/ssh                    \
            --with-privsep-path=/var/lib/sshd        \
            --with-default-path=/usr/bin             \
            --with-superuser-path=/usr/sbin:/usr/bin \
            --with-pid-dir=/run                      &&
make

要测试结果，请执行：

make -j1 tests.

现在，以 root 用户身份：

make install &&
install -v -m755    contrib/ssh-copy-id /usr/bin     &&

install -v -m644    contrib/ssh-copy-id.1 \
                    /usr/share/man/man1              &&
install -v -m755 -d /usr/share/doc/openssh-10.3p1     &&
install -v -m644    INSTALL LICENCE OVERVIEW README* \
                    /usr/share/doc/openssh-10.3p1

命令说明

--sysconfdir=/etc/ssh: 此选项可防止配置文件被安装到 /usr/etc 目录。

--with-default-path=/usr/bin 和 --with-superuser-path=/usr/sbin:/usr/bin:

这些选项用于设置 PATH，使其与 LFS 和 BLFS Shadow 软件包保持一致。

--with-pid-dir=/run:

此选项可防止 OpenSSH 引用已弃用的 /var/run 目录。

--with-pam:

此选项在构建时启用 Linux-PAM 支持。如果使用此选项，请确保在下文“配置信息”部分创建 PAM 配置。

--with-xauth=$XORG_PREFIX/bin/xauth:

此选项设置 X 身份验证所用 xauth 二进制文件的默认位置。环境变量 XORG_PREFIX 应按照 Xorg 构建环境进行设置。

也可在 sshd_config 中通过 XAuthLocation 关键字控制此位置。如果已安装 xauth（Xorg 应用程序之一），则可省略此开关。

--with-kerberos5=/usr:

此选项用于在构建中包含 Kerberos 5 支持。

--with-libedit:

此选项为 sftp 启用行编辑和历史记录功能。

配置 OpenSSH

配置文件 ~/.ssh/*、/etc/ssh/ssh_config 和 /etc/ssh/sshd_config

这些文件均无需进行必要修改。不过，你可能需要查看 /etc/ssh/ 目录下的文件，并根据系统安全需求进行适当调整。

建议进行的一项修改是禁用通过 ssh 进行的 root 登录。以 root 用户身份执行以下命令，禁用 root 通过 ssh 登录：

echo "PermitRootLogin no" >> /etc/ssh/sshd_config

如果希望无需输入密码即可登录，首先使用 ssh-keygen 创建 ~/.ssh/id_rsa 和 ~/.ssh/id_rsa.pub，然后将 ~/.ssh/id_rsa.pub 复制到要登录的远程计算机的 ~/.ssh/authorized_keys 中。

你需要将 REMOTE_USERNAME 和 REMOTE_HOSTNAME 替换为远程计算机的用户名和主机名，并且在执行 ssh-copy-id 命令时需要输入密码以确保成功：

ssh-keygen && ssh-copy-id -i ~/.ssh/id_ed25519.pub REMOTE_USERNAME@REMOTE_HOSTNAME

一旦实现无密码登录，实际上它比使用密码登录更安全（因为私钥比大多数人的密码要长得多）。如果现在希望禁用密码登录，请以 root 用户身份执行：

echo "PasswordAuthentication no" >> /etc/ssh/sshd_config && echo "KbdInteractiveAuthentication no" >> /etc/ssh/sshd_config

如果添加了 Linux-PAM 支持，并且希望 ssh 使用它，则需要为 sshd 添加配置文件并启用 LinuxPAM。

注意，ssh 仅使用 PAM 来检查密码，如果你已禁用密码登录，则不需要这些命令。如果希望使用 PAM，请以 root 用户身份执行以下命令：

sed 's@d/login@d/sshd@g' /etc/pam.d/login > /etc/pam.d/sshd && chmod 644 /etc/pam.d/sshd && echo "UsePAM yes" >> /etc/ssh/sshd_config

更多配置信息可在 sshd、ssh 和 ssh-agent 的手册页中找到。

Systemd 单元

要在系统启动时启动 SSH 服务器，请安装 blfs-systemd-units-20251204 软件包中包含的 sshd.service 单元。

[Note] 注意 BLFS 的 sshd systemd 单元不支持修改 /etc/sshd/sshd_config 中的 ListenAddress 设置。

make install-sshd

内容

已安装程序： scp、sftp、ssh、ssh-add、ssh-agent、ssh-copy-id、ssh-keygen、ssh-keyscan 和 sshd 已安装库：

 无 已安装目录： /etc/ssh、/usr/share/doc/openssh-10.3p1 和 /var/lib/sshd

简要说明

scp

是一个文件复制程序，其功能类似于 rcp，但使用加密协议

sftp

是一个类 FTP 程序，可通过 SSH1 和 SSH2 协议工作

ssh

是一个类 rlogin/rsh 的客户端程序，但使用加密协议

sshd

是一个监听 ssh 登录请求的守护进程

ssh-add

是一个向 ssh-agent 添加密钥的工具

ssh-agent

是一个可以存储私钥的身份验证代理

ssh-copy-id

是一个允许使用本地密钥登录远程机器的脚本

ssh-keygen

是一个密钥生成工具

ssh-keyscan

是一个用于从多个主机收集公共主机密钥的实用程序

报告日期：2026-06-30
系统环境：openEuler 25.09 x86_64
CPU：6 核 | 内存：30 GiB | 编译器：GCC 12.3.1
GPU：NVIDIA GeForce GTX 750（GM107）
原始内核：7.0.11 → 目标内核：7.1.2（最新稳定版）

一、内核编译安装

1.1 源码下载

1.2 编译配置

# 使用当前运行内核配置作为基础
zcat /proc/config.gz > .config
make olddefconfig

# 总配置项：8073 个
# 启用 ccache 加速增量编译

1.3 编译产物

1.4 安装位置

1.5 GRUB 启动菜单

index=0     openEuler (7.1.2) 25.09          ← 默认启动
index=1     openEuler (7.0.11) 25.09         ← 上一版本
index=2     openEuler (7.0.10) ...           ← 原厂内核

二、NVIDIA 驱动修复

2.1 问题原因

升级内核后，NVIDIA 专有驱动 580.159.04（GTX 750）的内核模块未针对新内核 7.1.2 重新编译，导致：

• nvidia.ko / nvidia-drm.ko / nvidia-modeset.ko / nvidia-uvm.ko 缺失

•  UKUI 图形界面（lightdm）无法启动

• nvidia-smi 无法与驱动通信

2.2 修复步骤

# 1. 安装 dkms 工具
dnf install -y dkms

# 2. 提取 NVIDIA 官方驱动安装包
cd /opt/softapp
./NVIDIA-Linux-x86_64-580.159.04.run --extract-only

cd NVIDIA-Linux-x86_64-580.159.04

# 3. 编译内核模块（针对 7.1.2）
./nvidia-installer \
  --kernel-module-only \
  --kernel-source-path=/lib/modules/7.1.2/build \
  --no-cc-version-check --no-x-check --ui=none \
  --no-questions --accept-license
  
 # 4. 更新模块依赖并加载
depmod -a 7.1.2
modprobe nvidia
modprobe nvidia-drm
modprobe nvidia-modeset
modprobe nvidia-uvm

# 5. 配置开机自动加载
cat > /etc/modules-load.d/nvidia.conf << EOF
nvidia
nvidia-drm
nvidia-modeset
nvidia-uvm
EOF

# 6. 重建 initramfs（加入 NVIDIA 驱动）

dracut -f --add-drivers "nvidia nvidia-drm nvidia-modeset nvidia-uvm" \
  /boot/initramfs-7.1.2.img 7.1.2
  
# 7. 重启显示管理器

​systemctl restart lightdm

2.3 修复结果

GPU:  NVIDIA GeForce GTX 750  (GM107)    1024 MB
驱动:  NVIDIA 580.159.04
CUDA:  13.0
nvidia-smi:   正常工作（46°C, 1W）
模块加载:   nvidia / nvidia-drm / nvidia-modeset / nvidia-uvm
显示服务:   lightdm 运行中，Xorg 使用 NVIDIA 驱动

三、完整操作命令速查

编译内核

# 下载
wget https://mirrors.tuna.tsinghua.edu.cn/kernel/v7.x/linux-7.1.2.tar.xz
tar -xJf linux-7.1.2.tar.xzcd linux-7.1.2

# 配置zcat /proc/config.gz > .config
make olddefconfig

# 编译
export CC="ccache gcc"
make -j$(nproc)

# 安装
make modules_install
make install

# 更新 GRUB
grub2-mkconfig -o /boot/grub2/grub.cfg
grubby --set-default /boot/vmlinuz-7.1.2

安装 NVIDIA 驱动（内核升级后）

cd /opt/softapp
./NVIDIA-Linux-x86_64-580.159.04.run --extract-only

cd NVIDIA-Linux-x86_64-580.159.04
./nvidia-installer --kernel-module-only \
  --kernel-source-path=/lib/modules/7.1.2/build \
  --no-cc-version-check --no-x-check --ui=none \
  --no-questions --accept-license
  
depmod -a 7.1.2

dracut -f --add-drivers "nvidia nvidia-drm nvidia-modeset nvidia-uvm" \
  /boot/initramfs-7.1.2.img 7.1.2

四、注意事项

1. 重启后生效：需重启系统进入 7.1.2 内核

2. 回退方案：若新内核启动异常，可在 GRUB 菜单选择 openEuler (7.0.11) 25.09

3. NVIDIA 驱动更新：未来再次升级内核时，需重新执行 nvidia-installer --kernel-module-only 步骤

4. 显示器连接：请确保显示器已正确插入 GTX 750 的输出接口

报告由 AtomCode (deepseek-v4-flash) 自动生成

在openeuler系统中没找到好用的图形化硬盘信息查看工具，
就使用gnome UI中的gnome-disk-utility软件通过openeuler官网提供的spec文件
进行RPM构建。

经测试在ukui图形界面可以正常使用，下载RPM包地址： AtomGit | GitCode - 全球开发者的开源社区,开源代码托管平台
源码与RPM下载地址

下面是上传的压缩包，理论上openeuler2203之后的版本都可以使用

gnome-disk-utility.zip (2.3 MB)

yum install libcanberra-gtk3

rpm -ivh gnome-disk-utility-46.1-2.x86_64.rpm

1. 安装

如果你的系统中没有该工具，可以通过以下命令安装：

bash

sudo apt update && sudo apt install gnome-disk-utility

2. 启动与界面

安装完成后，可以通过以下任一方式启动：

• 图形界面：在应用程序菜单中搜索并打开名为 Disks 或 磁盘 的应用。

• 命令行：在终端中输入以下命令并按回车：

  bash

  gnome-disks
  

3. 核心功能与操作

GNOME Disks的功能主要围绕磁盘和分区管理、健康监测和高级操作展开。

A. 分区管理

这是最常用的功能，可以对选中的磁盘进行分区、格式化等操作。

• 查看信息：界面左侧会列出所有连接的存储设备。选中任意磁盘或分区，右侧会显示其详细信息，如设备路径 (/dev/sda)、容量、分区表和文件系统等。

• 创建分区：在磁盘的未分配空间上，点击界面中的 + 号按钮，然后按照向导设置分区大小、文件系统类型 (如 ext4)、分区名称等。注意，分区操作不可逆，务必提前备份数据。

• 格式化与修改：选中某个已存在的分区，可以通过点击齿轮图标 ⚙️ 进行 格式化分区... 或 编辑分区... 来修改文件系统或分区标签。

• 挂载与卸载：选中一个分区后，可以点击下方的 ▶️ (挂载) 或 ⏹️ (卸载) 按钮来临时挂载或卸载它。对于需要系统启动时自动挂载的分区，可以在齿轮菜单中选择 编辑挂载选项... 进行配置。

B. 磁盘健康监测 (S.M.A.R.T.)

此功能用于检查硬盘的健康状况，提前预警潜在故障。

• 查看S.M.A.R.T.数据：选中目标磁盘，点击右上角的菜单或齿轮图标 ⚙️，选择 S.M.A.R.T.数据及自检...。

• 运行自检：在新窗口中，可以运行不同类型的S.M.A.R.T.测试来评估磁盘状态。

  • 短自检：快速检查磁盘的电、机械性能和一小部分数据区域，通常不到2分钟就能完成。

  • 长/扩展自检：对整个磁盘表面进行全面彻底的扫描，没有时间限制，根据磁盘大小和速度通常需要数小时。

• 解读属性：重点关注如 Reallocated Sector Count (重定位扇区计数) 等关键属性。如果该数值不为0，通常意味着磁盘已出现物理坏道，强烈建议立即备份数据并考虑更换硬盘。

C. 磁盘映像与备份

此功能可以创建整个磁盘或分区的完整备份（镜像文件），或者从镜像文件恢复数据。

• 创建磁盘映像：选中要备份的磁盘，点击右上角的菜单按钮（汉堡图标 ☰），选择 创建磁盘映像...。这会生成一个 .img 文件。

• 恢复磁盘映像：同样在菜单中选择 恢复磁盘映像...，然后选择之前备份的 .img 文件和要恢复到的目标磁盘。

• 重要提醒：此功能是按位进行完整复制，生成的镜像文件大小与源磁盘或分区的大小相同。操作前请确保目标存储介质有足够空间。

D. 基准测试 (Benchmark)

该功能可以测试磁盘的性能。

• 点击齿轮图标 ⚙️，选择 启动基准测试...。用户可以自定义采样次数和数据大小。测试完成后，会显示磁盘的读取响应时间和读写速率图表。

4. 实用命令行选项

gnome-disks 命令支持一些选项，可以直接启动并执行特定任务。例如：

• gnome-disks --block-device /dev/sda：启动GNOME Disks并直接选中 /dev/sda 这个磁盘。

• gnome-disks --restore-disk-image /path/to/backup.img：直接打开“恢复磁盘映像”对话框。

总结

gnome-disk-utility (GNOME Disks) 是将硬件设备与操作系统文件进行交互的关键工具。对于日常的分区管理、磁盘健康监控和系统级备份恢复，它是一个可靠且便捷的选择。

UKUI 控制中心没有蓝牙入口，通常是因为缺少对应的蓝牙管理插件或独立的图形工具。

你可以通过以下方法来解决，推荐优先尝试安装第三方蓝牙管理器（blueman），它成熟稳定，会在系统托盘生成图标，操作直观。

1. 确保蓝牙服务正常运行

先确认底层服务已启动，这是图形界面识别蓝牙的前提：

bash
sudo systemctl status bluetooth

若未运行，执行：

bash
sudo systemctl enable --now bluetooth

同时解除射频锁：

bash
rfkill unblock bluetooth

2. 安装蓝牙图形管理工具

UKUI 默认可能没有集成蓝牙面板，你需要手动安装一个前端。以下是两种常见方案（选其一即可）：

方案A：安装 Blueman（推荐）

Blueman 是一个轻量、功能完整的蓝牙管理器，安装后会在任务栏系统托盘出现蓝牙图标。

bash
sudo dnf install blueman

安装后，从应用菜单启动 blueman-manager，或点击托盘图标即可扫描、配对设备。若托盘未自动出现，可手动运行 blueman-applet。

方案B：安装 GNOME 蓝牙插件（如果 UKUI 兼容）

部分桌面环境可以借调 GNOME 的蓝牙面板，但依赖较多：

bash
sudo dnf install gnome-bluetooth
安装后重启控制中心或重新登录，看是否出现蓝牙入口。通常 UKUI 对此兼容性一般，更建议使用 Blueman。

3. 重启控制面板或会话
新安装的软件包可能需要重新加载桌面组件：

bash

重启 UKUI 控制面板（若进程存在）

killall ukui-control-center

或者注销当前桌面会话重新登录

再次打开“设置”，查找是否有“蓝牙”选项。如果没有，请直接用 Blueman 的独立窗口管理。

4. 使用 Blueman 连接设备（图形方式）
点击系统托盘的蓝牙图标，选择“设备管理器”或运行 blueman-manager。

点击“搜索”，设备列表出现后，右键你的设备选择“配对”。

根据提示完成配对码确认，连接成功后即可使用。

5. 命令行备用方案（无需图形界面）
如果图形工具依然不工作，或你习惯命令行，bluetoothctl 足够强大：

bash
bluetoothctl
power on
agent on
default-agent
scan on

看到设备 MAC 后

scan off
pair XX:XX:XX:XX:XX:XX
trust XX:XX:XX:XX:XX:XX
connect XX:XX:XX:XX:XX:XX
 可能遇到的障碍
**固障碍

固件问题件问题：若**：若 dmesgdmesg | grep - | grep -i bli bluetooth提示缺少.ibtuetooth提示缺少.ibt固 固件，需下载对应件，需下载对应文件文件到到 /lib/firmware/int/lib/firmware/intel/`。

**el/`。

服务冲突服务冲突：某些**：某些情况下情况下，蓝牙，蓝牙模块可能需要模块可能需要重新插重新插拔或拔或重启重启系统才能系统才能被被 rfkill 正确识别。
rfkill 正确识别。

音频设备连接- 音频设备连接后无后无声音：需要声音：需要安装 PipeWire安装 PipeWire 蓝牙 蓝牙插件：
插件：

bash
sudo ```bash
sudo dnf install pipewire-p dnf install pipewire-pulse libspulse libspa-bluetootha-bluetooth

system systemctl --ctl --user restart pipewire
user restart pipewire

text

安装 ` ```

安装 blueman 后blueman` 后，你的蓝牙，你的蓝牙使用使用体验会体验会非常接近 Windows非常接近 Windows 或 或主流主流 Linux 桌面。

若在安装或使用或使用中遇到任何报中遇到任何报错，欢迎继续交流错，欢迎继续交流。。

 openEuler 2509 的 UKUI 桌面下设置 fcitx5 开机自启，推荐使用XDG 自动启动方法，它更贴合 UKUI 等主流桌面环境的标准。

方案一：XDG 自动启动（推荐）

这个方案通过 .desktop 文件来设置自启，是 UKUI 这类 XDG 兼容桌面的标准做法。

1. 打开终端。

2. 运行以下命令：

   bash

   mkdir -p ~/.config/autostart
   cp /usr/share/applications/org.fcitx.Fcitx5.desktop ~/.config/autostart/

• mkdir -p ~/.config/autostart：如果不存在 .config/autostart 目录，则创建它。

• cp /usr/share/applications/org.fcitx.Fcitx5.desktop ~/.config/autostart/：将 fcitx5 的启动器文件复制到自启目录，下次登录 UKUI 时便会自动执行。

方案二：其他备选方法

方法 1：使用图形界面配置

这种方法直观且不易出错，是备选方案中的首选。

1. 打开 UKUI 控制面板（或系统设置）。

2. 找到 “启动应用程序” 或 “开机启动” 的相关设置项。

3. 点击“添加”或“新建”，在弹出的窗口中：

   • 名称 (Name)：可以填写 Fcitx5。

   • 命令 (Command)：填写 fcitx5。

4. 保存并关闭窗口。

方法 2：添加到 Shell 配置文件

如果上述方法都无效，可以将启动命令添加到 ~/.xprofile 文件中。这个文件在用户登录图形界面时会被执行。

1. 打开终端。

2. 编辑 ~/.xprofile 文件，如果文件不存在就创建一个：

   bash

   vim ~/.xprofile

3. 在文件中添加以下内容：

   bash

   fcitx5 &

4. 保存并退出。

 验证与重启

在应用任何更改后，建议重启系统或至少注销当前会话，然后重新登录，以确保所有更改都能生效。

登录后，在终端输入 fcitx5-diagnose | grep "Autostart"，可以快速检查自启配置是否已正确加载。

openEuler 2509 安装 kernel 7.0.11 与 UKUI 后无法驱动 Intel AX210 无线网卡问题

在 openEuler 上为 Intel AX210 网卡安装驱动后，系统提示“未检测到无线网卡”，这个问题很常见，通常与缺少驱动、缺少固件或 NetworkManager 配置有关。
其中，最常见的原因是 Linux 内核缺少必要的固件文件。

你可以按顺序尝试以下步骤来解决：

第一步：准备工作

在开始任何操作前，强烈建议通过有线网络或USB网络共享（如用安卓手机的USB网络共享功能）先将电脑连接到互联网，以保证后续的命令可以顺利执行。

第二步：诊断硬件状态

打开终端，运行以下命令检查系统是否已识别网卡硬件：

# 检查PCI接口的无线网卡是否被系统识别
lspci | grep -i network
# 检查内核日志中是否有无线网卡的相关信息
dmesg | grep -i iwlwifi

• 如果能看到 AX210 的型号，说明硬件已识别，问题在于驱动或固件缺失。

• 如果完全看不到，可能是硬件未被正确连接，需检查物理安装或在 BIOS 中确认是否启用。

 第三步：安装必备组件

系统提示未检测到无线网卡，可能是缺少 NetworkManager-wifi 插件。可以直接执行以下命令安装所需组件：

sudo dnf install -y NetworkManager-wifi wpa_supplicant wireless-tools

安装完成后，重启网络服务再检查：

# 启动并设置开机自启
sudo systemctl enable --now wpa_supplicant
sudo systemctl restart NetworkManager

然后运行 nmcli device status 检查网卡状态。如果网卡状态仍未变为“已连接”或“已断开”，请继续下一步。

第四步：安装 Intel AX210 驱动与固件

1. 安装驱动和基础固件包：

   bash

   # 安装Intel无线网卡驱动模块和基础固件包
   sudo dnf install -y linux-firmware-iwlwifi
   # 加载驱动模块
   sudo modprobe iwlwifi

2. 手动更新固件文件（最关键的一步）：
   如果上述步骤后问题依旧，说明系统自带的固件版本可能过旧。AX210网卡需要特定版本的固件文件（如 iwlwifi-ty-a0-gf-a0.pnvm）才能正常工作。

   • 下载最新固件：从 Linux 内核固件仓库下载最新的 iwlwifi 固件。

     bash

     git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git --depth=1

   • 复制固件文件：将下载的 AX210 固件文件复制到系统固件目录。

     bash

     # 进入 root 用户，如果没有root密码可先用 sudo passwd root 设置
     su
     # 复制所有 iwlwifi 开头的 .ucode 和 .pnvm 文件到系统目录
     cp linux-firmware/iwlwifi-*.{ucode,pnvm} /lib/firmware/

   • 重新加载驱动并重启：

     bash

     # 退出root用户
     exit
     # 移除iwlwifi模块
     sudo modprobe -r iwlwifi
     # 重新加载iwlwifi模块
     sudo modprobe iwlwifi
     # 重启网络服务
     sudo systemctl restart NetworkManager

 第五步：检查 NetworkManager 配置

如果网卡硬件已识别但 nmcli device status 显示为“未托管”（unmanaged），可以按以下步骤检查配置：

1. 修改配置文件：

   bash

   sudo vim /etc/NetworkManager/NetworkManager.conf

   找到 [main] 部分，确保有以下配置。如果没有就手动添加。

   ini

   [main]
   plugins=ifcfg-rh
   # 关键配置，true 表示管理所有设备
   managed=true

2. 删除状态文件：如果修改后问题依旧，可以尝试删除 NetworkManager 的状态缓存文件。

   bash

   sudo systemctl stop NetworkManager
   sudo rm /var/lib/NetworkManager/NetworkManager.state
   sudo systemctl start NetworkManager

 第六步：解除无线网卡屏蔽

某些笔记本有物理或软件开关会禁用无线网卡。

# 列出所有无线设备的状态
rfkill list

• 如果 Soft blocked: yes，运行以下命令解除软屏蔽：

  bash

  sudo rfkill unblock wifi

• 如果 Hard blocked: yes，则需要检查笔记本上的物理WiFi开关或使用 Fn + F功能键（如F2/F12，具体看键盘图标） 来开启。

第七步：最终检查与连接

完成以上所有步骤后，再次运行以下命令确认网卡状态：

# 查看网卡状态，wlp或wlan开头的设备应显示为“已断开”或“正在连接”
nmcli device status
# 开启WiFi功能
sudo nmcli radio wifi on
# 扫描附近的WiFi网络
nmcli device wifi list

如果能看到网络列表，就可以使用 nmcli 或图形界面的 nmtui 命令连接WiFi了：

# 通过命令行连接WiFi，请替换为实际的WiFi名和密码
sudo nmcli device wifi connect "你的WiFi名称" password "你的WiFi密码"

总结

解决 openEuler 与 Intel AX210 网卡的问题，关键通常在于确保系统内核、驱动、固件三者都达到足够新的版本。绝大多数情况下，手动更新固件文件就能解决问题。为了从根本上避免类似问题，可以考虑将内核升级到 5.16+，或选择软件包更前沿的发行版。希望这些步骤能帮你连上WiFi～

一、编译内核

1. 准备编译环境

首先，需要安装编译内核所必需的工具和依赖库。

在终端中执行以下命令：

# 1. 安装"Development Tools"组包，包含 gcc, make 等基础编译工具
sudo dnf groupinstall "Development Tools"
​
# 2. 安装内核编译的特定依赖
# ncurses-devel: make menuconfig 的图形界面支持
# elfutils-libelf-devel: 处理 ELF 格式文件
# bc: 编译过程中的计算工具
# openssl-devel: 内核签名等安全功能所需
# bison, flex: 语法解析器生成工具
​
sudo dnf install ncurses-devel elfutils-libelf-devel bc openssl-devel bison flex

如果编译失败并提示缺少某个头文件或工具，你可以尝试使用 sudo dnf builddep kernel 来自动安装 kernel 源码包的所有构建依赖。

2. 获取内核源码

由于 openEuler 25.09 源内暂无预编译的 7.0.7 RPM 源码包，我们选择从 kernel.org 手动下载官方源码。

2.1 下载内核源码压缩包

你可以在 https://www.kernel.org 上查找你想要的版本：

wget https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.0.7.tar.xz

2.2 解压源码

tar -xvf linux-7.0.7.tar.xz

2.3 进入源码目录

cd linux-7.0.7

3. 配置内核选项

通过复用现有配置并微调，可以确保新内核包含当前系统的驱动和功能，简化定制流程。

3.1 复用当前配置

将系统当前运行内核的配置文件复制到源码目录，作为基础配置：

cp /boot/config-$(uname -r) .config

3.2 修改内核配置（关键步骤）

使用 sed 命令清空证书路径，避免编译报错：

sed -i 's|CONFIG_SYSTEM_TRUSTED_KEYS=.*|CONFIG_SYSTEM_TRUSTED_KEYS=\"\"|' .config
sed -i 's|CONFIG_SYSTEM_EXTRA_CERTIFICATE=.*|CONFIG_SYSTEM_EXTRA_CERTIFICATE=\"\"|' .config
make olddefconfig

注意：以上命令修改内核配置，不然编译会有报错。

3.3 更新配置项（可选）

由于新版本内核会引入新选项，需要先更新.config 文件。运行此命令后，它会逐个提示你处理所有新增的配置项，直接按 Enter 键选择默认值即可。

make menuconfig

界面操作提示：

• 使用方向键移动

• 按空格键切换选择状态（* 表示编译进内核，M 表示编译为模块，[ ] 表示不编译）

• 选择 Save 保存配置，然后 Exit 退出

3.4 定制配置（可选）

如果需要进一步裁剪模块或开启特定功能，可使用图形化界面进行配置。

4. 编译内核

配置完成后，即可开始编译：

make -j$(nproc)

注意：编译过程耗时较长（半小时至数小时不等），如果在过程中遇到错误，可以尝试去掉 -j 参数，以便清晰地定位错误信息。

5. 安装内核与模块

编译成功后，需要将内核镜像、模块等文件安装到系统指定位置。

5.1 安装内核模块

sudo make modules_install

5.2 安装内核文件（vmlinuz, System.map 等）到 /boot 目录

sudo make install

执行 sudo make install 后，它会自动：

• 复制内核到/boot

• 生成对应的 initramfs

• 将新内核条目添加到 GRUB 的启动菜单中

5.3 更新配置文件

cp .config /boot/config-7.0.7

6. 更新引导与重启验证

6.1 手动更新 GRUB 以确保配置生效，并重启系统以加载新内核。

对于使用 UEFI 引导的系统：
GRUB 配置文件路径通常是 /boot/efi/EFI/openEuler/grub.cfg。如果不确定，可检查 /boot/efi/EFI/ 下的具体目录名：

# 请将路径替换为你的实际 GRUB 配置文件路径
sudo grub2-mkconfig -o /boot/efi/EFI/openEuler/grub.cfg

如果你使用的是传统的 BIOS 引导：
命令通常是：

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

6.2 重启系统

sudo reboot

7. 验证

成功登录后，执行以下命令，如果终端输出 7.0.7，则代表新内核已成功运行：

uname -r

二、编译报错解决方法

1. 重新运行编译，捕获详细日志

在源码目录（/opt/linux-7.0.7）执行：

# 先清理一下（可选，但建议）
make clean
​
# 使用单线程编译，并输出详细命令，同时保存到文件
make -j1 V=1 2>&1 | tee build.log
-j1：只用 1 个核心，让错误信息按顺序输出，不被并行日志打乱。
​
V=1：显示完整编译命令，便于定位哪个环节出错。
​
tee build.log：将所有输出同时显示在屏幕并保存到 build.log，方便事后搜索。

等待编译中断后，执行以下命令查看最后的错误：

grep -i "error:" build.log | tail -20

把这段输出贴出来，我就能直接判断了。

2. 根因分析

日志最后几行清楚地显示：

make[3]: *** 没有规则可制作目标"certs/openeuler-cert.pem"，由"certs/x509_certificate_list"需求。停止。
make[2]: *** [scripts/Makefile.build:546：certs] 错误 2
make[1]: *** [/opt/linux-6.19.14/Makefile:2065：.] 错误 2

根因分析：
你的 .config 里 CONFIG_SYSTEM_TRUSTED_KEYS 被设为了 certs/openeuler-cert.pem，但这个文件在主线内核源码中并不存在——它是 openEuler 发行版内核专用的签名证书。

你的 .config 很可能是从 openEuler 发行版 /boot/config-* 复制过来的，所以带上了 openEuler 的证书引用。

3. 解决方法

方法一：直接改 .config，把证书路径设为空

sed -i 's|CONFIG_SYSTEM_TRUSTED_KEYS=.*|CONFIG_SYSTEM_TRUSTED_KEYS=\"\"|' .config
# 也检查一下这个：
sed -i 's|CONFIG_SYSTEM_EXTRA_CERTIFICATE=.*|CONFIG_SYSTEM_EXTRA_CERTIFICATE=\"\"|' .config
# 然后重新生成完整配置并编译
make olddefconfig
make -j6

方法二：如果你是用 menuconfig / nconfig 交互式配置

make menuconfig
进去后找到：Cryptographic API → Certificates for signature checking
​
把以下两项清空（删掉路径，留空）：
​
Additional X.509 keys for default system keyring — 删掉 certs/openeuler-cert.pem
X.509 certificate to be preloaded into the system blacklist keyring — 如果有也清空
​
保存退出后 make -j6 即可继续编译。

三、安全提示

• 避免执行系统命令：编译过程可能会生成敏感文件，确保在安全环境中操作。

• 更新 GRUB：使用最新版本的 GRUB 配置以支持新内核。

• 标注来源：转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。

四、引用信息

【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。

• 文章标题：openeuler2509系统中编译kernel7.0.7内核方法

• 发布平台：华为云开发者社区（bbs.huaweicloud.com）

• 文章链接：https://bbs.huaweicloud.com/blogs/477812

• 作者信息：未明确标注，但内容来自华为云开发者社区

五、注意事项

1. 编译环境要求

   • 必须安装 Development Tools 组包（包含 gcc, make 等）

   • 需要特定依赖：ncurses-devel, elfutils-libelf-devel, bc, openssl-devel, bison, flex

2. 配置关键项

   • CONFIG_SYSTEM_TRUSTED_KEYS 必须是空字符串，不能是路径

   • CONFIG_SYSTEM_EXTRA_CERTIFICATE 也必须是空字符串

3. 编译时间较长

   • 使用 -j$(nproc) 可以加速，但建议先清理日志再重新编译以定位问题

4. 验证方式

   • 编译成功后运行 uname -r 应显示 7.0.7

   • 登录后执行 sudo systemctl status openeuler 确认内核启动正常

5. 错误排查

   • 查看 build.log 中的具体错误行，例如：

     • make[3]: *** 没有规则可制作目标"certs/openeuler-cert.pem"

     • make[2]: *** [certs] 错误 2

六、参考资源

• 官方内核下载：https://www.kernel.org/pub/linux/kernel/v7.x/

• 编译工具安装：使用 sudo dnf groupinstall "Development Tools"

• 依赖包安装：使用 sudo dnf install <package-name>-devel

• 源码解压：使用 tar -xvf <filename>.tar.xz

文档生成时间：2026-05-21
来源：华为云开发者社区博客（bbs.huaweicloud.com）
作者：AutoClaw+Deepseek 生成的示例内容