一、问题背景 在部署 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 …
背景说明 在 Proxmox VE（PVE）环境中，对虚拟机执行某些操作（如带内存的快照、暂停或状态保存）时，系统会输出一段看起来较长的日志。本文对一次完整的日志输出进行拆解说明，明确其含义、触发条件以及是否属于异常行为。 一、日志原文（已脱敏） 说明： 二、日志整体结论 该日志并非报错，而是一次“包含内存的虚拟机快照”或“虚拟机状态保存”的正常过程输出。 日志清晰地展示了以下两个阶段： 三、日志逐段解析 1️⃣ 创建虚拟机状态文件 含义： 该文件并非虚拟磁盘，而是“内存快照容器”。 2️⃣ 保存内存与运行状态 说明： 3️⃣ 内存写入进度输出 这是内存写入过程的实时进度信息： 关于“保存内存小于分配内存”的说明 在该环境中： 这是完全正常的行为，原因包括： 该结果表明虚拟机内存处于正常、稳定使用状态。 4️⃣ 日志输出频率降低说明 该提示仅表示： 5️⃣ 内存保存完成，开始磁盘快照 该行表明： 这一步明确说明：此次快照为“包含内存的快照（snapshot with RAM）” 四、该日志通常由哪些操作触发？ 常见触发场景包括： 如果仅执行普通磁盘快照，不会出现内存保存相关日志。 五、是否属于异常？是否需要处理？ ✔️ 正常情况 ➡ 无需任何处理 ⚠️ 需要注意的点（非故障） 六、运维建议（通用） 七、总结 本文所示日志为 Proxmox VE 在执行“虚拟机带内存快照”或“状态保存”时的标准输出。整个过程完整、连续、无异常，属于正常系统行为，不应被误判为错误或性能问题。
在自建服务体系中，电子邮件服务器是最基础、也最容易踩坑的一类服务。要求往往非常苛刻： 经过方案调研与实际部署，最终选择了 Mailcow（Dockerized），并已经稳定运行超过半年。 这篇文章对这段使用经历做一次阶段性技术复盘。 可选方案简要回顾 在选择 Mailcow 之前，常见的自建邮件方案主要包括： 如果仅从功能完整度出发，这些方案的差异非常明显。 内存需求排序（从低到高） 从实际运行经验和社区共识来看，内存需求大致如下： 结论很直接：Mailcow 不是最轻量，但是功能最完整的方案。 为什么最终选择 Mailcow Mailcow 的定位非常明确： 完整邮件系统，而不仅仅是“能收发邮件” 其优势主要体现在： 本质上，它更接近 “企业邮件系统的自建实现”。 半年稳定运行意味着什么 连续运行半年，且未出现结构性问题，本身已经说明： 这也是 Mailcow 相比轻量方案的重要优势：不是实验性质，而是长期可运行的基础设施。 半年节点的关键检查项 在运行半年后，有必要对以下几个关键点进行一次确认，而不是盲目“继续堆功能”。 1. DKIM / SPF / DMARC 状态 这直接决定邮件是否进垃圾箱。至少需要确认： 2. Rspamd 是否真正参与了“学习” 如果半年内： 那么反垃圾系统只是“存在”，而不是“被使用”。 3. ClamAV 是否仍然值得开启 现实结论往往是： 在这种情况下，ClamAV 的收益往往低于其内存成本。关闭后可显著降低整体内存占用，而不影响核心邮件功能。 4. 备份是否“可恢复” 关键问题只有一个： …
摘要 在长期运行的 Ubuntu 服务器上，历史遗留的 32 位（i386）架构往往来自早期软件需求，例如 SteamCMD。这类依赖在功能退役后若不清理，会增加系统复杂度、降低可预测性。本文记录了一次完整、可控的 i386 架构移除过程，并最终将异构需求交由 Docker 处理，使宿主系统回归纯 amd64 状态。 一、问题背景 在一台 Ubuntu 22.04 服务器上，通过以下命令确认系统启用了 i386 架构： 输出显示： 进一步检查已安装的 32 位软件包： 结果发现系统中存在大量 libc6:i386、libssl3:i386、zlib1g:i386 等基础库，但唯一的应用级包来源是 SteamCMD（32 位）。 随着使用策略调整，决定不再在宿主机直接运行 SteamCMD，而改用 Docker 容器 承担此类需求，于是启动了 i386 架构的彻底清理。 二、初步尝试与关键误区 在移除 SteamCMD 后，直接尝试移除架构： 结果失败： 原因很明确：只要系统中仍存在任何 :i386 包，dpkg 就不会允许移除该架构。 三、apt 通配符陷阱 尝试使用 apt 通配符清理： …