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

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

按照关键字 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点了，后面我发了个错误截图，也就是上面图片的后面的一部分

实际还有个 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的参数

$ 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字节了

# 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字节了，同样替换，最终起来了