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 repositories? -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant