在 Arch KDE 上配置系统级 Postfix 邮件通知出口:让 root 与普通用户脚本都能简单发信

背景 在一台 Arch KDE 桌面主机上,存在一个很实际的需求:当脚本、备份任务、系统维护任务或定时任务开始执行时,发送一封通知邮件,提示“任务已经开始,请不要关机”;当任务完成或失败时,再发送一封结果邮件。 目标不是在桌面主机上搭建完整邮件服务器,也不是让它接收外部邮件,而是让它具备一个稳定、统一、简单的“系统级发信出口”。 最终希望脚本中可以直接写: 任务完成时: 任务失败时: 无论脚本由普通用户执行,还是由 root 执行,都应能用同样方式发信。 已有经验:PVE/PBS 的系统级邮件出口 在已有服务器环境中,PVE 和 PBS 已经配置过邮件通知。它们通过本机 Postfix 将系统通知中继到外部 SMTP 服务,并使用专用账号作为发件人。备份任务、系统任务完成后都能正常发送通知邮件。 这类方案的特点是: 这种结构非常适合 PVE/PBS 这类服务器系统,因为系统任务天然由 root、systemd 或 cron 执行。如果桌面主机也希望 root 任务和普通用户任务都能统一发信,那么系统级 Postfix relay/null-client 方案比用户级 SMTP 客户端更合适。 为什么没有采用用户级 msmtp 方案 最初也可以考虑 msmtp + mailx 方案。它很轻量,适合普通用户脚本发信: 但当需求扩展为“root 任务也要发信”时,用户级方案会迅速变复杂: 这样会带来几个问题: 而实际需求只是希望以后脚本里能简单调用 mailx。因此,继续扩展用户级方案并不合适。 …

Arch Linux 上苹果硬件风扇控制与温度监控记录:从高温降频风险到 mbpfan 接管

摘要 一台运行 Arch Linux 的苹果硬件设备,在重任务后出现 CPU 温度接近高温上限的情况。排查发现,系统中已经加载 applesmc,并且存在 fan1_input、fan1_min、fan1_max 等 Apple SMC 风扇接口。这说明该设备的风扇控制并不适合优先使用通用 fancontrol,而更适合使用面向苹果硬件的 mbpfan。 最终处理方案是: 实施后,风扇不再长期停留在最低转速附近,而是可以随温度上升自动提高转速,温度控制状态明显改善。 一、问题背景 设备在重任务后曾出现 CPU 温度接近高温上限的情况。虽然温度随后下降,但该现象说明系统默认风扇策略可能偏保守,在 Linux 下没有及时把风扇转速拉高。 初始观察到的状态大致如下: 这种情况的风险在于: 因此,本次目标不是追求极限性能,而是让风扇更早介入,避免 CPU 在重任务下反复冲到高温边缘。 二、确认风扇控制接口 首先确认系统是否加载了苹果硬件相关模块: 如果输出中存在: 说明系统已经具备读取 Apple SMC 与 CPU 温度的基础条件。 然后确认风扇接口: 如果可以看到类似文件: 说明风扇是通过 Apple SMC 暴露出来的。 典型读数可能类似: 这些数值应以本机实际读取结果为准。 三、为什么选择 mbpfan 而不是 fancontrol fancontrol …

一次 KDE 用户级服务过早启动问题排查:OpenClaw、systemd 与 KWallet 的启动顺序

背景 在 Arch Linux + KDE Plasma 桌面环境中,OpenClaw Gateway 作为用户级 systemd 服务运行。为了避免在配置文件中保存明文密钥,Gateway 的认证信息通过 KDE Wallet 读取。这个设计本身是合理的:密钥交给桌面会话的钱包管理,服务启动时再通过本地 secret provider 取出。 问题出现在一次系统或应用更新之后。原本已经调整过的用户级 systemd 启动关系,被重新生成了一个 default.target.wants 下的链接,导致 OpenClaw Gateway 再次过早启动。由于启动时间早于 KDE 图形会话完全就绪,也早于 KWallet 通过 PAM 完成解锁,Gateway 无法读取钱包中的 secret,最终启动失败。 这个问题表面上像是 KWallet 崩溃、Qt 插件缺失,甚至 KDE 环境异常;但实际根因是:用户级 systemd 服务被错误地挂回了 default.target,启动顺序早于图形会话和钱包解锁。 现象 系统启动后,OpenClaw Gateway 没有稳定进入可用状态。日志中可以看到类似信息: 同时,KWallet 相关日志中还可能出现: …

Linux 手动维护的驱动源码应该放在哪里:从 DKMS 声卡驱动整理说起

背景 在 Linux 系统中,有些硬件驱动并不完全依赖发行版内核自带模块,而是需要额外使用第三方源码、DKMS 或手动安装脚本进行维护。常见场景包括无线网卡、特殊声卡、旧硬件驱动、笔记本专用补丁模块等。 这类源码最初往往会被临时 clone 到用户目录,例如: 这种做法在测试阶段很方便,但如果这个驱动后来成为系统长期运行所依赖的一部分,继续放在临时工作目录里就不太合适了。 一次 MacBook 声卡驱动维护过程中,就遇到了这个问题:驱动源码原本放在用户的 workspace 目录中,但该驱动实际上已经成为系统升级内核后恢复声音的重要维护组件。因此,有必要把源码移动到更合适的长期位置。 用户工作目录不适合长期保存系统驱动源码 类似下面的位置更适合作为临时工作区: 这些目录的特点是: 但如果里面存放的是长期依赖的系统驱动源码,就会出现几个问题: 尤其是 DKMS 驱动源码,它虽然最初只是一个 git 仓库,但后续可能会被反复用于: 这种性质已经不再是普通用户项目,而是本机系统维护资源。 推荐位置:/usr/local/src 对于本机管理员手动维护、非发行版包管理器安装的源码,一个比较合理的位置是: 例如: 这个位置的语义比较清楚: 它不同于发行版包管理器主要管理的 /usr/bin、/usr/lib、/usr/share 等路径,也不同于用户自己的普通文档目录。 因此,把第三方驱动的上游源码仓库放在 /usr/local/src,可以理解为: 需要区分的三个目录 以一个 DKMS 声卡驱动为例,整理后的结构可以分为三层。 1. 上游源码仓库 这是手动保留的 git 仓库,用于以后更新源码和重新安装驱动。 它的用途包括: 这个目录是人为维护的,不是 DKMS 自动生成的。 2. DKMS 注册源码目录 这是 …

Arch Linux 升级内核后 MacBook 内置声卡再次无声的排查与修复记录

问题现象 一台安装 Arch Linux 的 MacBook 在系统升级后再次出现内置扬声器无声的问题。系统中声卡设备仍然可以被识别,aplay -l 能看到 Intel HDA PCH 与 CS8409 相关设备,但实际没有声音输出。 这类问题容易被误判为 PipeWire、PulseAudio、ALSA 音量或桌面环境设置问题。但本次排查后确认,根本原因并不在用户层音频服务,而是在内核声卡驱动模块。 硬件与驱动背景 部分 MacBook 使用 Cirrus Logic CS8409 相关音频芯片,实际音频路径还涉及 CS42L83 codec。Linux 内核自带的 snd-hda-codec-cs8409 模块虽然可以识别声卡设备,但对某些 MacBook 的内置扬声器路径支持并不完整。 因此,这类机器通常需要使用 snd_hda_macbookpro 项目提供的修正版 DKMS 驱动。该驱动会覆盖或优先于内核自带的 snd-hda-codec-cs8409 模块,从而让内置声卡正常工作。 初始检查 系统升级后,首先检查当前内核版本、headers、DKMS 状态和声卡模块路径: 其中最关键的是: 如果输出类似: 说明系统正在使用内核自带的原始模块。 正确状态应该类似: updates/dkms 表示当前加载的是 DKMS …

Arch Linux 系统升级失败:PGP Signature Marginal Trust 问题完整排查记录

一、问题背景 在一次常规的 Arch Linux 系统升级过程中,执行: 升级流程在 checking package integrity 阶段全部通过,但随后出现大量错误: 最终导致: 系统无法完成升级。 值得注意的是: 表面看似软件包损坏,实际上问题完全不同。 二、错误本质 核心关键词: 这并不表示软件包损坏,而是: Pacman 无法确认签名者在本机 PGP 信任链中具备足够信任等级。 Arch Linux 的软件包安全机制依赖: 升级流程为: 当本机 keyring 状态异常时,即使: ✅ 包真实✅ 签名正确✅ 来源官方 Pacman 仍会拒绝安装。 因此出现: 实际上是 信任验证失败。 三、常见触发原因 实践中主要有以下几类原因: 1️⃣ archlinux-keyring 过旧(最常见) 长期未升级系统时: 导致签名无法建立信任路径。 2️⃣ 本地 pacman-key 数据损坏 可能来源: 3️⃣ …

系统更新后的一次日志解读:从软件包到内核重启

