异常排查

Q：aBMC 可以远程访问吗？

A：可以。aBMC 为独立带外管理单元，设备通电且管理网口网络连通时，支持远程访问 Web 管理界面、Redfish/IPMI 接口，可实现远程开关机、KVM 控制台、硬件监控、虚拟介质等运维操作。本地局域网访问：同一内网环境下，电脑与 aBMC 管理网互通，输入 aBMC 内网 IP 即可直接访问；

互联网跨地域访问：无法直接公网暴露端口使用，有两种合规方案：

终端通过 VPN 接入设备本地局域网，再访问 aBMC；
部署云端代理服务器，内网 aBMC 主动向外建立长连接，依托代理实现互联网远程运维。

安全提醒

禁止直接对公网开放 aBMC 服务端口，存在高权限安全风险；跨外网远程运维优先采用 VPN 或云端代理方案。

Q：服务器运行过程中无法访问 aBMC？

A：先区分两种故障场景排查：

场景 1：无法 ping 通 aBMC 管理 IP 优先排查物理链路与二层 / 三层网络：网线、交换机端口状态、IP 网段、VLAN 划分、访问控制策略。
场景 2：可 ping 通 aBMC IP，但无法访问 Web 管理界面
1. 若现场可外接显示器排查显示器正常输出终端 / 系统界面，代表底层操作系统正常运行。可在本机执行访问测试：https://127.0.0.1 1.1 本机能够正常打开 aBMC 页面：aBMC 业务服务运行正常，故障点位于运维终端与设备之间网络，排查方向：网段互通、交换机 ACL 策略、VPN、代理等； 1.2 本机同样无法访问 aBMC 页面：判定 aBMC 服务异常，按以下顺序排查 1.2.1 查看服务运行状态 systemctl status aBMC 1.2.2 服务状态为 active（运行中）：核查业务配置 cat /etc/aBMC/config.ini 1.2.2.1 确认启用访问协议（默认 HTTPS） 1.2.2.2 确认 Web 监听端口是否被修改 1.2.2.3 确认 Redis 通信端口配置 1.2.3 若服务异常、未启动：根据日志排查服务启动失败原因。
2. 若现场无法外接显示器，或显示器黑屏、花屏无输出
```
2.1 使用 Console 调试线（USB 转 RJ45 串口，波特率 115200）接入串口终端登录命令行系统；
2.2 登录成功后，复用上文 1.2 流程排查 aBMC 服务问题。
```
3. 若显示器终端登录、Console 登录均无响应，则大概率为 BMC 程序卡死、系统死机，常见诱因： 3.1 用户业务进程以 root 权限运行引发内核异常 3.1.1 优先查阅系统日志、内核日志定位应用 BUG； 3.1.2 若发生内核崩溃 Oops/panic，日志往往无法落盘留存。建议持续抓取串口日志复现问题，便于开发定位根因。
  
  3.2 BMC 系统分区磁盘占满（客户高频问题）多为用户自行部署业务产生大量调试日志、临时文件未定期清理，磁盘耗尽引发系统功能异常。
  
  3.3 用户修改 /etc/fstab 挂载配置不当阻塞系统启动若在 /etc/fstab 中配置开机自动挂载磁盘时，未添加 nofail 参数，一旦挂载过程出现异常，系统将因等待超时而陷入启动阻塞状态。常见引发此故障的典型场景包括： 3.3.1 资源标识错配：开发调试阶段固化的磁盘UUID与实际生产环境不符，且未在部署前修正。 3.3.2 底层硬件失效：磁盘发生物理性故障，导致内核无法获取设备响应，挂载请求被永久阻塞。 3.3.3 设备命名漂移：依赖设备路径（如 /dev/sda1）的挂载方式，因系统重启后内核枚举顺序变动而失效。 3.3.4 存储介质未预处理：新增磁盘未执行格式化和分区操作，导致系统在挂载时无法识别有效文件系统结构。

Q：如何在 aBMC 上使用 Redis？

A：aBMC 系统默认已内置 Redis 7.2。业务服务如有 Redis 使用需求，可直接使用系统自带实例，无需重新安装部署。如需自定义 Redis 端口、数据库编号、访问密码：

