Troubleshoot
There were a large number of “dracut timeout” messages in the on-site console log, after which the system automatically entered the dracut emergency shell. Searching on Google for relevant keywords led to a similar case on Red Hat Bugzilla: Bug 1346231 - unbootable after removing swap partition. This mentioned the need to remove the swap configuration from /etc/default/grub. I decisively mounted the disk and went to /etc/default/grub. Sure enough, it still contained residual configuration related to the swap partition.
The fix
Once the problem is located, the repair process is usually simple. Find and delete the following related content from /etc/default/grub:
resume=/dev/mapper/cs-swap rd.lvm.lv=cs/swap
After updating this configuration file, we should regenerate /boot/grub2/grub2.cfg to ensure the modification takes effect. First, we mount the boot partition:
mount /dev/disk/by-uuid/<your_boot_disk_uuid> /mnt/boot
Then, running the following command should update the configuration:
grub2-mkconfig > /mnt/boot/grub2/grub.cfg
However, a new problem arose at this point. First, the dracut emergency shell does not come with this script. Even if we use chroot to enter the new environment to solve this problem, it still relies on the three partitions: /sys, /proc, and /dev. These three partitions are not mounted in the environment after a simple chroot. How to solve this? This is where the --bind parameter provided by mount comes in handy: this parameter allows the two specified directories to point to the same area, which ensures that we can use the information provided by these three partitions in the emergency shell environment even after chroot. Therefore, before chroot, we should remount these three partitions:
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
After re-entering chroot, we make a slight adjustment to the command:
grub2-mkconfig > /boot/grub2/grub.cfg
At this point, we can successfully update grub.cfg. Reboot, and the problem is gone!