I think they got the nvidia driver accumulation thing straightened out. On Fedora 40, I had it automatically remove a bunch of older versions and now it only lists the 64 and 32 bit versions I expect it to.
$ flatpak list | grep nvidia
nvidia-550-76 org.freedesktop.Platform.GL.nvidia-550-76 1.4 system
nvidia-550-76 org.freedesktop.Platform.GL32.nvidia-550-76 1.4 system
Edit: looks like it’s fixed by this.
If you’re using universal blue images, that comes built into the image (at least on nvidia images for sure). To get rid of it, you’d have to use rpm-ostree override remove to get rid of it.
As far as I’m aware, CloudLinux is based on CentOS for older versions, and Alma Linux for newer versions, so it would be in the RHEL sphere of things.
They’re also the company that launched and continues to sponsor Alma Linux, a community run RHEL compatible distribution.
I’m not sure about using xml files, but there’s also a ‘picture-uri-dark’ key you need to set instead if you’re using dark mode. I have a similar setup with a systemd user timer that runs every 5 minutes.
Edit: I just tried it out in the terminal and it works ok for xml files, too. Also, I try to avoid parsing the output of ls in scripts. You can use find instead, something like
find $wallpath -name '*.xml'
should work.
Not quite the same issue, but similar in the sense that it was caused by a UEFI that didn’t conform to spec.
I have an HP laptop that I installed Debian on, and it would never actually boot to grub even though I checked the boot entries several times over. You could open the settings and choose the boot entry manually, so it’s not like it was a problem with the OS or with grub. Turned out, this model was hard coded to only allow a boot entry named “Windows Boot Manager” to be loaded by default. I used efibootmgr to rename the debian entry and it booted into grub straight away.
Nope, not at all. Silverblue here (GNOME), and the upgrade went smooth, nvidia drivers and all.