On Thu, 31 Dec 2020 at 07:49, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Dec 30, 2020 at 12:42 PM Lamar Owen lowen@pari.edu wrote:
On 12/30/20 3:47 AM, Nico Kadel-Garcia wrote:
He should also consider finding a more reputable hardware vendor.
Hey Nico, I'm right here.... :-) Anyway, these servers are Dell. Dell isn't a reputable vendor these days?
I've not looked this year. They need careful attention to avoid changing parts or chipsets without notification and breaking compatibility with your current, stable kernel. They all do. It was why, when I did hardware evals, I made sure to get one of any new model we wanted to order, put it in my test rack, and keep it there for kernel and OS deployment testing.
In any case, it's a moot point, since I didn't pick these servers, the servers picked me (that is, they were donated to us, and, to modify an old saying in my area of the world, "never look a gift server in the RAID controller." (the original expression: "never look a gift horse in the mouth.")).
If they cost you that much work, consider buying modest Adaptec RAID controllers. MegaRAID had a bad habit of doing a lot of the RAID work
Adaptec controllers haven't existed as 'distinct' hardware since before 2010. Since then they have been rebranded controllers some of which are MegaRAID, LSI and other systems. For the years between 2010 and 2018, the Megaraid or LSI was a better bet than Adaptec.
in the kernel, not on the attached hardware, which was why the kernel modules were so critical. And the add-on drivers from the vendor were usually at least a year behind those in the current Red Hat kernel and were in fact a regression, as long as we stuck to a contemporary Red Hat release. RHEL or CentOS these days. I'm very surprised if you have hardware that actually needs that third-party driver, though it may take work to get the latest kernel into a bootable ISO or PXE image.
RHEL8 kernels no longer comes with the megaraid controller enabled thus you need the CentOS kernel. The third party module is just the one in the normal kernel compiled.
I have war stories about those drivers.
Those so-called "megaraid" chipsets were abominable monstrosities and there were a number of extremely poorly written vendor kernel hacks supporting them.
As mostly an end-user these days, I really couldn't care less what kind of hacks are required. I just know that we as a public charity were donated these servers to put to use; I intend to put them to use in the spirit of the US Internal Revenu Code Section 501(c)(3). They beat the two-generations-older Dell PowerEdge 1950s that they are replacing, which still use the same basic RAID chipset and have serious performance bottlenecks as KVM hosts with modern KVM.
Makes you wonder why someone gave them away?
I believe there was a US Tax benefit for companies if they traded out their hardware after 4 but before 8 years and donated their old hardware to charities. Since there was a lot of hardware being 'donated' most of the US charities only want to take items they can get extended warranties and parts from the manufacturer from.. so getting a donated Dell is better than a donated Supermicro.
Back to CentOS Stream. One of the CentOS kernel advantages was that Red Hat apparently did test suites across a wide variety of hardware before considering a kernel for release. I'm afraid CentOS Stream kernels won't have that regression testing done. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel