克隆树莓派系统后,如何拆分两台设备的系统身份

背景 一套已经配置好的树莓派系统被完整复制到另一张存储卡上,随后分别在两台树莓派设备上启动。这样做可以节省大量重复配置时间,尤其适合系统中已经预先配置好远程访问、网络脚本、代理服务、Web 服务和若干常驻服务的情况。 不过,完整克隆系统也会带来一个明显问题:两台设备虽然硬件不同,但系统内部身份可能完全相同。 如果不处理,后续可能出现: 因此,在两台设备正式长期运行前,需要先把系统身份拆分开。 克隆系统后需要处理哪些身份信息 克隆系统后,至少需要检查和处理以下内容: 其中,最基础的三项是: 这三项分别对应: 只改主机名是不够的。如果 machine-id 和 SSH Host Key 仍然相同,两台设备在系统层面和安全身份层面仍然带有克隆痕迹。 第一次只改主机名为什么失败 一开始使用了常规方式修改主机名: 并同步修改: 当时看起来已经成功,但重启后主机名又恢复成旧值。 这说明问题并不在 hostnamectl 本身,而是系统启动过程中还有其他组件在覆盖主机名。 进一步检查发现,这套系统启用了 cloud-init。在该类系统中,主机名可能不是只由 /etc/hostname 决定,而是还会受到启动分区中的 cloud-init 配置影响。 关键位置包括: 如果启动分区的 user-data 中仍然写着旧主机名,同时 cloud-init 没有设置为保留当前主机名,那么重启后系统可能再次把主机名改回旧值。 因此,正确做法不是只改 /etc/hostname,而是要同时处理 cloud-init 的源头配置。 正确修改第一台设备主机名 假设第一台设备的新主机名为: 在 root 用户下,可以一次性执行: 重启后确认: 目标状态是: 这样,主机名才算真正持久修改成功。 重新生成 machine-id …

使用 Raspberry Pi Imager 建立分区后,通过 rsync 还原树莓派系统备份

背景 树莓派系统备份有两种常见方式:一种是直接使用镜像工具进行整卡复制,另一种是以目录形式保存完整 Linux 根文件系统。后者的优点是灵活,可以在不同容量的 SD 卡之间迁移,也方便排除临时文件、伪文件系统和缓存内容。 本次操作的目标是:使用 Raspberry Pi 官方写盘工具先写入一个新的可启动系统,让它自动建立 SD 卡分区结构;然后保留这个分区结构,删除新系统文件,再把已有的完整系统备份同步进去。最后修改新 SD 卡的 UUID,使系统能够正常启动。 这种方式适合以下场景: 基本思路 整个流程可以概括为: 其中最关键的地方是:还原文件之后,不能继续使用旧备份里的 UUID。必须把 fstab 和 cmdline.txt 中的 UUID 改成当前 SD 卡实际分区的 UUID。 事前确认 假设: 其中: 备份目录应当是完整的 Linux 根文件系统,顶层通常能看到: 如果备份使用的是较新的 Raspberry Pi OS 或 Ubuntu for Raspberry Pi,启动文件通常位于: 对应地,启动分区应挂载到: 第一步:用 Raspberry Pi Imager 写入基础系统 …

KDE Akonadi 登录阶段启动超时的排查与修复:一次由 kalendarac 引发的竞态问题

背景 某台 Arch Linux KDE Plasma 桌面系统在登录后检查用户级 systemd 服务状态时,发现曾经出现过 Akonadi 相关失败记录。Akonadi 是 KDE PIM 体系中的个人信息管理后端,常被 KMail、Kontact、KOrganizer、KAddressBook、日历提醒、联系人、邮件索引等组件使用。 问题的表面现象比较迷惑: 一开始能看到 Akonadi 相关失败;但随后执行: 又显示: 也就是说,systemd 认为某次 Akonadi 启动失败了,但 Akonadi 本身后来又确实运行起来了。 这类问题如果直接重建 Akonadi 数据库,很容易扩大风险。更合理的处理方式是先确认失败链路,再做最小可回退修复。 初始现象 用户级日志中可以看到类似记录: Akonadi 使用内置 MariaDB/MySQL 后端。日志中 mysqld 被 systemd 杀掉,说明失败并不是单纯的前端组件问题,而是 Akonadi 启动流程中包含的数据库进程被一并终止了。 系统级 unit 内容类似: 最初可疑点是 TimeoutSec=5sec。Akonadi 登录阶段启动时需要拉起 MariaDB、初始化数据库、注册 D-Bus …

在 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 …

Arch Linux KDE Plasma 高 DPI 缩放排查:从 SDDM 登录界面文字过小到全局缩放统一

背景 某台 Arch Linux 桌面系统使用 KDE Plasma 6,显示会话为 X11,登录管理器为 SDDM,桌面缩放设置为 150%。系统使用 Breeze 主题,光标、图标、颜色主题也都保持 Breeze 系列,以保证视觉风格一致。 问题出现在开机后的 SDDM 登录界面:登录前的界面没有按照预期进行缩放,文字显得很小,但鼠标指针又显得偏大。进入 KDE 桌面之后,应用界面和字体整体看起来正常,但经过进一步观察发现,桌面里的鼠标指针反而偏小。也就是说,问题并不是单纯的“SDDM 没有缩放”,而是登录界面、桌面会话、光标大小、字体 DPI 之间没有完全统一。 本次排查的目标是: 一、现象描述 系统设置中,KDE Plasma 桌面缩放比例为 150%。进入桌面后,大部分 Qt/KDE 应用显示正常。 但是开机后的 SDDM 登录界面出现以下现象: 最初容易误判为 SDDM 完全没有继承 KDE 的 150% 缩放。但后续检查发现,问题更细:SDDM 的底层 X11 DPI 已经是 144,也就是 150%,只是 SDDM greeter 没有完整吃到 …

一次 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 相关日志中还可能出现: …

一次 OpenClaw 可见浏览器无法启动问题的排查:systemd 用户服务、KDE 图形会话与 DISPLAY 环境变量

在 Linux 桌面环境中,有些后台服务本身运行正常,却无法启动可见窗口。这个问题表面上像是浏览器坏了,或者应用自身没有正确识别图形环境;但实际原因往往更底层:服务启动时没有继承当前图形会话的环境变量。 这次遇到的问题是:OpenClaw Gateway 作为 systemd –user 用户服务运行,终端可以正常连接 Gateway,TUI 也能启动,但让它打开可见浏览器时失败,提示当前服务环境中没有 $DISPLAY 或 $WAYLAND_DISPLAY。 问题现象 在终端中启动 OpenClaw TUI 后,输入“打开浏览器”,返回类似提示: 但此时桌面环境本身是正常的,终端也处在 KDE 图形桌面中。也就是说,问题并不是“系统没有图形界面”,而是 OpenClaw Gateway 这个后台服务进程没有拿到图形会话环境。 初步确认:这是用户服务,不是系统服务 一开始容易犯的错误是直接查系统级服务: 结果会显示: 这并不代表服务不存在,而是因为 OpenClaw Gateway 安装为用户级 systemd 服务,应使用: 用户级服务文件位于类似: 这类服务由当前用户的 systemd –user 管理,而不是系统级 systemd 管理。 检查当前终端环境与服务进程环境 问题的关键在于比较两层环境: 一层是当前终端环境: 在 KDE X11 会话中,终端里通常能看到类似: 另一层是 OpenClaw …

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 …