Conversion fails, incorrectly claiming grub2 is not installed

[teamits]

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

[SandakovMM]

Could you please check if the file /etc/default/grub exists?

[teamits]

It does not:
# ls -l /etc/default/
total 8
-rw-r--r-- 1 root root 1756 Jul 3 2024 nss
-rw-r--r-- 1 root root 119 Aug 6 2019 useradd

[teamits]

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 /etc/default/grub?

[SandakovMM]

Should I go that route?

Yes. In the past, Elevate depended on this file, so we included this pre-check to ensure the file is in order.
It is possible that the latest version of Elevate already skip the file when the file is missing, so I will check that. If so, we will be able to remove pre-checking of the file.

[teamits]

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.

[teamits]

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
[=========================( stage Pause before reboot / action pause before reboot )======> ] 19:38 / 30:44

---

The dist-upgrade process needs to reboot the server. It will be rebooted in several seconds.
The process will resume automatically after the reboot.
Current server time: 22:50:47.
To monitor the disupgrade status use one of the following commands:
/root/centos2alma --status
or
/root/centos2alma --monitor

---

then it ended in an emergency shell:

logs:

/etc/almalinux-release showed 8.10.
/etc/fstab was 0 bytes in that environment.

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:06,808 - INFO - stderr: plesk-modsecurity-configurator-18.0-2.centos.7+p18.0.67.3+t250217.0844.noarch has missing requires of python36-PyYAML
2025-02-19 23:09:06,809 - INFO - stderr: plesk-mysql-server-18.0.2-2.centos.7+p18.0.44.0+t220518.2121.noarch has missing requires of mariadb-server >= ('0', '5.0.60', None)
2025-02-19 23:09:06,809 - INFO - stderr: plesk-service-node-utilities-18.0-2.centos.7+p18.0.67.3+t250217.0844.x86_64 has missing requires of python36-PyYAML
2025-02-19 23:09:06,809 - INFO - stderr: plesk-web-hosting-18.0-2.centos.7+p18.0.67.1+t250130.1443.x86_64 has missing requires of psa-mod_proxy
2025-02-19 23:09:08,978 - INFO - stdout: Installing : 1:mariadb-libs-5.5.68-1.el7.x86_64 1/3
2025-02-19 23:09:10,964 - INFO - stdout: Installing : 1:mariadb-5.5.68-1.el7.x86_64 2/3
2025-02-19 23:09:11,131 - INFO - stdout: Installing : 1:mariadb-server-5.5.68-1.el7.x86_64 3/3
2025-02-19 23:09:11,147 - INFO - stdout: Verifying : 1:mariadb-server-5.5.68-1.el7.x86_64 1/3
2025-02-19 23:09:11,163 - INFO - stdout: Verifying : 1:mariadb-libs-5.5.68-1.el7.x86_64 2/3
2025-02-19 23:09:11,331 - INFO - stdout: Verifying : 1:mariadb-5.5.68-1.el7.x86_64 3/3
2025-02-19 23:09:11,331 - INFO - stdout:
2025-02-19 23:09:11,331 - INFO - stdout: Installed:
2025-02-19 23:09:11,331 - INFO - stdout: mariadb.x86_64 1:5.5.68-1.el7 mariadb-server.x86_64 1:5.5.68-1.el7
2025-02-19 23:09:11,332 - INFO - stdout:
2025-02-19 23:09:11,332 - INFO - stdout: Dependency Installed:
2025-02-19 23:09:11,332 - INFO - stdout: mariadb-libs.x86_64 1:5.5.68-1.el7
2025-02-19 23:09:11,332 - INFO - stdout:
2025-02-19 23:09:11,332 - INFO - stdout: Complete!
2025-02-19 23:09:11,371 - INFO - stderr: 2:postfix-3.5.25-2.centos.7+p18.0.67.1+t250130.1443.x86_64 has missing requires of libmysqlclient.so.18()(64bit)
2025-02-19 23:09:11,371 - INFO - Command ['/usr/bin/yum', 'install', '-y', 'mariadb', 'mariadb-server'] finished successfully
2025-02-19 23:09:11,371 - INFO - Running: ['/usr/bin/systemctl', 'start', 'mariadb']. Output:
2025-02-19 23:09:12,524 - INFO - stderr: Job for mariadb.service failed because the control process exited with error code. See "systemctl status mariadb.service" and "journalctl -xe" for details.
2025-02-19 23:09:12,525 - ERROR - Command ['/usr/bin/systemctl', 'start', 'mariadb'] failed with return code 1
2025-02-19 23:09:12,525 - ERROR - Failed: updating mariadb databases. The reason: Command '['/usr/bin/systemctl', 'start', 'mariadb']' returned non-zero exit status 1.

