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
Is your feature request related to a problem? Please describe.
On EFI based systems, /boot/grub2/grubenv is a symbolic link to ../efi/EFI/centos/grubenv. For a normal kernel update, it does not matter whether this is a symbolic link or a physical file in /boot/grub2. A kernel update will succeed, updating grubenv in the given location and also updating /boot/grub2/grub.cfg.
But: ELevate handles it differently. If /boot/grub2/grubenv is a physical file, ELevate will write a grubenv AND a new grub.cfg into /boot/efi/EFI/centos. When the server enters phase 2 and should boot into the ELevate temporary OS, it will not find the correct boot loader entry and instead offer the same boot loader entries as it did in a regular boot before the conversion started. The server will then boot into the previously installed system.
Describe the solution you'd like
We propose a pre-check whether /boot/grub2/grubenv is a physical file. If the system is EFI based, it should be pointed out to the user that ELevate may not start into the correct system in phase 2. It should also be checked as the last step of phase no. 1 that "grubby --default-kernel" responds with the expected ELevate temporary OS kernel and that in ../efi/EFI/centos no grub.cfg exists (or it should just be walked through the /boot directories to find the grub.cfg that was generated by Leapp and it should be determined whether it is located in the right path).
Describe alternatives you've considered
In our case we have moved the physical grubenv file in /boot/grub2 into /boot/efi/EFI/centos (and replaced the file in that location), removed the grub.cfg file that ELevate created from /boot/efi/EFI/centos (because it doesn't belong there), then created a symbolic link from /boot/grub2/grubenv to ../efi/EFI/centos/grubenv, then reverted phase 1 and started over with "./centos2alma --start". On that second attempt, after the corrections of paths in /boot, all went through as expected.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
On EFI based systems, /boot/grub2/grubenv is a symbolic link to ../efi/EFI/centos/grubenv. For a normal kernel update, it does not matter whether this is a symbolic link or a physical file in /boot/grub2. A kernel update will succeed, updating grubenv in the given location and also updating /boot/grub2/grub.cfg.
But: ELevate handles it differently. If /boot/grub2/grubenv is a physical file, ELevate will write a grubenv AND a new grub.cfg into /boot/efi/EFI/centos. When the server enters phase 2 and should boot into the ELevate temporary OS, it will not find the correct boot loader entry and instead offer the same boot loader entries as it did in a regular boot before the conversion started. The server will then boot into the previously installed system.
Describe the solution you'd like
We propose a pre-check whether /boot/grub2/grubenv is a physical file. If the system is EFI based, it should be pointed out to the user that ELevate may not start into the correct system in phase 2. It should also be checked as the last step of phase no. 1 that "grubby --default-kernel" responds with the expected ELevate temporary OS kernel and that in ../efi/EFI/centos no grub.cfg exists (or it should just be walked through the /boot directories to find the grub.cfg that was generated by Leapp and it should be determined whether it is located in the right path).
Describe alternatives you've considered
In our case we have moved the physical grubenv file in /boot/grub2 into /boot/efi/EFI/centos (and replaced the file in that location), removed the grub.cfg file that ELevate created from /boot/efi/EFI/centos (because it doesn't belong there), then created a symbolic link from /boot/grub2/grubenv to ../efi/EFI/centos/grubenv, then reverted phase 1 and started over with "./centos2alma --start". On that second attempt, after the corrections of paths in /boot, all went through as expected.
The text was updated successfully, but these errors were encountered: