Forums

Resolved
0 votes
In the past, ClearOS made a number of changes to the stock CentOS/RHEL code in order to support several technologies that required kernel modifications. This was in support of several features that were needed in the network stack and elsewhere where RHEL didn't have any solutions. Over time this number has diminished and we are down to the last one.

A current kernel change is implemented in ClearOS today that facilitates QoS on the inbound traffic lane. This is something that Linus Torvalds has consistently rejected in kernel space for a long time but we have used it successfully and solidly on ClearOS for many years. With the recent improvements in the modules that we use to facilitate other apps, there appears to be a mechanism where we can facilitate QoS on the inbound network lane without a kernel modification. What this gets us is the ability to merge back to the stock CentOS/RHEL kernel for ClearOS.

Sometime after the release of ClearOS 7.4 we will be engaging in the cut-over of the QoS app to this new method and adopting the upstream kernel. This will need a fair amount of testing and we will be running extended tests internally, publicly with the ClearOS Testing repos (voluntary pre-testing), testing with the ClearOS Community, and finally landing the QoS changes with the Home and Business users. Watch for instructions to follow.

What this gives us is broad 3rd party compatibility with drivers that are built against Redhat/CentOS specifically as our ABI will now match theirs.
Saturday, September 02 2017, 02:21 PM
Share this post:
Responses (6)
  • Accepted Answer

    Friday, February 23 2018, 12:48 PM - #Permalink
    Resolved
    0 votes
    In one of our meetings yesterday we talked about the kernel move and decided to focus on working on this innovation for ClearOS 8.x. Logistically there is no problem with introducing this on new installs but on existing installs there could be issues moving someone in this manner if they are using drivers compiled under the older ABI.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 27 2017, 12:17 AM - #Permalink
    Resolved
    0 votes
    This work is coming along well. Thanks Nick and Tony for the help and suggestions.

    We will start this beta once the 7.4 updates are over and done with.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 13 2017, 11:01 PM - #Permalink
    Resolved
    0 votes
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 06 2017, 07:11 AM - #Permalink
    Resolved
    0 votes
    Hi Tony,

    Funny you post this. After I made my post I had a similar dawning and I contacted the devs about it yesterday evening and they are now "chewing the cud"/"kicking the can around".

    re my rpm's, they are the same versions as the kmod ones so even if you installed the kmod repo they would not install automatically, but I think you could script it easily (rpm -qa | grep kmod.*njh piped into a yum reinstall somehow or even leave out the njh bit to pick up anyones)

    I have a feeling my rpm's won't stop a newer kernel installing. I also have a feeling that once the new kernel has installed you can at any time install a vanilla kmod rpm so everything is in place when you reboot, but this needs to be tested.

    Unfortunately there is no knowing who has installed my drivers. it could easily be Business customers who have popped into the forums doing some self-support or ones who have migrated from Community to a paid version, and I suspect there are many Community users who don't visit the forums either.

    The question of selecting kernels on boot up was also mentioned.

    I guess it is a "watch this space".
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, September 06 2017, 01:39 AM - #Permalink
    Resolved
    0 votes
    Same here for anybody using my kmod drivers - though as I haven't specifically advertised them for some time so not sure anybody is still using any. This does not affect none kmod rpms such as sarg...

    Think about the implications of what Nick has just posted. If you are relying on a kmod driver for internet access - the old driver will break when you install the upstream kernel rpm for 7.4... You need to update the driver(s) to the one(s) from ElRepo at that precise time. So a wise move would be to download the ElRepo kmod driver(s) BEFORE you upgrade to the upstream kernel, then you can remove the old kmod drivers and install the ElRepo ones as soon as the kernel is upgraded. *** Not sure how Nick did his kmod rpm versions - wouldn't advise relying on yum to decide the ElRepo versions are newer and thus automatically updating the kmod drivers concurrently with the upstream kernel update, unless...

    The ClearOS team are clearly not responsible for updating any none ClearOS supplied drivers that we may have installed - but maybe they will surprise us and address this issue with more than the warning above :D

    *** there might even be a problem installing the new kernel while the old kmod rpms are installed? If this is the case, the old kmod drivers will have to be removed, install the new kernel that was previously downloaded, then install the previously downloaded kmod drivers - testing when the time comes will confirm the best method - all speculation at this time

    Another consideration will be failing back to an older kernel after the new downstream kernel is up and running with ElRepo kmod drivers. We then have the reverse situation of the old ClearOS kernels not working with the now currently installed ElRepo kmod drivers. Burning bridges behind us :p

    Tony... http://www.sraellis.tk/
    The reply is currently minimized Show
  • Accepted Answer

    Monday, September 04 2017, 06:10 PM - #Permalink
    Resolved
    0 votes
    Please note that this change will also affect anyone using my kmod drivers which will not be compatible with the new kernel and I will cease to compile them. Instead you will be able to install them directly from the ElRepo repo or from any of their download mirrors.

    Also it means you should be able to use any of the ElRepo kernels if you require features which have not been backported from the latest kernels.
    The reply is currently minimized Show
Your Reply