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

Conversion fails, incorrectly claiming grub2 is not installed #418

Open
teamits opened this issue Feb 18, 2025 · 12 comments
Open

Conversion fails, incorrectly claiming grub2 is not installed #418

teamits opened this issue Feb 18, 2025 · 12 comments
Labels
bug Something isn't working

Comments

@teamits
Copy link

teamits commented Feb 18, 2025

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

@teamits teamits added the bug Something isn't working label Feb 18, 2025
@SandakovMM
Copy link
Collaborator

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

@teamits
Copy link
Author

teamits commented Feb 18, 2025

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
Copy link
Author

teamits commented Feb 18, 2025

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
Copy link
Collaborator

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
Copy link
Author

teamits commented Feb 19, 2025

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
Copy link
Author

teamits commented Feb 20, 2025

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:

Image

logs:
Image

/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
Copy link
Collaborator

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
Copy link
Author

teamits commented Feb 20, 2025 via email

@SandakovMM
Copy link
Collaborator

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
Copy link
Author

teamits commented Feb 20, 2025

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
Copy link
Collaborator

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
Copy link
Author

teamits commented Feb 25, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants