Announcement

Collapse
No announcement yet.

AlmaLinux 8.10 Released With Support Re-Enabled For Some Older Hardware

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AlmaLinux 8.10 Released With Support Re-Enabled For Some Older Hardware

    Phoronix: AlmaLinux 8.10 Released With Support Re-Enabled For Some Older Hardware

    For those continuing to rely on the Enterprise Linux 8 series, AlmaLinux 8.10 has made its stable debut this morning as the newest version of this community-oriented operating system derived from Red Hat Enterprise Linux 8.10...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Can someone explain to me why this thing exists?

    If you need support for these devices, you can use Alma 9.4.

    Then again I can't stand the whole Red Hat ecosystem, it doesn't make any sense to me, it's like artificial segmentation for the sake of artificial segmentation.

    I was offered a job last year building bare metal Linux and Unix servers and during the interview process they explained to me that some of their clients wanted RH 7. some wanted RH8. some RH9, some wanted Rocky, some wanted Alma and I just sat their thinking to myself wtf is the difference?

    This mentality seems to permeate to various markets, there's a widely used piece of software called Davinci Resolve, generally considered the gold standard for color grading and used to produce many big budget movies and TV shows.

    This software runs on Windows, Mac (generally preferred) and Linux.

    Black Magic Design, the company that makes the software, actually has an official Linux distro iso for those that want to run Resolve on Linux, guaranteed to work.

    The distro? Rocky Linux 8.6.

    It's just so arbitrary, it's like someone woke up one day and said instead of using this version I am going to modify a different versions and use that instead.

    Why?

    Nothing better to do, that's why.

    Comment


    • #3
      Originally posted by sophisticles View Post
      If you need support for these devices, you can use Alma 9.4.
      Imagine you have software that only works (or is commercially supported) for EL8 but you only have hardware that is supported by these drivers. This offering gives a viable solution.
      Yes, it may not be a niche required by your use-case or mine currently but I am sure somewhere on the planet, there are others that have this exact problem.

      Originally posted by sophisticles View Post
      Then again I can't stand the whole Red Hat ecosystem, it doesn't make any sense to me, it's like artificial segmentation for the sake of artificial segmentation.
      I kind of agree but at the same time, I actually like the fact that there are ~5 different implementation of the *same* Linux distro.
      This mirrors one of the strengths of C and C++ having loads of vendor compilers. So if one flakes out, another can pick up the slack.
      EL is now more of a "unifying standard" rather than a product. Red Hat used to embrace this with CentOS until their business strategy changed. But that doesn't mean that the original potential advantage to users isn't still there.

      Originally posted by sophisticles View Post
      Nothing better to do, that's why.
      I guess competition means that they are trying to stand out against the rest.
      If they sell one or two licenses because of this, they have earned their efforts back many times over (ticking kernel compile time options isn't exactly much effort, our open-source code to support these drivers is already there in the kernel tree).
      Last edited by kpedersen; 28 May 2024, 12:04 PM.

      Comment


      • #4
        I read before about Redhat removing support for these drivers in RHEL9, but they removed it in RHEL8 too? RHEL9 I can understand, it's newer, but you figure that people running the older distros are doing so on older hardware which is expected to be supported till end of life for the existing older OS...wow, Redhat sinking to new low here, that's some serious rug pulling. Thank you Alma

        Comment


        • #5
          Some of these controllers are quite common. E.g. the HP Z840 workstations have a built in LSI SAS controller that uses the mpt3sas driver. I have an 8x 2.5" drive cage hooked up to mine in one of the 5.25" bays.

          Comment


          • #6
            Originally posted by scratchi View Post
            I read before about Redhat removing support for these drivers in RHEL9, but they removed it in RHEL8 too? RHEL9 I can understand, it's newer, but you figure that people running the older distros are doing so on older hardware which is expected to be supported till end of life for the existing older OS...wow, Redhat sinking to new low here, that's some serious rug pulling. Thank you Alma
            To the best of my knowledge, Red Hat has not removed anything in RHEL 8.1+. Take a look at the release notes for 8.0 -> 8.10. All of the content removed in 8.0 can be found in the "Considerations for Adopting RHEL 8" documentation. For the first three subsequent minor releases you need to look at the Deprecated Functionality chapter and review the details there (typically Kernel and Hardware Enablement if they exist). Starting with 8.4, a new subsection labeled "Deprecated and Unmaintained Devices" was added to the chapter to consolidate everything.

            Remember, "deprecated" and "unmaintained" are terms regarding support, not existence.

            Originally posted by Red Hat Documentation
            This section lists devices (drivers, adapters) that
            • continue to be supported until the end of life of RHEL 8 but will likely not be supported in future major releases of this product and are not recommended for new deployments. Support for devices other than those listed remains unchanged. These are deprecated devices.
            • are available but are no longer being tested or updated on a routine basis in RHEL 8. Red Hat may fix serious bugs, including security bugs, at its discretion. These devices should no longer be used in production, and it is likely they will be disabled in the next major release. These are unmaintained devices.
            PCI device IDs are in the format of vendor:device:subvendor:subdevice. If no device ID is listed, all devices associated with the corresponding driver have been deprecated. To check the PCI IDs of the hardware on your system, run the lspci -nn command.
            Realistically you just need to review the following two pages as they provide the baseline (removed) and the aggregate (deprecated/unmaintained):Cheers

            Comment


            • #7
              Originally posted by sophisticles View Post
              Can someone explain to me why this thing exists?

              If you need support for these devices, you can use Alma 9.4.

              Then again I can't stand the whole Red Hat ecosystem, it doesn't make any sense to me, it's like artificial segmentation for the sake of artificial segmentation.

              I was offered a job last year building bare metal Linux and Unix servers and during the interview process they explained to me that some of their clients wanted RH 7. some wanted RH8. some RH9, some wanted Rocky, some wanted Alma and I just sat their thinking to myself wtf is the difference?
              Each RHEL version has different libraries, compilers, etc so they're like using a PC at a certain snapshot in time. It's like when a Windows user has a requirement for MS-DOS, 98, or Vista and compatibility mode isn't good enough for their needs so they need the actual OS on bare metal or in a VM, container, chroot, or wherever.

              It's also about accountability. RHEL is certified safe like how an up-to-date Windows is considered certified safe in regards to audits after being hacked. Using an identical enough RHEL fork like Alma or Rocky and keeping it up to date is considered good enough.

              Those two points combined is the point of EL and LTS. The system stays the same while being patched and up to date. They're like high school girls. I get older, they stay the same age.

              ​This mentality seems to permeate to various markets, there's a widely used piece of software called Davinci Resolve, generally considered the gold standard for color grading and used to produce many big budget movies and TV shows.

              This software runs on Windows, Mac (generally preferred) and Linux.

              Black Magic Design, the company that makes the software, actually has an official Linux distro iso for those that want to run Resolve on Linux, guaranteed to work.

              The distro? Rocky Linux 8.6.

              It's just so arbitrary, it's like someone woke up one day and said instead of using this version I am going to modify a different versions and use that instead.

              Why?

              Nothing better to do, that's why.
              Officially, it's Rocky Linux 8.6 with NVIDIA graphics. Unofficially, you can try whatever you want, GPU included, and there are lots of reports of that working. The reason for Rocky 8.6 is because it's free and people using it are covered in case shit happens. Unlike Arch or Tumbleweed, with EL you won't take an update that'll FUBAR your entire desktop in the middle of a multi-million dollar project. Granted, if you're on a project of that caliber I'd expect one or two backup systems.

              Divinci Resolve is expensive when you factor in the hardware and the software. It can all run a person tens of thousands of dollars. Forcing their users onto RHEL instead of the identical free version after spending that kind of money is just a dick move. I expect them to be able to afford RHEL if they can afford multiple $40K editing stations, but that's besides the point.

              Comment


              • #8
                skeevy420 The designation of a non-RHEL build with a specific point release comes from the following: BMD and Autodesk (for the Flame product) offer an optional ISO that includes all the kernel modules, peripheral drivers (NVIDIA, AJA, BMD, etc), configs, and software needed to slap on a system and get to work. Not using the ISO is supported, but you have to assemble those pieces yourself. Formerly CentOS Linux filled this role, but for EL8+ an alternative was chosen. RHEL isn't used because that would require the vendors to become a Red Hat partner and pay to distribute RHEL via mechanisms like the RHEL for Embedded program.

                As to why things lag behind tied to a specific minor release... yeah you'll have to ask their dev teams but I suspect you can guess the reasoning. Honestly they'd probably change a bit quicker if kernel modules weren't involved. But at the end of the day DaVinci Resolve and Autodesk Flame systems are more often than not air-gapped, so the risk tolerance of running an older operating system is a bit higher in order to have a system that Just Works™.

                Cheers

                Comment


                • #9
                  Originally posted by mroche View Post

                  To the best of my knowledge, Red Hat has not removed anything in RHEL 8.1+. Take a look at the release notes for 8.0 -> 8.10. All of the content removed in 8.0 can be found in the "Considerations for Adopting RHEL 8" documentation. For the first three subsequent minor releases you need to look at the Deprecated Functionality chapter and review the details there (typically Kernel and Hardware Enablement if they exist). Starting with 8.4, a new subsection labeled "Deprecated and Unmaintained Devices" was added to the chapter to consolidate everything.

                  Remember, "deprecated" and "unmaintained" are terms regarding support, not existence.

                  Ok, they didn't remove support, but disabled it. Thats a more than just deprecating it, despite what redhat's documentation claims, as disabling it can break existing systems until enabled again. Accoding to article, it needs to be enabled again, as that's basically what Alma is doing:

                  AlmaLinux 8.10 re-enables some PCI IDs that were previously disabled in upstream RHEL
                  Thats still shitty for those running an old platform with expectation OS will be supported on it till end of life, even if it is possible and not complicated to enable it again.
                  Last edited by scratchi; 28 May 2024, 04:11 PM.

                  Comment


                  • #10
                    Originally posted by scratchi View Post


                    Ok, they didn't remove support, but disabled it. Thats a more than just deprecating it, despite what redhat's documentation claims, as disabling it can break existing systems until enabled again. Accoding to article, it needs to be enabled again, as that's basically what Alma is doing:



                    Thats still shitty for those running an old platform with expectation OS will be supported on it till end of life, even if it is possible and not complicated to enable it again.
                    Again, I could be totally wrong on this but unless I'm mistaken AlmaLinux is re-enabling hardware that was disabled in 8.0. Taking a cursory look at the very first RHEL 8.0 kernel source package the IDs they're turning back on match the ones disabled from the start. Granted they aren't nicely organized like they are in 8.10. You can verify for yourself with the following steps from a RHEL 8 system:

                    Code:
                    > dnf download --source kernel-4.18.0-80.el8
                    > rpm2cpio kernel-4.18.0-80.el8.src.rpm | cpio -idm -D kernel-4.18.0-80.el8
                    > cd kernel-4.18.0-80.el8
                    > tar xf linux-4.18.0-80.el8.tar.xz
                    > cd linux-4.18.0-80.el8
                    > find . -type f \( -name "*.c" -o -name "*.h" \) | xargs grep [pattern]
                    > less [file]
                    The search pattern could be something like this:

                    Code:
                    # Adaptec 3230S (Harrier), PCI ID 0x9005:0x0285:0x9005:0x0288
                    > find . -type f \( -name "*.c" -o -name "*.h" \) | xargs grep "0x9005.*0x0285.*0x9005.*0x0288"
                    ./drivers/scsi/aacraid/linit.c: { 0x9005, 0x0285, 0x9005, 0x0288, 0, 0, 16 }, /* Adaptec 3230S (Harrier) */
                    ./drivers/scsi/aacraid/linit.c: { 0x9005, 0x0285, 0x9005, 0x0288, 0, 0, 16 }, /* Adaptec 3230S (Harrier) */​
                    
                    > less ./drivers/scsi/aacraid/linit.c
                    [/Harrier]
                    static const struct pci_device_id aac_pci_tbl[] = {​
                    ...
                            { 0x9005, 0x0285, 0x9005, 0x0288, 0, 0, 16 }, /* Adaptec 3230S (Harrier) */
                    ...
                    }
                    ...
                    static const struct pci_device_id aac_pci_ids_removed[] = {
                    ...
                            { 0x9005, 0x0285, 0x9005, 0x0288, 0, 0, 16 }, /* Adaptec 3230S (Harrier) */
                    ...
                    }
                    That ID can be found in the disabled device list in 8.10 here: Red Hat Code Browser | RHEL 8.10 | kernel-4.18.0-553.5.1.el8_10/source/kernel/rh_messages.h​

                    You can see the changes that AlmaLinux made here, but just know that a little elbow grease is required for matching ID-to-ID between 8.0 and 8.10 in terms of where things are found.

                    Cheers
                    Last edited by mroche; 11 June 2024, 11:53 PM.

                    Comment

                    Working...
                    X