I recently ran into an issue converting a system from CentOS 7 to Alma Linux 8 on a Linode VM I’ve had for almost seven years. I couldn’t even get through the first step:

curl -o /etc/yum.repos.d/CentOS-Base.repo https://el7.repo.almalinux.org/centos/CentOS-Base.repo

It seemed to just hang. I could pull it up in my browser though, so I thought nothing of it, created the new repo file via cut and paste, moved on to the next step of beginning the upgrade process via Elevate. That failed too, with errors about missing package dependencies. Turns out the issue is that el7.repo.almalinux.org has an AAAA record in DNS (IPv6) but the resolved address (2600:1f18:2fb8:a600:ba8b:5056:5e29:65b0 on Jan 27 2025) is not currently functional, so yum was breaking on downloading what it needed from that repo.

Linode VM’s typically have IPv6 enabled, so you can temporarily disable it in real time via:

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
Code language: PHP (php)

However, after the first reboot occurs, you may need to jump back in and re-run those very quickly so the next phase doesn’t break. Or, temporarily add to /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
Code language: PHP (php)

Next issue, after the first reboot, my VM never came back online. I got into the Linode control panel, clicked into my VM, then “Launch LISH Console” to get to the VM’s console. It was stuck at a grub> prompt. Assuming you have a typical setup, if you ls (hd0)/boot/ you should see some big jumble of crap like:

efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-11efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-11efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-11efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-11efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-11efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-11efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-11efi/ grub2/ grub/ loader/ config-4.18.0-553.36.1.el8_10.x86_64 config-3.10.0-1160.119.1.el7.x86_64 vmlinuz-4.18.0-553.36.1.el8_10.x86_64 vmlinuz-3.10. 0-1160.119.1.el7.x86_64 vmlinuz-0-rescue-868514a7928b4edb857497dfbfae4373 System.map-4.18.0-553.36.1.el8_10.x86_64 System.map-3.10.0-1160.119.1.el7.x86_64 initramfs-3.10.0-1160.119.1.el7.x86_64kdump.img initramfs-0-rescue-868514a7928b4edb857497dfbfae4373.img initramfs-4.18.0-553.36.1.el8_10.x86_64.img initramfs-3.10.0-1160.119.1.el7.x86_64.img symvers-4.18.0-553.36.1.el8_10.x86_64.gz symvers-3.10.0-1160.119.1.el7.x86_64.gz

I’m not sure if that’s because grub doesn’t output line breaks, or if LISH console dosen’t honor the method of line breaks grub uses. Either way, you’ll probably need to cut and paste that into a text editor to split it all apart and find the right kernel to boot. Then, you’ll execute the following commands from grub>

set root=(hd0)
linux /boot/vmlinuz-4.18.0-553.36.1.el8_10.x86_64 root=/dev/sda console=ttyS0,19200n8
initrd /boot/initramfs-4.18.0-553.36.1.el8_10.x86_64.img
boot
Code language: JavaScript (javascript)

That should get your VM back up, but it will keep happening. Next step, edit /etc/default/grub and ensure this line is present and set to false:

GRUB_ENABLE_BLSCFG=false
Code language: JavaScript (javascript)

Then execute:

grub2-mkconfig -o /boot/grub2/grub.cfg

If you reboot again, it should boot fine. Safe to turn IPv6 back on now too.