• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved CentOs2Alma conversion failed - disk space?

Franco

Regular Pleskian
Server operating system version
CentOs 7.9
Plesk version and microupdate number
Version 18.0.62 Update #1
Hello,

I used the Plesk provided script to convert my CentOs7.9 VPS to Almalinux, but, after a great deal of conversions and installations, it failed with not enough space, apparently quite a common situation despite having 17GB free on the server. The "troubled area" starts with:
...
2024-07-12 21:11:25,301 - INFO - Total 33 MB/s | 1.1 GB 00:33
2024-07-12 21:11:25,301 - INFO - Running transaction check
2024-07-12 21:11:25,301 - INFO - Transaction check succeeded.
2024-07-12 21:11:25,301 - INFO - Running transaction test
2024-07-12 21:11:25,302 - INFO - The downloaded packages were saved in cache until the next successful transaction.
2024-07-12 21:11:25,302 - INFO - You can remove cached packages by executing 'dnf clean packages'.
2024-07-12 21:11:25,302 - INFO - STDERR:
2024-07-12 21:11:25,302 - INFO - No matches found for the following disable plugin patterns: subscription-manager
2024-07-12 21:11:25,302 - INFO - Repository extras is listed more than once in the configuration
2024-07-12 21:11:25,302 - INFO - Repository extras-source is listed more than once in the configuration
2024-07-12 21:11:25,302 - INFO - Warning: Package marked by Leapp to upgrade not found in repositories metadata: gpg-pubkey
2024-07-12 21:11:25,302 - INFO - RPM: warning: Generating 6 missing index(es), please wait...
2024-07-12 21:11:25,302 - INFO - Error: Transaction test error:
2024-07-12 21:11:25,302 - INFO - installing package kernel-modules-4.18.0-553.8.1.el8_10.x86_64 needs 4MB on the / filesystem
2024-07-12 21:11:25,302 - INFO - installing package libsecret-0.18.6-1.el8.x86_64 needs 5MB on the / filesystem
2024-07-12 21:11:25,302 - INFO - installing package pinentry-1.1.0-2.el8.x86_64 needs 5MB on the / filesystem
....

and this is the last bit of the log file:
...
2024-07-12 21:11:25,445 - INFO - installing package elfutils-libs-0.190-2.el8.i686 needs 419MB on the / filesystem
2024-07-12 21:11:25,445 - INFO - installing package libstdc++-8.5.0-22.el8_10.i686 needs 420MB on the / filesystem
2024-07-12 21:11:25,445 - INFO - installing package libattr-2.4.48-3.el8.i686 needs 420MB on the / filesystem
2024-07-12 21:11:25,445 - INFO - installing package pcre-8.42-6.el8.i686 needs 421MB on the / filesystem
2024-07-12 21:11:25,445 - INFO - installing package nss-softokn-freebl-3.90.0-7.el8_10.i686 needs 422MB on the / filesystem
2024-07-12 21:11:25,445 - INFO - Error Summary
2024-07-12 21:11:25,445 - INFO - -------------
2024-07-12 21:11:25,445 - INFO - Disk Requirements:
2024-07-12 21:11:25,445 - INFO - At least 567MB more space needed on the / filesystem.
2024-07-12 21:11:25,445 - INFO - ============================================================
2024-07-12 21:11:25,445 - INFO - END OF ERRORS
2024-07-12 21:11:25,445 - INFO - ============================================================
2024-07-12 21:11:25,445 - INFO - Debug output written to /var/log/leapp/leapp-upgrade.log
2024-07-12 21:11:25,445 - INFO - ============================================================
2024-07-12 21:11:25,446 - INFO - REPORT
2024-07-12 21:11:25,446 - INFO - ============================================================
2024-07-12 21:11:25,446 - INFO - A report has been generated at /var/log/leapp/leapp-report.json
2024-07-12 21:11:25,446 - INFO - A report has been generated at /var/log/leapp/leapp-report.txt
2024-07-12 21:11:25,446 - INFO - ============================================================
2024-07-12 21:11:25,446 - INFO - END OF REPORT
2024-07-12 21:11:25,446 - INFO - ============================================================
2024-07-12 21:11:25,446 - INFO - Answerfile has been generated at /var/log/leapp/answerfile
2024-07-12 21:11:25,467 - ERROR - Command ['/usr/bin/leapp', 'upgrade'] failed with return code 1
2024-07-12 21:11:25,468 - ERROR - Failed: doing the conversion. The reason: Command '['/usr/bin/leapp', 'upgrade']' returned non-zero exit status 1.
2024-07-12 21:11:25,745 - DEBUG - Going to write json '/usr/local/psa/var/centos2alma/actions.json' with new data

