网路互联

ELAN0618 触摸板 Windows Server 2019 修复,可正常驱动触控板操作。

Thu, 03 Sep 2026 11:52:13 +0800

ELAN0618 触摸板 Windows Server 2019 修复包

https://gitcode.com/micoder/ELAN0618_Touchpad

问题

Windows Server 2019 不内置 ELAN 触摸板驱动。ELAN SA469D-22HB (ACPI\ELAN0618) I2C 触摸板仅由通用 hidi2c 驱动驱动，无法响应触摸输入。

根因

Server 2019 缺少 ELAN 专用驱动（ETD），通用 HID 驱动（mouhid）无法正确处理 ELAN 触摸板的 HID 报告。

修复原理

从 Windows 10 ELAN 驱动包（Synaptics_Driver_Extract）移植 ETD 驱动，通过 InstallHinfSection API 强制安装为 HID 鼠标设备的上层过滤器。

使用方法

方法一：双击运行（推荐）

右键 fix_elan_touchpad.bat → 以管理员身份运行

方法二：PowerShell

# 以管理员身份运行 PowerShell
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\fix_elan_touchpad.ps1

方法三：手动安装

rundll32 setupapi.dll,InstallHinfSection ETD_HID_Group6_WIN10_Inst.NT 132 "%~dp0ELAN_Driver\ETD.inf"

修复后的设备状态

设备实例	驱动	说明
ACPI\ELAN0618	hidi2c	I2C HID Miniport（保持不变）
HID\ELAN0618&COL01	mouhid + ETD（上层过滤器）	ELAN 触摸板核心驱动
HID\ELAN0618&COL02	ETDHCF	ELAN HID 类过滤驱动
ETD 服务	RUNNING	ETD.sys 内核驱动
ETDService	RUNNING	触摸板应用服务

文件清单

ELAN0618_Touchpad_WinSrv2019_Fix/
├── fix_elan_touchpad.bat          ← 一键修复批处理（双击运行）
├── fix_elan_touchpad.ps1          ← PowerShell 修复脚本
├── README.md                      ← 本文档
└── ELAN_Driver/                   ← ELAN 驱动文件
    ├── ETD.inf                    ← 触摸板驱动安装信息
    ├── ETD.sys                    ← 触摸板内核驱动
    ├── etd.cat                    ← ETD 数字签名
    ├── ETDHCF.inf                 ← HID 过滤驱动安装信息
    ├── ETDHCF.sys                 ← HID 过滤内核驱动
    ├── etdhcf.cat                 ← ETDHCF 数字签名
    ├── ETDService.exe             ← 应用服务
    ├── ETDCtrl.exe                ← 控制程序
    ├── ETDCtrlHelper.exe          ← 辅助程序
    ├── ETDApix.dll                ← API 扩展库
    ├── ETDCmds.dll                ← 命令库
    ├── ETDFavorite.dll            ← 收藏库
    ├── ETDTouch.exe               ← 触控程序
    ├── ETDUn_inst.exe             ← 卸载程序
    ├── LenovoAPI.dll              ← Lenovo 接口库
    ├── dpinst.exe                 ← 驱动安装工具（备用）
    ├── dpinst.xml                 ← DPInst 配置
    └── Setup.exe                  ← 安装程序（备用）

目标设备兼容性

本驱动适用于以下 ELAN 触摸板型号：

设备 ID	说明
HID\VEN_ELAN&DEV_0608	LCFC ideapad 320-14/15/17IKB
HID\VEN_ELAN&DEV_0611	LCFC ideapad 320&520IKBRA
HID\VEN_ELAN&DEV_0617	Wistron V530/V330/E53 (SKL)
HID\VEN_ELAN&DEV_0618	Wistron V530/V330/E53 (KBL) ← 本机
HID\VEN_ELAN&DEV_0619	Wistron V530/V330/E53 (AMD)
HID\VEN_ELAN&DEV_0623	Wistron V340/V140/E54
...	以及更多 (详见 ETD.inf)

注意事项

管理员权限：必须以管理员身份运行
驱动签名：所有文件已签名（etd.cat / etdhcf.cat），无需开启测试签名
重启：通常无需重启；如触摸板无响应，请重启系统
卸载：运行 ETDUn_inst.exe 或设备管理器中禁用 ETD 过滤器

修复过程中记录的系统修改

修改的系统文件

文件路径	说明
`C:\Windows\System32\drivers\ETD.sys`	ETD 内核驱动（新增）
`C:\Windows\System32\drivers\ETDHCF.sys`	ETDHCF 内核驱动（新增）
`C:\Windows\INF\oem37.inf`	ETD.inf 的发布副本（驱动库自动生成）
`C:\Windows\INF\oem38.inf`	ETDHCF.inf 的发布副本（驱动库自动生成）

修改的注册表项

注册表路径	修改内容
`HKLM\SYSTEM\CurrentControlSet\Services\ETD`	ETD 服务注册
`HKLM\SYSTEM\CurrentControlSet\Services\ETDService`	ETDService 服务注册
`HKLM\SYSTEM\CurrentControlSet\Enum\HID\ELAN0618&COL01\...\UpperFilters`	添加 ETD 上层过滤器
`HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e96f-...}\00XX`	ETD 类实例注册

未修改（已还原）

修改项	状态
`bcdedit /set testsigning on`	已被 Secure Boot 自动重置为 Off
`BTH\MS_BTHPAN` 设备节点注册表	已还原为原始状态
`Net 类实例 0017`	已删除（手动绑定尝试，未成功）
`C:\Windows\INF\bthpan.sys` 临时文件	已删除
`system32\drivers\bthpan.sys`	已还原为原始版本

