Welcome to the monthly update for Tumbleweed for September 2024! This month, the rolling-release model has kept pace with numerous important updates and bug fixes. PostgreSQL received a major update moving to 17 and text shaping engine harfbuzz had a major update to version 10. Packages like systemd, git, bash and qemu were also updated this month in the rolling release. Various packages saw CVE fixes and desktop components for GNOME and KDE were also updated. As always, remember to roll back using snapper if any issues arise.

Happy updating and tumble on!

Should readers desire more frequent information about snapshot updates, they are encouraged to subscribe to the openSUSE Factory mailing list.

New Features and Enhancements

• Linux Kernel 6.11.0: The latest update brings reversion of the PCI ACS configurability extension to address an issue bsc#1229019. Key updates in the release include a fix to the block subsystem, resolving how the scheduler is handled in elv_iosched_local_module. A correction was made in the AMD GPU display driver to address a mistake from a previous revert related to bsc#1228093. Updates also include refreshed ALSA patches to enhance power management blacklist options. The improvements are expected to provide greater stability and performance for various hardware configurations.
• postgresql17: This major release provides key improvements like a revamped memory management system for vacuum, boosting efficiency by reducing memory usage by up to 20x along with optimized processing for high concurrency workloads. Version 17 also enhances query execution with faster processing using B-tree indexes and parallel BRIN index builds. Developers benefit from the addition of the SQL/JSON JSON_TABLE command and expanded MERGE capabilities, as well as a 2x speed improvement in data exports with the COPY command. Logical replication now simplifies major version upgrades by eliminating the need to drop replication slots, improving ease of use in high availability setups. The software package further enhances database security and operational management, with new TLS options, incremental backups, and detailed monitoring tools.
• harfbuzz 10.0.1: Significant fixes were made for the text shaping engine including support for Unicode 16.0.0. The version has a new Application Programming Interfaces that allows clients to customize glyphs when a Unicode Variation Selector isn’t supported by the font, as well as a callback for getting table tags from hb_face_t. Updates also address pair positioning lookup subtable application for compatibility and ensure subsetting fails if no glyphs are present to prevent silent errors.
• GNOME 46.5: gnome-shell now addresses issues with smartcard logins, fixes glitches when quick settings menu animations are interrupted, and resolves problems with new Wi-Fi connections for restricted users. It also ensures required animations remain enabled, fixes display of pending PAM messages on the login screen and plugs memory leaks. Un update of the gnome-software has a reduction in power usage when the main window is closed, along with translation updates..
• KDE Plasma 6.1.5: In Discover, snapType mapping is corrected, and Flatpak now properly reports extensions without errors. KWin addresses several crash scenarios, such as null dereference and input event handling from removed devices. Plasma Desktop includes fixes for keyboard navigation in Kickoff, task list alignment in RTL mode and it has proper handling of background icons and test windows. Plasma Workspace enhances touchscreen interaction, system tray tooltips and clipboard functionality. Additional fixes included targeted crashes in hotplugging and svg rendering, while SDDM KCM improves state management.
• Frameworks 6.6.0: Attica adds CI jobs for Alpine/musl, while Baloo sets up crash handling for baloo_file. New icons are introduced in Breeze. KCoreAddons improves dbus error handling and licensing, and KDeclarative adjusts rendering for better DPI positioning. KIO resolves issues with restoring trash entries and enhances service menu handling. KTextEditor receives performance optimizations and additional C++ porting for sorting and unique functionalities. Kirigami continues to improve icon handling and toolbars, while KNewStuff and KWalletf ocus on making shared actions more reliable and enhancing crash handling.
• KDE Gear 24.08.1: Akademy 2024 Videos are out, but a lot of efforts went into last month’s conference. Akonadi resolves a crash related to query cache eviction and fixes configuration file handling. Dolphin improves usability with fixes for button functionality and file list resizing, while Elisa enhances its Now Playing view and toolbar layout. Itinerary and Kalarm both receive updates for better dark mode handling and audio alarm functionality. Kdenlive addresses multiple timeline and rendering issues, optimized keyframe handling and fixes several bugs related to effects and transitions. Kate adds support for the Odin language in its formatter and Okular now sets tooltips for forms.

Key Package Updates

