lve-utils conflicts with ea-apache24-mod_lsapi

[jndawson]

We are setting up a new whm box (CentOS7, whm 86.0.4) and installed CloudLinux after getting whm/cpanel configured. This error popped up:

Error: lve-utils conflicts with ea-apache24-mod_lsapi-1.1-36.37.11.cpanel.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Neither suggested fix worked.

Do we need to uninstall ea-apache24-mod_lsapi-1.1-36.37.11.cpanel.x86_64 and rebuild CloudLinux? Or is there an easier way?

Also, shouldn't this be an automatic check in the makefile?

 

[jndawson]

We removed ea-apache24-mod_lsapi-1.1-36.37.11.cpanel.x86_64 and reinstalled CloudLinux without the same errors. However, we got these:

Switching to "cloudlinux-default" profile
error opening /boot/grub/grub.cfg for read: No such file or directory

[WARNING]    /etc/grub2.cfg is not a link
[WARNING]    /etc/grub2.cfg points to the wrong file instead of /boot/grub2/grub.cfg
[WARNING]    Kernel 3.10.0-962.3.2.lve1.5.28.el7.x86_64 GRUB entry is missing
[ERROR]    Kernel 3.10.0-962.3.2.lve1.5.28.el7.x86_64 initramfs GRUB entry is missing and cannot be automatically added due to unknown reasons, please fix GRUB config manually
error: clcommon: get_lve_version: Can`t open file /proc/lve/list

How debilitating is this?

 

[jndawson]

In order to convert to CloudLinux, we removed ea-apache24-mod_lsapi-1.1-36.37.11.cpanel.x86_64 via WHM > EasyApache4.

Then, we went to 'Customize' the EA4 profile to add back in mod_lsapi.

We can not edit the profile.

Selecting 'Customize' returns to the same main EasyApache4 page.

Tried to save our functioning configuration as a profile, which went as expected, but we can't Cusomize that one, either.

What is broken and how do we fix it?

 

[jndawson]

Also, this happens:

!!!Important: Memory limits are disabled by default.
To enable memory limits, please run:
# lvectl ubc enable --save
Ignore error message that you will receive.
[ Tue Feb 18 16:35:10 ]
[ [email protected] ~># lvectl ubc enable --save
error: clcommon: get_lve_version: Can`t open file /proc/lve/list
[ Tue Feb 18 16:35:41 ]
[ [email protected] ~># ls -l /proc/lve/list
ls: cannot access /proc/lve/list: No such file or directory

The last CloudLinux install went much smoother than this.

 

[CloudLinux Skhristich]

Also, this happens:

!!!Important: Memory limits are disabled by default.
To enable memory limits, please run:
# lvectl ubc enable --save
Ignore error message that you will receive.
[ Tue Feb 18 16:35:10 ]
[ [email protected] ~># lvectl ubc enable --save
error: clcommon: get_lve_version: Can`t open file /proc/lve/list
[ Tue Feb 18 16:35:41 ]
[ [email protected] ~># ls -l /proc/lve/list
ls: cannot access /proc/lve/list: No such file or directory

The last CloudLinux install went much smoother than this.

Hello,
To help you with this question we need a little bit more information, please create a ticket here https://cloudlinux.zendesk.com/hc/en-us/requests/new and technical experts will help you asap.
Thank you

 

[jndawson]

Followup (we opened ticket #93452284 after not finding anything anywhere that explained the issue):

cPanel techs took a look and responded:

I was able to determine that the issue was due to the wrong EasyApache 4 repository being utilized. The CloudLinux repository for EasyApache 4 was missing, resulting in the default cPanel EasyApache 4 repository being used. The mod_lsapi in cPanel's EA4 repository isn't identical to the one in CloudLinux's repository and would result in conflicts.

That was pretty clear when we discovered the issue, but we still don't know what or why it happened. The fix was to run:

# wget https://repo.cloudlinux.com/cloudlinux/sources/cloudlinux_ea3_to_ea4
# sh cloudlinux_ea3_to_ea4 --convert

Which worked, and CloudLinux got installed. However, the bootloader was still loading the CentOS7 kernel.

After another day of investigating, the CL tech, working under (another) ticket #93452307, responded:

I've fixed it and reinstalled the kernel. I've created a symlink from /etc/grub2.cfg to /boot/grub/grub2.cfg

So, now the kernel loads and everything else seems to be functioning.

Again, no reason why or how it happened, but the tech provided this:

It may be related to an individual configuration, but the symlink was created incorrectly.

Not sure what individual configuration may have made the change as the entire installation was brand new and out-of-the-box. We're assuming that somebody will decide if this is worth opening a case.

 

[cPanelLauren]

It sounds like there was an installation problem when installing CloudLinux where not only was the repo not modified but the symlink wasn't either. Are there any errors noted in the CloudLinux related logs or system logs? /var/log/cloud-init.log possibly? I've seen a couple of times where the issue is exclusions in the yum conf or inability to connect to the CL licensing servers.

 

[jndawson]

It sounds like there was an installation problem when installing CloudLinux where not only was the repo not modified but the symlink wasn't either. Are there any errors noted in the CloudLinux related logs or system logs? /var/log/cloud-init.log possibly? I've seen a couple of times where the issue is exclusions in the yum conf or inability to connect to the CL licensing servers.

There is no /var/log/cloud-init.log, However, the /var/log/cldeploy.log exists and there were lots of yum issues logged:

mv: cannot stat '/etc/yum.repos.d/RedHat-Base.repo': No such file or directory
Loaded plugins: fastestmirror, universal-hooks
No Match for argument: rhnlib
No Packages marked for removal
Loaded plugins: fastestmirror, universal-hooks
No Packages marked for removal
mv: cannot stat '/etc/yum.repos.d/CentOS-AppStream.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Extras.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-PowerTools.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-centosplus.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-AppStream.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-Base.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-Debuginfo.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-Extras.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-Media.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-PowerTools.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-Sources.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-Vault.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/CentOS-Stream-centosplus.repo': No such file or directory
warning: /etc/yum/vars/contentdir saved as /etc/yum/vars/contentdir.rpmsave
warning: file /etc/yum.repos.d/CentOS-fasttrack.repo: remove failed: No such file or directory
warning: file /etc/yum.repos.d/CentOS-Vault.repo: remove failed: No such file or directory
warning: file /etc/yum.repos.d/CentOS-Sources.repo: remove failed: No such file or directory
warning: file /etc/yum.repos.d/CentOS-Media.repo: remove failed: No such file or directory
warning: file /etc/yum.repos.d/CentOS-Debuginfo.repo: remove failed: No such file or directory
warning: file /etc/yum.repos.d/CentOS-CR.repo: remove failed: No such file or directory
warning: file /etc/yum.repos.d/CentOS-Base.repo: remove failed: No such file or directory
error: package centos-release-notes is not installed
error: package redhat-logos is not installed
mv: cannot stat '/etc/yum.repos.d/sl.repo': No such file or directory
mv: cannot stat '/etc/yum.repos.d/cd.repo': No such file or directory
error: package sl-release is not installed
error: package sl-release-notes is not installed

And

Error: lve-utils conflicts with ea-apache24-mod_lsapi-1.1-36.37.11.cpanel.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Keep in mind this is a new installation on a new server. We installed Centos7, ran yum update, installed WHMv84, ran the update to v86 via WHM, installed CloudLinux via WHM. The issue seems to be somewhere in the installation scripts.

 

[jndawson]

So, guess what? We're installing a new cloudlinux box and the same thing is happening regarding the EA4 issue. At some point, whoever it is that creates the install scripts will figure it out.

 

[cPanelLauren]

So that's definitely going to conflict if CloudLinux doesn't properly remove the EA4 repo. They use their own REPO for EA4 related stuff. If you'd already installed mod_lsapi from our ea4 repo then installed cloudlinux it wouldn't be surprising.

Those errors you see are CloudLinux trying to remove repositories that may conflict - since they don't exist it can't remove them.

 

[jndawson]

And now the grub loader still insists on loading centos instead of cloudlinux, even though somebody fixed the symlink creation in the setup script. We'll see what the CL techs have to say this time.

 

[CloudLinux Skhristich]

And now the grub loader still insists on loading centos instead of cloudlinux, even though somebody fixed the symlink creation in the setup script. We'll see what the CL techs have to say this time.

Hello,
Please specify, did you open a ticket to the CloudLinux technical support service?

 

[jndawson]

Cpanel tech took a look:

I noticed CloudLinux was actually running, and the LVE kernel was in place:

[16:59:50 cp4 [email protected] ~]cPs# uname -a
Linux cp4.ipns.com 3.10.0-962.3.2.lve1.5.32.el7.x86_64 #1 SMP Fri Feb 28 07:18:51 EST 2020 x86_64 x86_64 x86_64 GNU/Linux

However, I saw that the WHM banner still said "Centos". The file for this hadn't yet updated, so I moved it aside and regenerated it to fix that.

[17:03:20 cp4 [email protected] ~]cPs# cat /var/cpanel/sysinfo.config
# This values in this file are calculated and updated if necessary nightly. If you wish to override
# these values, populate lock= with a comma delimited list of keys you don't want updated.
# This will allow you to change those values to suit your needs.
#
# Example: if you set lock like this, then rpm_dist and rpm_arch will not be updated nightly:
# lock=rpm_dist,rpm_arch
#
ises=2
lock=
release=7.7
rpm_arch=x86_64
rpm_dist=centos
rpm_dist_ver=7
[17:03:27 cp4 [email protected] ~]cPs# mv /var/cpanel/sysinfo.config{,.1} -v && /scripts/gensysinfo
‘/var/cpanel/sysinfo.config’ -> ‘/var/cpanel/sysinfo.config.1’
[17:03:36 cp4 [email protected] ~]cPs# cat /var/cpanel/sysinfo.config
# This values in this file are calculated and updated if necessary nightly. If you wish to override
# these values, populate lock= with a comma delimited list of keys you don't want updated.
# This will allow you to change those values to suit your needs.
#
# Example: if you set lock like this, then rpm_dist and rpm_arch will not be updated nightly:
# lock=rpm_dist,rpm_arch
#
ises=2
lock=
release=7.7
rpm_arch=x86_64
rpm_dist=cloudlinux
rpm_dist_ver=7

 

[cPanelLauren]

As far as I am aware when you install CloudLinux this file should be regenerated - is that still the case @CloudLinux Skhristich ?

 

[CloudLinux Skhristich]

Hello,
Yes, according to the deploy script, a new config should be generated:

generate_sysinfo_cpanel() {
    if [ -e /scripts/gensysinfo ]; then
        rm -f /var/cpanel/sysinfo.config
        /scripts/gensysinfo
        generate_sysinfo_cpanel
                generate_sysinfo_cpanel