CloudLinux OS Blog - CloudLinux OS 7.7 released
CloudLinux OS Blog

Featured 

CloudLinux OS 7.7 released

b2ap3_large_CL__20190903-134138_1

Updated: September 4, 2019, 2:32 AM Pacific Timezone

You can find issue description and solution here: https://www.cloudlinux.com/cloudlinux-os-blog/entry/issues-with-cloudlinux-os-7-7-update-on-systems-with-kernel-v3-10-0-862-or-lower.

We’re excited to let you know about the release of the new CloudLinux OS 7.7 which is based on the Red Hat Enterprise Linux 7.7.

How to update

To update your server to CloudLinux OS 7.7, run the following commands:

$ yum clean all $ yum upgrade $ reboot

To convert from CentOS to CloudLinux, you can use the updated cldeploy script from the https://repo.cloudlinux.com/cloudlinux/sources/cln/cldeploy.

Important note

The new iproute-4.11.0-25.el7 package is not compatible with kernels lower than 3.10.0-862. You may need to add iproute to the exclude section in the /etc/yum.conf file if your system is running such kernel and yum conflict arises.
Your system will boot without networking if you will try to use a kernel lower than 3.10.0-862 with the new iproute version.

ATTENTION! If the control panel asks you to reboot the server after the update, and you use the kernel lower than 3.10.0-862, please do not proceed with the reboot. It is very likely that the networking will go down. Instead, just revert the recent yum update transaction.

We are working on a different approach to the update, so it won't affect the older kernels in that way. We will update this post as soon as we have any news.

UPDATE: The compatibility issues have been resolved in the latest iproute release. Please follow this post for further instructions: https://www.cloudlinux.com/cloudlinux-os-blog/entry/issues-with-cloudlinux-os-7-7-update-on-systems-with-kernel-v3-10-0-862-or-lower

Changelog

You can find the full RHEL 7.7 release notes here: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.7_release_notes/index.

Beta: Alt-PHP updated
Beta: CageFS updated
 

Comments 14

Guest - Andre on Tuesday, 03 September 2019 15:43

will updating the iproute package on an old kernel give immediate errors or only after reboot?

will updating the iproute package on an old kernel give immediate errors or only after reboot?
Inessa Atmachian on Tuesday, 03 September 2019 18:29

Hi Andre,

If you have an old kernel, then yum conflict arises. If you have an old and a new kernel, then your system will boot without networking if you will try to use the old kernel but iproute will not arise conflict.

Hi Andre, If you have an old kernel, then yum conflict arises. If you have an old and a new kernel, then your system will boot without networking if you will try to use the old kernel but iproute will not arise conflict.
Guest - Client on Tuesday, 03 September 2019 19:27

It is possible downgrade iproute?

It is possible downgrade iproute?
Guest - Ryan Smith on Tuesday, 03 September 2019 19:47

cPanel overwrites the /etc/yum.conf file daily. Is it possible to make the exclude of iproute permanent aside from making the /etc/yum.conf file immutable?

cPanel overwrites the /etc/yum.conf file daily. Is it possible to make the exclude of iproute permanent aside from making the /etc/yum.conf file immutable?
Guest - Dave on Wednesday, 04 September 2019 01:17

My server did yum update before this post was even written and has an older kernel
I now have no networking - and as it is in AWS, I cant do anything except alter files on the disk while it is attached to a rescue instance

When the server boots without networking - is there a way to get networking going.
Can I override configs to make it work?

Also I can confirm that

"If you have an old kernel, then yum conflict arises."
Is not the case - my kernel is old and yum did not conflict it succeeded and I lost networking on reboot.

and

"If you have an old and a new kernel, then your system will boot without networking"
Is also not the case - I do NOT also have a newer kernel and it did boot without networking.

My server did yum update before this post was even written and has an older kernel I now have no networking - and as it is in AWS, I cant do anything except alter files on the disk while it is attached to a rescue instance When the server boots without networking - is there a way to get networking going. Can I override configs to make it work? Also I can confirm that "If you have an old kernel, then yum conflict arises." Is not the case - my kernel is old and yum did not conflict it succeeded and I lost networking on reboot. and "If you have an old and a new kernel, then your system will boot without networking" Is also not the case - I do NOT also have a newer kernel and it did boot without networking.
Guest - Hamid Tavakoli on Wednesday, 04 September 2019 05:06

This issue wastes almost my whole day today. And I am still fixing this issue in the safe mode. I have both kernel care and clould Linux . This is not acceptable

This issue wastes almost my whole day today. And I am still fixing this issue in the safe mode. I have both kernel care and clould Linux . This is not acceptable
Guest - aziz on Wednesday, 04 September 2019 06:30

Had same problem had to revert our /root and /boot partitions back to few days old backup and sync everything again. Cant have downtime more than 2 hours already in the day time. Had to sort it out fast. I advise rest of you do the same. We tried to use Cloudlinux DVD to revert kernel to old version but that didnt work even wiped grub and still nothing. Hence backup may be only option unless someone knows a different method?

Had same problem had to revert our /root and /boot partitions back to few days old backup and sync everything again. Cant have downtime more than 2 hours already in the day time. Had to sort it out fast. I advise rest of you do the same. We tried to use Cloudlinux DVD to revert kernel to old version but that didnt work even wiped grub and still nothing. Hence backup may be only option unless someone knows a different method?
Guest - Dave on Wednesday, 04 September 2019 06:34