环境

OS: Windows Server 2019 Datacenter Build 17763.9121
触摸板: ELAN SA469D-22HB (I2C HID, ACPI\ELAN0618)
I2C 控制器: Intel Serial IO I2C Host Controller - 9D60

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

Tue, 01 Sep 2026 10:39:27 +0800

kernel7.2.0

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

环境信息

项目	值
系统	openEuler 25.09 (x86_64)
原内核	7.1.2
目标内核	7.2.0
硬件	6 核 CPU / 30Gi 内存 / 磁盘可用 134G
显卡	NVIDIA GeForce GTX 750 (GM107)

编译与安装过程

解压源码：linux-7.2.tar.gz（约 260MB，解压后 1.8G）→ linux-7.2/
内核配置：复用当前运行内核配置（/proc/config.gz）→ .config，再执行 make olddefconfig 适配 7.2
并发编译：make -j3（按需求限制并发为 3，防止系统死机；全量编译约 2.5 小时，产出 15000+ 目标文件）
安装模块：make modules_install → /lib/modules/7.2.0
安装内核：make install → /boot/vmlinuz-7.2.0、System.map-7.2.0、initramfs-7.2.0.img（dracut 生成）
更新引导：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，避免系统负载过高死机

ly_ueditor_plus 粘贴换行丢失修复总结报告

Tue, 01 Sep 2026 10:36:52 +0800

ly_ueditor_plus 粘贴换行丢失修复总结报告

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

一、问题现象

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

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

典型表现：…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>行内容\n…</code></pre> 结构，换行符其实都在。但 htmlparser 的空白清理正则

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

