[FIXED] Issues with CentOS7 OVH kernel

aljaxus

New Member
Jul 6, 2019
15
8
3
Them Interwebz
aljaxus.eu
Hello

I am having some quite severe-looking issues with some dedicated box I have. I am asking (also) here because I am quite frustraded since this never happened to me.
I have CentOS7 installed on this server - hosted at OVH, with their kernel in use.
After running `yum update` all packages are downloaded successfully, but when running the transaction test I get an transaction check error about OVH kernel(-s) packages conflicting with each other.
Code:
Transaction check error:
  file /usr/include/asm-generic/..install.cmd conflicts between attempted installs of kernel-4.19-ovh-mod-std-ipv6-64-headers-4.19_ovh_mod_std_ipv6_64-837149.x86_64 and kernel-4.19-ovh-xxxx-std-ipv6-64-headers-4.19_ovh_xxxx_std_ipv6_64-837149.x86_64
  file /usr/include/asm/..install.cmd conflicts between attempted installs of kernel-4.19-ovh-mod-std-ipv6-64-headers-4.19_ovh_mod_std_ipv6_64-837149.x86_64 and kernel-4.19-ovh-xxxx-std-ipv6-64-headers-4.19_ovh_xxxx_std_ipv6_64-837149.x86_64
  file /usr/include/drm/..install.cmd conflicts between attempted installs of kernel-4.19-ovh-mod-std-ipv6-64-headers-4.19_ovh_mod_std_ipv6_64-837149.x86_64 and kernel-4.19-ovh-xxxx-std-ipv6-64-headers-4.19_ovh_xxxx_std_ipv6_64-837149.x86_64
  file /usr/include/linux/..install.cmd conflicts between attempted installs of kernel-4.19-ovh-mod-std-ipv6-64-headers-4.19_ovh_mod_std_ipv6_64-837149.x86_64 and kernel-4.19-ovh-xxxx-std-ipv6-64-headers-4.19_ovh_xxxx_std_ipv6_64-837149.x86_64
... ... ...

I've searched for any solutions for over a few days and I wasn't able to find any.
I would really appreciate any help or any clues whatsoever.
 

RTM

Active Member
Jan 26, 2014
554
194
43
First of all, you probably don't need to bump a thread that is already at the top of a subforum, it's a little redundant ;)

I don't know that much about these transaction tests, but I suppose you could try removing old kernels (the ones not in use at the moment) that may be in conflict, perhaps with a bit of luck that'll solve your issues.

Another suggestion, could be to not use the OVH kernel, can you install a CentOS original kernel?
Similarly, perhaps you can get rid of OVH's CentOS install entirely by copying over a fresh basic install, I have done the same on servers delivered by Hetzner via a rescue system.

Finally, have you tried asking OVH?
 

aljaxus

New Member
Jul 6, 2019
15
8
3
Them Interwebz
aljaxus.eu
First of all, you probably don't need to bump a thread that is already at the top of a subforum, it's a little redundant ;)
Yeah, true.

Finally, have you tried asking OVH?
Well it's actually SoYouStart - so now you can go and "predict" what type of support we got..
Code:
I'm sorry for the big delay. We can't handle with software issues, this would
exceed the support-frame. But ports are open now and the system seems to be
started. In case of kernel-errors the usage of our netboot-kernels helps in
much cases.
The guy misunderstood the issue - it's not a problem booting up, it's a problem with updating.

Anyhow..
I don't know that much about these transaction tests, but I suppose you could try removing old kernels (the ones not in use at the moment) that may be in conflict, perhaps with a bit of luck that'll solve your issues.
This will probably do. As stated, this is the first time I'm having such issues so I was not going to experiment what *could* happen if I attempt to remove a kernel or something...

Thanks for replying. Though I haven't got any new info, your reply makes me feel a little less stressed afterall, so thank you a lot :)
 

RTM

Active Member
Jan 26, 2014
554
194
43
Fair enough, I've never really gotten why these hosting providers feel a need to provide updated kernels (bar very new and otherwise unsupported hardware) and other modifications to a supposed base install of an OS (as I recall Hetzner disables apparmor), i'd much rather have a default installation, that way you have normal "community" support and probably a more common configuration.

Anyway I can recommend Hetzner, they are also cheap (and will probably also not provide fantastic support), but at least I can confirm that they have a rescue environment, that'll allow you to install a clean OS (with some tricks of course).
 

aljaxus

New Member
Jul 6, 2019
15
8
3
Them Interwebz
aljaxus.eu
Fair enough, I've never really gotten why these hosting providers feel a need to provide updated kernels (bar very new and otherwise unsupported hardware) and other modifications to a supposed base install of an OS (as I recall Hetzner disables apparmor), i'd much rather have a default installation, that way you have normal "community" support and probably a more common configuration.

Anyway I can recommend Hetzner, they are also cheap (and will probably also not provide fantastic support), but at least I can confirm that they have a rescue environment, that'll allow you to install a clean OS (with some tricks of course).
Thanks. We're good with OVH, or better said SoYouStart, to be perfectly honest. You have
- secure boot (which is an essential thing)
- KVM console ("virtual monitor" over web)
- quite good infrastructure
And we have client sites on this machine, so we're not moving it any time soon.

Anyhow... Go figure, after few days of pulling hair I changed my search query from { insert any string you can think of } to "ovh kernel can not update" and guess what.. (link)

A few very simple commands...
Code:
# In case someone else comes to this issue and wants to copy these commands... DO NOT!
# Read the following post: https://forums.cpanel.net/threads/kernel-conflicts-on-ovh-servers-due-to-missing-exclude-line-in-etc-yum-repos-d-ovh-kernel-repo.654231/post-2673723
# Exclude the following packages in the OVH-kernel repository
echo "exclude=kernel-4.19-ovh-xxxx-std-ipv6-64-headers,kernel-4.19-ovh-xxxx-std-ipv6-64-hz1000-headers,kernel-4.19-ovh-mod-std-ipv6-64-headers" >> /etc/yum.repos.d/OVH-kernel.repo
# Update all packages
yum update -y
# Update the GRUB config to use the new kernel
grub2-mkconfig -o /boot/grub2/grub.cfg
# Reboot the box
reboot
So yeah... This was way too random for me - after searching the solid answer for a few days "I got it fixed" in less than 3 minutes.
@RTM Thanks for replying to this thread. I really do appreciate it.

Kind regards,
~ Aljaz