On this article, we are going to go over a number of the steps required to repair a boot error on an Azure Linux VM resulting from a file system mount error. We’ll cowl a number of the choices obtainable to keep away from this downside. The content material of this text may help you in your Linux certification (Red Hat or LCFS) research, in addition to cloud directors who’re managing Linux VMs in Microsoft Azure.
We are able to use a easy state of affairs. Our company, AP6 Enterprises, is planning to begin with an infrastructure to support Linux in Microsoft Azure. We’ve excessive utilization of volumes being added, modified and faraway from our Linux VMs.
We’re going to preserve it easy and create a single quantity and fix it to the VM. We went over your entire step-by-step intimately in another article the place the principle matter was managing particular person disks in Azure Linux VMs.
We’re going to doc solely the required steps to create the surroundings with out explaining the validation course of as a result of it was included within the earlier article we linked to above.
The present Linux VM known as srv001, and we added a 32GB disk, and the disk was labeled disk000 (for lack of higher creativeness).
After including the brand new disk utilizing the Azure Portal, we carried out these following steps to create the brand new partition. First, we record all the present disks on the working system (Merchandise 1), and we seen that the brand new disk is /dev/sdc (Merchandise 2).
We executed fdisk utility utilizing the brand new disk as a parameter (Merchandise 3). We began the creation of a brand new partition (Merchandise 4), outlined as main partition (Merchandise 5), since that’s the first partition we designated as such (Merchandise 6), the primary part we left default values (Merchandise 7), and we outlined the scale to be 10Gb (Merchandise 8). We wrote all these adjustments (Merchandise 9).
The subsequent step in troubleshooting Azure Linux VM boot errors is to format the newly created partition (Merchandise 1) and create a folder that we are going to mount the partition (Merchandise 2) and the place the applying will reference to make use of to retailer information.
A easy check is to mount the partition earlier than committing the adjustments to the /and so forth/fstab file. One necessary be aware to recollect is that the /dev/sdX (the place X is the letter related to the disk) might shift if you happen to transfer your disks round. It’s extremely really useful to make use of the UUID of the disks as an alternative of their /dev/<disk/partition> tackle.
After mounting the disk, run a blkid (Merchandise 1) and duplicate the UUID (Merchandise 2) of the specified disks, and use that data on the /and so forth/fstab file.
The result’s summarized within the image beneath. We begin by checking the content material of the file /and so forth/fstab (Merchandise 1), and we are going to discover the newly added line into the file (Merchandise 2). For the reason that machine restarted, we are able to examine all mounted file programs utilizing df -h (Merchandise 3). Certainly, we are able to see that the drive /dev/sdc1 is mounted on /mnt/fs.
We’re introducing chaos!
The second regulation of thermodynamics says that entropy all the time will increase, that means from order to dysfunction. Let’s assume that our Linux administrator had that mindset and altered the /and so forth/fstab to a nonexistent worth within the line that we specify our new disks. One other doable technique to trigger disruption is to disconnect the disks from the Azure VM.
Answer 1: Fixing the /and so forth/fstab
By default, when a disk can’t be mounted, it can present an error and the system will enter rescue mode routinely. If you happen to examine the console of the Linux server, the foundation password will probably be requested to proceed.
If you happen to don’t have the foundation password, check out my previous article that goes over this actual state of affairs in Azure Linux VMs.
After getting authenticated as root, edit the /and so forth/fstab and repair the issue. There are a few methods to deal with the problem. First, if the disk not exists, a disconnected disk for instance, then delete or remark the road. Second, if the disk exists and there’s a typo, repair it and save the file.
When full with the adjustments, run systemctl reboot to restart the Linux server. If there aren’t any further errors within the /and so forth/fstab, the system will begin usually.
Answer 2: Avoiding the issue with nofail parameter
It’s possible you’ll wish to keep away from the issue even earlier than it turns into an actual downside. If you happen to use Purple Hat or every other distribution that helps nofail or one thing related, we are able to undertake this methodology as customary when including entries to the/and so forth/fstab file.
Within the Purple Hat, add nofail separated by a comma in addition to the default column. Within the picture depicted beneath, we added an X to the UUID and restarted the Linux server. The Linux server restarted with none points, and the one downside, for apparent causes, is that the file system was not mounted.
This workaround doesn’t resolve the issue the place the applying will be unable to make use of the info. Nevertheless, it’s only a matter of fixing the /and so forth/fstab in a dwell system. This method is far simpler on the operation facet.
After fixing the /and so forth/fstab file, simply run mount -a. The system will reread the file and mount any lacking partition. This process ensures that you’re not going to have the identical subject within the subsequent restart.
So, as you’ll be able to see, fixing boot errors in an Azure Linux VM brought on by file system adjustments shouldn’t be all that troublesome.
Featured picture: Shutterstock