昨天一台 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 的参数
1 | $ systemctl cat kmod-static-nodes |
在 emergency mode 的 shell 里看了下这个 service 的内容是一样的，启动命令的部分未修改过，cat -A 也没有不可见字符，而 run 目录是运行产生的，还报错Exec fmt err，是不是 /bin/kmod 有问题?
ldd 看了下居然说不是动态的， ls -l 看了下果然不正常，居然变成0字节了
1 | # ls -l /bin/kmod |
修复的尝试中已经叫同事下发一台同样操作系统的ubuntu了，然后给正常ubuntu添加了一个硬盘格式化文件系统，把kmod拷贝进去，然后把该盘卸载了，挂载到故障机器上。由于emergency mode是只读挂载根分区的，所以我用centos 进rescue mode进去拷贝的。拷贝完还发现udevadm同样错误，看了下也是0字节了，同样替换，最终起来了
