Hi there,
Almost everything is in the title. After I noticed that volume group was named after a DHCP IP workstation name, I wanted to clean my Almalinux 9 server’s volume name… so I renamed it in Cockpit and after the next reboot… crashed!
My mistake! But if I can spare the reconfiguration of Kasm by fixing the boot, this would be nice. There is probably no other damage.
So VM boots in emergency mode because it doesn’t find the volume group but I don’t know how I can fix it. Where do we start?
If anybody can help, it would be very much appreciated!
You know the “boot process”:
- Firmware (UEFI/BIOS) loads bootloader
- Bootloader loads kernel and initramfs
- Kernel uses instructions from initramfs to load the rest of system
The info about specific kernel that bootloader does use is probably in /boot/loader/entries/
However, one does not need to update it yet, since one can edit GRUB boot menu entry during boot (for that boot attempt).
Anyway, the entry contains kernel command-line options. An example:
options root=/dev/mapper/almalinux_xxx-root ro resume=/dev/mapper/almalinux_xxx-swap rd.lvm.lv=almalinux_xxx/root rd.lvm.lv=almalinux_xxx/swap nomodeset rhgb quiet crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M
Note how that tells kernel something about LVM volumes that the ‘root=’ and ‘resume=’ may depend on.
I would start by choosing the edit entry (e) from GRUB menu, before kernel is loaded.
If rename in kernel options does not save the day, then there might be conflicting instructions within initramfs. That is a (compressed) filesystem in a file. One could list the files with:
lsinitrd /boot/initramfs-5.14.0-362.13.1.el9_3.x86_64.img
but I have not edited the image in years.
Do you have a “rescue” kernel as one option in GRUB menu?
Can you boot the VM with the installer? The latter definitely has “troubleshoot” option
where one can mount the filesystems of “broken” system, chroot in them, and then fix config. I’d uninstall some kernel and then reinstall, in order to get the ‘dracut’ create fresh initramfs.
Plan C is to rename the volume group back to its original name.
Hi there,
That is precious information but right before your answer, I tried the Almalinux CD in emergency mode and I was able to rename the volume group back to previous value which allowed me to boot the VM again.
Nevertheless, I’m still stuck with old name. I found this procedure but my knowledge doesn’t allow me to understand if this is still valid, can you confirm please?
But now, I’ve valid snapshot, so I can try whatever I want (including backups too)! 
Thanks
I’ve renamed boot VGs on hosts several times. What you linked is indeed the outline of what needs done, but there’s probably no grub.cfg in /boot/grub2/ on 9. If you learn to use Grubby you can use the same commands 7 thru 9. In general though, you don’t have to be super worried about getting everything perfect before you reboot. I’ve always found everything I needed to fix a mistake or oversight from emergency mode.
Instead of using a device path, I use the filesystem UUID for fstab (instead of /dev/mapper/…, UUID=…). You can get the UUID for the filesystem from sudo blkid. This way you’re a little more resistant to your mounts breaking due to path changes.
