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.