[Linux] VMware虚拟机开机后直接进入memtest

问题描述

今天碰到一个很难受的问题，昨天写报告的时候虚拟机还是正常的，早上开机的时候忽然报错+进不了ubuntu虚拟机直接进入一个memtest的界面，情况大概是这样的：
一开始会报一些“error syntax”“error incorrect command”等错误，紧接着进入了Memtest

问题定位

谷歌搜相应问题
开机的问题先查启动项，谷歌了半天最接近的结果也是因为改了grub文件导致的，按照这篇文章流程，先将虚拟机的CD/DVD改为装虚拟机时候的ISO镜像，然后进BIOS修改启动顺序，将CD-ROM Drive提到Hard Drive之前；

注：虚拟机进BIOS是按F2，如果由于虚拟机启动太快进不了BIOS的话可以参考这篇文章直接从设置进入或者改一下.vmx文件；
进入临时ubuntu系统
此时我们虽然没有恢复先前的虚拟机系统，但是Other Location里可以看到先前的文件环境了，大家可以在这里定位一下自己的问题发生在哪里；

我的问题是发生在/boot/grub里面，发现grub.cfg文件变成了乱码，网上有看到可能是虚拟机关闭时没有完成而宿主机直接断电引起的（我昨天有关得这么急吗？）

如何解决

定位到大概是grub损坏的问题，我有尝试在临时环境里直接利用boot-repair修复grub，但是boot-repair给出的命令我一直报错，没有成功

dpkg error parsing file '/var/lib/dpkg/status' near line 0: empty field name

然后我脑洞大开用了一种很离奇的方法
我的方法：
①利用ubuntu ISO镜像重新构建一个虚拟机，然后将新虚拟环境的/boot/grub文件复制到原始的虚拟磁盘中（这个新虚拟机可以在VMware 虚拟机的硬盘环境里设置挂在之前的虚拟磁盘）；

②复制之后重新启动原系统会报grub错误，内容大概为：

此处可以分为两个问题，即系统找不到名为“17428bf…”这么一长串的硬盘设备+需要的启动文件“/boot/vmlinuz…”找不到；因为这两个都对应着我们新建的系统中的内容；
③针对②中第一个问题，在之前boot-repair时我就注意到，boot-repair最终使用的就是用一个命令修复一个名字为一长串的磁盘里的grub项；我们重新进入临时系统，在/media中挂载就是我们需要找的磁盘名，把他复制过来替换掉grub.cfg中所有的“17428bf…”，第一个问题即解决了；
④针对②中第二个问题，参照这两篇文章[1，2]即可重新建立联系，重新进入系统之后不要忘记sudo update-grub，不然下次开机还得重新来一遍！

总结

至此解决了我碰到的VMware虚拟机开机报错+直接进入memtest的问题，出现该问题很有可能是因为grub出了问题，寻找修复grub相关的方法即可