一、问题背景 在一次常规的 Arch Linux 系统升级过程中，执行： 升级流程在 checking package integrity 阶段全部通过，但随后出现大量错误： 最终导致： 系统无法完成升级。 值得注意的是： 表面看似软件包损坏，实际上问题完全不同。 二、错误本质 核心关键词： 这并不表示软件包损坏，而是： Pacman 无法确认签名者在本机 PGP 信任链中具备足够信任等级。 Arch Linux 的软件包安全机制依赖： 升级流程为： 当本机 keyring 状态异常时，即使： ✅ 包真实✅ 签名正确✅ 来源官方 Pacman 仍会拒绝安装。 因此出现： 实际上是 信任验证失败。 三、常见触发原因 实践中主要有以下几类原因： 1️⃣ archlinux-keyring 过旧（最常见） 长期未升级系统时： 导致签名无法建立信任路径。 2️⃣ 本地 pacman-key 数据损坏 可能来源： 3️⃣ …
一、背景 在一次跨地域服务器迁移过程中，需要将既有系统中的 V2Ray 运行文件迁移至一台新设备。迁移对象主要包括以下内容： 日志文件不参与迁移，因为目标系统会自动重新生成。 迁移环境具有如下特征： 因此，本次迁移的核心问题并非“如何复制文件”，而是： 如何在跨境高延迟网络下稳定、高效、可恢复地完成文件同步。 二、初始方案：SFTP / SCP 拉取 最初采用的方式为： 该模式存在两个问题： 数据路径实际变为： 这种结构会导致： 实际测速仅达到几十 KB/s。 三、方向调整：改为 Push 模式 随后调整为： 即： 跨地域网络中，一个经验规律是： 让网络质量更好的节点主动发送数据。 方向切换后，传输速率立即提升。 四、引入 Rsync 相比 SCP，Rsync 具备以下关键优势： 1. 差异同步（Delta Transfer） Rsync 不会无条件复制文件，而是： 即使文件体积较大，只要修改较少，传输量也会显著降低。 2. 断点续传能力 跨境链路中断十分常见。 默认 SCP： 而 Rsync 可通过参数实现安全续传。 五、最终使用命令 迁移采用如下形式： 参数说明： 参数 作用 …
一、问题背景 在基于 FRP 的远程连接或内网穿透架构中，客户端通常以 systemd 服务方式长期运行，以确保设备重启后能够自动恢复连接。 在实际部署过程中，经常出现以下现象： 这些问题多数并非 FRP 本身造成，而是 systemd 启动顺序与网络就绪状态之间的不匹配。 二、常见错误配置 部分配置中会出现类似写法： 该参数来源于容器编排系统，并 不属于 systemd 支持的语法。 结果是： 因此必须使用 systemd 原生参数。 三、核心稳定原则 长期运行类网络服务需要满足三个条件： systemd 中对应的关键机制为： 它表示： 四、推荐的标准 systemd 服务模板（脱敏） 以下为经过泛化处理后的通用配置示例： 说明： 项目 含义 Description 服务描述（任意名称） WorkingDirectory 程序工作目录 ExecStart 客户端启动命令 Restart=always 退出后自动重启 RestartSec 重启等待时间 network-online.target 等待网络就绪 五、为什么必须等待 network-online 典型系统启动流程如下： 此时服务会直接退出。 …
一、问题背景 在部署 FRP（Fast Reverse Proxy） 时，官方 Release 页面通常提供大量二进制版本，例如： linux_amd64linux_armlinux_arm64linux_arm_hflinux_mipslinux_riscv64windows_amd64darwin_arm64… 对于使用单板计算机、软路由或服务器设备的环境，选择错误架构是最常见的启动失败原因之一。 本文对常见 Linux 设备架构与 FRP 版本进行统一对照总结。 二、Linux CPU 架构判定方法 在目标设备执行： uname -m 或： getconf LONG_BIT 即可确定系统架构。 三、FRP 架构对应关系（核心对照表） uname -m 输出 CPU 架构 系统类型 应下载 FRP x86_64 AMD64 / x86_64 PC / 服务器 / VPS linux_amd64 aarch64 ARM64 ✅ ARM 64 …
摘要 本文记录一次在线系统迁移过程：在系统正常运行的前提下，将 Raspberry Pi 上的 Ubuntu 24.04 LTS 系统从一张 8GB SD 卡迁移到一张 16GB SD 卡，并实现根分区自动扩容。 本流程不使用 dd，采用 rsync 进行文件系统级复制，并通过 UUID 启动方式避免盘符混乱问题。 该方法适用于： 迁移目标 当前环境示例 运行系统盘： 目标盘（通过 USB 读卡器接入）： 一、重新分区目标 SD 卡 目标卡必须为： 执行： 输入： 二、创建文件系统 三、挂载新系统 四、复制整个系统（文件系统级迁移） 使用 rsync 而非 dd。 原因： 执行两次： 第二次执行用于补同步。 五、获取新卡 UUID 示例： 六、修改新系统 fstab 编辑： …
Ubuntu 采用固定的时间发布节奏，每年发布两个版本，分别位于 4 月（.04） 与 10 月（.10）。版本号由 年份 + 月份 组成，同时每个版本都配有一个以相同首字母开头的英文代号，形式为 形容词 + 动物名。 以下整理自 2016 年开始的 Ubuntu 主要版本及其官方代号。 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 发布与支持周期规律总结 使用场景说明 该时间线可用于以下场景：
本文记录一次 Ubuntu 22.04 LTS → Ubuntu 24.04 LTS 的原地升级过程，适用于已经长期运行、承载多项服务的系统。供后续参考。 一、升级背景与原则 这台系统最早安装于 Ubuntu 16.04，随后经历了 18.04 → 20.04 → 22.04 的多次大版本升级。系统上运行着多个长期服务，因此本次升级遵循以下原则： 升级目标版本为： 二、升级前准备（关键） 1. 确认当前系统版本 确认输出为： 2. 将 22.04 更新到“绝对干净状态” 必须确保在一个完全更新、无残留错误的 22.04 系统上升级。 3. 检查 LTS 升级策略 编辑升级策略文件： 确认内容为： 4. 数据与系统备份（不可省略） 至少满足以下任一条件： 示例（脱敏）： ⚠️ 大版本升级不可逆，备份是底线。 三、正式升级流程 使用官方升级工具（推荐） 若提示： 可使用： 对 LTS 来说，-d …
背景 在一次正常启动 Ubuntu 22.04 LTS 系统时，在 TTY 登录界面看到如下内核提示信息： 该提示出现在系统启动过程中或 TTY 登录前，看起来像是一个错误信息，容易让人误以为系统存在异常或潜在故障。本文记录该提示的含义、产生原因以及是否需要处理，供后续排查和参考。 提示信息解析 该信息来自 Linux 内核，逐词解释如下： 需要强调的是： 这是一条 warning（提示），不是 error（错误）。 出现该提示的常见原因 结合实际使用场景，出现该提示通常与以下情况有关： 1. 使用或安装过容器相关组件 例如： 这些组件在启动或初始化时会尝试使用 overlayfs，部分情况下会探测 idmapped 功能，从而触发内核提示。 2. 系统或服务发生过异常重启 例如： 在重新初始化 overlayfs 时，内核会输出该提示。 是否严重？是否需要处理？ 结论明确： 不严重，不需要处理。 具体影响如下表所示： 项目 影响 系统登录 无影响 系统稳定性 无影响 Docker/容器运行 正常 数据安全 不受影响 性能 无明显影响 …
背景 在对 Rocket.Chat 从 7.9 升级至 7.10.x 的过程中，修改了 docker-compose.yml 中 Rocket.Chat 镜像版本号，随后执行： 结果出现拉取失败，错误信息指向 MongoDB 镜像，而非 Rocket.Chat 本身。 错误现象 执行 docker compose pull 时出现如下关键报错： 同时，Rocket.Chat 镜像拉取被中断： 初步排查结论 因此问题并非配置写错或版本不兼容。 根本原因分析 问题的根源在于 Bitnami MongoDB 镜像的 tag 已在远端 registry 中不存在： Docker 在执行 docker compose pull 时，会对 compose 文件中所有服务镜像执行拉取操作： 一旦 registry 中不存在该 tag，就会直接报错并中断整个 pull 流程。 …
背景说明 在一次 Linux 虚拟机运行过程中，由于操作需要，对虚拟机执行了强制关机（相当于物理断电）。随后再次启动虚拟机时，系统在引导阶段进入了 ext4 文件系统自动检查（fsck），并在控制台输出大量类似以下信息： 同时，系统在该阶段停留时间较长，给人以“卡住”的直观感觉。 现象描述 引导过程中，fsck.ext4 输出了大量 orphaned inode（孤儿 inode） 清理信息，持续时间明显长于平时正常启动。 但在日志中可以观察到： 原因分析 1. 强制关机导致文件系统处于未一致状态 ext4 是日志文件系统，但在以下情况下仍会留下不完整状态： 虚拟机被强制关机时，这些操作会被中断。 2. orphaned inode 的来源 orphaned inode 是指： 在包含 Web 服务、数据库、同步程序（如文件同步系统）等场景下，这类 inode 数量可能较多。 3. fsck 运行缓慢的技术原因 fsck.ext4 运行缓慢并不意味着异常，主要原因包括： fsck 在修复过程中几乎不会提供进度指示，因此容易被误认为“卡死”。 预计耗时范围 在类似环境下，fsck 的常见耗时如下： 场景 耗时范围 数据量较小 5–15 分钟 普通服务器虚拟机 10–30 …