• git 2.46.1: A clarification has been made to git checkout --ours to inform users they need to specify paths, avoiding confusion. An issue with git add -p failing for users with diff.suppressBlankEmpty was corrected. Additionally, git notes add -m '' --allow-empty no longer improperly invokes an editor, and unnecessary re-encoding operations for tracing have been removed.
• qemu 9.1.0: The update introduces new migration capabilities, such as compression offload support via Intel In-Memory Analytics Accelerator (IAA) or User Space Accelerator Development Kit (UADK) and improved postcopy failure recovery. RISC-V architecture also sees support for several extensions, while x86 adds KVM support for AMD SEV-SNP guests and emulation for newer Intel CPU models like Ice Llake and Sapphire Rapids.
• systemd 256.6: This version no longer attempts to restart udev socket units, addressing issue bsc#1228809 where safely restarting socket-activated services and their socket units simultaneously was problematic.
• pipewire 1.2.4: The update addresses a crash during the cleanup of globals and enhances the RequestProcess dispatch mechanism. The Simple Plugin API framework now uses systemd-logind to detect new devices. Pulse-Code Modulation device handling is also improved.
• GStreamer 1.24.8: The multimedia framework package improves handling in decodebin3 and encodebin for better media decoding and smart rendering, respectively. Enhancements for proper viewport resizing when video size changes were made and audio stream enhancements were made for better compatibility with Firefox. There were some stability fixes for wayland including crash prevention and Application Binary Interface corrections.
• Mesa 24.1.7: This release continues to support OpenGL 4.6 and Vulkan 1.3, though the version reported depends on the specific driver used. Key bug fixes include resolving issues with smartcard logins, race conditions when generating enums, and artifacts in games such as Black Myth Wukong and DCS World with certain GPUs.
• GTK4 4.16.1: This GTK Scene Graph Kit layer sees speed optimizations for Vulkan operations, reduces startup time by skipping unnecessary GL and Vulkan initialization and fixes a crash related to certain Vulkan drivers. Memory format conversions in GIMP Drawing Kit are now faster. The builder-tool has also been improved for better box conversion.
• bash 5.2.37: This update has key patches to address issues such as an incorrect handling of quoted text during auto-completion and multibyte character handling in readline. The update resolves system compatibility with select and pselect availability and fixes a parsing issue in compound assignments during alias expansion. A typo in the autoconf test affecting strtold availability when compiled with GNU Compiler Collection 14 was corrected.
• vim 9.1.0718: One notable fix in the text editor resolves issues with personal Vim runtime directory recognition. The update also addresses unnecessary NULL checks in parse_command_modifiers() and corrects color name parsing errors introduced in a previous version. Other improvements include updates to syntax highlighting for various file types such as HCL, Terraform, and tmux. Performance improvements were also made to include the more efficient inserting with a count and resolving cursor position crashes.

Bug Fixes

• curl 8.10.0:
  • CVE-2024-8096 may have incorrectly validated certificates using Online Certificate Status Protocol stapling, ignoring certain errors like ‘unauthorized’.
• OpenSSL:
  • CVE-2024-41996 was fixed, which could have allowed remote attackers to trigger costly server-side DHE calculations via public key order validation in Diffie-Hellman.
• postgresql17
  • CVE-2024-7348 fixes a race condition that could allow attackers to execute arbitrary SQL as the user running pg_dump.
• python311: This package fixed a few CVE’s. Here are a couple of fixes
  • CVE-2024-4030 had a fix to ensure Unix “700” permissions are applied to secure the directory.
• tiff 4.7.0:
  • CVE-2023-52356 had a segmentation fault allowing remote attackers to trigger a heap-buffer overflow that could cause a denial of service.
  • CVE-2024-7006 had a null pointer dereference in that could trigger application crashes and cause denial of service.
• LibreOffice 24.8.1.2
  • CVE-2024-5261 was fixed that disabled TLS certificate verification, allowing improper certificate validation during document processing in third-party components.
• Mozilla Firefox 130.0.1:
  • This release fixes several CVEs. One of the most critical fixes involves CVE-2024-8385, where a WASM type confusion issue could lead to exploitable vulnerabilities. Another significant fix is for CVE-2024-8381, which could trigger a type confusion vulnerability when looking up property names within a “with” block. CVE-2024-8388 fixed an issue where fullscreen notifications could be hidden on Android devices, potentially leading to UI spoofing attacks. Two memory safety bugs, CVE-2024-8387 and CVE-2024-8389, were also patched.
