本文作者 / 飞哥
专注于OpenStack计算、Python
热爱大海、雪山
导 言
UEFI正在逐渐取代传统的BIOS,在使用UEFI启动系统的过程中,有时会遇到系统无法启动的问题。如,制作好的centos虚拟机镜像与iso分离后竟无法启动?突然掉电导致引导文件丢失?怎样才能修复这些问题使得虚拟机能够正常工作?本篇描述了在openstack环境下一次引导文件丢失问题的修复过程。
一、问题描述
在一个openstack环境中,对几台虚拟机进行了resize操作,将内存有32G调整到了48G,磁盘和cpu均保持不动。其中有2个虚拟机出现了resize完成后无法启动的情况,通过虚拟机console界面可以看到虚拟机报如下错误信息:
从前面的输出可以看出,这是一个关于UEFI的问题,无法加载EFIneokylingrubaa64.efi。
二、UEFI是什么
UEFI(Unified Extensible Firmware Interface, 统一的可扩展固件接口)是一种用来替代 BIOS 的标准,它一开始叫 EFI,后来统一之后改叫 UEFI。对于硬盘启动而言,UEFI 的作用之一是读取硬盘上的引导信息,然后加载。
UEFI固件会遍历磁盘上的每个EFI系统分区(按照磁盘上的分区顺序),固件将查找位于特定位置的具有特定名称的文件,即EFIBOOTBOOT{计算机类型简称}.EFI。
对于x86_64平台来说,计算机类型简称为x64,所以这个默认的特定文件是EFIBOOTBOOTx64.EFI;对于aarch64平台来说,计算机类型简称为AA64,所以这个默认的特定文件是EFIBOOTBOOTAA64.EFI。
在安装CentOS操作系统的时候,系统会要求必须创建一个/boot/efi分区,否则系统无法引导启动,这个分区就是前面提及的EFI系统分区,这个分区里面存放了UEFI启动所需要的文件。下面通过一个具体的虚拟机来看下这个分区下的文件:
三、问题分析
现在再来看一下刚开始提到的系统启动失败的问题,从打印信息可知shim调用StartImage()发生了异常,原因是找不到EFIneokylingrubaa64.efi文件。
首先进入正常的虚拟机,查看文件EFIneokylingrubaa64.efi是否存在,文件的具体路径从前面可以知道是/boot/efi/EFI/neokylin/grubaa64.efi:
从上面的输出可以看到,正常虚拟机是有grubaa64.efi这个文件的。那么对于存在问题的虚拟机,猜测可能是该文件丢失导致的无法启动。
由于目前虚拟机已经无法正常启动,我们可以将虚拟机的磁盘挂载到正常的操作系统上来进行修复。这里我们将虚拟机的系统盘挂载到宿主机的目录下,进行查看和修改。要挂载虚拟机的磁盘文件到宿主机的文件系统中,需要使用到libguestfs-tools,安装方法如下:
代码语言:javascript复制[root@compute ~]# yum install -y libguestfs-tools
接下来使用guestmount命令将虚拟机的系统盘挂载到/mnt目录下:
从命令输出可以看到,当前这个有问题的虚拟机确实丢失了grubaa64.efi文件。
四、问题解决
知道具体的原因后,问题解决就变得很容易了,只需要从正常的虚拟机中将grubaa64.efi文件拷贝出来,并放到/mnt/boot/efi/EFI/neokylin目录下就可以完成虚拟机的修复。
执行完上面的操作后,虚拟机就可以正常启动了。
参考资料:
1、https://blog.woodelf.org/2014/05/28/uefi-boot-how-it-works.html
2、http://bbs.wuyou.net/forum.php?mod=viewthread&tid=303679
3、http://jcf94.com/2017/08/06/2017-08-06-efi/
4、https://access.redhat.com/documentation/zh-tw/red_hat_enterprise_linux/6/html/installation_guide/s2-grub-whatis-booting-uefi
5、http://blog.itpub.net/20747382/viewspace-2153053/
猜你还想看这些内容
●Harbor企业级实践丨20倍性能提升so easy!
●Harbor企业级实践丨零侵入改造!
●Kustomize上篇丨Helm 和 Kustomize:不只是含谷量的区别
●Kustomize下篇丨Kustomize 中的增删改查
· END ·
记得文末点个好看鸭~
点就完事儿了!