RHEL 9 graphics better fix

[acdingman]

The fact that this works all but guarantees it will "just work" in RHEL 9.1. So, waiting for that is definitely an option. Obviously that's going to be a requirement for formal support from Red Hat. But it's only a few packages and RH usually doesn't make you revert things in practice unless there's reason to believe it's actually causing the problem.

I found myself sitting here thinking "I wish I still had access to Red Hat internal engineering builds, 'cause I bet they've backported the new vmwgfx module. But they usually don't ship hardware enablement fixes until it's time for a minor release." Then I remembered that the whole CentOS Stream thing people were so weirdly pissed about is basically moving those engineering builds out where everyone can see them! Sure enough, if you cherry pick a few packages from CentOS Stream 9, you get graphics integration with resolution control.

So, the basic idea is to add a CentOS repository file but tightly restrict it to a minimal handful of packages so you don't accidentally convert your nice RHEL system into a weird RHEL-CentOS frankensystem. I'm attaching the relevant pieces of mine. The forum is picky about file extensions, so you'll need to remove ".txt" from the name to use the repo file. It's based on the one from the official centos-stream-repos package, and as such doesn't work unless you also set the "stream" variable, which the official package does by creating a file named stream in /etc/dnf/vars with the value, "9-stream". I've attached that, too, but you'll need to name it apropriately. You'll also need to trust the CentOS package signing key to validate these packages. You really should fetch it from a more verifiably trustworthy source, but If you're confident this random guy on a forum wouldn't lie to you, that's attached here, too. Trust it with rpm --import filename regardless of where you get it from.

With all that in place, dnf upgrade should happily offer you the various kernel*-5.14.0-160.el9 and open-vm-tools*-12.0.5-1.el9 as upgrades from CentOS. (Or later versions, depending on when you see this.) You'll then need to re-boot into the new kernel without vmwgfx blacklisted, which has the side effect of also re-starting your vmtoolsd. On my RHEL 9 aarch64 VM, the blacklist was on both the kernel command line and the /etc/modprobe.d/anaconda-blacklist.conf file. Since you'll still want it for any existing official RHEL kernels, I suggest commenting out the entry in modprobe.d (or just deleting the file if that's all that's there), but leaving it in the boot entries for official kernels. For a first test boot it's probably safest to interactively edit out modprobe.blacklist=vmwgfx so that you don't make it persistent if it's not working right for you.

Assuming that all went as well for you as it did for me, you can use grubby to modify the persistent grub configuration

• sudo grubby --update-kernel=/boot/vmlinuz-5.14.0-160.el9.aarch64 --remove-args=modprobe.blacklist will remove the argument just for the kernel we just installed. You'd need to do this again for each kernel upgrade that supports the newer VMWare graphics hardware, but any new official RHEL kernels will be fine.
• sudo grubby --update-kernel=DEFAULT --remove-args=modprobe.blacklist will keep it from being added to boot stanzas for future kernel upgrades, but won't touch existing configurations. So you need to run the one above either way, but if you do this you won't need to run that one again for future kernels.

I've gone ahead and changed the default on mine, because in all likelihood I won't install another official RHEL kernel before there's a 9.1 release that I expect will include the same fix. But that's very much your call.

If you want to make sure you don't stay ahead of the official RHEL packages once RHEL catches up to the versions you have installed, you can uncomment the two lines "#priority=200" in my centos-stream.repo file. If you do that, dnf won't offer packages from those repos that exist in the official repos even if they are the newest ones available. So you'll only get them installed if you specifically request them by name and version number. You could also entirely disable the repositories. I'm not doing either on my VM because I do want to get any security updates that might happen between now and RHEL 9.1, and 9.1 should have a "release" version that's newer than whatever I've pulled from CentOS in the interim. But there's not a single obviously correct choice.

[acdingman]

Oh, you may also need to back out the changes to /etc/default/grub from the Tips & Techniques guide if you did that. I'm not sure if it's needed, but I did.