Wondering why onapp custom CloudLinux template not booting? We can help you to fix this!

As part of our Server Virtualization Technologies and Services, we assist our customers with several OnApp queries.

Today, let see how our Support Engineers help our customers to fix this booting issue with onapp CloudLinux template.
 

OnApp custom CloudLinux template not booting

 
We will recieve the following error in the VM’s logs, under a failed StartupVirtualServer:

Running: xm create /onapp/config/vmidentifier
Using config file "/onapp/config/vmidentifier".

Error: Boot loader didn't return any data!

Fatal: Virtual machine has not been started on hypervisor
Executing Rollback...

Because of this error the virtual machine will not start.

To resolve this issue we should check and update the grub.conf accordingly.

Now let’s see how we can fix this booting issue by updating the grub.conf file:

Firstly, we need to check the grub.conf. Generally, it should be changing the grub.conf, but sometimes it may fail to make the correct changes or to change at all.
The grub.conf file will not have a valid kernel for it to boot, so it will be unable to. We can determine this by checking the files on the VM through recovery mode, and then update the grub.conf accordingly.

Normally, in the recovery boot the primary drive of the virtual machine will be /dev/xvdb1.

[root@recovery ~]# mkdir /mnt/xvdb1 && mount /dev/xvdb1 /mnt/xvdb1 && cd /mnt/xvdb1
[root@recovery xvdb1]# cat /mnt/xvdb1/etc/grub.conf
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You do not have a /boot partition. This means that
# all kernel and initrd paths are relative to /, eg.
# root (hd0,0)
# kernel /boot/vmlinuz-version ro root=/dev/sda1
# initrd /boot/initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=30
splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title CloudLinux Server (2.6.32-379.19.1.lve1.2.7.el6.x86_64)
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-379.19.1.lve1.2.7.el6.x86_64 ro root=/dev/xvda1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb nohz=off console=tty0
initrd /boot/initramfs-2.6.32-379.19.1.lve1.2.7.el6.x86_64.img

So, here we have the information of original grub.conf file. Now should check it across the VM’s kernels in /boot.

[root@recovery xvdb1]# ls -lah /mnt/xvdb1/boot/vmlinuz* /mnt/xvdb1/boot/initramfs*
-rw-r--r-- 1 root root 14M Nov 10 2013 /mnt/xvdb1/boot/initramfs-2.6.32-458.18.1.lve1.2.39.el6.x86_64.img
-rw------- 1 root root 14M Dec 22 14:47 /mnt/xvdb1/boot/initramfs-2.6.32-458.23.2.lve1.2.45.el6.x86_64.img
-rw------- 1 root root 14M Jan 14 11:14 /mnt/xvdb1/boot/initramfs-2.6.32-458.23.2.lve1.2.48.el6.x86_64.img
-rwxr-xr-x 1 root root 4.0M Sep 16 2013 /mnt/xvdb1/boot/vmlinuz-2.6.32-458.18.1.lve1.2.39.el6.x86_64
-rwxr-xr-x 1 root root 4.0M Nov 22 13:18 /mnt/xvdb1/boot/vmlinuz-2.6.32-458.23.2.lve1.2.45.el6.x86_64
-rwxr-xr-x 1 root root 4.0M Jan 3 16:39 /mnt/xvdb1/boot/vmlinuz-2.6.32-458.23.2.lve1.2.48.el6.x86_64

We can see that the same images are not there. So we will need to take a backup of the grub.conf file and then change the image name to an existing kernel.

After taking the backup, we can now edit the grub.conf file as we know which kernels exists.

The difference between the two shows the following:

[root@recovery etc]# cp grub.conf grub.backup-05-15-14.conf
[root@recovery etc]# vi grub.conf
--changed to images that are in the boot folder--
[root@recovery etc]# diff grub.conf grub.backup-05-15-14.conf
14c14
< title CloudLinux Server (2.6.32-458.23.2.lve1.2.48.el6.x86_64)
---
> title CloudLinux Server (2.6.32-379.19.1.lve1.2.7.el6.x86_64)
16,17c16,17
< kernel /boot/vmlinuz-2.6.32-458.23.2.lve1.2.48.el6.x86_64 ro root=/dev/xvda1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb nohz=off console=tty0
< initrd /boot/initramfs-2.6.32-458.23.2.lve1.2.48.el6.x86_64.img
---
> kernel /boot/vmlinuz-2.6.32-379.19.1.lve1.2.7.el6.x86_64 ro root=/dev/xvda1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb nohz=off console=tty0
> initrd /boot/initramfs-2.6.32-379.19.1.lve1.2.7.el6.x86_64.img

After changing we can safely unmount the drive.

[root@recovery ~]# umount /mnt/xvdb1 && rmdir /mnt/xvdb1

Then we can normally reboot the virtual machine. Now the grub configuration should boot to the kernel that we specified.

style="padding-left: 30px;"

[Do you need more assistance with OnApp queries? We would be happy to do it for you]
 

Conclusion

 
In short, today we saw how our Support Techs help our customers to fix this booting issue with the onapp custom CloudLinux template.