最近一次系统更新完成后,系统输出了一系列日志内容。记录显示,共有 265 个软件包进行了更新,包括 VLC 播放器、图形相关组件(如 vulkan、webkit2gtk)、Zoom、yt-dlp、Zotero 等常用软件。其中,VLC 增加了一些新的可选插件支持,如字幕渲染(vlc-plugin-freetype)、系统通知(vlc-plugin-notify)以及对 .srt 字幕文件的支持(vlc-plugin-srt)。 除了软件包升级之外,系统还自动执行了一系列 “post-transaction hooks”(事务后处理脚本),确保更新后的系统稳定运行。这些操作包括: 其中一个关键步骤是 DKMS(动态内核模块支持)模块的安装。日志中显示,安装了两个模块: 这两个模块都针对内核版本 6.15.9-arch1-1 进行了编译,随后使用 depmod 更新模块依赖信息。 接下来的步骤是构建内核启动镜像(initramfs): 完成所有任务后,系统显示当前内核版本为 6.15.7-arch1-1,而不是新安装的 6.15.9-arch1-1。 这表明虽然新内核和所有更新已经完成,但系统还没有重启。因此,新的内核和驱动模块尚未生效。 建议操作 执行以下命令以启用新内核并使驱动生效: 重启完成后,可以通过以下命令验证当前使用的内核: 预期输出应为: 这代表系统已经成功切换到新内核,并启用了最新的驱动和更新配置。

在 Arch Linux 上安装与管理多个 Java 版本

在 Arch Linux 或其衍生发行版中(如 Manjaro),开发者和用户常常需要在多个 Java 版本之间切换,以满足不同软件对 JDK 的依赖要求。本文将介绍如何在 Arch 系统中并行安装多个 Java 版本,并使用 archlinux-java 工具进行版本管理和切换。 一、查看已安装的 Java 版本 可以使用以下命令列出系统中当前可用的 Java 环境: archlinux-java status 输出示例: Available Java environments: java-11-openjdk java-17-openjdk java-24-openjdk java-8-openjdk/jre (default) 括号中标注 (default) 的版本即当前系统默认使用的 Java 版本。 二、安装所需的 Java 版本 Arch 的官方仓库提供多个 OpenJDK 版本,常见安装命令如下: # 安装 Java 8sudo pacman -S …

Arch Linux 旧内核模块清理与 DKMS 编译错误彻底解决记录

在长期使用 Arch Linux 的过程中,内核会不断更新,系统也会留下许多历史内核版本的残留模块目录。这些残留文件虽然通常不会影响正常启动,但在安装或编译 DKMS(动态内核模块,如无线网卡驱动、显卡驱动等)时,常常会提示「为旧内核编译失败」的错误,影响体验。 这篇文章记录一次系统性清理旧内核文件的全过程,并分析 DKMS 触发机制,最终彻底解决编译提示问题。 💡 背景 Arch Linux 采用滚动更新模式,经常自动升级到最新内核。每次升级时,pacman 会安装新内核并更新 /usr/lib/modules 目录。然而,老版本内核的模块目录并不会自动删除,导致大量「历史残留」。 例如,/usr/lib/modules 中可能出现如下目录: 5.15.29-1-lts5.15.30-1-lts5.16.16-arch1-16.7.6-zen1-1-zen6.14.10-arch1-16.15.2-arch1-1 ← 当前使用内核 ⚠️ 问题表现 在安装 DKMS 驱动(如 snd-hda-macbookpro、rtl88x2bu 等)时,经常出现以下提示: 为内核 5.16.16-arch1-1 编译失败:找不到内核头文件或符号表 虽然不影响当前系统的正常运行,但会导致日志或安装输出杂乱,给人一种「系统不干净」的印象。 🔎 原因分析 DKMS 如何决定编译哪些内核 DKMS 并不是对 /usr/lib/modules 中每个目录都强制编译,而是根据以下条件判断: 只要 build 文件存在,即使该内核实际已被卸载,DKMS 仍然会尝试为其编译驱动,最终导致提示错误。 ✅ 彻底解决思路 1️⃣ 清理 /usr/lib/modules 旧内核目录 …

内核相关报错,升级Archlinux时

全部问题 ==> WARNING: Possibly missing firmware for module: ‘qla1280’ ==> WARNING: Possibly missing firmware for module: ‘qed’ ==> WARNING: Possibly missing firmware for module: ‘bfa’ ==> WARNING: Possibly missing firmware for module: ‘aic94xx’ ==> WARNING: Possibly missing firmware for module: ‘wd719x’ ==> WARNING: Possibly missing firmware for module: ‘qla2xxx’ ==> …