2025-02-19 23:09:13,297 - DEBUG - Sent error report
2025-02-19 23:09:13,425 - DEBUG - Trying to send status of conversion by report-update utility '/root/parallels/report-update'
2025-02-19 23:09:14,394 - ERROR - centos2alma process has failed. Error: Failed: updating mariadb databases. The reason: Command '['/usr/bin/systemctl', 'start', 'mariadb']' returned non-zero exit status 1.
2025-02-19 23:09:14,395 - INFO - Going to free lockfile '/usr/local/psa/var/centos2alma/centos2alma.lock'...
2025-02-19 23:09:14,396 - INFO - Create signals handler with keep MOTD: True
2025-02-19 23:10:47,624 - INFO - Started with arguments ['./centos2alma', '--prepare-feedback']
2025-02-19 23:10:47,624 - DEBUG - Got upgrader name 'Plesk::Centos2AlmaConverter' for feedback preparation from '/usr/local/psa/var/centos2alma/resume.json'
2025-02-19 23:10:47,624 - DEBUG - Detected current OS distribution as CentOS 7
2025-02-19 23:10:47,624 - DEBUG - Current system: CentOS 7
2025-02-19 23:10:47,624 - DEBUG - Available upgraders: [Centos2AlmaConverterFactory(upgrader_name=Plesk::Centos2AlmaConverter)]
2025-02-19 23:10:47,624 - DEBUG - Looking for upgrader by the name 'Plesk::Centos2AlmaConverter'
2025-02-19 23:10:47,624 - DEBUG - Found upgraders: [Centos2AlmaConverterFactory(upgrader_name=Plesk::Centos2AlmaConverter)]
2025-02-19 23:10:47,625 - INFO - Selected upgrader: Centos2AlmaConverter (1.4.5-319e16aa)
2025-02-19 23:10:47,625 - DEBUG - Upgrader Centos2AlmaConverter support of your system: as source = True, as target = False

At this point I restored from backup.

centos2alma_feedback.zip

[SandakovMM]

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.

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.

[teamits]

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. :(

[SandakovMM]

It is possible that the latest version of Elevate already skip the file when the file is missing, so I will check that. If so, we will be able to remove pre-checking of the file.

JFYI: I've checked if the Elevate still requires the file. It does, so we need to keep this pre-checker.

[teamits]

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.

[SandakovMM]

Perhaps it's some interaction with how Virtuozzo is converting the container

We even have an issue for supporting conversion inside the container. Unfortunately, we do not have the resources to fix it at the moment.

[teamits]

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.

[teamits]

Backups succeed but a restore writes the entire disk file out to disk and then deletes it, leaving the VM without a disk

For the record this was fixed last month in 7.5 update 7 hotfix 3: https://docs.virtuozzo.com/virtuozzo_advisory_archive/virtuozzo-hybrid-server/VZA-2025-006.html

[teamits]

Backups succeed but a restore writes the entire disk file out to disk and then deletes it, leaving the VM without a disk

For the record this was fixed last month in 7.5 update 7 hotfix 3: https://docs.virtuozzo.com/virtuozzo_advisory_archive/virtuozzo-hybrid-server/VZA-2025-006.html