You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Last Saturday (Sep 23rd 2023) I was about to elevate a CentOS 7 installation on a root server to Alma 8. I took the elevate script directly from there on this date. I did this on another server (some months prior) and it worked. However, things wouldn't proceed as planned. The system rebooted into stage 4 and then went radio silent. After three hours, I felt like things went wrong.
So, I issued a weekend ticket at that hoster and requested a KVM access to see what error was popping up.
What I saw was that the system was stuck in the grub rescue console. Now, I could recover from that after I went into a rescue system, fixed the bootloader and then finish the installation properly.
The root cause however took me a bit to figure out. It was your preparation script. See, when your script prepares the stage 4 reboot, it will replace the bootloader. Usually, that wouldn't cause an issue, but in my case the server is using pretty old hardware (budget class server) and it doesn't support EFI at all. Your script does not seem to properly check for that (one simple check would be to see if the folder /sys/firmware/efi exists) and tries to install EFI regardless which ends up in a broken and partially installed grub bootloader. I could confirm that when I was doing a chroot from the rescue system into the server. There were empty EFI folder structures in the /boot folder. What baffled me that your script/log did not even register an error here. The modified grub configuration worked when I did a manual grub install on the correct hard drive.
To Reproduce
Have no EFI or inactive EFI. Execute the elevate script. Wait until stage 4 reboot.
Expected behavior
Properly detecting the system's boot mode and installing the boot loader accordingly.
Screenshots
In the attachment
Side nodes
The system itself never had an issue upgrading the Linux kernels, so I can exclude that odd system setup (md0 (raid1), no separate /boot partition; grub installation targets are /dev/sda and /dev/sdb) as a cause.
The text was updated successfully, but these errors were encountered:
Describe the bug
Last Saturday (Sep 23rd 2023) I was about to elevate a CentOS 7 installation on a root server to Alma 8. I took the elevate script directly from there on this date. I did this on another server (some months prior) and it worked. However, things wouldn't proceed as planned. The system rebooted into stage 4 and then went radio silent. After three hours, I felt like things went wrong.
So, I issued a weekend ticket at that hoster and requested a KVM access to see what error was popping up.
What I saw was that the system was stuck in the grub rescue console. Now, I could recover from that after I went into a rescue system, fixed the bootloader and then finish the installation properly.
The root cause however took me a bit to figure out. It was your preparation script. See, when your script prepares the stage 4 reboot, it will replace the bootloader. Usually, that wouldn't cause an issue, but in my case the server is using pretty old hardware (budget class server) and it doesn't support EFI at all. Your script does not seem to properly check for that (one simple check would be to see if the folder /sys/firmware/efi exists) and tries to install EFI regardless which ends up in a broken and partially installed grub bootloader. I could confirm that when I was doing a chroot from the rescue system into the server. There were empty EFI folder structures in the /boot folder. What baffled me that your script/log did not even register an error here. The modified grub configuration worked when I did a manual grub install on the correct hard drive.
To Reproduce
Have no EFI or inactive EFI. Execute the elevate script. Wait until stage 4 reboot.
Expected behavior
Properly detecting the system's boot mode and installing the boot loader accordingly.
Screenshots
In the attachment
Side nodes
The system itself never had an issue upgrading the Linux kernels, so I can exclude that odd system setup (md0 (raid1), no separate /boot partition; grub installation targets are /dev/sda and /dev/sdb) as a cause.
The text was updated successfully, but these errors were encountered: