File system read only告警

交流互助区
2

答案内容由AI生成，仅供参考：

结论总结

项目 结论
告警触发原理 当系统检测到根文件系统（如 /dev/mapper/openeuler-root）以只读方式挂载时，由事件系统（events.lua）触发 System.SystemFSReadonly 告警。检测机制可能依赖 GetMountStatus 获取挂载选项。
是否与权限有关 不是传统的文件权限（chmod），而是 文件系统的挂载属性（mount options）。出于安全考虑，OpenUBMC 将 rootfs 设计为默认只读挂载以防止运行时篡改。
根本原因 根文件系统 rootfs 被以只读模式挂载（read-only mount），阻止写入操作。
解决思路 - 使用 /data 分区存储可变数据
- 创建软链接代替直接写代码区
- 通过启动脚本预置文件
- （仅调试）手动 mount -o remount,rw /
点击此处查看详细分析解答

关于 System.SystemFSReadonly 告警触发原理及文件权限要求的分析

问题描述

系统中精细化告警 System.SystemFSReadonly 频繁触发，日志显示文件系统 /dev/mapper/openeuler-root 处于只读状态（read-only），并伴随多次状态切换。用户希望了解此告警的触发机制以及系统是否对相关文件或文件系统权限有特殊要求。

相关告警日志示例如下：

2026-04-08 03:00:12 | Major | 0x2C000071 | File system (/dev/mapper/openeuler-root) is read only.
...
event NOTICE: events.lua(110): System major count change 0 to 1 by [System_System.SystemFSReadonly_[“/dev/mapper/openeuler-root”]___]

告警触发原理分析

1. 根本原因：根文件系统进入 Read-Only 模式

根据知识库中的信息，系统出现 “Read-Only System” 的根本原因为：

根文件系统（rootfs）被挂载为只读（read-only mount），从而阻止所有写入操作，导致组件无法修改文件。

这一现象与实体 read-only mount 和 rootfs 之间的关系完全吻合：

  • read-only mount 明确定义为：rootfs 变为只读，阻止写入和系统正常运行。
  • rootfs 是 Linux 嵌入式系统的基础文件系统，包含 BMC 运行所需的全部配置文件和可执行程序。

当系统因硬件异常、文件系统损坏、内核错误或安全策略激活等原因检测到潜在风险时，内核会自动将根文件系统从读写模式（rw）重新挂载为只读模式（ro），以防止数据进一步损坏。

2. 告警检测机制

虽然未直接提及 System.SystemFSReadonly 告警的具体实现，但可以通过以下机制推断其触发逻辑：

（1）文件系统状态监控

通过如 GetMountStatus 方法检测挂载点状态：

  • DstPath 表示目标挂载路径。
  • MountStatus 是一个结构体，包含文件系统名称、挂载点、类型和挂载选项（如 rw 或 ro）。
  • 系统定期调用 GetMountStatus 查询关键分区（如 /, /dev/mapper/openeuler-root）的挂载选项。
  • 一旦发现挂载选项为 ro（只读），即触发 System.SystemFSReadonly 告警。

（2）事件驱动型监控

系统使用事件管理模块（如 events.lua）监听底层状态变化：

  • 日志中频繁出现 System major count change，表明事件系统持续检测到状态波动。
  • 每次从“正常”变为“只读”时，增加 Major 告警计数；恢复后归零。
  • 多次来回切换可能意味着文件系统处于不稳定状态（如间歇性 I/O 故障）。

3. 为何会进入只读模式？

尽管上下文未直接说明 OpenUBMC 中导致只读的具体条件，但结合通用 Linux 系统行为及上下文信息可总结如下：

原因类别 说明
文件系统错误 如 ext4 文件系统检测到一致性错误（如 superblock corruption），内核自动 remount 为只读。
存储设备故障 底层块设备（如 eMMC、SSD）出现 I/O 错误或坏道，导致无法写入。
安全机制触发 为了保护代码区不被篡改，某些版本在启动后自动将 rootfs 设为只读（见文档 chunk 2 中 Gendany 的说明）。
手动操作或脚本干预 调试时执行了 mount -o remount,ro / 导致切换（反之可通过 mount -o remount,rw / 恢复）。

文件/文件系统权限要求分析

1. 是否对文件权限有要求？

不是传统意义上的“权限”问题（如 chmod 644），而是挂载时的读写属性控制。

:white_check_mark: 实际限制来源：

  • 挂载模式（Mount Option）：即使文件本身权限为 666，若整个文件系统以 ro 挂载，则仍不可写。
  • 安全设计策略：有明确说明指出：

    “根分区为代码区，出于安全考虑分区以只读方式挂载，且在正式版本会开启分区对应存储设备的上电写保护，不允许篡改代码区的文件。”

    • 来源：文档 chunk 2 回复者 Gendany

这说明 OpenUBMC 主动设计为只读挂载，旨在防止运行时修改核心系统文件。

:cross_mark: 排除传统权限问题：

  • 用户已尝试使用 root 权限运行组件但仍失败，说明不是用户权限不足。
  • 后续通过 mount -o remount rw / 成功修改文件，证明问题出在挂载属性而非文件权限。

2. 建议的解决方案（规避只读限制）

根据已有知识库内容，推荐通过以下方式实现动态文件修改需求：

:white_check_mark: 方案一：使用 /data 分区作为可写存储区

推荐做法：将需动态修改的文件保存在 /data 分区，并在启动时创建软链接指向原路径。

  • 原因：/data 分区通常格式化为可写文件系统，专用于持久化运行时数据。
  • 实施方法（参考 Larry_Li 给出的建议）：
    # 创建文件并软链接
ln -sf /data/my_config.conf /opt/bmc/my_config.conf

:white_check_mark: 方案二：启动阶段初始化可写文件

参考 account 组件的实现方式：

  • 在 rc.start 脚本中创建文件（如 S08init_user.sh）。
  • CMakeLists.txt 中打包该脚本进入 HPM 包。
  • 配置 permissions.ini 设置正确权限（如 f 550 0 0）。

:white_check_mark: 方案三：运行时 remount 为可读写（临时解决）

mount -o remount,rw /

:warning: 注意：此操作仅限调试环境使用，生产环境不建议轻易执行，以免破坏系统完整性。

结论总结

项目 结论
告警触发原理 当系统检测到根文件系统（如 /dev/mapper/openeuler-root）以只读方式挂载时，由事件系统（events.lua）触发 System.SystemFSReadonly 告警。检测机制可能依赖 GetMountStatus 获取挂载选项。
是否与权限有关 不是传统的文件权限（chmod），而是 文件系统的挂载属性（mount options）。出于安全考虑，OpenUBMC 将 rootfs 设计为默认只读挂载以防止运行时篡改。
根本原因 根文件系统 rootfs 被以只读模式挂载（read-only mount），阻止写入操作。
解决思路 - 使用 /data 分区存储可变数据
- 创建软链接代替直接写代码区
- 通过启动脚本预置文件
- （仅调试）手动 mount -o remount,rw /

附加建议

  1. 检查系统日志：查看 dmesg 或 /var/log/messages 是否有文件系统错误或 I/O 故障记录。
  2. 验证设备健康状态：检查底层块设备（如 SSD、eMMC）的 S.M.A.R.T. 状态。
  3. 确认是否为预期行为：如果是安全策略强制只读，请勿强行 remount，应采用 /data 分区方案。

:pushpin: 参考链接：

如需进一步分析具体设备或日志上下文，建议收集 dmesg 输出及挂载信息（mount | grep root）。