一、问题背景与目标 在一个多网卡环境的树莓派系统中，存在如下网络接口： 接口 类型 说明 lo 回环接口 系统内部通信 eth0 板载有线网卡 常态不插网线 enxUSB0 USB 以太网适配器 期望作为主要联网方式 wlan0 无线网卡 偶尔手动连接 系统出现的主要现象： 目标状态： 系统重启后，只要： 系统就应该： 同时需要实现多网卡路由优先级策略： wlan0（手动连接时优先）↓USB 以太网 enxUSB0↓eth0 二、确认接口状态与问题复现 首先查看系统识别到的网络接口： ip a 当时观察到： eth0 已获取 IPv4（192.168.x.x）enxUSB0 DOWNwlan0 未连接 进一步只查看 USB 网卡： ip link show enxUSB0 三、区分链路问题还是 DHCP 问题 在网络排查中，第一步必须判断物理链路是否建立。 使用 ethtool 检查链路状态： …
一、背景 在日常使用 SD 卡的过程中，常会遇到这样几种情况： 这次的目标很明确：将两张不同容量的 SD 卡都整理为统一格式，即： 二、第一张 SD 卡的初始状态检查 首先查看第一张卡的分区信息。结果显示： 从表面上看，这张卡的结构并没有明显错误，属于“已经是单分区 FAT32”的状态。但仅凭分区表信息，还不能确认文件系统内部是否完全正常，因此继续做文件系统检查。 三、第一次文件系统检查发现的问题 对 FAT32 分区执行只读检查后，发现两处轻微异常： 这类问题通常不属于严重损坏，也不意味着卡本身有物理故障。更常见的原因是： 也就是说，这时的问题主要在文件系统元数据层，不是分区层，也暂时看不出是假卡或坏卡。 四、修复第一张卡的文件系统 随后对该分区执行自动修复。修复动作主要包括： 修复完成后再次执行只读检查，没有再出现报错，说明这张卡的 FAT32 文件系统已经恢复正常。 到这里可以得出一个中间结论： 第一张卡在分区结构上本来就是正常的，只是文件系统存在轻微元数据异常；修复后已经恢复到可正常使用的状态。 五、对第一张卡进行彻底重新格式化 虽然文件系统已经修好，但为了让状态更加统一、更加干净，后续还是决定重新格式化一次。 操作思路如下： 最终结果如下： 这样一来，第一张卡就从“可用但有轻微元数据问题”，变成了“结构标准、状态干净、检查通过”的整理完成状态。 六、第二张 SD 卡的初始状态 第二张卡容量约 14.8 GiB。最初的分区结构并不是普通存储卡的样子，而是典型的 Linux 镜像刷写后的结构： 这类结构非常常见，尤其是在刷写树莓派、嵌入式系统、各类 Linux 镜像之后。对于普通电脑、相机、文件传输等用途，这种结构并不方便，因此需要恢复成标准单分区 FAT32。 七、第二张卡的清理与重建过程 为了更彻底地清理这张卡，采用了比第一张更强一点的方式： 检查结果表明： 也就是说，第二张卡已经从“系统镜像卡”恢复成了“普通标准存储卡”。 八、最终统一后的状态 经过整理，两张卡最终都被统一为同一种结构： 目标状态 …
在一台树莓派上的 Ubuntu Server 系统中，首次启动后通常会创建一个默认的普通用户。这个用户往往承担“主用户”的角色：拥有独立家目录、默认 shell，并且通常具备较完整的 sudo 与硬件访问权限。 本文围绕一个实际问题展开：在不删除原有用户、不修改原有用户配置的前提下，新建一个新的管理员用户，并使其在实际使用层面与原始主用户基本等价。 一、首次初始化创建的用户，有什么特殊之处 系统首次启动时创建的普通用户，常见特征如下： 这类用户并不是 root，也不是隐藏系统用户，本质上仍然是普通用户。它的“特殊”主要体现在： 也就是说，它更像是“初始化阶段生成的默认管理员型普通用户”。 二、如何确认一个用户的权限画像 可以通过以下命令查看一个已有用户的核心信息： id <user>getent passwd <user>sudo -l -U <user> 这三条命令分别用于查看： 例如，一个典型的初始化用户，通常会显示： 如果出现 NOPASSWD: ALL，说明该用户执行 sudo 时不需要输入密码，属于非常高可用性的管理员账户。 三、UID/GID 到底意味着什么 很多人在创建新用户时，会注意到 UID 和 GID 与原有用户不同，于是担心“是不是权限不一样”。 实际上，UID/GID 更像是系统内部使用的编号，不是用户可见的身份标签，也不是“住址”。 可以这样理解： Linux 底层处理权限时，更看重的是 UID/GID，而不是用户名本身。但在单机日常运维场景下，只要满足以下条件，UID/GID 的具体数值通常不重要： 因此，如果只是想新建一个可正常使用的新管理员用户，并不需要追求 UID/GID 与旧用户相同。 四、两个用户“完全等价”到底指什么 严格来说，两个不同用户不可能在“身份层面”完全相同，因为： 但如果忽略 UID/GID，仅从实际使用功能来看，两者可以做到基本完全等价。判断标准包括： …
一、问题背景 某台树莓派通过 USB 连接了一台便携式网络设备。该设备支持通过 USB 向树莓派暴露一个共享网络接口，但在未插入可用 SIM 卡时，本身并不具备实际的外网接入能力。与此同时，树莓派还通过自身的无线网卡连接家庭无线网络实现上网。 因此，系统中出现了这样一种结构： 这类结构的关键问题在于：系统如何识别这些网络接口，它们何时会变成 UP，何时会保持 DOWN，以及后续是否可以把 USB 连接作为备用链路使用。 二、当前网络接口状态的含义 通过 ip a 查看系统网络接口时，可以看到几类典型状态： 1. 回环接口 回环接口用于本机内部通信，通常始终处于可用状态。 2. 有线网口 物理有线网口即使被系统启用，只要没有插入网线，也会出现如下特征： 这说明：网口本身存在，但底层链路没有建立。 3. 无线网卡 当无线网卡已经成功连接到无线接入点并获得地址后，通常会看到： 这说明： 4. USB 暴露出的虚拟网卡 便携式网络设备通过 USB 共享网络时，Linux 会将其识别为一个额外网卡，通常接口名类似于 enx…。在未形成有效共享链路时，可能会看到： 这表示： 三、为什么 USB 接口当前是 DOWN USB 暴露出的网络接口之所以存在，是因为系统已经识别到该设备支持网络共享模式。但接口是否真正可用，不取决于“是否插着 USB 线”这一点，而取决于更完整的条件链。 典型条件包括： 如果上述条件不完整，即使接口名已经出现，该接口仍可能保持 DOWN。 …
一、需求背景 在一台运行 Ubuntu Server 的树莓派上，已经存在稳定可用的有线网络连接。与此同时，还希望接入无线网络，以满足以下需求： 这一需求本质上不是“桌面式自动联网”，而是“服务器式可控联网”。 二、系统现状判断 首先需要确认系统中可用的网络工具，以及当前的网络管理方式。检查结果显示： 这说明该环境属于典型的 Ubuntu Server 风格： 因此，后续方案不采用 NetworkManager，不依赖图形界面，而是基于以下工具链完成： 三、总体策略 本次实践最终形成了如下结构： 1. 有线网络长期保留 有线接口始终保持可用，作为系统的远程管理保底入口。 这样做的意义很大： 2. 无线网络按需启用 无线不作为系统的开机自动连接项，而是在需要时手动触发： 3. 当双接口同时在线时，设为 Wi-Fi 优先 这是通过调整默认路由 metric 实现的： 最终实现的逻辑是： 有线常驻保底，Wi-Fi 按需启用；启用后 Wi-Fi 优先，有线备用。 四、工具安装与基础验证 为了支持命令行下的无线操作，需要安装以下工具： 安装完成后，需要验证几个关键点： 实际验证结果表明： 这说明系统层面已经具备无线接入能力。 五、扫描附近 Wi-Fi 在命令行环境下，第一步是先拉起无线接口，然后扫描附近无线网络。 扫描结果中能够看到多个 SSID，说明： 值得注意的是，扫描结果中个别中文 SSID 可能以转义形式显示。这并不意味着扫描失败，只是终端编码显示方式不同。 六、为什么不直接修改系统主配置 在服务器环境中，最常见的做法之一，是直接将 …
背景 某台 Linux 主机使用 LVM 管理根分区，系统原本可以正常启动。后续为了统一命名规范，对卷组名称进行了重命名。重命名本身成功，LVM 层状态正常，但随后出现了两个典型问题： 这类问题的本质并不在于 LVM 重命名失败，而在于启动链路中的历史引用没有被同步更新。也就是说，LVM 元数据已经变了，但 GRUB、内核命令行、initramfs、fstab 等位置仍然残留旧名字。 本文记录一次完整的排查与修复过程，并总结出一套可复用的方法。 现象 在卷组重命名之后，LVM 状态看起来已经正常，例如： 但是执行以下命令时会出错： update-initramfs -u -k all 报错类似： cryptsetup: ERROR: Couldn’t resolve device /dev/mapper/旧卷组-rootcryptsetup: WARNING: Couldn’t determine root device 继续执行： update-grub 又会报错： /usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/旧卷组-root’. 这说明系统运行态已经基于新逻辑卷工作，但启动配置里仍然有旧名字残留。 问题本质 LVM 的卷组名变更，只会修改 …
在学习 Linux 网络结构时，几乎每个人都会看到一个特殊的网络接口： lo 它通常对应地址： 127.0.0.1localhost 与此同时，在互联网历史中也存在一个非常著名的记录：1969 年互联网（ARPANET）发送的第一条消息是 “LO”。 由于两者在字母上完全相同，很多人会产生一个疑问： Linux 中的 lo 接口，是否与互联网历史上的 “LO” 有关联？ 结论是： 两者没有任何历史或技术上的关系，仅仅是字母上的巧合。 本文对这两个概念进行简单说明。 一、Linux 中的 lo 接口 在 Linux 网络系统中： lo = loopback interface 即 回环网络接口。 回环接口的作用，是让一台计算机能够在 不经过任何物理网络设备 的情况下，与自身进行网络通信。 常见地址： 127.0.0.1 或主机名： localhost 可以使用以下命令测试： ping 127.0.0.1 数据包不会离开计算机，而是在 操作系统内核的网络协议栈内部循环处理。 回环接口的特点 lo 接口具有几个重要特点： 1 永远存在 无论系统是否连接网络，lo …
适用对象：ARM64 设备（如 R2S / 树莓派等）上运行 Ubuntu 24.04（noble），APT 默认指向 ports.ubuntu.com，更新速度慢或链路不稳定。目标：保持“官方仓库内容等价”的前提下，切换到国内镜像加速，并移除不适合生产环境的 -proposed 测试仓库。 1. 背景现象：APT 命中 ports.ubuntu.com 在 ARM64 Ubuntu 上执行 apt update，常见输出类似： 其中 ports.ubuntu.com 是 Ubuntu 官方用于 非 x86 架构（ARM 等） 的主仓库入口。它是“源站”，内容权威，但在亚洲链路上经常出现吞吐偏低的问题。 2. 关键点：ARM 的“国内镜像”必须是 ubuntu-ports 镜像 很多人换源失败，是因为误用只同步 x86 的镜像路径（如普通 ubuntu/），而 ARM 设备应使用 ubuntu-ports。 镜像等价关系如下： 3. 配置现状确认：使用传统 sources.list（而非 ubuntu.sources） Ubuntu 24.04 …
目标：在一台 ARM 小主机（双网口场景常见，如 R2S 一类）上，完成1）长期累计流量统计（按天/月/年）2）终端实时图形化监控（看瞬时带宽、看谁在跑流量）并解决“vnstat 显示 No data/查不到数据”的典型问题。 1. 为什么需要两类工具：累计统计 vs 实时观察 网络监控分两类，作用不同： 1.1 长期累计（趋势、账单、限额） 选型：vnStat优点：轻量、低开销、重启不丢（数据库在本机保存）。 1.2 实时观察（当前状态、排障、抓异常） 选型：bmon / nload / iftop其中： 2. 基础概念：RX / TX 是什么 所有工具里都绕不开： 在转发型节点（隧道/代理）里，经常出现一个明显特征： RX ≈ TX（接收多少就转发多少） 而在普通客户端（浏览网页、下载）上更常见： RX >>> TX 3. 长期累计：vnStat 的正确用法与常见误解 3.1 vnStat 的工作机制（决定了“能不能看历史”） vnStat 不会回溯系统历史流量。它的机制是： 因此： 这也是很多人第一次用 vnStat 时最容易误解的点：看到 “since …
摘要 本文记录一次远程边缘节点的灾备体系设计过程。 目标环境为长期运行的 ARM 小型网络节点，其物理设备位于异地，日常仅通过 SSH 远程维护。系统运行在 SD 卡上，一旦存储介质损坏，将导致节点完全离线，因此需要构建一种： 的 SD 卡灾备方案。 本文最终采用： 首次整盘克隆（dd） + 后续文件级同步（rsync） + 异地配置备份 的分层灾备结构。 一、问题背景 边缘节点通常具有以下特点： 一旦 SD 卡损坏，将出现： 因此核心问题变为： 是否可以提前制作一张备用 SD 卡，使其在原卡损坏后直接替换启动？ 二、系统结构特点（R2S 与树莓派的差异） 许多 Raspberry Pi 迁移方案基于如下结构： 系统仅依赖单一 root 分区，因此可以通过 rsync 复制后修改 UUID 启动。 但 NanoPi R2S 采用 Rockchip 启动结构： 关键差异： 因此： 仅复制文件 …