修改配置文件 /etc/aBMC/config.ini 中的 Redis 相关参数；
重启 aBMC 服务，新配置方可生效。

提示

提示：请勿手动独立安装、启动额外 Redis 进程，防止出现端口冲突、资源抢占等系统异常。

Q：如何修改会话登录后的 LOGO？

A：默认情况下，用户通过 SSH、串口等方式登录 aBMC 后，终端会显示系统默认的 LOGO。如需修改会话登录后显示的 LOGO，可编辑以下文件

/etc/update-motd.d/00-header

保存文件后，重新建立会话即可查看修改后的显示效果。

禁止

请勿修改 /etc/profile.d/ 目录下的文件来配置会话登录后的 LOGO。

Q：BMC usb_net 网卡与子板 eth0 网卡是否允许修改或增加 IP 地址？

A：不允许。

是什么

BMC 的 usb_net 网卡（192.168.150.100/24）与子板的 eth0 网卡（192.168.150.xx/24）用于构建 BMC 与子板之间的 SSH 通信链路。

该链路是 aBMC 定义的私有通信链路，用于实现 BMC 与子板之间的内部通信。
为什么不允许修改

aBMC 依赖该链路进行 BMC 与子板之间的通信。增加、修改或删除该链路上网卡的 IP 地址，会导致 BMC 与子板无法正常通信，进而导致子板失联，影响到 aBMC 功能的正常使用。
修改后无法通信怎么办

如果误改了相关网络配置，导致 BMC 与子板无法正常通信，可按照以下方式恢复：
1. BMC
  
  执行以下命令，清除 Netplan 网络配置并重启 BMC：
```
rm -rf /etc/netplan/*
reboot
```
2. 子板
  
  进入 aBMC 固件升级页面，重新执行固件升级操作。
  
  具体操作请参考：固件升级

Q：aBMC Web 页面显示子板断联，如何排查？

A：先通过串口确认子板系统是否仍在运行（子板系统本身异常时，必然无法与 aBMC 建立连接），再根据子板平台与运行状态采取相应处理。

场景 1：串口终端敲击回车键有响应（子板系统仍在运行）

子板系统正常运行时断联，多为连接通道异常，根据子板平台分别处理：
1. Rockchip Linux 平台（Ubuntu、Debian 等）
  
  重启 USB 设备服务：
  
  systemctl restart usbdevice.service
  
  若连续三次重启均失败，执行 df -h 检查磁盘占用情况：若已用 100%，需清理文件释放磁盘空间（建议系统盘保留至少 10% 可用空间），然后重启子板，子板应可恢复连接。
2. Rockchip Android 平台
  
  重启 adbd 服务：
  
  setprop ctl.restart adbd
  
  重启后确认 aBMC 是否恢复连接。若恢复，说明故障为 USB 瞬断 / 重枚举后 adbd 的 functionfs 传输卡死，重启 adbd 服务即可恢复；如需彻底解决，可联系 Firefly 技术支持更新固件。
3. Sophgo 平台
  
  多为网络中断所致，在子板上 ping aBMC 管理 IP 确认连通性：
  
  3.1 若无法 ping 通且网络设置有误，修正网络配置后即可恢复；
  
  3.2 若网络设置无误仍无法 ping 通，执行 df -h 检查磁盘占用情况：磁盘占满也会导致 SSH 服务异常而无法连接，若已用 100%，需清理文件释放磁盘空间（建议系统盘保留至少 10% 可用空间），清理后确认是否恢复；
  
  3.3 若磁盘占用正常仍无法 ping 通，大概率为网卡故障，可重启设备再试；重启后仍未恢复，请联系 Firefly 技术支持。
场景 2：串口终端敲击回车键无响应（子板系统疑似宕机）

保持串口连接状态，重启子板并观察有无日志输出：
1. 有日志输出，且系统可正常操作
  
  查看此时 aBMC 是否已恢复连接：
  
  1.1 若已恢复，说明子板曾因未知原因宕机。建议开启该子板的串口采集，持续跟踪该子板串口日志，待问题再次复现时，将日志提供给 Firefly 技术支持分析。
  
  1.2 若仍未恢复，请联系 Firefly 技术支持处理。
