[CentOS-devel] Balancing the needs around the RHEL platform

Wed Dec 30 10:55:33 UTC 2020
Ljubomir Ljubojevic <centos at plnet.rs>

On 12/30/20 9:47 AM, Nico Kadel-Garcia wrote:
> On Tue, Dec 29, 2020 at 7:04 AM Phil Perry <pperry at elrepo.org> wrote:
>> On 28/12/2020 23:32, Lamar Owen wrote:
>>> Will Stream cut it for me?  One issue that keeps getting glossed over is
>>> that many drivers that are already in-kernel, not 3rd party, but
>>> disabled by Red Hat, still have users who need them.  ELrepo and others
>>> have provided support at the "point release" milestones for these
>>> "unsupported" drivers; it really looks like Stream will break this hard.
>>> For instance, I need megaraid_sas for my servers; that's not a 3rd party
>>> binary driver, but is already in-kernel; it is intentionally not built
>>> by Red Hat.  ELrepo rebuilds this AND most importantly provides a
>>> working driver disk for installs; I just don't see Red Hat providing
>>> these drivers, even in a SIG, for hardware they have already decided is
>>> "unsupported "; but I always reserve the right to be wrong.
>> Hi Lamar,
>> Unfortunately there's an issue with driver disk ISO images too, as they
>> are based on point release GA kernels (as are most all OEM ISO driver
>> disks), and Stream regularly releases new installation media based on
>> the latest Stream kernel, so if you need a 3rd party driver disk to
>> install, you are probably out of luck and may not even be able to
>> install CentOS Stream, even if a driver were available. I'm guessing for
>> the next year you could install CentOS Linux 8 and convert to Stream,
>> but after 2021 that will no longer be an option.
> He should also consider finding a more reputable hardware vendor.
> Those so-called "megaraid" chipsets were abominable monstrosities and
> there were a number of extremely poorly written vendor kernel hacks
> supporting them.
> Why wouldn't installing from CentOS 8.3 and updating to CentOS Stream
> be an option? The yum repos are well defined, in well-defined RPMs.
> And an add-on internal RPM to point to a locked internal repository to
> provide a "base OS imae" snapshot is a commonplace practice for EPEL,
> one I've used effectively myself to lock the "update" channels from
> RHEL and CentOS for consistency in cluster deployment. The approach
> costs time and effort to set up, and some internal resources, but it
> provides much faster "yum update" or "yum check-update" operations
> than always reaching out to the central repos. It's also very useful
> when you need to rebuild or update 200 cluster members simultaneously,
> and the yum metadata alone will overwhelm your external bandwidth.
> _______________________________________________

And dozens or hundreds of thousands of regular users with need for 3rd
party drivers and no time and/or money for carefully maintained internal

Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant