I’ve had to create a Red Hat 9.4 virtual machine on my M1 Max MacBook using UTM ( https://mac.getutm.app ). Because this is an ARM architecture machine, I used UTM because it would use Apple Silicon’s native virtualization support, and I installed the aarch64 version of Red Hat Enterprise Linux 9.4 so that it would be truly virtualized, not emulated.

So far the virtualization works flawlessly. Unfortunately for me and my work, the reason for installing it, to provide a RHEL environment for some work I’m doing, is a failure because the software I need to run under RHEL is only available for x86-64, not aarch64. Not everyone is rushing to embrace the future, especially with regards to processor architectures. It now appears that far too many vendors are refusing to support ARM systems, which is a sad state of affairs considering everyone is trying to install as much ARM-based silicon in their clouds; consider for example that AWS released Graviton 4, a 96 core beast that consumes far less power than Intel or AMD for the same workloads.

Anyway, this modest post documents how to set up UTM to install and then run aarch64 RHEL 9.4  on Apple Silicon M1 Max and a MacBook Pro. I’m going to leave the acquisition and installation of UTM as an exercise to the reader. It is open source, so you can either download a free copy from UTM’s website, or else use the App Store to purchase a permanent copy for $9.99. Using the App Store helps the UTM developers to help keep the lights on, and provides you, the user, a way to get automatic updates through the App Store.

After acquiring and installing UTM, you also need to get a copy of Red Hat’s Enterprise Linux to install. You can also do that for free by registering as a developer. You can download and install up to six copies for personal use. I’ve installed three so far, one under UTM and the other two using Parallels on another MacBook Pro running with an Intel i9. I wrote about that machine earlier, and called it the Beast.

With all the bits in place, it’s time to configure UTM and get RHEL installed on it. Again, installing the RHEL ISO isn’t that difficult, but the configuration can be somewhat perplexing. These settings work fine for me, and might work fine for you. But at least they’re a starting point.

I enabled everything on the virtualization tab except Rosetta on Linux. Remember this RHEL is aarch64. I have no idea how RHEL under x86_64 emulation might operate, and I don’t ever intend to find out. Also note that keyboard and pointer support are Mac keyboard and trackpad. The defaults are generic, and they don’t quite work as well.

I had absolutely no idea where to start with the display, so I had to play around with this for awhile before I found the value shown above. I can now shut down the VM window, and when I start it back up it will be at the correct size and resolution. Getting to this point was aggravating.

Finally we come to the networking. I found these settings on a forum posting, and discovered they work well for my setup. For one thing network traffic between my native MacBook Pro and the RHEL VM stay on my machine.

One nice note: power consumption at idle, especially inside the RHEL VM, is at an absolute minimum.

I’m still amazed at the power of Apple Silicon. With UTM installed I will probably start looking at other versions of Linux compiled natively for aarch64 under UTM.

While the majority of the stories about newly released Linux distributions have centered around Fedora 40 and Ubuntu 24.04, Red Hat released Enterprise Linux (RHEL) 9.4 on May 1st. As a RHEL developer I keep a VM running the latest release so I can stay familiar with RHEL in general as well as the tools that come bundled with RHEL. There’s a link at the bottom to the complete what’s new about RHEL 9.4, so I won’t go into breathless detail when you can get the straight scoop from Red Hat. But I am going to comment on some of the tools and the versions they released.

Tools In General

Python 3.12, Ruby 3.3, and PostgreSQL 16 are all great versions; that’s what their current major release levels are. Unfortunately when I updated my RHEL 9.3 instance to RHEL 9.4, I didn’t pick up the latest advertised tools. Instead I’m still at Python 3.9, Ruby 3.0, and PostgreSQL 13.

Other tools advertised with this release were Rust 1.75, Go 1.21, and LLVM 17. The current releases of those tools are Rust 1.78, Go 1.22.2, and LLVM 18. I should point out that Rust 1.78 now requires LLVM 18 as its back-end machine assembler. I should also point out that if you’re contemplating writing Rust drivers for the Linux kernel, 6.8 and later, that you’ll need Rust 1.77 at a minimum as well as a distribution that is running Linux kernel 6.8 or later. Unfortunately RHEL 9.x isn’t one of those distributions as it’s running a version 5 Linux kernel.

I suppose that if I were to perform a clean install of RHEL 9.4 I might actually get the updated tools, but performing an update to RHEL 9.4 from an earlier release, such as I did from 9.3, won’t get you there.

Clang

Clang, the C/C++ language front end for LLVM, isn’t installed by default, but you can install it after installing RHEL. In this instance it’s one major release behind current Clang, which is version 18. If I were to choose between GCC and Clang I believe I’d choose Clang, if for no other reason than GCC is relatively old compared with Clang, and Clang 17 has solid C++ 17 compliance, as well as C++ 20 and C++ 23.

Final Thoughts

RHEL is an IBM company, and it’s beginning to really “smell” like an IBM company that is catering to Big Businesses that use Linux in their businesses. If you work for such a company then RHEL will suit you just fine. If you’re into being more up-to-date with tooling and the latest Linux infrastructure such as the kernel, or if you’re doing kernel development, then I would recommend you use the latest Fedora, Linux Mint, or Ubuntu distributions. I personally use Linux Mint 21.3 with the Linux kernel 6.5 as my daily driver, Ubuntu 23.10 on my Raspberry Pi 5 and Fedora 40 (the latest) on my 2010 Samsung notebook. I’d like to point out that a fourteen year old computer is running one of the latest Linux distributions; with Linux there never truly is an obsolete (Apple calls them “legacy”) computer.

Links

What’s new in Red Hat Enterprise Linux 9.4? — https://developers.redhat.com/articles/2024/05/01/whats-new-red-hat-enterprise-linux-94#

Why I Maintain A RHEL 9.x VM

In the past I have been called upon to work in a RHEL environment, going all the way back to RHEL 5. It therefore behooves me to keep an up-to-date installation so I can remain familiar with the product. As a retired engineer and a consultant, I maintain that I will only work on the latest RHEL release; at this point in time that is RHEL 9, which was initially released in May 2022. Before then it was RHEL 8. Since it’s now a solid two years since RHEL 9’s initial release I believe there’s no excuse not to be running your business on RHEL 9. There are all sorts of excuses why a business refuses to update, but in the end none of them are good. I have turned down work because of the older RHEL releases someone may be using. It’s just not worth the aggravation; no amount of money will make me change my mind.

Since Red Hat has torpedoed the RHEL source code hangers-on, downloading and installing a RHEL clone anonymously has become impossible, assuming you want an up-to-date matching bug-for-bug release that can accept bug fixes and updates over time. Since I’m looking for what will become my future daily driver Linux distribution, I have no problems with either registering with Red Hat for a free developer account or registering the RHEL instance once it’s up and running. That developer account allows me to download for free an up-to-date Red Hat desktop DVD ISO for general personal use, not for resale. I’m sure I could download the server version for free, but that’s not what I’m looking to do.

Once my installed and running Red Hat workstation instance was registered, I was able to update to all the latest RHEL 9.2 patches, as well as install the EPEL repository references and then install a few EPEL packages such as neofetch (see above). That’s when I found out that my starting 9.2 instance had been updated to 9.3 (Plow).

Setting everything set up has been without any drama. If you’ve been working with any Linux distributions over the last two years, then you won’t be surprised at the pure Gnome desktop. Red Hat comes with the added assurance that the critical bugs will get fixed, in spite of what some critics may say.

I now see eye-to-eye with Red Hat’s attitude that groups like the original CentOS (before Red Hat bought it) as well as follow-on Rocky and Alma Linux are free-loaders, and the people who used those re-builds of Red Hat source to underpin their businesses are also free-loaders. If you’re building a business on top of Red Hat Enterprise Linux then you need to price in the cost of RHEL and pay for a copy of RHEL. Open source means free-as-in-speech, not free-as-in-beer. No-where is it written that open software must always be free to use, only free to study and extend as necessary.

Or to borrow the words of the late science fiction author Harlan Ellison, “pay the writer.”

Links

How to install EPEL on RHEL and CentOS Stream — https://www.redhat.com/sysadmin/install-epel-linux

Harlan Ellison’s Wonderful Rant on Why Writers Should Always Get Paid — https://www.openculture.com/2015/11/harlan-ellisons-wonderful-rant-on-why-writers-should-always-get-paid.html

I’ve create a Red Hat developer account for myself ( https://developers.redhat.com/ ) and downloaded my free (as in beer) RHEL 9.2 ISO for eventual installation later. I’ve done this primarily because of the (lack of) security in the repository chains that open source depends upon. A bit of cursory investigation shows that Red Hat may be big and corporate but I’ve come to believe they’re more trustworthy when it comes to the quality of the Linux product they deliver as well as support. That support costs, but it’s the kind of corporate support that corporate users demand.

To give you an idea as to what corporations are transitioning away from CentOS to RHEL, there’s the example of Salesforce, who’ve announced they’re migrating some 200,000 server-class machines from CentOS 7 to RHEL 9 (see link below). And that’s just one example. If you can believe the statistics, more than 90% of the Fortune 500 that use Linux use RHEL. I have no idea what the other 10% use, but it might just be Ubuntu primarily.

I have downloaded the RHEL Desktop 9.2 ISO, and I will spin up a small VM under Virtual Machine Manager and begin the process of determining how to migrate from Linux Mint to RHEL. I want to, in particular, determine if I can continue my Espressif/Arduino/Micropython development with external boards. Espressif has stated on their Github page that they support Ubuntu/Debian and CentOS 7/8. I’m assuming that this hasn’t been updated in a while due to the versions of CentOS the documentation calls out, but since CentOS was supposed to be bug-for-bug, feature-for-feature exact, then I see no reason why the Espressif tool chain won’t work on RHEL 9.x.

Once this is done my daily driver system will be Red Hat. I’ll only use other distributions if that’s what is supplied with hardware, such as, for example, Raspbian (Debian) for Raspberry Pi 4 and 5, or Ubuntu for the nVidia development boards.

Links

moving away from red hat to debian

Automation at Scale: Migrating 200,000 Machines from CentOS 7 to RHEL 9 — https://engineering.salesforce.com/automation-at-scale-migrating-200000-machines-from-centos-7-to-rhel-9/

Espressif Standard Toolchain Setup for Linux and macOS — https://docs.espressif.com/projects/esp-idf/en/latest/esp32/get-started/linux-macos-setup.html