**************************************************************************************
The dist-ugrade process has failed. See the /var/log/plesk/centos2alma.log file for more information.
The last 100 lines of the file are shown above.
For assistance, call 'centos2alma --prepare-feedback' and follow the instructions.
To revert the server to its original state, call 'centos2alma --revert'.
**************************************************************************************
...

Here's my disk status before the conversion attempt:
# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 3.9G 9.1M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/mapper/centos-root 118G 101G 17G 86% /
/dev/vda1 497M 216M 281M 44% /boot
tmpfs 781M 0 781M 0% /run/user/0

I see that other people report a similar problem, but I could not find answers that could resolve it, hence my new post.
 
What's the output of df? I mean df as it comes by default (with the -T option) so that it also shows the number of occupied and available blocks?
 
Hi, here's the result:

# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
devtmpfs devtmpfs 3983000 0 3983000 0% /dev
tmpfs tmpfs 3994788 0 3994788 0% /dev/shm
tmpfs tmpfs 3994788 17480 3977308 1% /run
tmpfs tmpfs 3994788 0 3994788 0% /sys/fs/cgroup
/dev/mapper/centos-root xfs 123205632 105724956 17480676 86% /
/dev/vda1 xfs 508588 220916 287672 44% /boot
tmpfs tmpfs 798960 0 798960 0% /run/user/0
 
Sorry, more readable
Code:
Filesystem              Type     1K-blocks      Used Available Use% Mounted on
devtmpfs                devtmpfs   3983000         0   3983000   0% /dev
tmpfs                   tmpfs      3994788         0   3994788   0% /dev/shm
tmpfs                   tmpfs      3994788     17480   3977308   1% /run
tmpfs                   tmpfs      3994788         0   3994788   0% /sys/fs/cgroup
/dev/mapper/centos-root xfs      123205632 105724956  17480676  86% /
/dev/vda1               xfs         508588    220916    287672  44% /boot
tmpfs                   tmpfs       798960         0    798960   0% /run/user/0
 
Thank you, no problem there. probably an issue with the virtualization environment as in other cases. You may obtain help from your provider in this case.
 
In the end I succeeded by using the command "export LEAPP_OVL_SIZE=4096" before the script execution.
At the end of the conversion, though, the apache/nginx configuration files contained errors (ex:
Error: New configuration files for the Apache web server were not created due to the errors in configuration templates: nginx: [emerg] open() "/etc/nginx/plesk.conf.d/vhosts/domain.com.conf" failed (2: No such file or directory) in /etc/nginx/conf.d/zz010_psa_nginx.conf:7 nginx: configuration file /etc/nginx/nginx.conf test failed.)

I had to try a few fixing iterations within the Web Configurations Troubleshooter after having deleted the conf file of an old domain no longer listed among my websites. All in all a rather scaring experience, but I am happy with the result.

In the hope this will help somebody else make a smoother conversion.
 
We had to "# plesk repair web" after each migration, too. Else the setup was just no right and Apache for unknown reasons could not attach to Nginx although it was presumably listening on the right port.
 
Back
Top