会把 span/code/pre/br 等白名单标签两侧的 \n\r 全部剥掉（\n、</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` 直接转为 ` `（关键）

把换行转换中的 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,"");                                            // 标签间残留清理

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

修复 D：纯文本（无 pre）换行 → ` `

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

四、验证结果

检查项	结果
`node --check ueditor.all.js` 语法	✅ 通过
真实场景：`pre>code>span` 逐行代码块（每行 `</span>\n`）→ 每行 `<br/>`，缩进 ` ` 保留，span 结构保留	✅
来源网页无换行 + 纯文本回退 → 19 行全部恢复	✅
正常 pre（换行充足）→ 恢复逻辑跳过、不重复处理	✅
pre 与纯文本不匹配 / 无 pre / 单行 → 原样不动	✅
代码含 `$1` `$&` `&&` → 不被替换符吞掉	✅
纯文本多行 → 逐行 `<br/>`，空行 → 双 `<br/>`	✅
段落间 `</p>\n<p>` → 不产生多余 `<br>`	✅
Word 样式 + pre（修复 A）回归	✅

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

五、部署与缓存

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

文件	改动
`ueditor-plus/ueditor.all.js`	修复 A/B/C/D
`ly_ueditor_plus_core.php`	加载版本号 `?0309 → ?0313`（破浏览器缓存）

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

六、文件变更清单

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

oracle 26ai安装示例数据库

Tue, 01 Sep 2026 09:55:23 +0800

oracle 26ai安装示例数据库

安装报告 (Installation Report)

安装日期：2026-08-15。本报告记录示例 schema 在本环境中的安装过程、账号信息、验证结果与已知限制。

1. 目标数据库

项目	值
数据库	Oracle 23.26.3.0.0（26ai 系列），多租户架构
主机 / 端口	192.168.3.88:1521 openueler2509系统
容器	CDB: `ORCLCDB`，PDB: `ORCLPDB1`（READ WRITE）
连接串	`192.168.3.88:1521/ORCLPDB1`
组件	XDB、SDO（Spatial）均 VALID

2. 客户端工具（安装于本机）

工具	版本	位置
SQLcl	26.2.1.222.1617	`D:\tools\sqlcl`
Instant Client (Basic)	23.26.3.0.0	`D:\Program Files\instantclient-basic-oracle-23.26.3.0.0\instantclient_23_26`
Instant Client (Tools，含 SQL*Loader)	23.26.3.0.0	同上（本次补充解压，提供 `sqlldr.exe`）

3. 账号汇总

所有 schema 密码统一为 88888888，数据表空间统一为 sample，临时表空间 TEMP。

用户	密码	表空间	说明
system / sys	88888888	-	管理员账号（sys 以 SYSDBA 连接）
hr	88888888	sample	Human Resources
co	88888888	sample	Customer Orders
sh	88888888	sample	Sales History
oe	88888888	sample	Order Entry（归档，含 OC 子 schema）
pm	88888888	sample	Product Media（归档）

4. 安装过程摘要

HR / CO / SH（受支持 schema）：以 system 连接 PDB，分别在 human_resources/、customer_orders/、sales_history/ 目录运行 <schema>_install.sql，按提示输入密码 88888888、表空间 sample、覆盖 YES。SH 官方要求使用 SQLcl 运行。
OE / PM（归档 schema）：先按官方流程执行 perl 替换 __SUB__CWD__ → D:/db-sample-schemas（生成了 .bak 备份），再以 system 连接，运行 order_entry/oe_main.sql 与 product_media/pm_main.sql，传入 9 个参数（各 schema 密码、表空间 sample、临时表空间 TEMP、数据/日志路径、版本 v3、连接串）。PM 通过 SQL*Loader 从客户端加载 LOB 数据。

5. 验证结果（provided = actual，全部一致）

HR：

表	行数
regions / countries / departments / locations / employees / jobs / job_history	5 / 25 / 27 / 23 / 107 / 19 / 10

CO：

表	行数
customers / stores / products / orders / order_items / shipments / inventory	392 / 23 / 46 / 1950 / 3914 / 1892 / 566

SH：

表	行数
channels / costs / countries / customers / products / promotions / sales / times / supplementary_demographics	5 / 82112 / 35 / 55500 / 72 / 503 / 918843 / 1826 / 4500

OE（93 个对象，0 无效；OC 类型 27 个，公共同义词 COE_ 5 个，HR→OE 授权 9 项）：*

表	行数
customers / orders / order_items / product_information / product_descriptions / inventories / warehouses / promotions	319 / 105 / 665 / 288 / 8640 / 1112 / 9 / 2

PM（8 个对象，0 无效；SQL*Loader 加载 16 条记录，0 拒绝）：

对象	行数
print_media	4
textdocs_nestedtab（嵌套表）	12

6. 已知限制

OE 的 XDB 采购订单演示（xdb03usg.sql）：目录对象 SS_OE_XMLDIR 指向服务器端路径，而 purchaseOrder.xml/.xsd 文件在安装机本地、无法放置到远端服务器，因此 XDB 资源创建步骤失败（ORA-22288 / ORA-31001）。仅影响 XDB 演示资源，OE/OC 的表、视图、类型与数据完整。
PM 的 BFILE 列（print_media.ad_graphic）：MEDIA_DIR 目录对象已创建但指向本机路径字符串，服务器上无对应媒体文件，BFILE 定位符存在但 DBMS_LOB.FILEEXISTS = 0。BLOB 数据（照片、文档等）均正常入库。

7. 日志位置

HR / CO / SH：各 schema 目录下的 <schema>_install.log，运行输出副本在仓库根目录 *_run_out.log。
OE / PM：logs/oe_oc_v3.log、logs/pm_main.log、logs/pm_p_lob.log（及运行输出副本 logs/oe_run_out.log、logs/pm_run_out.log）。

8. 卸载方式

HR / CO / SH：以特权用户运行各目录下的 <schema>_uninstall.sql。
OE / PM：以特权用户执行 DROP USER oe CASCADE; 与 DROP USER pm CASCADE;。

9. 具体安装命令与步骤

以下命令在本机 Git Bash（Windows）中实际执行并验证通过。/d/... 为 Git Bash 路径写法，等价于 D:/...。

9.1 工具准备

# 1) 下载并解压 SQLcl（需已装 Java 11+）
curl -sSL -o sqlcl-latest.zip https://download.oracle.com/otn_software/java/sqldeveloper/sqlcl-latest.zip
unzip -q sqlcl-latest.zip -d /d/tools          # 得到 /d/tools/sqlcl

# 2) 下载 Instant Client Tools 包（提供 sqlldr.exe），解压进已有 Basic 目录
curl -sSL -o ic-tools.zip "https://download.oracle.com/otn_software/nt/instantclient/2326300/instantclient-tools-windows.x64-23.26.3.0.0.zip"
unzip -q ic-tools.zip -d "/d/Program Files/instantclient-basic-oracle-23.26.3.0.0/instantclient_23_26/"
# zip 内含一层 instantclient_23_26/ 子目录，需将内容上移一层到 Basic 目录根

# 3) 建日志目录
mkdir -p /d/db-sample-schemas/logs

9.2 HR / CO / SH（受支持 schema，交互提示）

脚本用 ACCEPT 依次询问：密码、表空间、是否覆盖已存在 schema。以下用管道预填答案：
三行输入 = 密码 / 表空间 / 覆盖确认（空行回车 = 默认 YES）。

# HR
cd /d/db-sample-schemas/human_resources
printf '88888888\nsample\n\n' | /d/tools/sqlcl/bin/sql -S "system/88888888@192.168.3.88:1521/ORCLPDB1" @hr_install.sql

# CO
cd /d/db-sample-schemas/customer_orders
printf '88888888\nsample\n\n' | /d/tools/sqlcl/bin/sql -S "system/88888888@192.168.3.88:1521/ORCLPDB1" @co_install.sql

# SH（官方要求 SQLcl 运行）
cd /d/db-sample-schemas/sales_history
printf '88888888\nsample\n\n' | /d/tools/sqlcl/bin/sql -S "system/88888888@192.168.3.88:1521/ORCLPDB1" @sh_install.sql

三个脚本末尾自带的验证段（provided = actual 行数对比）会打印在输出与 <schema>_install.log 中。

9.3 OE / PM（归档 schema，参数传入）

归档脚本用 DEFINE &1..&9 接收参数（非交互提示），需先替换脚本与数据文件中的
__SUB__CWD__ 占位符为仓库绝对路径（官方安装流程，会生成 .bak 备份）：

cd /d/db-sample-schemas
perl -p -i.bak -e 's#__SUB__CWD__#D:/db-sample-schemas#g' *.sql */*.sql */*.dat

OE（含 OC 子 schema） — @oe_main.sql 后跟 9 个参数：

cd /d/db-sample-schemas
printf 'exit\n' | /d/tools/sqlcl/bin/sql -S -L "system/88888888@192.168.3.88:1521/ORCLPDB1" \
  @order_entry/oe_main.sql 88888888 sample TEMP 88888888 88888888 \
  D:/db-sample-schemas D:/db-sample-schemas/logs/ v3 192.168.3.88:1521/ORCLPDB1

PM — @product_media/pm_main.sql 后跟 9 个参数（先确保 sqlldr 在 PATH 中）：

export PATH="/d/Program Files/instantclient-basic-oracle-23.26.3.0.0/instantclient_23_26:$PATH"
cd /d/db-sample-schemas
printf 'exit\n' | /d/tools/sqlcl/bin/sql -S -L "system/88888888@192.168.3.88:1521/ORCLPDB1" \
  @product_media/pm_main.sql 88888888 sample TEMP 88888888 88888888 \
  D:/db-sample-schemas/product_media/ D:/db-sample-schemas/logs/ \
  D:/db-sample-schemas/product_media/ 192.168.3.88:1521/ORCLPDB1

参数顺序说明（OE / PM 一致）：

#	含义	本次取值
1	目标 schema 密码	`88888888`
2	默认表空间	`sample`
3	临时表空间	`TEMP`
4	HR（OE 用）/ OE（PM 用）密码	`88888888`
5	SYS 密码	`88888888`
6	数据/控制文件目录	OE: `D:/db-sample-schemas`；PM: `D:/db-sample-schemas/product_media/`（PM 中同时写入目录对象 `MEDIA_DIR`）
7	日志目录（末尾需带分隔符）	`D:/db-sample-schemas/logs/`
8	OE: 版本号 `v3`（对应 `coe_v3/loe_v3/poe_v3` 系列脚本，注意不是 README 原写的 `3`）；PM: 工作目录（存放 `pm_p_lob.dat`）	OE: `v3`；PM: `D:/db-sample-schemas/product_media/`
9	连接串	`192.168.3.88:1521/ORCLPDB1`

说明：纯数字密码（88888888）无需引号即可 CREATE USER ... IDENTIFIED BY ...；
CREATE DIRECTORY 不校验服务器路径是否存在，故 PM 的 MEDIA_DIR 指向本机路径也能完成安装。

9.4 验证抽查命令

/d/tools/sqlcl/bin/sql -S -L "system/88888888@192.168.3.88:1521/ORCLPDB1" <<'EOF'
select 'HR.employees='||count(*) from hr.employees;
select 'CO.orders='||count(*) from co.orders;
select 'SH.sales='||count(*) from sh.sales;
select 'OE.customers='||count(*) from oe.customers;
select 'PM.print_media='||count(*) from pm.print_media;
exit
EOF

完整的逐表行数对比见上文第 5 节验证结果。

libfastjson 1.2304.0 重建修复记录

Mon, 31 Aug 2026 18:03:54 +0800

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 崩溃定位链

**rsyslogd -N1 配置测试直接段错误**（exit=139）；gdb 回溯显示崩溃发生在
动态链接器 ld-linux-x86-64.so.2 调用 libm.so.6 内 IFUNC 解析器期间。
**反汇编 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。
**libfastjson.so.4 的 DT_NEEDED 只有 libc.so.6，缺少 libm.so.6**：
libc.so.6 也导出 modf（弱 IFUNC），链接期 --as-needed 把 -lm 丢弃。
运行时 libfastjson 的 modf 引用经全局作用域预取（symbol preemption）
绑定到 libm 的 IFUNC；该路径下解析器执行时 _rtld_global_ro GOT 槽
尚未正确填充 → NULL 解引用 → SIGSEGV。

3.2 关键对照实验

场景	结果
直接 `gcc test.c -lm` 调用 modf	✅ 正常（exit=0），即使 `-Wl,-z,now`
libfastjson 不直接链接 libm，modf 经全局作用域预取	❌ 崩溃（exit=139）

结论：问题不是 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

要点	说明
移除 `--as-needed` 并追加 `-lm`	使 DT_NEEDED 包含 `libm.so.6`，modf 直接绑定、不再预取
`--define 'dist .oe2509'`	保持 release 后缀与发行版一致，便于 `rpm -Uvh --replacepkgs` 同版本替换
rsyslog 本体无需改动	仅 libfastjson 需重建；rsyslog 单独重建见 micoder/rsyslog

五、验证结果

验证项	修复前	修复后
`readelf -d libfastjson.so.4` NEEDED	仅 `libc.so.6`	`libm.so.6` + `libc.so.6`
`rsyslogd -N1` 配置测试	exit=139（SIGSEGV）	exit=0
rsyslog.service	崩溃循环	active (running)，PID 稳定
`/var/log/messages`	空（停写）	正常写入
新增 coredump	每 2 秒一个	无

六、仓库结构

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，可直接执行。

八、相关仓库

仓库	说明
[micoder/rsyslog]`https://atomgit.com/micoder/rsyslog`	rsyslog 8.2312.0 重建修复记录（依赖本仓库修复 libfastjson）
[micoder/glibc] `https://atomgit.com/micoder/glibc`	自编译 glibc 2.44 的构建工程（问题源头）