Ive been down all day since 2:19am and its now 4:30pm (Thats 14 hours)

I suspect that this has created quite a lot of issues as the Cloud Linux Support Team's response was quick this morning and now im getting very slow replies with minimal information.

pushing our updates with compatibly issues that are known to brick servers is not exactly the smartest way forward.
The thing is that this update was applied automatically - so I never even had the opportunity to decline it or revert it.

If you have automatic updates - and your not already dead in the water - turn them off.

Ive been down all day since 2:19am and its now 4:30pm (Thats 14 hours) I suspect that this has created quite a lot of issues as the Cloud Linux Support Team's response was quick this morning and now im getting very slow replies with minimal information. pushing our updates with compatibly issues that are known to brick servers is not exactly the smartest way forward. The thing is that this update was applied automatically - so I never even had the opportunity to decline it or revert it. If you have automatic updates - and your not already dead in the water - turn them off.
Dmitriy Serafin on Wednesday, 04 September 2019 06:43

Hello everyone,

Here is a brief update from the CloudLinux team. Right now we are working on a hotfix for all servers, that could potentially have the networking disabled after the reboot. It will be released later today so that it won't be necessary to make downgrades.

I hope my answers below will prove useful to you; we'll also keep you posted in the blog post itself.
> It is possible downgrade iproute?
Sure, it's possible to revert the recent yum transaction right away. However, we recommend keeping the updates, as the hotfix is already on its way. You will need to simply run the `yum update` as soon as the update for the iproute package is available.

> cPanel overwrites the /etc/yum.conf file daily. Is it possible to make the exclude of iproute permanent aside from making the /etc/yum.conf file immutable?
Based on the information we have, cPanel doesn't rewrite that file so you could exclude any package you wish. However, that won't be necessary very soon.

> Is not the case - my kernel is old and yum did not conflict it succeeded and I lost networking on reboot.
There is a way to 'protect' users who use the older kernel from the impact that iproute has on the networking, and it was implemented in this release. To our deepest regret, that wasn't enough, and it didn't work to its full extent. We're still looking into that to make sure that this situation won't happen ever again.

> This issue wastes almost my whole day today. And I am still fixing this issue in the safe mode. I have both kernel care and clould Linux . This is not acceptable
> Had same problem had to revert our /root and /boot partitions back to few days old backup and sync everything again.
On behalf of the entire CloudLinux team, I sincerely apologize for this incident. This is not an acceptable way to handle the updates, and this is something we intend to fix very soon.

Hello everyone, Here is a brief update from the CloudLinux team. Right now we are working on a hotfix for all servers, that could potentially have the networking disabled after the reboot. It will be released later today so that it won't be necessary to make downgrades. I hope my answers below will prove useful to you; we'll also keep you posted in the blog post itself. > It is possible downgrade iproute? Sure, it's possible to revert the recent yum transaction right away. However, we recommend keeping the updates, as the hotfix is already on its way. You will need to simply run the `yum update` as soon as the update for the iproute package is available. > cPanel overwrites the /etc/yum.conf file daily. Is it possible to make the exclude of iproute permanent aside from making the /etc/yum.conf file immutable? Based on the information we have, cPanel doesn't rewrite that file so you could exclude any package you wish. However, that won't be necessary very soon. > Is not the case - my kernel is old and yum did not conflict it succeeded and I lost networking on reboot. There is a way to 'protect' users who use the older kernel from the impact that iproute has on the networking, and it was implemented in this release. To our deepest regret, that wasn't enough, and it didn't work to its full extent. We're still looking into that to make sure that this situation won't happen ever again. > This issue wastes almost my whole day today. And I am still fixing this issue in the safe mode. I have both kernel care and clould Linux . This is not acceptable > Had same problem had to revert our /root and /boot partitions back to few days old backup and sync everything again. On behalf of the entire CloudLinux team, I sincerely apologize for this incident. This is not an acceptable way to handle the updates, and this is something we intend to fix very soon.
Guest - Chris on Wednesday, 04 September 2019 07:23

We were also impacted by this issue. Although, it wasn't apparent as to what the issue was at first.

We contacted our VPS provider and they mentioned everything was fine on their side, something within our server was preventing our networking to come up.

We tried restoring from backups, but no good.

We only had a few hours notice from CloudLinux that we need to be at 3.10.0-962. However, I could imagine a lot of people are not due to using KernelCare.

We didn't have an adequate kernel on the server. Our VPS provider assisted with getting a new kernel installed via recovery.

This resulted in 5-6 hours of downtime for us.

It's crazy to push an update that can cut off all networking capabilities and provide only a few hours notice!

We were also impacted by this issue. Although, it wasn't apparent as to what the issue was at first. We contacted our VPS provider and they mentioned everything was fine on their side, something within our server was preventing our networking to come up. We tried restoring from backups, but no good. We only had a few hours notice from CloudLinux that we need to be at 3.10.0-962. However, I could imagine a lot of people are not due to using KernelCare. We didn't have an adequate kernel on the server. Our VPS provider assisted with getting a new kernel installed via recovery. This resulted in 5-6 hours of downtime for us. It's crazy to push an update that can cut off all networking capabilities and provide only a few hours notice!
Already Registered? Login Here
Guest
Thursday, 14 November 2019

Captcha Image