Upgrading the Kernel of a Linux VM hosted in Azure

The Background

I’m running a CentOS Linux VM on Azure in the Australia East Region (Sydney) and I need to access a CIFS (Common Internet File System) share in the Azure Southeast (Melbourne) region.

CIFS is also known as SMB, you know, the \\ImaNetworkShare file(s) over the network. This is possible in Windows but so far not in Linux prior to Kernel V 4.0

One simple setup, 2 VMs, 1 Windows, 1 Linux in Sydney to read files from a network share in Melbourne

Kernel Upgrade

Note: This can be done in CentOS, because it allows the use of ELRepo ( “ELRepo supports Red Hat Enterprise Linux (RHEL) and its derivatives (Scientific Linux, CentOS & others)

Output will look like this:

Now, list the Kernel Repos, only

It will look like this:

And then install the selected version, one I chose was kernel-ml.x86_64, ml: means mainline stable

Once installed, it will confirm:

Do a reboot

 

Make the new Kernel the boot default. Edit in /etc/default/grub the following line, it’s a ‘0’ (zero) even when it may look like an O

GRUB_DEFAULT=0 

Recreate the Kernel Config

 

Reboot again

Verify

Another command for verifying

With this new Kernel mounting an SMB partition in an Azure File service found in a different region to the VM will be possible.

Note:

It has happened in some of the Centos Release 7 images from the Azure Marketplace that the kernel gets updated but not set as the default bootable, if that happens, follow the steps in the Update section just below. All the previous steps remain the same. Go to the Update Section.

Update

Follow these section if the bootable kernel was not updated, make sure you followed all the steps previous to this point.

The output will look like this:

This command presents all the boot menu options available. It shows the kernel was downloaded and it’s available as bootable.

Check which is the actual default

It will output:

Kernel 3.x! Which is line Number 1 in the boot file

Change to Kernel V 4.x

Verify

Done, changed to Kernel 4.x

Reboot once more

Verify with uname -a

Done, running on Kernel 4.x

Roberto