九、遗留事项

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

十、经验总结

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

许可协议

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

glibc 2.44 — openEuler 2509 RPM 打包工程

Mon, 31 Aug 2026 18:03:04 +0800

glibc 2.44 — openEuler 2509 RPM 打包工程

项目简介

本仓库为在 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）

补丁	性质	说明
`add-pthread_cond_clockwait-GLIBC_2_28.patch`	ABI 兼容	为 openEuler 2.28 时代链接的二进制提供 `pthread_cond_clockwait@GLIBC_2.28` 兼容符号（2.44 上游未含）
`add-Wl-z-noseparate-code-for-so.patch`	厂商性能	x86_64 关闭 separate-code，避免 shell 类程序性能下降 8%~10%（`relro-LDFLAGS` 机制在 2.44 仍有效）
`AArch64-modify_the_SVE_memcpy_implementation_for_32-byte_aligned_access.patch`	鲲鹏性能	SVE memcpy 由 16 字节对齐改为 32 字节对齐，降低跨缓存行访问与 bank 冲突
`strcmp-delete-align-for-loop_aligned.patch`	鲲鹏性能	删除 strcmp `loop_aligned` 的 `.p2align 4`，修复鲲鹏 920 上 16~23 字符场景分支预测性能劣化

主要变更记录

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）

