Bobcares

EC2: Fail to boot due to issues with the GRUB2 BLS Configuration File

PDF Header PDF Footer

EC2: Fail to boot due to issues with the GRUB2 BLS Configuration File? We can help you.

We can use the grubby tool to manage the blscfg files and retrieve information from the /boot/loader/entries/.

Here, at Bobcares, we assist our customers with several AWS queries as part of our AWS Support Services.

Today, let us see how to recover the BLS configuration (blscfg) file found under /boot/loader/entries/ if it is corrupt.

 

EC2: Fail to boot due to issues with the GRUB2 BLS Configuration File

GRUB2 in RHEL 8 and Centos 8 uses blscfg files and entries in /boot/loader for the boot configuration.

Suppose the blscfg files are missing from this location or corrupted. In that case, grubby doesn’t show any results.

 

How to resolve this?

Moving ahead, let us see the methods our Support Techs recommend to resolve this query.

Since this procedure requires a stop and start of the instance, any data on the instance can be lost. So we make sure not to perform this procedure on an instance store-backed instance.

 

Attach the root volume to a rescue EC2 instance

Initially, we create an EBS snapshot of the root volume.

2. Then we open the Amazon EC2 console.

3. From the navigation pane, we select Instances > Impaired instance.

4. After that we go to, Actions > Instance State > Stop.

5. Under the Root device in the Description tab, we select /dev/sda1, and then the EBS ID.

6. Then we select Actions > Detach Volume > Yes, Detach. Here, we need to note the Availability Zone.

7. In the same Availability Zone we need to launch a similar rescue EC2 instance. This becomes the rescue instance.

8. Once it launches, we select Volumes and then choose the detached root volume of the impaired instance.

9. Eventually, we go to Actions > Attach Volume.

10. Here we need to select the rescue instance ID, and then set an unused device.

 

Mount the volume of the impaired instance

1. First, we connect to the rescue instance via SSH.

2. Then we run the lsblk command to view the available disk devices.

[ec2-user@ip-10-10-1-111 /]s lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 10G 0 disk
├─xvda1 202:1 0 1M 0 part
└─xvda2 202:2 0 10G 0 part /
xvdf 202:80 0 10G 0 disk
├─xvdf1 202:81 0 1M 0 part
└─xvdf2 202:82 0 10G 0 part

3. After that, we create a mount directory, and then mount the root partition of the mounted volume to this new directory.

In the above example, /dev/xvdf2 is the root partition.

sudo mkdir /mount
sudo mount /dev/xvdf2 /mount

4. We mount /dev, /run, /proc, and /sys of the rescue instance to the same paths as the new.

sudo mount -o bind /dev /mount/dev
sudo mount -o bind /run /mount/run
sudo mount -o bind /proc /mount/proc
sudo mount -o bind /sys /mount/sys

5. Finally, we start the chroot environment.

sudo chroot /mount

 

Regenerate the blscfg files

1. Here, we run the rpm command and take note of the available kernels in the instance.

[root@ip-10-10-1-111 ~]# rpm -q --last kernel
kernel-4.18.0-147.3.1.el8_1.x86_64 Tue 21 Jan 2020 05:11:16 PM UTC
kernel-4.18.0-80.4.2.el8_0.x86_64 Tue 18 Jun 2019 05:06:11 PM UTC

2. After that, to recreate the blscfg file, we run:

sudo kernel-install add 4.18.0-147.3.1.el8_1.x86_64 /lib/modules/4.18.0-147.3.1.el8_1.x86_64/vmlinuz

Make sure to use your kernel version number.

The blscfg for the designated kernel regenerates under /boot/loader/entries/.

[root@ip-10-10-1-111 ~]# ls /boot/loader/entries/
2bb67fbca2394ed494dc348993fb9b94-4.18.0-147.3.1.el8_1.x86_64.conf

3. If necessary, we can repeat step 2 for other kernels on the instance. However, the latest kernel is set to the default kernel.

4. Then to see the current default kernel we run the grubby command –-default kernel.

sudo grubby --default-kernel

5. Eventually,we exit from chroot and unmount the /dev, /run, /proc, and /sys mounts.

Exit
sudo umount /mount/dev
sudo umount /mount/run
sudo umount /mount/proc
sudo umount /mount/sys
sudo umount /mount

6. Later, we mount the device back to the original instance with the correct block device mapping. Now the device boots with the default kernel.

[Stuck in between? We are here to assist you]

 

Conclusion

In short, we saw how our Support Techs go about EC2: Fail to boot due to issues with the GRUB2 BLS Configuration File.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = "owonCMyG5nEQ0aD71QM";
0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Get featured on the Bobcares blog and share your expertise with a global tech audience.

WRITE FOR US
server management

Spend time on your business, not on your servers.

TALK TO US

Or click here to learn more.

Speed issues driving customers away?
We’ve got your back!

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF