You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

如何排查reboot命令引发的Linux内核panic及kernel_restart未执行问题

Linux重启失败:BusyBox已执行halt_reboot_pwoff但内核kernel_restart未触发的排查方案

问题场景

执行reboot命令重启Linux系统时,从日志确认BusyBox已跑完static void halt_reboot_pwoff(int sig)函数,但内核的kernel_restart()并未执行,且触发内核空指针错误。相关日志如下:

# reboot
# Stopping network: OK
Saving random seed: OK
Stopping klogd: OK
Stopping syslogd: OK
umount: devtmpfs busy - remounted read-only
[ 1321.807085] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
[ 1323.827308] Unable to handle kernel NULL pointer dereference at virtual address 00000250
[ 1323.835746] pgd = 52a87f0e
[ 1323.838390] [00000250] *pgd=00000000
[ 1323.842067] Internal error: Oops: 5 [#1] PREEMPT ARM
[ 1323.846953] Modules linked in:
[ 1323.849995] CPU: 0 PID: 138 Comm: init Not tainted 4.14.139.1 #5

核心疑问:BusyBox调用sys_reboot()的流程里有没有故障点?要排查哪些环节?


一、BusyBox调用sys_reboot()流程的潜在故障点

从日志里的Requesting system reboot来看,BusyBox已经走到调用sys_reboot()系统调用的前置步骤,但内核触发空指针错误直接打断了流程,导致kernel_restart()没被执行。可能的故障点包括:

  • BusyBox传给sys_reboot()的参数不合法(比如魔术值、重启命令不符合内核要求)
  • sys_reboot()系统调用被第三方模块hook篡改
  • 重启前的系统环境异常(比如关键文件系统没卸载干净,内核处理重启时访问已释放的资源)

二、具体排查环节

1. 验证BusyBox的reboot参数正确性

  • 查BusyBox源码里halt_reboot_pwoff函数调用sys_reboot()的参数,确认LINUX_REBOOT_MAGIC1、LINUX_REBOOT_MAGIC2魔术值和LINUX_REBOOT_CMD_RESTART重启命令是否正确
  • 写个简单的C程序手动调用sys_reboot(),传入标准参数测试重启,看能不能正常触发kernel_restart()

2. 深挖内核Oops日志

  • 收集完整的Oops日志(当前日志缺栈回溯信息),定位空指针错误的内核代码位置
  • 解析错误地址00000250对应的内核符号,判断是哪个函数访问了空指针——比如是不是某个驱动的shutdown回调出错,或者内核重启代码本身有bug
  • 结合内核版本4.14.139.1,查对应版本的sys_reboot()和kernel_restart()相关代码,排查是否有已知bug

3. 检查系统卸载状态

  • 日志里umount: devtmpfs busy - remounted read-only说明devtmpfs没正常卸载,大概率有进程还在占用设备文件
  • 重启前手动跑lsof /dev看占用devtmpfs的进程,确认是否有进程没被SIGKILL终止
  • 检查UBIFS状态:虽然后台线程已停止,但可能还有挂载点没卸载干净,导致内核重启时访问相关资源出错

4. 排查内核模块影响

  • 虽然日志显示Modules linked in:为空,但不排除有模块没正确列出,或者模块的shutdown/exit回调在重启时触发错误
  • 尝试进入单用户模式(不加载额外模块)重启,看能不能正常执行,判断是否是模块导致的问题

5. 验证内核重启路径

  • 在内核里加调试打印,跟踪sys_reboot()到kernel_restart()的流程,看在哪一步触发了错误
  • 检查内核配置:确认CONFIG_REBOOT等重启相关配置是否正确开启

内容的提问来源于stack exchange,提问作者andy

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.07.02 17:57:13