• apr 1.7.5:
  • CVE-2023-49582 had shared memory permissions that could expose sensitive data to local users.

Conclusion

September 2024 brings important updates for Tumbleweed users. Security fixes across packages like PostgreSQL, libtiff, and LibreOffice ensure stability and security. Significant improvements were made in tools like systemd, git, and qemu, enhancing performance and compatibility. Noteworthy updates in PostgreSQL 17 and Harfbuzz 10 also bring major enhancements, contributing to a more robust and refined rolling release environment.

Stay updated with the latest snapshots by subscribing to the openSUSE Factory mailing list. For those Tumbleweed users who want to contribute or want to engage with detailed technological discussions, subscribe to the openSUSE Factory mailing list . The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.

Contributing to openSUSE Tumbleweed

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

Dear Tumbleweed users and hackers,

This week looked pretty normal for Tumbleweed: we could publish 5 snapshots (0919, 0920, 0922, 0923, and 0924). 0925 was tested but needed to be discarded, as the cURL 8.10.1 update caused issues with libostree/flatpak. The issue could be resolved for Snapshot 0926, which is currently in QA and will likely be shipped over the weekend.

The most relevant changes during this week are:

• libeconf 0.7.3
• bind 9.20.2
• Linux kernel 6.10.11
• Mozilla Firefox 130.0.1
• git 2.46.1
• PostgreSQL 17 as new default (currently shipping PostgreSQL 17 RC1)
• Meson 1.5.2
• perl=Bootloader was renamed to update-bootloader

Staging projects and QA are currently working on – and testing – these changes

• Bash 5.2.37
• cURL 8.10.1 – libostree 2024.8 to address the identified crashes in flatpak
• fwupd 1.9.25
• GStreamer 1.24.8
• GTK 4.16.2
• Linux kernel 6.11.0
• openSSH 9.9p1
• systemd 256.6
• TCL 8.6.15
• PostgreSQL 17.0
• LLVM 19
• Mesa 24.2.x
• Plasma 6.2 (beta)
• timezone 2024b: postgresql test suites fixed
• Audit 4.0
• grub2 change: Introduces a new package, grub2-x86_64-efi-bls; some scenarios do not install the proper branding package
• Change of the default LSM (opted in at installation) to SELinux. AppArmor is still an option, just not the default. This change only impacts new installations
• GNOME 47

EuroBSDCon was fantastic, as always :-) I talked to many interesting people during the four days about sudo and syslog-ng, and of course also about many other topics. I gave a sudo tutorial, and it went well, with some “students” already planning which features to implement at home. There were many good talks, including one from Dr. Marshall Kirk McKusick, who was with the FreeBSD project right from the beginning, and worked on BSD even earlier. The weather was also good to us, so I could look around in Dublin for a bit.

sudo

The first two days of the conference were tutorials. I gave a sudo tutorial, which was well received: https://events.eurobsdcon.org/2024/talk/FLCHU3/. Luckily my audience was very active: I got many good questions. They did not really know most of the advanced sudo features. As usual, I also received feature requests while giving my sudo tutorial. I forwarded those to Todd Miller, maintainer of sudo.

At the end of my tutorial I asked my audience, which sudo features they plan to implement on their network, when they get back to the office. These were the top 3:

• sub-command logging
• central session recording
• using the Audit API from Python

During the conference I received many questions asking why I delivered a sudo tutorial if I was wearing a syslog-ng shirt :-) In short: Todd Miller, maintainer of sudo, was my colleague for a couple of years. I quickly learned that sudo is a lot more than just a prefix, and started writing and talking about it: https://peter.czanik.hu/posts/on_teaching_sudo/

Another returning question was comparing sudo with sudo replacements. The reason is quite simple: most people are not aware of the features sudo provides. As soon as I mention some of the enterprise focused features, like session recording, central management through LDAP, plugin support, and others, suddenly they understand the difference. Replacements are good in single user environments, however only sudo includes features for enterprise environments.

syslog-ng