2. 无任何日志输出
  
  请联系 Firefly 技术支持处理。

Q：内核日志出现 `bm-sophon0 api process fail` 或 `Tpu hang`，如何处理？

A：这类日志表示 Sophon TPU（AI 加速单元）的任务处理异常，可能由驱动或固件异常、TPU 长时间高负载、硬件故障等原因引起。建议按以下步骤处理：

记录日志：

dmesg -T | grep -iE "bm-sophon|tpu"
journalctl -k --no-pager | grep -iE "bm-sophon|tpu"

记录出现问题的子板编号以及当时运行的业务，重启对应子板或整机，观察是否复现。
若重启后不再出现，可继续观察；若反复出现，请停止该子板上的 TPU 业务，收集上述日志并联系技术人员处理。

注意

出现 Tpu hang 后不要继续长时间高负载运行，避免异常扩大；也不要自行刷新固件，先联系技术人员确认原因。

Q：BMC 上电后 `pci_net` 网卡消失，如何排查？

A：BMC 上电后如果系统中看不到 pci_net 网卡，先按以下步骤确认：

确认网卡是否真的缺失：

ip link show
ls /sys/class/net
lspci -nn | grep -i net

使用 lsblk 检查 /boot 分区是否已挂载：
```
lsblk
findmnt /boot
```
如果 /boot 分区未挂载，可能是系统启动或分区异常。不要手动格式化分区，也不要随意修改 /etc/fstab，请联系技术人员处理。
如果 /boot 已正常挂载但 pci_net 仍然不存在，请收集以下信息后联系技术人员：
```
dmesg -T | grep -iE "pci|net"
lspci -nn
```

注意

请勿通过重命名网卡或自行新建网络配置文件的方式尝试"恢复" pci_net，以免影响 BMC 与子板之间的通信。

Q：内核日志出现 `mmc0` 报错，如何判断 eMMC 是否健康？

A：mmc0 通常对应板载 eMMC。出现 mmc0 相关报错时，先确认报错内容，再读取 eMMC 的寿命信息：

查看内核报错：

dmesg -T | grep -i mmc
journalctl -k --no-pager | grep -i mmc

读取 eMMC 寿命：

cat /sys/block/mmcblk0/device/life_time
cat /sys/block/mmcblk0/device/pre_eol_info

结果解读：
- life_time 是两个十六进制值，依次为 Type A、Type B（主存储区通常参考 Type B）：0x01 表示已使用 0–10%，0x02 表示 10–20%，依次类推，0x0A 表示 90–100%，0x0B 表示已超出寿命；
- pre_eol_info：0x01 表示正常，0x02 表示预警（已使用约 80%），0x03 表示紧急（已使用约 90%）。
如果 pre_eol_info 为 0x01 且 life_time 数值较小，说明 eMMC 寿命正常，可按普通 I/O 报错继续排查；如果出现 0x02、0x03、0x0B，或内核持续报 I/O 错误，请先备份数据，再联系技术人员处理。

提示

eMMC 只能读到寿命分档，无法给出精确百分比。若设备长期大量写日志，建议将日志外置或定期清理，减少 eMMC 写入。

Q：SATA 硬盘变成只读，如何处理？

A：SATA 硬盘出现只读，通常是硬盘自身进入故障保护，或文件系统、链路异常。建议按以下步骤确认：

使用 lsblk 确认出现问题的盘符（以下以 /dev/sdX 表示）。

确认只读状态：

mount | grep " ro,"
cat /sys/block/sdX/ro

查看内核报错和硬盘健康信息：

dmesg -T | grep -iE "ata|sata|I/O error|read-only"
smartctl -a /dev/sdX   # 若系统已安装 smartctl

如果使用的是机械硬盘，建议更换为固态硬盘（SSD）。机械硬盘在老化、震动或供电异常时更容易进入只读保护，继续使用可能导致数据丢失。
更换硬盘前请先备份数据；如果更换 SSD 后仍出现只读，请收集上述日志并联系技术人员。

注意

不要通过强制重新挂载为读写（mount -o remount,rw）继续写入故障盘，可能造成数据损坏。请先备份数据再处理。

本页目录