字段	原值	新值
Version	2.38	2.44
Release	120	1
Source0	`%{name}-%{version}.tar.xz`	`.tar.gz`（2.44 发布格式）
gcc 要求	>= 7.2.1-6	>= 12.1（对齐 2.44 INSTALL）
binutils 要求	>= 2.30-17	>= 2.39（对齐 2.44 INSTALL）
Patch 声明	123 条	4 条（Patch0~Patch3）
%changelog	2.28~2.38 历史条目	清空并新增 2.44-1 条目

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

3. 文件清理

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

补丁适用性审计方法

解包 glibc-2.44.tar.gz 得到纯净源码树
按 spec 中 Patch 声明顺序，逐一对每个补丁执行 git apply --check -p1（可应用则 git apply 继续），模拟 %autosetup 行为
对失败补丁在纯净树复检，排除"前序补丁导致的时序冲突"误判
对文本可应用的补丁再做源码对照：确认改动未被 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

构建中修复的错误：

错误	原因	修复
`cannot open file '/rpmbuild/SOURCES/LanguageList'`	systemd-run 服务环境缺 `HOME`，`%{_topdir}` 解析成 `/rpmbuild`	启动时注入 `--setenv=HOME=/root`
`RPM build errors: 没有找到文件：.../COPYING`	glibc-2.44 上游已移除顶层 `COPYING` 文件	`%license` 移除 `COPYING` 引用，保留 `COPYING.LIB LICENSES`

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）：

改动	说明
`removeLoadPath()` 条件	由仅匹配 `$ORIGIN` 扩展为清除任意 RPATH/RUNPATH（`$ORIGIN` 情况保留 `findReliantLib` 软链逻辑）
清理范围	由仅 `gconv/` 子目录扩大至整个 `%{_libdir}`（覆盖 `audit/sotruss-lib.so`）

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

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

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

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

修复（两个提交）：

提交	内容
`e5dfc32`	`make check` 加 `-k`（子目录测试失败不再中止顶层合并）；`test -s tests.sum` 容忍缺失
`3f0dd3b`	`%check` 重排中止逻辑：先汇总非通过项（`tests.sum` 缺失时回退到各子目录 `subdir-tests.sum`），仅当"无失败项可汇总且无 Summary 行"（测试套件整体未运行/构建失败）才判为致命

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

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

rsyslog 8.2312.0 重建修复记录

Mon, 31 Aug 2026 17:53:02 +0800

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 本体：

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

反汇编 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 崩溃

libfastjson.so.4 的 DT_NEEDED 只有 libc.so.6，缺少 libm.so.6：
libc 也导出 modf（弱 IFUNC），链接期 --as-needed 因此丢弃了 -lm。
运行时 libfastjson 的 modf 引用经全局作用域预取绑定到 libm 的 IFUNC，
该预取路径下解析器读取 _rtld_global_ro GOT 槽时为 NULL → SIGSEGV。
对照实验：直接 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，分两步重建：

步骤	仓库	内容
1️⃣	[micoder/libfastjson]`https://gitcode.com/micoder/libfastjson`	重建 libfastjson：`build_ldflags` 追加 `-Wl,--no-as-needed -lm`，DT_NEEDED 加入 libm.so.6
2️⃣	本仓库（rsyslog）	重建 rsyslog：使用一致的 `build_ldflags`，保持 ABI 一致性

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

要点	说明
`--define 'dist .oe2509'`	保持 release 后缀与原发行版一致，`rpm -Uvh --replacepkgs` 可同版本替换，RPM 数据库不产生版本回退
`--nocheck`	跳过 rsyslog 自身耗时的 `make check` 测试套件（10+ 分钟），最终以服务实际启动验证为准
版本号不变（`-8.oe2509`）	仅二进制重新构建，配置与数据文件不受影响

五、验证结果

验证项	修复前	修复后
`rsyslogd -N1` 配置测试	exit=139（SIGSEGV）	exit=0
rsyslog.service 状态	崩溃循环（每 ~2s 重启）	active (running)
Main PID 稳定性	每次崩溃更换	30 秒观察保持不变
`/var/log/messages`	空（停写）	测试日志正常落盘
新增 coredump	每 ~2s 一个	无

六、仓库结构

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_64rpm -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，可直接执行。

八、相关仓库

仓库	说明
[micoder/libfastjson]`https://gitcode.com/micoder/libfastjson`	libfastjson 1.2304.0 重建修复记录（本修复的前置依赖）
[micoder/glibc]`https://gitcode.com/micoder/glibc`	自编译 glibc 2.44 的构建工程（问题源头）

九、遗留事项

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

十、经验总结

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

许可协议

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

pytcper与gotcper tcp网络调试工具助手

Tue, 25 Aug 2026 09:46:10 +0800

pytcper与gotcper tcp网络调试助手

pytcper TCP网络调试助手：基于 Python3 编写的图形化 TCP 网络调试工具助手，支持图形化界面，支持客户端与服务器端，多编码发送，接收，广播指令。零第三方依赖，可跨平台运行，支持Windows / Linux / macOS

项目地址：pytcper:基于 Python + tkinter 的跨平台 TCP 调试助手 - AtomGit

