Using Boom Boot Manager on CentOS Stream 9: Managing Boot Entries and Creating Restore Points from LVM Snapshots – ITFROMZERO

Yesterday, a developer on my team updated the kernel on a production server — and then the system failed to boot. No snapshot, no fallback boot entry, and we spent three hours in rescue mode. It’s the kind of story every experienced sysadmin has lived through at least once.

That’s why I started using Boom Boot Manager — a tool that lets you create and manage boot entries in GRUB2, combined with LVM Snapshots to create genuinely usable system restore points. My company still runs a few servers on CentOS 7, and migrating them to AlmaLinux is something I’ve already dealt with. But on CentOS Stream 9, Boom is what helps me sleep easier before every update.

Table of Contents

Get started in 5 minutes: Create your first boot entry

Before diving into explanations, let’s just try it and see how it works.

Step 1: Install Boom

dnf install boom-boot -y

Step 2: Create an OS Profile

Boom needs information about your operating system to generate boot entries with the correct syntax:

# Check if a profile already exists
boom profile list

# If not, create one automatically from the current host
boom profile create --from-host

Step 3: Create a test boot entry

# Get the profile ID we just created
PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')

# Create a boot entry from the current kernel
boom entry create \
  --profile ${PROFILE_ID} \
  --title "CentOS Stream 9 - Test Entry" \
  --root-device /dev/mapper/cs-root

# Verify the entry was created
boom entry list

After rebooting, you’ll see the new entry appear in the GRUB menu. That’s all there is to it.

Understanding what Boom actually solves

GRUB2 has its configuration file at /boot/grub2/grub.cfg, but this file is automatically generated by grub2-mkconfig. Every time a new kernel is installed, this file gets overwritten. Any manual changes are lost along with it.

Boom solves this by creating Boot Entries — separate files in /boot/loader/entries/ — following the Boot Loader Specification (BLS) standard. These files are not overwritten when a new kernel is installed; they exist independently of grub.cfg.

# View boot entry files
ls /boot/loader/entries/

# Read the contents of an entry
cat /boot/loader/entries/*.conf

An entry file looks like this:

title CentOS Stream 9 - Restore Point 20240115
version 5.14.0-362.el9.x86_64
machine-id abc123def456
options root=/dev/mapper/cs-snap-20240115 ro crashkernel=1G-4G:192M
linux /vmlinuz-5.14.0-362.el9.x86_64
initrd /initramfs-5.14.0-362.el9.x86_64.img

Note the root= line — this is where you point to any LVM volume, including snapshots.

Advanced: Combining Boom with LVM Snapshots to create restore points

This is the important part. Boom is designed to work with LVM Snapshots — meaning you take a snapshot of the system state at a point in time, create a boot entry pointing to that snapshot, and when needed, boot into it to restore.

Check your current LVM configuration

# View volume groups
vgs

# View logical volumes in detail
lvs

# Example output:
# LV    VG  Attr       LSize
# home  cs  -wi-ao----  5.00g
# root  cs  -wi-ao---- 35.00g
# swap  cs  -wi-ao----  4.00g

Create an LVM Snapshot before updating

# Create a snapshot of the root volume (10GB capacity for changes)
lvcreate -L10G -s -n root-snap-$(date +%Y%m%d) /dev/cs/root

# Verify the snapshot
lvs | grep snap

I usually set the snapshot size to 20–30% of the original volume. Write-heavy servers need more — if a snapshot fills to 100% it auto-invalidates, and any boot entry pointing to it becomes unusable.

Create a Boom Boot Entry pointing to the snapshot

PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')
SNAP_DATE=$(date +%Y%m%d)
SNAP_DEV="/dev/cs/root-snap-${SNAP_DATE}"

boom entry create \
  --profile ${PROFILE_ID} \
  --title "Restore Point ${SNAP_DATE}" \
  --root-device ${SNAP_DEV} \
  --root-opts "ro"

boom entry list

Script to automate the entire process

Doing this manually every time is tedious, so I wrote this script and run it before every update:

#!/bin/bash
# /usr/local/bin/create-restore-point.sh

SNAP_DATE=$(date +%Y%m%d_%H%M)
VG_NAME="cs"
LV_NAME="root"
SNAP_SIZE="10G"
SNAP_NAME="${LV_NAME}-snap-${SNAP_DATE}"

echo "=== Creating restore point: ${SNAP_DATE} ==="

# 1. Create LVM snapshot
echo "Creating LVM snapshot..."
lvcreate -L${SNAP_SIZE} -s -n ${SNAP_NAME} /dev/${VG_NAME}/${LV_NAME}
if [ $? -ne 0 ]; then
  echo "FAILED: Could not create snapshot"
  exit 1
fi

# 2. Create boom entry
echo "Creating boot entry..."
PROFILE_ID=$(boom profile list --short | head -1 | awk '{print $1}')
boom entry create \
  --profile ${PROFILE_ID} \
  --title "Restore Point ${SNAP_DATE}" \
  --root-device /dev/${VG_NAME}/${SNAP_NAME} \
  --root-opts "ro"

echo "=== Done! Restore point ${SNAP_DATE} is ready ==="
boom entry list

chmod +x /usr/local/bin/create-restore-point.sh

# Run before updating
create-restore-point.sh

# Update away
dnf update -y

Practical tips

Cleaning up old restore points

Snapshots consume disk space, so don’t let them pile up:

# View entries with their Entry IDs
boom entry list

# Delete an entry you no longer need (replace abc123 with the actual Entry ID)
boom entry delete abc123

# Remove the corresponding LVM snapshot
lvremove /dev/cs/root-snap-20240110_0930

Monitor snapshot usage

# Check usage — if Data% approaches 100%, pay attention
lvs -o lv_name,lv_size,data_percent /dev/cs

I set up a daily cron job for early warnings:

#!/bin/bash
# /etc/cron.daily/check-snapshots

lvs --noheadings -o lv_name,data_percent | while read lv pct; do
  pct_int=${pct%%.*}
  if [ -n "${pct_int}" ] && [ "${pct_int}" -gt 80 ] 2>/dev/null; then
    echo "WARNING: LVM Snapshot ${lv} is at ${pct}% usage" | \
      logger -t lvm-snapshot-alert
  fi
done

Booting into a restore point when you need to recover

Reboot the server
At the GRUB screen, press any key to stop the countdown
Select the “Restore Point YYYYMMDD” entry
The system boots into the state at the time the snapshot was taken
Check that everything looks good, then decide whether to roll back or keep the update

If you decide to fully roll back, merge the snapshot into the original volume (this operation is irreversible — must be done from rescue mode or a live environment):

# Run from rescue mode or live CD
lvconvert --merge /dev/cs/root-snap-20240115_0900

Boom vs grubby — when to use which?

Many people are used to using grubby to manage boot entries. The practical difference: grubby modifies grub.cfg directly and is easily overwritten, while Boom creates independent BLS entry files — much safer and far better suited for LVM Snapshot workflows. If you’re working with LVM Snapshots, Boom is the natural choice.

Since adopting this workflow, my team no longer worries about kernel updates or major package upgrades. Run create-restore-point.sh first, update, verify everything looks good, then delete the snapshot. We’ve never had to actually use a restore point — but knowing it’s there makes everyone work with far more confidence.