In a previous article, it was described how to manually fix kernel related issues that could cause a Linux VM to not boot properly.

There is also an option where you can use steps to use CHROOT and then use tools to automatically fix these same issues without the need to manually edit files.

Assuming you have your system ready after going to the steps described in this article, meaning you just went through the sequence of steps and you finally executed:
chroot /rescue

For a quick example, let’s assume you had a non-boot scenario after updating the kernel on a CentOS 7.2 to version:
3.10.0-327.36.1.el7.x86_64

You can quickly see which kernels you still have installed by running:
cd /rescue/boot/grub2/
grep -i linux16 grub.cfg

The output should be similar to:
linux16 /boot/vmlinuz-3.10.0-327.36.1.el7.x86_64 root=UUID=3b5d406c-7fa6-458f-815c-9684bb9fe148 ro console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300 net.ifnames=0 LANG=en_US.UTF-8
linux16 /boot/vmlinuz-3.10.0-327.18.2.el7.x86_64 root=UUID=3b5d406c-7fa6-458f-815c-9684bb9fe148 ro console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300 net.ifnames=0

Which means you have the current one 36.1 as well as the 18.2 installed.

You can then easily roll back to 18.2 by executing:
grep -i menuentry grub.cfg

Output should be similar to:
menuentry ‘CentOS Linux (3.10.0-327.36.1.el7.x86_64) 7 (Core)‘ –class centos –class gnu-linux –class gnu –class os –unrestricted $menuentry_id_option ‘gnulinux-3.10.0-327.18.2.el7.x86_64-advanced-3b5d406c-7fa6-458f-815c-9684bb9fe148’ {
menuentry ‘CentOS Linux (3.10.0-327.18.2.el7.x86_64) 7 (Core)‘ –class centos –class gnu-linux –class gnu –class os –unrestricted $menuentry_id_option ‘gnulinux-3.10.0-327.18.2.el7.x86_64-advanced-3b5d406c-7fa6-458f-815c-9684bb9fe148’ {

With that you can then execute: grub2-editenv list This will display:
saved_entry=CentOS Linux (3.10.0-327.36.1.el7.x86_64) 7 (Core)

grub2-set-default “CentOS Linux (3.10.0-327.18.2.el7.x86_64) 7 (Core)”

This will change the kernel back to the 18.2 version, now after this you can safely go through the final steps to exit the CHROOT environment:

The steps to exit the chroot environment and umount everything are:

exit cd / umount /rescue/proc/ umount /rescue/sys/ umount /rescue/dev/pts umount /rescue/dev/

For Debian and Ubuntu distributions you will need to umount (run):

umount /rescue/run/ umount /rescue

The finally you can detach the disk and use one of our articles to rebuild the VM using either PowerShell or Azure CLI:
Azure PowerShell: How to delete and re-deploy a VM from VHD

Azure CLI: How to delete and re-deploy a VM from VHD