gotcper TCP网络调试助手：一个基于 Go 编写的图形化 TCP 网络调试工具助手，纯 Go 编译（CGO 关闭，无需 C/C++ 工具链），Windows 原生界面，零运行时依赖。支持客户端与服务器端，多编码发送，接收，广播指令。可跨平台运行，支持Windows ， Linux。

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

OpenSSH 10.5p1 - openEuler RPM 打包项目

Sun, 23 Aug 2026 14:37:09 +0800

OpenSSH 10.5p1 - openEuler RPM 打包项目

概述

本项目基于 openEuler 系统环境，对 OpenSSH 10.5p1 源码进行 RPM 打包构建。支持 openEuler 22.03 LTS 和 24.03 LTS。

项目结构

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                      # 本文档

构建产物

构建完成后生成以下 RPM 子包：

RPM 包名	说明	包含内容
`openssh`	核心包	`ssh-keygen`, `ssh-keysign`, `moduli`
`openssh-clients`	客户端包	`ssh`, `scp`, `sftp`, `ssh-agent`, `ssh-add`, `ssh-keyscan`, `ssh-copy-id`, `ssh-pkcs11-helper`, `ssh-sk-helper`
`openssh-server`	服务端包	`sshd`, `sshd-auth`, `sshd-session`, `sftp-server`, Systemd 服务, PAM 配置
`openssh-askpass`	图形密码对话框	`gnome-ssh-askpass`, profile.d 脚本
`openssh-help`	文档和 man 手册	所有 man 手册页和文档

环境要求

支持的操作系统

系统	版本	架构
openEuler	22.03 LTS	x86_64, aarch64
openEuler	24.03 LTS	x86_64, aarch64
openEuler	24.09	x86_64, aarch64

完整依赖清单

构建依赖 (BuildRequires)

包名	版本要求	用途
autoconf	-	重新生成 configure 脚本
automake	-	自动生成 Makefile
gcc	-	C 编译器
make	-	构建工具
dos2unix	-	转换换行符
groff	-	格式化 man 手册
util-linux	-	基础工具集
perl-interpreter	-	Perl 解释器（构建脚本辅助）
perl-generators	-	Perl 依赖生成器
perl-podlators	-	POD 格式转换
zlib-devel	-	压缩库
openssl-devel	>= 1.1.1	SSL/TLS 加密库
pam-devel	-	PAM 认证框架
libselinux-devel	>= 2.3-5	SELinux 安全策略
audit-libs-devel	>= 2.0.5	Linux 审计系统
krb5-devel	-	Kerberos 5 认证
systemd-devel	-	Systemd 服务集成
p11-kit-devel	-	PKCS#11 智能卡支持
openldap-devel	-	LDAP 支持
gtk2-devel	-	GTK2 图形库（askpass）
libX11-devel	-	X11 图形库（askpass）
libedit-devel	-	行编辑和历史记录（sftp）
ncurses-devel	-	终端控制库
xauth	-	X11 认证工具
gnupg2	-	GPG 签名验证
crypto-policies	-	加密策略

运行时依赖 (Requires)

包名	版本要求	归属子包
/sbin/nologin	-	openssh
libselinux	>= 2.3-5	openssh
audit-libs	>= 1.0.8	openssh
openssh-server	= %{version}-%{release}	openssh
crypto-policies	>= 20180306-1	clients, server
pam	>= 1.0.1-3	server
shadow	-	server (pre)
systemd	-	server

包名	用途
p11-kit	PKCS#11 智能卡中间件

快速构建

方法一：使用构建脚本（推荐）

# 以 root 身份运行

sudo bash build.sh

脚本会自动完成：

安装所有构建依赖
设置 RPM 构建环境
生成 SRPM 源码包
构建二进制 RPM 包
输出构建结果

方法二：手动构建

# 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

配置说明

服务端配置

主配置文件: /etc/ssh/sshd_config
扩展配置目录: /etc/ssh/sshd_config.d/
PAM 配置: /etc/pam.d/sshd
服务环境变量: /etc/sysconfig/sshd

客户端配置

全局配置: /etc/ssh/ssh_config
扩展配置目录: /etc/ssh/ssh_config.d/

服务管理

# 启动服务
sudo systemctl start sshd

# 设置开机自启
sudo systemctl enable sshd

# 查看状态
sudo systemctl status sshd

# 重启服务（重新加载配置）

sudo systemctl restart sshd

已启用的功能特性

特性	说明
PAM 认证	可插拔认证模块支持
SELinux 支持	安全增强型 Linux 策略
Kerberos 5	企业级 Kerberos 认证
Linux Audit	系统审计日志
PKCS#11	智能卡/U2F 硬件密钥
Systemd	现代服务管理
X11 转发	图形界面转发
ssh-copy-id	便捷密钥分发
seccomp_filter	沙箱隔离（x86_64/aarch64）
PIE 安全加固	地址空间布局随机化
RELRO/BIND_NOW	只读重定位保护
libedit	sftp 行编辑历史

注意事项

FIDO/U2F 测试: 构建过程中禁用了测试套件，因为 FIDO 密钥模拟器在容器/虚拟机环境中可能存在问题。
seccomp 沙箱: 在 riscv64、loongarch64、sw_64 架构上自动禁用 seccomp_filter 沙箱（这些架构内核支持不完整）。
签名文件: 不再需要 Source1 签名文件（.asc），构建过程已移除相关检查。
自检测试: 如需运行测试，在 spec 中取消注释 %%check 部分，然后执行 make tests。

版本历史

版本	日期	说明
10.5p1-1	2026-08-22	基于 openEuler 的 OpenSSH 10.5p1 打包
10.4p1-1	2026-07-20	首次适配 openEuler 的 OpenSSH 10.4p1 打包
10.3p1-1	2026-06-01	基于 openEuler 的 OpenSSH 10.3p1 打包

Spec 文件审查报告

本节记录对 openssh-10.4p1.spec 的全面审查结果，包括功能验证与问题修复。该审查发现的所有修复项均已同步移植到当前版本的 openssh.spec（10.5p1），

包括 openEuler 2403 兼容修复（%undefine __brp_digest_list + BuildRequires: systemd-rpm-macros）与 %files 完整性修复。

功能验证

功能	审查结论	验证依据
X11 转发	完整支持	`BuildRequires: libX11-devel gtk2-devel xauth` + `--with-xauth=/usr/bin/xauth` + `sshd_config` 默认启用 `X11Forwarding` + `gnome-ssh-askpass` 构建与安装
ssh-copy-id	完整支持	`contrib/ssh-copy-id` 安装到 `%{_bindir}` + 手册页安装到 `man1` + `%files clients` 中声明
PAM 认证	已启用	`--with-pam` + 自定义 `/etc/pam.d/sshd` 配置
SELinux	已启用	`--with-selinux` + `libselinux-devel` 构建依赖
Kerberos 5	已启用	`--with-kerberos5` + `krb5-devel` 构建依赖
Linux Audit	已启用	`--with-audit=linux` + `audit-libs-devel` 构建依赖
PKCS#11	自动检测	`p11-kit-devel` 构建依赖，configure 自动启用
Systemd	完整集成	`%systemd_post` / `%systemd_preun` / `%systemd_postun_with_restart` + `sshd.service` 单元
seccomp 沙箱	条件启用	`--with-sandbox=seccomp_filter`（x86_64/aarch64），riscv64/loongarch64/sw_64 自动禁用
PIE 安全加固	已启用	`LDFLAGS="$LDFLAGS -pie -z relro -z now"`
libedit	已启用	`libedit-devel` 构建依赖，configure 自动检测
askpass 图形对话框	完整支持	GTK2 版 gnome-ssh-askpass 构建 + ssh-askpass 符号链接 + profile.d 脚本

审查发现的问题与修复

#	问题描述	严重程度	修复方式
1	`BuildRequires` 中误用运行时库 `audit-libs >= 1.0.8`（非 devel 包，且第31行已有 `audit-libs-devel >= 2.0.5`）	中	已删除该冗余条目
2	`%install` 中创建了 `ssh_config.d` 目录，但 `%files clients` 中未声明，rpmbuild 时会报 `unpackaged files` 错误	高	已在 `%files clients` 中添加 `%dir %attr(0755,root,root) %{_sysconfdir}/ssh/ssh_config.d`
3	缺少 `--with-xauth` 配置选项，可能导致 xauth 路径检测失败，影响 X11 转发	中	已添加 `--with-xauth=/usr/bin/xauth`
4	openEuler 2403 构建失败：`brp-digest-list` 脚本因 SELinux 路径检查失败报 `Path is outside buildroot`	高	添加 `BuildRequires: systemd-rpm-macros` + `%undefine __brp_digest_list`

语法结构验证

检查项	结果
`%if` / `%endif` 平衡（2个条件块）	全部闭合
`%package` 与 `%files` 对应（5个子包）	全部匹配
Source 声明与 `%install` 引用对应（4个 Source）	全部引用
构建脚本 `build.sh` shell 语法检查	通过 (`bash -n`)

构建适配总结报告（2026-08-23）

本节记录近期对本项目构建配置的两次适配优化：dist 发行版后缀参数化与systemd 构建依赖按 openEuler 版本条件选择。

1. dist 发行版后缀参数化（build.sh）

背景

本机打包时需要为 RPM 添加发行版后缀（如 .oe2509），原实现将 --define "dist .oe2509" 硬编码在 rpmbuild 命令中，导致所有场景（含非本机打包）都会带上该参数。

修改方案

build.sh 配置区新增 DIST 变量，默认留空（不传 dist 参数）；仅本机打包时填写：

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

# 根据 DIST 是否填写构造 rpmbuild 参数（为空则不添加 --define "dist ..."）

DIST_ARGS=()if [ -n "$DIST" ]; then
    DIST_ARGS=(--define "dist $DIST")fi

rpmbuild -bs 与 rpmbuild -bb 命令均改为引用 "${DIST_ARGS[@]}"，留空时不添加任何 dist 定义。

配套修改 openssh.spec：Release: %{openssh_release} → Release: %{openssh_release}%{?dist}，使 dist 宏能正确拼入版本号。

验证结果

模式	rpmbuild 参数	Release 展开
默认（DIST 留空）	不传 dist	`openssh-10.5p1-1`
本机打包（DIST=.oe2509）	`--define "dist .oe2509"`	`openssh-10.5p1-1.oe2509`

顺带修复

原 rpmbuild -bb 命令行中的 $(rpm --eval '%{?_smp_mflags}') 在 openEuler 上会展开成未解析的 ${RPM_BUILD_NCPUS}（/usr/lib/rpm/macros 中 %_smp_mflags 定义为
-j${RPM_BUILD_NCPUS} 的 shell 风格），导致 rpmbuild 报错 未知的选项。
已从命令行移除该参数（_smp_mflags 只应通过 %make_build 在 spec 内部使用）。

2. systemd 构建依赖按 openEuler 版本条件选择（openssh.spec）