During the conference I wore syslog-ng t-shirts. First of all: I do not have any sudo t-shirts, but dozens of syslog-ng t-shirts :-) And also, because I work on syslog-ng both as my job, and as the maintainer of the syslog-ng port in FreeBSD. I handed out many syslog-ng stickers too. There are many active syslog-ng users among FreeBSD users and developers. They use syslog-ng on FreeBSD in very diverse environments: collecting jail logs, in various appliances, bank security, telecommunications, and others. I am always happy to hear some positive feedback, and here I received many!

Sometimes I even felt, as if I was a kind of celebrity. People knew my name, and came to me to talk a bit after following me on Twitter / LinkedIn / Mastodon for years. They were very happy to learn that MacOS / FreeBSD receives now some extra care (see: https://www.syslog-ng.com/community/b/blog/posts/version-4-8-0-of-syslog-ng-improves-freebsd-and-macos-support)

During the conference I also received a feature request for syslog-ng: a new source to collect FreeBSD audit logs. This is how I learned that FreeBSD also has audit logs :-) Implementing something in C would be time consuming, and there is no ETA for that right now. Luckily syslog-ng also has a program() source. For that I could put together a working configuration over the lunch break of the conference. Of course it still has some rough edges, like ugly error messages, unnecessary quotation marks, etc, but it’s a good start. Here is a sample output:

{
  "fbaudit": {
    "record": {
      "text": "\"successful login root\"",
      "subject": {
        "_uidit-uid": "root",
        "_tiddt-uid": "46906172.16.167.1",
        "_siddt-uid": "909",
        "_ruidt-uid": "root",
        "_rgidt-uid": "wheel",
        "_piddt-uid": "909",
        "_gidit-uid": "wheel",
        "_audit-uid": "root"
      },
      "return": {
        "_retval": "0",
        "_errval": "success"
      },
      "_version": "11",
      "_timefier": "\"Sun Sep 22 15:36:46 2024\"",
      "_msecfier": "\" + 770 msec\"",
      "_modifier": "0",
      "_eventon": "\"OpenSSH login\""
    }
  },
  "TRANSPORT": "local+program",
  "SOURCE": "s_fbaudit_xml",
  "PRIORITY": "notice",
  "MSGFORMAT": "raw",
  "MESSAGE": "<record version=\"11\" event=\"OpenSSH login\" modifier=\"0\" time=\"Sun Sep 22 15:36:46 2024\" msec=\" + 770 msec\" ><subject audit-uid=\"root\" uid=\"root\" gid=\"wheel\" ruid=\"root\" rgid=\"wheel\" pid=\"909\" sid=\"909\" tid=\"46906172.16.167.1\" /><text>successful login root</text><return errval=\"success\" retval=\"0\" /></record>",
  "HOST_FROM": "fb14",
  "HOST": "fb14",
  "FACILITY": "user",
  "DATE": "Sep 22 17:45:39"
}

The conference

The conference was intense. Two days of tutorials co-located with the FreeBSD developer summit, and two days of talks. I delivered my sudo tutorial on the first day, and went back to my hotel quickly to rest a bit. I was completely exhausted from talking three hours straight. Then met up with some fellow Hungarians and FreeBSD developers for a beer that night. The next day I participated the developer summit, where I listened to interesting talks and discussions. In the late afternoon I walked around in Dublin.

The “real” conference happened on the third and fourth days. There were three parallel tracks, sometimes it was really difficult to choose where to go :-) There was a coffee break before each talk, which ensured that no matter how tired we were, we stayed awake :-) And of course it also gave us the possibility of networking. Lots of good discussions. It is difficult to pick highlights from the talks, all were great. My absolute favorite was given by Dr. Marshall Kirk McKusick: FreeBSD at 30 Years: Its Secrets to Success. It looked back at the history of the FreeBSD project and also shared some interesting statistics. I also learned about WifiBox, the latest news about FreeBSD RC scripts, or how to build an AI powered house. For a complete list of talks and tutorials, check the schedule.

Summary

I hope to see you next year in Zagreb at EuroBSDCon 2025 :-)

Last week I wrote about a campaign that we started to resolve issues on GitHub. Some of the fixes are coming from our enthusiastic community. Thanks to this, there is a new syslog-ng-devel port in MacPorts, where you can enable almost all syslog-ng features even for older MacOS versions and PowerPC hardware. Some of the freshly enabled modules include support for Kafka, GeoIP or OpenTelemetry. From this blog entry, you can learn how to install a legacy or an up-to-date syslog-ng version from MacPorts.

Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/huge-improvements-for-syslog-ng-in-macports

