OnApp XEN平台Recovery模式修复Linux系统无法启动问题[转]

转一个网友遇到的问题,留着以后备用:

今天Kaijia遇到了一件郁闷事。Kaijia登录一台由OnApp驱动的Ubuntu VPS时发现系统里有些早前的内核可以删除,于是Kaijia用dpkg列出了所有旧内核,全部删除了并且执行了update-grub更新GRUB引导的menu.lstupdate-grub没有提示错误,更新完成之后重启服务器,结果Kaijia等了很长时间都无法连接SSH,登录到管理界面一看才发现是VPS无法成功启动了。

于是Kaijia尝试使用OnApp提供的Console,但是当VPS关闭时Console是不可用的。重复几次尝试启动系统失败后,Kaijia确认是由于内核无法载入导致GRUB失败,因此此时只能使用OnApp提供的Recovery Console尝试修复系统。搜索了一些资料后Kaijia找到了OnApp官方提供的使用文档,按照文章的提示成功修复了系统。

通过管理面板启动OnApp恢复模式

通过管理面板启动ONAPP恢复模式

首先要在管理界面中点击运行Recovery模式,网页会弹出提示说恢复模式的用户名是root,密码是recovery,然后可以通过OnApp提供Console或者SSH连接恢复模式(SSH的端口是默认的22)。登录后显示的响应是:

1
[root@onapp] #

显然这不是Kaijia服务器的文件系统,因此需要挂载原来的文件系统,首先运行

1
fdisk -l

查看所有的分区(可能会提示分区有错误但是不会影响操作),找到文件系统所在的分区(OnApp系统包含备份等盘,分区很多,可以根据分区的大小来判断)。例如Kaijia制定的分区是一个8G的盘,系统会将这个盘显示为/dev/sdb1

Disk /dev/sdb1: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdb1 doesn’t contain a valid partition table

然后使用mount命令挂载对应的分区到/mnt

1
mount /dev/xxxx /mnt

挂载分区后切换到/mnt文件夹就可以看到原系统的根目录了。然后Kaijia查看了最有可能造成系统无法启动的/boot/grub/menu.lst文件,结果在此文件的最上方发现了问题:

title Ubuntu 12.04.3 LTS, kernel 3.2.0-23-generic-pae
root (hd0,0)
kernel /boot/vmlinuz-3.2.0-23-generic-pae ro console=tty0 root=/dev/xvda1
initrd /boot/initrd.img-3.2.0-23-generic-pae

可以肯定此行是原始XEN模板中留下来的,而update-grub只会删除menu.lst底部的列表,不会删除顶部的内容,于是当GRUB启动时找不到刚刚被删除的linux-3.2.0-23-generic-pae导致了启动失败。

原因找到之后只需要删除这四行并且使用:

1
halt

关闭Recovery模式并且在控制板中重新启动系统就可以正常运行了。

Add a Comment

邮箱地址不会被公开。 必填项已用*标注