背景

构建 RPM 时发现：openEuler 25.09 才有独立的 systemd-rpm-macros 包（提供 %systemd_post 等 RPM 宏），而 22.03/24.03 等低版本由 systemd 包提供。
原 spec 写死 BuildRequires: systemd-rpm-macros，在低版本上无法解析。

修改方案

openssh.spec 从 /etc/openEuler-release 提取主版本号，按版本条件选择构建依赖：

# 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

版本宏调查结论

候选宏	openEuler 22.03	openEuler 25.09	结论
`%{?openEuler}`	`1`（EulerMaker 文档确认）	`2`（本机确认）	值不反映具体版本，不可靠
`%{?rhel}` / `%{?fedora}` / `%{?oe_ver}`	空	空	均未定义，不可用
`/etc/openEuler-release` 版本号	`22`	`25`	最终采用

验证结果（`rpmspec -P` 实测展开）

模拟版本	oe_major	选中的 BuildRequires
22.03	22	`systemd`
24.03	24	`systemd`
25.09	25	`systemd-rpm-macros`

验证中发现并修复的宏解析陷阱

最初提取版本号使用 %(sed -n 's/^openEuler release $[0-9]*$\..*/\1/p' ...)，其中 $ $ 转义括号干扰了 rpm 宏解析，

导致 oe_major 展开为空、2509 也误走 systemd 分支。改用无转义括号的管道写法（sed ... | cut -d. -f1）后验证通过。

提交	说明
`eb4a1bb`	build: dist 参数改为可选变量，默认不传
`7923bdc`	spec: systemd 构建依赖按 openEuler 版本条件选择

openeuler2509安装Oracle AI Database 26ai

Fri, 14 Aug 2026 23:59:26 +0800

Oracle AI Database 26ai 安装报告

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

1. 安装结果总览

项目	状态	说明
预装包 `oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm`	✅ 已安装	创建 oracle 用户/组、内核参数、限额
数据库软件 `oracle-ai-database-ee-26ai-1.0-1.el10.x86_64.rpm`	✅ 已安装	Oracle Home:`/opt/oracle/product/26ai/dbhome_1`
容器数据库 ORCLCDB	✅ READ WRITE	SID=ORCLCDB,字符集 AL32UTF8
插接库 ORCLPDB1	✅ READ WRITE	随 CDB 创建
监听器 LISTENER:1521	✅ READY	实例 ORCLCDB 已注册
数据文件位置	✅	`/opt/oracle/oradata`(约 3.4G)

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 部分依赖无法直接满足,处理过程如下:

依赖缺失诊断:首次 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 未安装

解决措施:

# 创建 /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

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

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

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

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

内核参数(/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):

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

3.2 数据库软件安装

介质校验:首次下载的 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
```
属主修正:安装时 %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
```
安装产物:

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 注意事项

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

安装日志:/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. 安装介质

文件	大小	说明
`oracle-ai-database-preinstall-26ai-1.0-1.el10.x86_64.rpm`	35 KB	预装包(官方 sha256 `9e70e660…` 校验一致)
`oracle-ai-database-ee-26ai-1.0-1.el10.x86_64.rpm`	2.1 GB	数据库软件(完整性校验通过)

网路互联

ELAN0618 触摸板 Windows Server 2019 修复,可正常驱动触控板操作。

ELAN0618 触摸板 Windows Server 2019 修复包https://gitcode.com/micoder/ELAN0618_Touchpad

问题

根因

修复原理

使用方法

方法一：双击运行（推荐）

方法二：PowerShell

方法三：手动安装

修复后的设备状态

文件清单

目标设备兼容性

注意事项

修复过程中记录的系统修改

修改的系统文件

修改的注册表项

未修改（已还原）

环境

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

kernel7.2.0

环境信息

编译与安装过程

安装结果验证

NVIDIA 闭源驱动适配（580.159.04）

1. strncpy 被内核 7.2 彻底移除

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

3. conftest.sh 签名检测过时

并发限制

驱动安装验证

重启后验证命令

回滚方案

备注

ly_ueditor_plus 粘贴换行丢失修复总结报告

ly_ueditor_plus 粘贴换行丢失修复总结报告

一、问题现象

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

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

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

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

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

修复 A：filterWord 保护 <pre> 块

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

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

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

四、验证结果

五、部署与缓存

六、文件变更清单

oracle 26ai安装示例数据库

oracle 26ai安装示例数据库

安装报告 (Installation Report)

1. 目标数据库

2. 客户端工具（安装于本机）

3. 账号汇总

4. 安装过程摘要

5. 验证结果（provided = actual，全部一致）

6. 已知限制

7. 日志位置

8. 卸载方式

9. 具体安装命令与步骤

9.1 工具准备

9.2 HR / CO / SH（受支持 schema，交互提示）

9.3 OE / PM（归档 schema，参数传入）

9.4 验证抽查命令

libfastjson 1.2304.0 重建修复记录

libfastjson 1.2304.0 重建修复记录

📑 目录

一、项目简介

二、问题背景

三、根因分析

3.1 崩溃定位链

3.2 关键对照实验

四、修复方案

五、验证结果

六、仓库结构

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

八、相关仓库

九、遗留事项

十、经验总结

许可协议

ELAN0618 触摸板 Windows Server 2019 修复包

https://gitcode.com/micoder/ELAN0618_Touchpad

1. `strncpy` 被内核 7.2 彻底移除

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

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

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

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

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

修复 A：`filterWord` 保护 `<pre>` 块

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

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

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

验证结果（`rpmspec -P` 实测展开）