Last week I wrote about a campaign that we started to resolve issues on GitHub. Some of the fixes are coming from our enthusiastic community. Thanks to this, there is a new syslog-ng-devel port in MacPorts, where you can enable almost all syslog-ng features even for older MacOS versions and PowerPC hardware. Some of the freshly enabled modules include support for Kafka, GeoIP or OpenTelemetry. From this blog entry, you can learn how to install a legacy or an up-to-date syslog-ng version from MacPorts.

Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/huge-improvements-for-syslog-ng-in-macports

This article shows how to install and deploy Kubernetes (K8s) using RKE2 by SUSE Rancher on openSUSE Leap 15.6 with the NVIDIA GPU Operator. This operator deploys and loads any driver stack components required by CUDA on K8s Cluster nodes without touching the container host and makes sure, the correct driver stack is made available to driver containers. We use a driver container specifically build for openSUSE Leap 15.6 and SLE 15 SP6. GPU acceleration with CUDA is used in many AI applications. AI application workflows are frequently depoyed through K8s.

Introduction

NVIDIA’s Compute Unified Device Architecture (CUDA) plays a crucial role in AI today. Only with the enormous compute power of state-of-the-art GPUs it is possible to process training and inferencing with an acceptable amount of resources and compute time.

Most AI workflows rely on containerized workloads deployed and managed by Kubernetes (K8s). To deploy the entire compute stack - including kernel modules - to a K8s cluster, NVIDIA has designed its GPU Operator, which, together with a set of containers, is able to perform this task without ever touching the container hosts.

Most of the components used by the GPU Operator are ‘distribution agnostic’ however, one container needs to be built specifically for the target distribution: the driver container. This is owed to the fact that drivers are loaded into the kernel space and therefore need to be built specifically for that kernel.

For a long time, NVIDIA kernel drivers were proprietary and closed source. More recently, NVIDIA has published a kernel driver that’s entirely open source. This enables Linux distributions to publish pre-built drivers for their products. This allows for a much quicker installation. Also, prebuilt drivers are signed with the key thats used for the distribution kernel. This way, the driver will work seamlessly in systems with secure boot enabled. The container utilized below makes use of a pre-built driver.

In the next section we will explore how to deploy K8s on openSUSE Leap 15.6 once this is done, we will deploy the NVIDA GPU Operator in the following section run some initial tests. If you have K8s already running you may want to skip ahead to the 2nd part.

Install RKE2 on openSUSE Leap 15.6

We have chosen RKE2 from SUSE Rancher for K8s over the K8s packages shipped with openSUSE Leap: RKE2 is a well curated and maintained Kubernetes distribution which works right out of the box while openSUSE’s K8s packages have been broken pretty much ever since openSUSE Kubic has been dropped.

RKE2 does not come as an RPM package. This seems strange at first, however, it is owed to the fact that Rancher wants to ensure maximal portability across various Linux distributions.

Instead, it comes as a tar-ball - which is not unusual for application layer software.

Most of what’s described in this document has been taken from a great article by Alex Arnoldy on how to deploy NVIDIA’s GPU Operator on RKE2 and SLE BCI. Unfortunately, it was no longer fully up-to-date and thus has been taken down.

Install the K8s server

Kubernetes consists of at least one server which serves as a control node for the entire cluster. Additionally clusters may have any number of agents - i.e. machines which workloads will be spread across. Servers will act as an agent as well. If your K8s cluster consists just of one machine, you will be done once your server is installed. You may skip the following section. For system requirements you may want to check here. We assume, you have a Leap 15.6 system installed already (minimal installation is sufficient and even preferred).

1. Make sure, you have all components installed already which are either required for installation or runtime:

   zypper -n install -y curl tar gawk iptables helm
   

   For the installation, a convenient installation script exists. This downloads the required components, performs a checksum verification and installs them. The installation is minimal. When RKE2 is started for the first time, it will install itself to /var/lib/rancher and /etc/rancher. Download the installation script:

   # cd /root
   # curl -o rke2.sh -fsSL https://get.rke2.io
   

