Having trouble with your custom CloudLinux template not booting? Read to find out what our expert Support Engineers have to say.

If your virtual machine refuses to boot, it is time to call in the experts. Our Support Services solves all your queries in a jiffy. With Bobcares by your side, you can leave your worries aside.

How to resolve custom CloudLinux template not booting

If your custom CloudLinux template refuses to boot, you have come to the right place. You may have noticed something like the following under failed StartupVirtualServer in the VM’s logs.

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...

In fact, this is the reason why your virtual machine refuses to start.

In order to resolve this issue, first, check the grub.conf. In most cases, changing the grub.conf resolves the issue on hand. Verify whether grub.conf has a valid kernel or not. This can be checked by entering VM via recovery mode.

Usually, the VM’s primary data is present in /dev/xvdb1 in the recovery boot.

[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

Once we have access to the inifrmation in the origianl grub.conf, it is time to cross-check it with the virtual machine’s kernels in boot as seen below:

[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

Once we are sure the same images are not there, we need to backup the grub.conf. After that, we change the image name to an existing kernel.

Furthermore, we can now edit grub.conf after taking a backup. For instance, here is the difference between the two:

[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 that, safely unmount the drive with the following command:

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

Then, navigate to the control panel’s UI and reboot the VM as normal. This time around, the grub configuration will boot the kernel you specified earlier.

[Need a helping hand? We are here to help.]

Conclusion

In conclusion, we learned there is no need to despair if our custom CloudLinux template is not booting. The Support Engineers at Bobcares offer their advice on the issue.