-
Notifications
You must be signed in to change notification settings - Fork 11
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
Conversion fails, incorrectly claiming grub2 is not installed #418
Comments
Could you please check if the file |
It does not: |
Since it's a sister company, I will post that I found https://support.cpanel.net/hc/en-us/articles/21890559516183-ELevate-blocker-GRUB-is-missing which suggests creating it, and rebuilding the grub.cfg file. I also found a few random posts indicating the missing file isn't used, but to build grub.cfg anyway, basically, as indicated in the above URL. Should I go that route? Or should the script not be looking for |
Yes. In the past, Elevate depended on this file, so we included this pre-check to ensure the file is in order. |
OK. thank you, will report back in a few days when I get a chance to do it. For additional info, we have two slave name servers we converted from CentOS 7 to AlmaLinux 8 last year using https://docs.virtuozzo.com/virtuozzo_hybrid_server_7_users_guide/advanced-tasks/converting-containers-with-almaconvert8.html (which won't run if Plesk is installed) and later converted to VMs. Neither have a /etc/default/grub file. |
On the plus side, the script proceeded past the grub2 error. However it did not complete successfully. I generated the grub file, rebooted, ran the script, it pointed out a kernel update, I installed that and rebooted a second time. Then I reran the script. It did not begin the first restart: [=========================( stage Pause before reboot / action pause before reboot )======> ] 19:37 / 30:44 The dist-upgrade process needs to reboot the server. It will be rebooted in several seconds. then it ended in an emergency shell: /etc/almalinux-release showed 8.10. IIRC, this is basically where I ended up on a non-Plesk Hyper-V VM I tried to upgrade 18 months ago, using various upgrade methods (not the Plesk script of course). I tried multiple times but eventually I gave up and recreated that VM. Hoping that's not the case here or for other Plesk VMs. When I rebooted at this point it booted up normally but then apparently tried to continue and failed. This is the end of centos2alma.log after it booted (I saved the whole file): 2025-02-19 23:09:06,808 - INFO - stderr: plesk-core-18.0-2.centos.7+p18.0.67.3+t250217.0844.x86_64 has missing requires of psa-phpmyadmin >= ('0', '5.2.1', None) 2025-02-19 23:09:13,297 - DEBUG - Sent error report At this point I restored from backup. |
The centos2alma script utilizes Elevate, so if you couldn't upgrade those systems using Elevate, sadly centos2alma will encounter the same error. Did you happen to save the file /run/initramfs/rdsosreport.txt? I believe it should contain error details. |
I did upgrade the two slave name servers successfully…
The Hyper-V VM was in our office, totally different. Unclear why some succeed and some don’t boot.
I have the screen cap above of the end of the log file. No way to get it out of the VM, AFAIK. Most commands don’t exist in that state.
Worse, turns out the Virtuozzo restore on the converted VM failed. I had to restore the container and work my way forward with files. :(
|
JFYI: I've checked if the Elevate still requires the file. It does, so we need to keep this pre-checker. |
Interesting, I wonder how almaconvert8 does it then. Well, we can't exactly remove Plesk and put it back again, and if the converted VMs with Plesk won't upgrade then I guess we're back to a manual migration via Plesk trial license. Perhaps it's some interaction with how Virtuozzo is converting the container, I don't know, but it seems like the "easy" path of double converting is not going to work. I have a ticket open with Virtuozzo...if we could restore quickly I'd try again if we could find something to try, but restoring at least that server as a VM isn't working right now. (!) Side note: IIRC for that Hyper-V VM, if I booted that from emergency mode, it always returned to emergency mode, whereas in this case this Plesk VM booted back into CentOS7 and tried to continue the upgrade, leaving it broken. |
We even have an issue for supporting conversion inside the container. Unfortunately, we do not have the resources to fix it at the moment. |
That's why we were planning to convert to VMs. But, no point if the OS upgrade will fail. (I expect it works for other people...not sure why on this one, and not super excited about doing a long convert-backup-upgrade-restore process on others if it's not assured to work for us) FWIW, Virtuozzo did confirm a bug with their CT-to-VM conversion, it can put the hard disk file in an unexpected path (subfolder). Backups succeed but a restore writes the entire disk file out to disk and then deletes it, leaving the VM without a disk. The workaround is to move the disk file before doing the backup. |
Describe the bug
Script claims grub2 is not installed.
# ./centos2alma
Doing preparation checks...
Required pre-conversion condition 'checking if grub2 is installed' not met:
Grub2 does not appear to be installed.
To proceed with the conversion, please install the 'grub2', 'grub2-common' and/or 'grub2-tools' packages
Conversion can't be performed due to the problems noted above
but also:
# yum install grub2 grub2-common grub2-tools
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* epel: d2lzkl7pfhq30w.cloudfront.net
Package 3:grub2-2.02-0.87.0.2.el7.centos.14.tuxcare.els2.x86_64 already installed and latest version
Package 3:grub2-common-2.02-0.87.0.2.el7.centos.14.tuxcare.els2.noarch already installed and latest version
Package 3:grub2-tools-2.02-0.87.0.2.el7.centos.14.tuxcare.els2.x86_64 already installed and latest version
Nothing to do
This is a Virtuozzo VM that was converted from a container using c2v-convert.
Feedback archive
centos2alma_feedback.zip
The text was updated successfully, but these errors were encountered: