Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pre-check if /boot/grub2/grubenv is a symbolic link as otherwise ELevate will write grub.cfg into a wrong directory #224

Open
Bitpalast opened this issue Mar 28, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@Bitpalast
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant