zhangguanzhang's Blog

记录一次request_module: runaway loop modeprobe binfmt-0000

字数统计: 982阅读时长: 3 min
2020/03/02

昨天一台 gpu 的主机的阵列卡突然坏了,最终整起来后上面的几台虚机恢复后有一台虚机无法正常开机,开机进 emergency mode,同事看上面的报错以为是挂载了啥 iscsi,当然无法开机应该找到最开始的错误,进到 emergency mode 这个视角的时候已经是雪崩的最后的错误了,多半是没有意义的。输入 root 密码后执行journalctl -xb翻看最开始的错误

binfmt-1

按照关键字request_module: runaway loop modeprobe binfmt-0000搜到的都是裁剪内核出现的binfmt-484c啥的或者2.6内核的出错,尝试了换内核和挂载iso进rescue mode把同样系统正常ubuntu的boot拷贝过来配置grub还是不行,也搜了下/lib里内核模块,确实有binfmt的内核模块。

找了存储运维的同时把故障之前的快照挂载了,发现还是同样的错误。这个时候就明白了这个机器是之前就有错误,只不过没重启没被发现而已,和本次故障无关。最后拉了个内核研发过来看,希望能去看看内核源码这个错误的相关代码附近找找,看看能不能定位到故障范围。

当时是一起拉了个微信语音聊天,因为gpu的主机是华三的,也拉了华三的人,一般进入emergency mode多半是fstab里配置的盘无法挂载导致的,开机过程中显示boot分区的盘迟迟挂载不了。华三他们就把/boot的挂载注释了,然后居然进去了。当然我上去仔细看了下实际进来的系统和emergency mode一样,只不过少了个输入root密码的提示而已。

每次发生故障的时候最害怕的就是信息不一致,每个人或多或少的能肯定不是A方面的原因,建议往B方向一起排查。但是每次故障发生的时候各个领域的同事不是同一时间来的,排查的方向就重复了。
最后都找不出来啥范围的故障,我说先从最开始的那个红字错误排查吧。实际接手的时候是晚上七八点,拉了华三的人看完了是晚上接近0点了,后面我发了个错误截图,也就是上面图片的后面的一部分

binfmt-2

实际还有个kmod-static-nodes.service: Main process exited, code=exited, status=203/EXEC的字段在后面,就不发图片了

内核研发搜了下 203 的退出码是不存在,叫我关注下相关的服务,我思考了下 kmod-static-nodes 退出和上面的Failed to step EXEC spawning /bin/kmod Exec fmt err

找了个同样的 ubuntu16.04 系统对比了下 exec 的参数

1
2
3
4
$ systemctl cat kmod-static-nodes
# /lib/systemd/system/kmod-static-nodes.service
...
ExecStart=/bin/kmod static-nodes --format=tmpfiles --out-put=/run/tmpfiles.d/kmod.conf

在 emergency mode 的 shell 里看了下这个 service 的内容是一样的,启动命令的部分未修改过,cat -A 也没有不可见字符,而 run 目录是运行产生的,还报错Exec fmt err,是不是 /bin/kmod 有问题?
ldd 看了下居然说不是动态的, ls -l 看了下果然不正常,居然变成0字节了

1
2
# ls -l  /bin/kmod
-rwxr-xr-x 1 root root 0 Dec 27 18:13 /bin/kmod

修复的尝试中已经叫同事下发一台同样操作系统的ubuntu了,然后给正常ubuntu添加了一个硬盘格式化文件系统,把kmod拷贝进去,然后把该盘卸载了,挂载到故障机器上。由于emergency mode是只读挂载根分区的,所以我用centos 进rescue mode进去拷贝的。拷贝完还发现udevadm同样错误,看了下也是0字节了,同样替换,最终起来了

binfmt-3

CATALOG