2. and run it:

   sh rke2.sh
   

3. To make sure, that the binaries provided by RKE2 - most importantly, kubectl - are found and will find their config files, you may want to create a separate shell profile:

   #  cat > /etc/profile.d/rke2.sh << EOF
   export PATH=$PATH:/var/lib/rancher/rke2/bin
   export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
   export CRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/crictl.yaml
   EOF
   

4. Now enable and start the rke2-server service:

   systemctl enable --now rke2-server
   

   With this, the installation is completed.

5. To check is all pods have come up properly and are running of have completed successfully, run:

   # kubectl get nodes -n kube-system
   

Install Agents

If you are running a single node cluster, you are done now and may skip this chapter. Otherwise, you will need to perform the steps below for every node you want to install as an agent.

1. As above, make sure, all required prerequisites are installed:

   # zypper -n install -y curl tar gawk iptables
   

2. Download the installation script

   # cd /root
   # curl -o rke2.sh -fsSL https://get.rke2.io
   

3. and run it:

   # INSTALL_RKE2_TYPE="agent" sh rke2.sh
   

4. Obtain the token from the server node, it can be found on the server at /var/lib/rancher/rke2/server/node-token. and add it to config file for the RK2 agent service:

   # mkdir -p /etc/rancher/rke2/
   # cat > /etc/rancher/rke2/config.yaml
   server: https://<server>:9345
   token <obtained token>
   

   (You have to replace by the name of IP of the RKE2 server host and by the agent token mentioned above.

5. Now you are able to start the agent:

   kubectl enable --now rke2-agent
   

6. After a while you should see that the node is has been picked up by the server. Run:

   kubectl get nodes
   

   in the server machine. The output should look something like this:

    NAME     STATUS   ROLES                       AGE    VERSION
    node01   Ready    control-plane,etcd,master   12m   v1.30.4+rke2r1
    node02   Ready    <none>                      5m    v1.30.4+rke2r1
   

Deploying the GPU Operator

Now, with the K8s cluster (hopefully) running, you’d be ready to deploy the GPU operator. The following steps need to be performed on the server node only, regardless if this has a GPU installed or not. The correct driver will be installed on any node that has a GPU installed.

1. To simply configuration, create a file /root/build-variables.sh on the server node:

   # cat > /root/build-variables.sh <<EOF
   export LEAP_MAJ="15"
   export LEAP_MIN="6"
   export DRIVER_VERSION="555.42.06"
   export OPERATOR_VERSION="v24.6.1"
   export DRIVER_IMAGE=nvidia-driver-container
   export REGISTRY="registry.opensuse.org/network/cluster/containers/containers-${LEAP_MAJ}.${LEAP_MIN}"
   EOF
   

2. and source this file from the shell you run the following commands from:

   # source /root/build-variables.sh
   

   Note that in the script above we are using kernel driver version 555.42.06 for CUDA 12.5 instead of CUDA 12.6 as in 12.6 NVIDIA has introduced some dependency issues which have not been resolved fully, yet. This will limit CUDA used in the payload to 12.5 or older since a kernel driver version will only work for CUDA versions older or equal to the version it was provided with. This will be fixed in future versions so that later driver of GPU operator versions can be used. Also note, that $REGISTRY points to a driver container in https://build.opensuse.org/package/show/network:cluster:containers/nv-driver-container This is a driver container specifically built for Leap 15.6 and SLE 15 SP6. The nvidia-driver-ctr container will look for a container image ${REGISTRY}/${DRIVER_IMAGE} tagged: ${DRIVER_VERSION}-${ID}${VERSION_ID}. ${ID} and ${VERSION_ID} are taken from /etc/os-release on the container host. Currently, the container above is tagged for Leap 15.6 and SLE 15 SP6.

3. Add the NVIDIA Helm repository:

   # helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
   

4. and update it:

   # helm repo update
   

5. Now deploy the operator using the nvidia/gpu-operator Helm chart:

   # helm install -n gpu-operator \
     --generate-name   --wait \
     --create-namespace \
     --version=${OPERATOR_VERSION} \
     nvidia/gpu-operator \
     --set driver.repository=${REGISTRY} \
     --set driver.image=${DRIVER_IMAGE} \
     --set driver.version=${DRIVER_VERSION} \
     --set operator.defaultRuntime=containerd \
     --set toolkit.env[0].name=CONTAINERD_CONFIG \
     --set toolkit.env[0].value=/var/lib/rancher/rke2/agent/etc/containerd/config.toml \
     --set toolkit.env[1].name=CONTAINERD_SOCKET  \
     --set toolkit.env[1].value=/run/k3s/containerd/containerd.sock \
     --set toolkit.env[2].name=CONTAINERD_RUNTIME_CLASS \
     --set toolkit.env[2].value=nvidia \
     --set toolkit.env[3].name=CONTAINERD_SET_AS_DEFAULT \
     --set-string toolkit.env[3].value=true
   

   After a while, the command will return.

6. Now, you can view the additional pods that have started in the gpu-operator namespace:

   kubectl get pods --namespace gpu-operator
   

7. To verify that everything has been deployed correctly, run:

   # kubectl logs -n gpu-operator -l app=nvidia-operator-validator
   

   This should return a result like:

   Defaulted container "nvidia-operator-validator" out of: nvidia-operator-validator, driver-validation (init), toolkit-validation (init), cuda-validation (init), plugin-validation (init)
   all validations are successful
   

   Also, run:

    # kubectl logs -n gpu-operator -l app=nvidia-cuda-validator
   

   which should result in:

   Defaulted container "nvidia-cuda-validator" out of: nvidia-cuda-validator, cuda-validation (init)
   cuda workload validation is successful
   

   To obtain information on the NVIDIA hardware installed on each node, run:

   # kubectl exec -it "$(for EACH in \
     $(kubectl get pods -n gpu-operator \
     -l app=nvidia-driver-daemonset \
     -o jsonpath={.items..metadata.name}); \
     do echo ${EACH}; done)" -n gpu-operator -- nvidia-smi
   

One should note, that most arguments to helm install ... above are for the RKE2 variant of K8s. Some of them may be different for an ‘upstream’ Kubernetes or may not be needed at all for it.

With GNOME 47 out, it’s time for my bi-annual wallpaper deep dive. For many, these may seem like simple background images, but GNOME wallpapers are the visual anchors of the project, defining its aesthetic and identity. The signature blue wallpaper with its dark top bar remains a key part of that.

In this release, GNOME 47 doesn’t overhaul the default blue wallpaper. It’s more of a subtle tweak than a full redesign. The familiar rounded triangles remain, but here’s something neat: the dark variant mimics real-world camera behavior. When it’s darker, the camera’s aperture widens, creating a shallower depth of field. A small but nice touch for those who notice these things.

The real action this cycle, though, is in the supplemental wallpapers.

We haven’t had to remove much this time around, thanks to the JXL format keeping file sizes manageable. The focus has been on variety rather than cutting old designs. We aim to keep things fresh, though you might notice that photographic wallpapers are still missing (we’ll get to that eventually, promise.

In terms of fine tuning changes, the classic, Pixels has been updated to feature newer apps from GNOME Circle.

The dark variant of Pills also got some love with lighting and shading tweaks, including a subtle subsurface scattering effect.

As for the new wallpapers, there are a few cool additions this release. I collaborated with Dominik Baran to create a tube-map-inspired vector wallpaper, which I’m particularly into. There’s also Mollnar, a nod to Vera Molnar, using simple geometric shapes in SVG format.

Most of our wallpapers are still bitmaps, largely because our rendering tools don’t yet handle color banding well with vectors. For now, even designs that would work better as vectors—like mesh gradients—get converted to bitmaps.

We’ve introduced some new abstract designs as well – meet Sheet and Swoosh. And for fans of pixel art, we’ve added LCD and its colorful sibling, LCD-rainbow. Both give off that retro screen vibe, even if the color gradient realism isn’t real-world accurate.

Lastly, there’s Symbolic Soup, which is, well… a bit chaotic. It might not be everyone’s cup of tea, but it definitely adds variety.

Preview

If you’re wondering about the strange square aspect ratio, take a look at the wallpaper sizing guide in our GNOME Interface Guidelines.

Also worth noting is the fact that all of these wallpapers have been created by humans. While I’ve experimented with image generation for some parts of the workflow in some of of my personal projects, all this work is AIgen-free and explicitly credited.