Ultramarine Linux 39 Review [KDE Plasma Edition]

Introduction

I recently discovered Ultramarine Linux from a review of one of its previous on Distrowatch, after which I installed the Flagship Edition, featuring the Budgie desktop environment, on my tertiary laptop. After using it briefly, I found it to be extremely refined, adding to the already excellent Fedora base, so I decided to install the KDE Plasma Edition on my primary multi-booting laptop, a Lenovo LEGION 5i PRO 16ITH6 Review [82JF002RUS]Lenovo Legion 5i Pro, in place of the Fedora I had been planning to install on a Btrfs filesystem with an openSUSE style subvolume layout and Snapper integration. This will be a permanent installation that will join an existing Arch installation, installed with the openSUSE Btrfs/Snapper configuration using the process described in An Arch Linux Installation on a Btrfs Filesystem with Snapper for System Snapshots and Rollbacks, which has been running reliably with this configuration for three years, and an existing openSUSE Tumbleweed installation, which of course comes out-of-the box with this configuration and has been running reliably for almost as long.

Because Fedora's Anaconda installer, also used by Ultramarine, does not support complex hierarchical subvolume layouts, I converted an initial installation of Ultramarine using Anaconda to the openSUSE style of subvolume layouts and Snapper integration using the process described in A Fedora Installation with an openSUSE Style Btrfs Subvolume Layout and Snapper Integration for System Snapshots and Rollbacks.

Review Summary

A full review of Ultramarine Linux 39 KDE Plasma Edition is presented below, but for readers short on time, my observations of the distribution are summarized here.

• Installation on a UEFI system with systemd-boot directories in the ESP (EFI System Partition), created by a previous Linux distribution installation which uses systemd-boot, will cause the Ultramarine Linux installation to be un-bootable by GRUB.
• Like its base, Ultramarine Linux's GRUB configuration uses a BLS configuration which creates drop in snippets in the GRUB configuration that standardizes the GRUB configuration process for all platforms. This is not a problem for most installations, but the Ultramarine Linux is a non-standard -- for Fedora -- Btrfs configuration, one that uses grub-btrfs to create entries of read-only bootable Btrfs snapshots in the GRUB menu, BLS will cause problems.
• The most important thing Ultramarine Linux adds to the excellent Fedora base is the additional repositories that are enabled out-of-the-box. These are the third-party RPM Fusion repository, which distributes, among other software, proprietary codecs and drivers -- including those for Nvidia GPUs, and the Terra repository, maintained by Frya Labs, the developers of Ultramarine. Terra contains software that is not necessarily proprietary, but is not distributed by Fedora.
• One area of the system that the deviates from standard Fedorafundamentally is the choice of the shell. Ultramarine uses zsh as the user's default shell, as a login shell and as an interactive shell. This shell has some user conveniences compared to Bash in interactive terminal sessions, but not as much as the fish shell which has, for example, powerful and robust completion features. Bash is installed and the startup files that would be read by Bash are sourced by zsh also. The choice of zsh will require users to accept a learing curve if they find its features useful, be annoyed by some zsh characteristics, or change their shell. I chose to change the default shell to Bash and integrate fish as the interactive shell.
• Ultramarine also deviates from Fedora in its incorporation of the System76 Sheduler, a utility that modifies the Linux CPU scheduler behavior by modifying process priorities to provide a more responsive system. This is even integrated in the Plasma desktop, which includes a setting to allow Plasma's window manager, KWin to communicate with System76 Scheduler to notify it which window has focus so that the application displayed in the window is prioritized.
• Apart from the issue caused by systemd-boot during installation, an issue that many users may not experience, the only issue that required intervention after installation -- due to the characteristics of the Lenovo -- was that hibernation was problematic. The issue was related to the ACPI S4 Platform Handler, described in Section: ACPI Power States of /general-guides/1/Hardware/2/Graphics/3/Nvidia/nvidia-optimus-on-linux and described in Lenovo LEGION 5i PRO 16ITH6 Review [82JF002RUS] which would require intermediate interaction with the rEFInd boot manager (which I use to boot the GRUB of the distribution I want to boot -- convenient when multi-booting because rEFInd can be always set as the default boot manager) to enter hibernation.
• A less serious issue I encountered concerns one of the elements in my preferred layout of Plasmashell in which I create a top panel with, among other widgets, the Global Menu widget. This of course works as intended with KDE applications, but did not work with two important applications GTK applications -- Inkscape and GIMP. This issue is not present in the other distributions that I regularly use.
• After installing the Nvidia driver from RPM Fusion, it is possible to set the Nvidia GPU as the primary GPU; without this, Optimus will work in offload mode by default. It is also possible to switch between proprietary Nvidia driver or the FOSS Nouveau driver with appropriate kernel command-line options.
• Although only a Wayland session is available in the live ISO environment, an X11 session is also available in the installed system. I did not experience any issues with Wayland on the KDE Plasma Edition installed on the Lenovo, although there was one slight noticieble difference in the behavior between the two: the icon of the manually installed Firefox Developer Edition was replaced with an icon of the Wayland logo when the application was open.

Recommendation

In my brief use of Ultramarine's Budgie based Flagship Edition, I found that the distribution put extensive effort in providing an excellent Budgie experience, for example ensuring all of the Budgie extras, such as panel widgets ere available. As a Fedora based distribution, this experience is largely due to the already reliable and refined Fedora base, which makes an excellent development workstation. Because of my very positive impression of the Flagship Edition I choset to install the distribution's KDE Plasma edition instead of Fedors's KDE spin, as I had been planning to with a customized openSUSE style Btrfs/Snapper configuration.

Understandably, the amount of work done on desktop environment specific elements in the Plasma edition was not as extensive as the Flagship edition since this desktop not really the focus of the distribution. But those who prefer Plasma do get the benefit of Ultramarine's additions to the Fedora base, such as additional repositories enabled out-of-the box, a better -- arguably -- shell than Bash configured by default, and a promised performance improvement provided by incorporating System76 Scheduler.

In my case, because there was considerable effort in modifying the default Ultramarine (or Fedora) installation to the openSUSE Btrfs/Snapper configuration, Ultramarine's additions were not significant in saving the amount of time to a usable system. However, for potential Fedora users who will choose one of the typical storage configurations during installation, Ultramarine's enablement of additonal repositores, including the developers' own Terra repository is significant in providing a usable Fedora system out-of-the-box.

Review

Pre-Installation

The pre-installation activities, i.e., finding the appropriate download link and finding checksums and GPG signatures or keys for ISO verification, for some distributions can be difficult, if the distribution does not prioritize these elements of its infrastructure. In Ultramarine's case, "Download" links are prominent on its website, and easy to find for each edition. Links to the checksum of each ISO is also easy to find as they are directly below the download links. GPG signatures or public keys, however are nowhere to be found on Ultramarine's website or GitHub pages. I did stumble upon the GPG key hidden on one of the GitHub pages for the Flagship Edition when I first installed it on my tertiary laptop, but it seems to have disappeared since then. I could not find the GPG signature or public key for the KDE Plasma Edition. Even Ultramarine's wiki providing instructions on ISO verification only mentions download integrity verification and makes no mention of authenticity verification using GPG signatures. This deficiency is the only area in which the distribution could be improved.

The lack of authenticity verification through GPG signed ISOs or GPG signed checksum files is common with many -- otherwise good -- distributions that are small, immature, or lack resources provided by corporate backing. As with Ultramarine, this happens to be the case in the recently reviewed Garuda Linux KDE Dragonized Edition.

Incidentally, Mageia has the best website in this respect, which easily allows filtering for the appropriate download by selecting installation type, desktop environment, target architecture, and download type. And after the download link is activated and the download is initiated, a page with comprehensive instructions for authenticity verification using GPG, in addition to download integrity verification, is opened.

Installation Medium/Live Environment

The KDE Plasma Edition installation ISO, like the other three editions, is a fully functional live environment. It was faithfully representative of the installed system, except the lack of an available X11 session, as described below.

It has a range of applications to allow it to be useful even without installation of the OS. The Flagship Edition ISO I dded to a USB thumb drive even seemed to support persistence. The KDE Plasma Edition, however, definitely does not.

The live environment is entered, as usual, through the GRUB menu, which has two options, one to enter the live environment and another to test the installation image and then enter the live environment. After selecting either, the user is taken to the desktop environment without having a chance to select the session type, automatically using a Wayland session, although the installed system allows selection of an X11 session, as well as the default Wayland, from the SDDM login screen. This was one of the areas I had any issue with the installation ISO, because the screen recording application I used to record the installation and process to convert the installation to the openSUSE Btrfs subvolume layout and Snapper integration only had experimental support for Wayland.

Installation

Ultramarine, as a distribution based on Fedora, uses Anaconda, the installer used by Fedora and related distributions, including RHEL, the use in which was discussed in the review of Red Hat Enterprise Linux 9. It is telling of Ultramarine's character as closely following its parent in that the distribution uses Anaconda instead of the popular Calameres installer, as many distributions do, even if they are derivatives and their base distribution uses another installer.

Anaconda is a fairly advanced installer, allowing for advanced configurations, including the ability to set up encrypted RAID partitions. It is organized in a "hub and spoke" paradigm where its major parts are launched from a central screen. Users select each in turn, enter and modify installation parameters, and return to the central screen. Once all parts have been visited and parameters entered to the installer's satisfaction, the installation can proceed when the final confirmation button is pressed in the central screen. The following images show the central navigation screen and each of the components.

Anaconda provides two alternative components for configuring storage for the installation target. The older and traditional component, and Blivet-GUI, an embedded advanced partitioning component. This was used to initially configure storage during installation -- as shown in the following set of images -- before modifying the installed system to follow the openSUSE Btrfs subvolume layout and Snapper integration, as described in A Fedora Installation with an openSUSE Style Btrfs Subvolume Layout and Snapper Intergration for System Snapshots and Rollbacks.

Despite Blivet-GUI's limitations, described in the article referenced above, the initial installation was straightforward. There was one serious installation issue to be aware of, however, regarding how an existing systemd-boot boot manager in the ESP partition affects the installation, whatever the filesystem and storage configuration chosen for the installation target. The issue was that existing directories with a thirty-two character alpha-numeric name created by systemd-boot will cause the installed system's kernel to be written to the ESP partition, mounted at /boot/efi instead of /boot, as discussed in a Fedora Forum thread. In my case, a previous installation of KaOS, which only allows systemd-boot or rEFInd for installations on UEFI systems, had created such a directory on my Acer, and on my Legion an old installation of PopOS which uses systemd-boot by default instead of GRUB created this directory. On both laptops, because the kernel was installed in the ESP, this caused the GRUB menu to be created with entries that did not contain a valid path to the kernel image, causing a non-booting system when the entry was selected. On the Acer, where I first encountered the issue, I had to reinstall the Ultramarine Linux 39 Flagship Edition after resolving the issue by mounting the ESP in the live ISO environment and removing the directory. On the Lenovo, I made sure to remove the directory before attempting the installation of the KDE Plasma Edition. The offending directory on the Legion is shown in the following image, captured from the KDE Plasma Edition ISO live environment.

First Boot

On first boot of Ultramarine KDE Plasma Edition, the Plasma Welcome application is presented. The application provides a brief introduction to Plasma's capabilities and features, as well as allowing integration of supported online accounts. Its screens are shown in the following set of images.

Appearance Settings

The Ultramarine Linux KDE Plasma Edition theme is typical of other distributions' Plasma appearance. The desktop layout is the standard Plasma panel at the bottom of the screen featuring the Icons Only Task Manager and System Tray widgets, among others. The color scheme is also standard Plasma with the Breeze Dark color scheme activated by default. The only notable aspect of the distrubtion edition's appearance is the availability of the Lightly Plasma Application Style, a fork of the default Plasma application style, Breeze, that modernizes the default by removing some decorative elements, such as frames around panels. It is also more configurable than Breeze, although not as configurable as Kvantum based application styles. The Plasma Application Styles screen of Plasma's System Settings with two of the Lightly style's configuration dialog tabs is shown in Image 6 and Image 7 in the following set.

Additional Repositories

The most substantive value addition that Ultramarine makes to the already excellent Fedora base is the out-of-the box enablement of additional repositories. The third-party RPM Fusion repositories which distribute software as precompiled RPMs for current versions of Fedora and Red Hat Enterprise Linux, including proprietary Nvidia drivers, are enabled out-of-the box, saving users some time after installation.

Ultramarine also includes two of its own repositories in the system, the Ultramarine repository, used mainly for the distribution's settings packages, and the Terra repository, maintained by Fyra Labs, the developers of Ultramarine Linux. The following set of images show the enabled and disabled repositories, and the software installed from the Fyra maintained repositories.

COPR

Unfortuanately, the available repostories, even with the additional repositories that Ultramarine makes available by default, may not have software packaged as RPMs (Flatpack installation is fully enabled out of the box in Discover, KDE's GUI package management application). One such software is the hblock script for modifying /etc/hosts for blocking ads and malicious hosts. The Fedora user repository COPR is available for software packaged as RPMs that is not available in the other repostiories.

The Shell

The only way I have seen that Ultramarine deviates from its Fedora base in a fundamental way is in its choice of the default shell. The distribution uses zsh as the default login shell. Bash is also available and provides the sh command via symbolic link, and by providing this command it is essential in the system. It is used, for example, as the interpreter for the SDDM .sh script that is executed at user login and actually invokes zsh as the login shell.

It is also set as the interactive shell in Konsole terminal emulator sessions by specifying /usr/bin/zsh as the command that is executed when Konsole is started.

Like fish, the "friendly, interactive shell," zsh is intended primarily to be an interactive shell. It provides advanced syntax highlighting, error checking, and completion. It is however, in my opinion, lacking in all of these areas compared to fish. Fish is especially robust in its command completion capability which parses the man pages available on the system to provide completions, as well as providing an advanced interface for viewing and cycling through completion alternatives. So, it seems to me that if the distribution wants to deviate from the typical choice of Bash as both the login and interactive shell, to choose fish as the interactive shell and Bash as the login shell.

Besides, the superiority of fish as an interactive shell, there are also some annoyances with zsh that users accustomed to Bash will have to overcome, which may make fish the better choice for use as an interactive shell. The most annoying characteristic of zsh for me is that the [HOME] and [END] keys have no effect on its command line.

There is one advantage, however, to the choice of zsh as both the interactive and login shell, as opposed to fish and Bash in that there will not be a situation where a user would switch to Bash from a fish shell to run a command in a familiar way. This is due to the fact that zsh is related to the original Bourne Shell whereas fish is not. The zsh configuration also includes expressions to avoid issues when it used to interpret Bash or other sh scripts. The configuration also sets zsh to emulate the behavior of Korn Shell (ksh), another shell in the Bourne Shell family.

Shell Prompt

In addition to the non-typical shell, Ultramaring also customizes the shell prompt with Starship. It uses the default configuration provided by the upstream project, so the prompt itself is not as interesting as Garuda's or my own custom configuration, but it is informative, depending on the current directory. Among the information it provides is information on about a Git repository if the present working directory is at some level inside the root of a repository.

Performance Optimization

In the few weeks I have used Ultramarine, I have only noticed one area of performance optimization; that is the use of the System76 Scheduler, originally developed by System76 for use with Pop Shell, and installed by the Terra repository package, system76-scheduler.

The contents of the package, as displayed by the DNF command in the Konsole window in the following image, includes a systemd service -- com.system76.Scheduler.service, a binary daemon started by the service -- /usr/bin/system76-scheduler, two .kdl and one D-Bus related .conf configuration files in the system configuration directory, and two .kdl and one D-Bus related .conf configuration files in the system data directory. The configuration files indicated as being in the system configuration directory are not actually installed by the package because they are included in the RPM spec as %ghost files; such files are if they are placed there by the user, for example by copying the configuration files from the system data directory to the system configuration directory, the package would own the files (see Directives For the %files list) .

The systemctl status query of the service is shown in the following listing.

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ sudo systemctl status com.system76.Scheduler.service
[sudo] password for brook:
● com.system76.Scheduler.service - Automatically configure CPU scheduler for responsiveness on AC
     Loaded: loaded (/usr/lib/systemd/system/com.system76.Scheduler.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Wed 2024-04-10 19:19:06 EDT; 1 day 20h ago
   Main PID: 1320 (system76-schedu)
      Tasks: 8 (limit: 28398)
     Memory: 294.5M
        CPU: 5.034s
     CGroup: /system.slice/com.system76.Scheduler.service
             ├─1320 /usr/bin/system76-scheduler daemon
             ├─1511 /usr/bin/python3 /usr/share/bcc/tools/execsnoop
             └─1787 /usr/bin/system76-scheduler pipewire

Apr 10 19:19:05 Ultramarine-16ITH6 systemd[1]: Starting com.system76.Scheduler.service - Automatically configure CPU scheduler for responsiveness on AC...
Apr 10 19:19:06 Ultramarine-16ITH6 system76-scheduler[1320]:    INFO  monitoring process IDs in realtime with execsnoop
Apr 10 19:19:06 Ultramarine-16ITH6 systemd[1]: Started com.system76.Scheduler.service - Automatically configure CPU scheduler for responsiveness on AC.

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?] took 3s
❯

According to the project's GitHub page, it is a

Scheduling service which optimizes Linux's CPU scheduler and automatically assigns process priorities for improved desktop responsiveness. Low latency CPU scheduling will be activated automatically when on AC, and the default scheduling latencies set on battery. Processes are regularly [swept] and assigned process priorities based on configuration files. ...

These changes result in a noticeable improvement in the experienced smoothness and performance of applications and games. The improved responsiveness of applications is most noticeable on older systems with budget hardware, whereas games will benefit from higher framerates and reduced jitter. This is because background applications and services will be given a smaller portion of leftover CPU budget after the active process has had the most time on the CPU.

Phoronix also describes it and its potential to improver performance:

Last week System76 released System76-Scheduler 2.0 as their Rust-written Linux desktop scheduler that serves as a user-space daemon to dynamically manage process priorities to favor performance and responsiveness. [The new version includes the ability to detect] additonal processes, Pipewire integration, new performance optimizations, and other changes. With System76-Scheduler 2.0.1 there is now a "significant" reduction in total memory and CPU consumption. This performance work includes faster process info look-ups from PIDs, reduced heap allocations in hot paths, a new garbage collection method, and more. The v2.0.1 release also has some daemon fixes, Gamescope has been added to the scheduler's detection, other game launchers also now detected, and various other updates.

A Kwin -- Plasma's window manager -- script is included which informs the System76 Scheduler which GUI window has focus so that it can be prioritized by the scheduler. However, it is not enabled by default. The following image shows the Plasma System Settings (Workspace -> Window Management -> KWin Scripts) KWin settings screen where it can be enabled.

A benchmark tools such as Phoronix Test Suite (described in Introduction to Phoronix Test Suite) is required to objectively state the performance improvement due to the use of the scheduler, but in my use of Ultramarine I noticed that starting and stopping a headless VirtualBox virtual machine is much faster. Plasma desktop effects also seem much quicker and smoother.

Wayland

The installation defaulted to Wayland on both the Flagship Edition installed on the Acer and the KDE Plasma Edition installed on the Dell and Lenovo, although Plasma had not yet defaulted to Wayland in Plasma 5.27, the version provided by Ultramarine's KDE Plasma Edition. The Plasma Edition did have one issue in which the menu of GTK applications was not displayed in Plasma's Global Menu widget, a widget that is not used in the default Plasmashell layout shipped by the distribution. The issue is discribed further, below, in the section Issues.

The only other issue with Wayland was a minor one in which there was a difference in behavior between X11 and Wayland sessions. In the Wayland session, the icon of the manually installed Firefox Developer Edition was replaced with an icon of the Wayland logo when the application was open. For some reason, this did not happen with Firefox Beta, despite both being installed as described in Installing Multiple Versions of Firefox Including Multiple Profiles. In the X11 session, when Firefox Develope Edition was open, the icon displayed in Icons Only Task Manager was the actual application icon. This seems to be an issue with Firefox Developer seen in some distributions, because even in X11 sessions the icon displayed in the taks manager is a generic one, if the application is not open.

The Flagship Edition did have a problem -- one that I hesitate to mention since I only used it very breiefly -- when connecting an external screen. I simply switched to an X11 session for the very brief time I used this edition.

Another issue some users may contend with is not related to Wayland itself but the lack of native support for Wayland in some applications. This was apparent when using Vokoscreen-NG, the screen recording application, which warned that Wayland support was not complete. Despite some instability, it actually did function much better than my first choice of screen recording application, Simple Screen Recorder

NVIDIA

All three installations of Ultramarine Linux were on Optimus laptops, the Flagship Edition on the Acer with a GeForce GTX-960M, the KDE Plasma Edition on the Dell with a GeForce 1050 Ti Mobile and on the Lenovo with a GeForce RTX-3050. In all three cases, the FOSS Nouveau driver was the only driver made available by the Anaconda installer for the Nvidia GPU, despite the Ultramarine Wiki stating that if a network is available during installation, the proprietary NVIDIA driver would be installed.

Default State of Graphics (NVIDIA Optimus with Nouveau)

Despite its limitations, for example not using the dedicated video memory and using more CPU resources, the default Nouveau driver worked well, with even external monitors working. It is my understanding the the default graphics configuration on Optimus laptops, all rendering is done by the integrated GPU and the NVIDIA GPU is used with Nouveau on demand. When the laptop is connected the Nouveau provides the output to the external display. On the Acer, on which I only used Ultramarine for a matter of hours, an external UHD TV connected via HDMI had no problems, except for having to initially use an X11 session. On the Lenovo, on which I used Ultramarine KDE Plasma Edition extensively for many weeks also had no problems, even when connecting a portable AOpen monitor with Display Port through a USB3/Thunderbolt4 connector and an HDMI to mini-HDMI connector. During the course of writing this review, the old Acer finally became unusable because of an extremely noisy fan, and was replaced by the Dell, which I had initially only used to work out the modification of the initial installation to the openSUSE Btrfs/Snapper configuration. Since then I have used it with the default Nouveau driver while continuously connected to a TV through the HDMI connector and have not had any issues. On all three laptops, with my typical usage on each, which does not include gaming, the performance was without issues.

I did eventually install the NVIDIA driver on the Legion, but before I describe the usage experience and characteristics of graphics with the NVIDIA driver below, and the installation and configuration in the section Fixes and Enhancements, I describe the characteristics of the default, as installed, configuration of Ultramarine Linux with the FOSS Nouveau driver. The next listing shows the recognized GPU on the Lenovo's PCI bus.

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ lspci | grep -e VGA
00:02.0 VGA compatible controller: Intel Corporation TigerLake-H GT1 [UHD Graphics] (rev 01)
01:00.0 VGA compatible controller: NVIDIA Corporation GA107BM [GeForce RTX 3050 Mobile] (rev a1)

The following listing shows the loaded video related kernel modules with the lsmod command. The first invocation of the command shows that the proprietary nvidia driver is not loaded. (Kernel modules which include "nvidia" are loaded, but these are not the actual graphics driver, but those provided by Linux for functions such as keyboard controls.) The actual driver used by the NVIDIA GPU is shown in the output of the second invocation of the lsmod command.

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ lsmod | grep nvidia
nvidia_wmi_ec_backlight    12288  0
video                  77824  5 nvidia_wmi_ec_backlight,ideapad_laptop,xe,i915,nouveau
wmi                    36864  6 video,nvidia_wmi_ec_backlight,wmi_bmof,ideapad_laptop,mxm_wmi,nouveau

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ lsmod | grep nouveau
nouveau              3641344  2
mxm_wmi                12288  1 nouveau
drm_gpuvm              45056  2 xe,nouveau
drm_exec               12288  3 drm_gpuvm,xe,nouveau
gpu_sched              69632  2 xe,nouveau
i2c_algo_bit           20480  3 xe,i915,nouveau
drm_display_helper    237568  3 xe,i915,nouveau
drm_ttm_helper         12288  2 xe,nouveau
ttm                   110592  4 drm_ttm_helper,xe,i915,nouveau
video                  77824  5 nvidia_wmi_ec_backlight,ideapad_laptop,xe,i915,nouveau
wmi                    36864  6 video,nvidia_wmi_ec_backlight,wmi_bmof,ideapad_laptop,mxm_wmi,nouveau
	

The driver associated with the NVIDIA GPU is also shown to be nouveau in the following listing, first in a cat output of one of the files associated with the GPU in the /sys filesystem.

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ ls -laH /sys/bus/pci/devices/0000:01:00.0/driver
total 0
drwxr-xr-x.  2 root root    0 Apr 23 20:35 .
drwxr-xr-x. 43 root root    0 Apr 23 20:35 ..
lrwxrwxrwx.  1 root root    0 Apr 23 20:35 0000:01:00.0 -> ../../../../devices/pci0000:00/0000:00:01.0/0000:01:00.0
--w-------.  1 root root 4096 Apr 23 20:35 bind
lrwxrwxrwx.  1 root root    0 Apr 23 18:28 module -> ../../../../module/nouveau
--w-------.  1 root root 4096 Apr 23 20:35 new_id
--w-------.  1 root root 4096 Apr 23 20:35 remove_id
--w-------.  1 root root 4096 Apr 23 20:35 uevent
--w-------.  1 root root 4096 Apr 23 20:35 unbind

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯

The messages generated in the journal by kwin_wayland, shown in the following listing, indicated that the Intel driver is being used for genrating video, while Nouveau is still available to use the NVIDIA GPU on demand.

Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: OpenGL vendor string:                   Intel
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: OpenGL renderer string:                 Mesa Intel(R) UHD Graphics (TGL GT1)
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: OpenGL version string:                  4.6 (Core Profile) Mesa 23.3.6
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: OpenGL shading language version string: 4.60
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: Driver:                                 Intel
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: GPU class:                              Tiger Lake
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: OpenGL version:                         4.6
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: GLSL version:                           4.60
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: Mesa version:                           23.3.6
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: X server version:             ,          1.23.2
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: Linux kernel version:                   6.8.4
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: Requires strict binding:                no
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: GLSL shaders:                           yes
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: Texture NPOT support:                   yes
Apr 23 18:50:07 Ultramarine-16ITH6 kwin_wayland[2055]: Virtual Machine:                        no

The most notable observation of the Nouveau driver with the Lenovo's NVIDIA GeForce RTX-3050 Mobile is the improvement -- since the introduction of the post-Turing GPUs -- in Nouveau's apparent ability to use and manage the GPU's internal power management features. The next listing shows that at the time the first cat command displayed in the listing was was executed, the NVIDIA GPU was fully powered on and in the maximum power consumption mode, the ACPI Device Powwer State D0 (see target for the meaning of the ACPI power state and the reason that newer NVIDIA GPUs can never be completely off). The second cat command in the listing shows some parameters of the internal power management features of the GPU, most notably the auto mode for the control parameter.

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ cat /sys/bus/pci/devices/0000:01:00.0/power_state
D0

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ cat /sys/bus/pci/devices/0000:01:00.0/power/{autosuspend_delay_ms,control,runtime_active_time,runtime_status,runtime_suspended_time,wakeup}
5000
auto
7954823
active
125317
disabled
	

Even more notable is the next listing, which shows that at some time after the command shown in the previous listing of the ACPI power state, the GPU is in a suspended state, ACPI Device Power State D3cold, even without the NVIDIA driver being loaded, another indication, apparently, that the Nouveau driver has made progress in power management of relatively newer NVIDIA post-Turing generation GPUs, or at least in querying its internal power status.

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ cat /sys/bus/pci/devices/0000:01:00.0/power_state
D3cold

brook on Ultramarine-16ITH6 ordinatechnic_content on  exp [!?]
❯ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status
suspended

NVIDIA Optimus with Proprietary Driver

In order to take full advantage of the Lenovo Legion 5i Pro's NVIDIA GeForce RTX-3050's capability, I installed and configured the proprietary NVIDIA GPU driver, available from the RPM Fusion repository. The installation and configuration process, which essentially only required installing the akmod-nvidi package, causing dependencies to be installed, and creating one configuration file with an appropriate option in the system configuration directory, is described below in the section Fixes and Enhancements.

The state of NVIDIA Optimus -- only considering use with the propietary driver -- is the worst on Fedora (and Ultramarine Linuxi, as a distribution based on Fedora) compared to of all the distributions I regularly use. This is due to the lack of utilities to switch between Optimus modes. openSUSE has SUSEPrime, Arch and derivatives have Optimus Manager, and Ubuntu and derivatives have NVIDIA Prime. SUSEPrime is the least capable and has the most quirks, but it does perform its job; Optimus Manager is extremely configurable and flexible; NVIDIA Prime is the best of the three which impressively has both a very simple to use GUI integrated in the actual NVIDIA Settings application and a command line component, which I've never needed to use. The NVIDIA Prime GUI is so good that it is aware that post-Turing generation Optimus hybrid graphics do not support completely powering off the NVIDIA GPU and only, appropriately, display options for a Hybrid Mode and a Discrete mode on these Optimus configurations, graying out the option for Integrated Mode. For this reason I find the RPM Fusion documentation's statement:

nvidia-prime is not something from NVIDIA despite the name. It's a collection of integration scripts made by canonical for Ubuntu. Better to avoid using custom scripts and to have the driver to setup appropriately if on Optimus hardware or single GPU setup. With Fedora 25 and later, everything is automatically setup.

to be surprising. (See Nvidia Optimus on Linux.)

With the other distribtutions' utilities it is only necessary to issue a command (and to re-login) to switch modes, with extensive options (more so with Optimus Manager) to also set Optimus related configuration, default graphics mode, and in the case of Optimus Manager, even set the mode automatically based on active power source when the laptop is booted. NVIDIA Prime only requires activating a toggle button in NVIDIA Settings to set the mode persistently. Fedora (and Ultramarine) in contrast requires, first, that the kernel command options

d.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1

be set in order for the NVIDIA driver to be loaded, and second, it is necessary to modify the X Window System configuration and add Option "PrimaryGPU" "yes" to a configuration file copied from the data directory to the system configuration directory to switch from Hybrid mode, the default after installation of the NVIDIA driver, to Discrete mode. Switching back to Hybrid mode requires editing the configuration to remove this option. It seems to me that the other distributions, especially Ubuntu and derivatives, provide a better experience for switching graphics modes. Fedora may have tools for launching applications specifying that the NVIDIA GPU should be used for rendering that application when already in Hybrid mode, but not for switching modes.

The necessary kernel command line options should be set automaticlly during installation of akmod-nvidia, and usually is, as it was with my RHEL 9 experience, but in this instance, while they were written automatically they were placed at the beginning of the GRUB_CMDLINE_LINUX parameter list, causing them to be ignored. It was necessary to edit /etc/default/grub to place the parameter values at the end of the parameter list and update grub.

After installation of the NVIDIA driver, the default mode is the Hybrid mode. As mentioned before, in order to be able to switch to Discrete mode, the configuration file /etc/X11/xorg.conf.d/nvidia.conf must be created by copying /usr/share/X11/xorg.conf.d/nvidia.conf, and the option PrimaryGPU added to the file. Each time a mode switch is desired, the value of the option must be changed between Yes and No, or the value set to yes for Discrete mode and commented out for Hybrid mode.

While mode changing is more inconvenient in Fedora (and Ultramarine) than in the distributions mentioned earlier, it is possible in Fedora (and Ultramarine) using the method described above. The ability to switch modes is important because of the difference in overall performance and functionality with respect to how graphics are rendered. In Hybrid mode, the integrated GPU is used by default, but the NVIDIA GPU is used on demand by applications started with appropriate environment variables. In discrete mode, all applications including the desktop environment use the NVIDIA GPU by default. This difference is apparent in the following set of images which show the GPU usage statistics, provided by nvidia-smi, in each mode, the first image showing usage in Hybrid mode and the second image showing usage in Discrete mode. The first image shows that in Hybrid mode, only Xorg is using the NVIDIA GPU, all other applications, including the desktop environment are using the integrated GPU. The second image shows that all applications, including the desktop environment, are using the NVIDIA GPU. In the second image, we see that a total of 355MiB of GPU memory is being used. In Hybrid mode, if none of the applications are started with the appropriate environment variables to cause their rendering with the discrete GPU, a similar amount of system memory would be used for graphics rendering, making the same amount unavailable to other non graphics related processes.

The first image also shows the relevant contents of /etc/X11/xorg.conf.d/nvidia.conf as the output of the fifth command displayed in the terminal window. The option that controls the mode, PrimaryGPU is shown commented out, which will cause Optimus to operate in Hybrid mode.

When the full power and functionality of the discrete GPU is not needed, the Hybrid mode offers the benefit of reduced power use. Note the difference in the output of

cat /sys/bus/pci/devices/0000:01:00.0/power_state

in the second and third commands shown in the first image. In the second command, the GPU was momentarily activated by the invocation of nvidia-smi, causing the NVIDIA GPU's ACPI device power state to be D0. By the third command, the GPU's ACPI device power state is D3cold meaning it is sleeping, thus using the minimum power possible for the GPU.

Issues

Ultramarine Linux, is an excellent distribution, in large part due to the excellence of its Fedora base. The KDE Plasma Edition provides a good Plasma experience. It does hoevever have a few issues. The first described in Installation, above, while serious will not affect anyone who had not previously installed systemd-boot. The OS did also have post-installation issues, one related to problematic hibernation specifically due to the Lenovo Legion 5i Pro's firmware, and another minor one in which the Global Menu widget -- a plasmoid not used by Ultramarine's default Plasmashell layout -- does not display the menu of GTK applications. Since encountering the latter issue, which only occurs in Wayland session, I have learned that it is not specific to Ultramarine Linux, but caused by a Wayland bug.

Hibernation

In its default state after installation was complete (including the modifications described in A Fedora Installation with an openSUSE Style Btrfs Subvolume Layout and Snapper Intergration for System Snapshots and Rollbacks) Ultramarine Linux, as with all distributions installed on the Lenovo Legion 5i Pro, had problems with hibernation. The issue was related to the ACPI OEM Platform S4 Handler shown in the following image taken from a larger image found in Section: ACPI Power States of /general-guides/1/Hardware/2/Graphics/3/Nvidia/nvidia-optimus-on-linux in which the ACPI power states are described.

The problematic hibernation behavior on the Legion -- also described in Lenovo LEGION 5i PRO 16ITH6 Review [82JF002RUS] -- required interaction with the rEFInd boot manager after hibernation was requested to ultimately enter hibernation. (I have set rEFInd as the default boot manager from which I select the GRUB of the distribution I want to boot; this is convenient when multi-booting because rEFInd can be permenantly set as the default boot manager. If a distribution's kernel has been compiled with an EFI stub, the kernel can be started directly from rEFInd bypassing its GRUB menu.)

Specifically, the observed problematic behavior on the Legion when requesting hibernation, for example, with

systemctl hibernate

the system would

1. first lock the screen and display the Plasma lock screen
2. the screen and the keyboard backlight would then turn off
3. the screen would turn back on then off
4. then the rEFInd interface would then be presented
5. at this point the rEFInd interface cab be used to turn off the laptop

The issue was easily resolvable, such that the system would directly the hibernation state, and not present the rEFInd interface, by editing the systemd-sleep configuration to override some configuration parameters. To modify the systemd-sleep parameters, I created a drop-in configuration file -- as suggested in the systemd-sleep documentation -- at /etc/systemd/sleep.conf.d/99-local.conf by copying /etc/systemd/sleep.conf and replaced the existing values of HibernationMode such that

#HibernateMode platform shutdown

became

HibernateMode shutdown

and

#HybridSleepMode suspend platform shutdown

became

HybridSleepMode suspend shutdown

The effect of the configuration modification was a change in the value written to the file /sys/power/disk by the systemd suspend/hibernate services. When effecting a system hibernation, these services cause each of the actions corresponding to the configruation parameter in the order that they appear in the paramater assignment, by writing each in turn to the file /sys/power/disk. The first action that is completed without an error is the one that is that is put in to effect. The configuration change prevented "platform" as one of the possible values that can be written to /sys/power/disk. (See systemd-hibernate.service(8) and freedesktop.org systemd-sleep Configuration Documentation.)

The following set of images show the relevant files and illustrate the effect of the configuration changes. In the first image, the Konsole window at the lower right shows the contents of /sys/power/disk before the configuration change is put into effect, where the active mode, indicated by the square brackets, is "platform". In the second image, in the lower pane of the Konsole window to the upper right of the image, the active mode is "shutdown". The Konsole window at the bottom right of the image shows the drop-in file with the overridden parameters. The top pane in the Konsole window at the top right of the second image is also an interesting illustration of hibernation after the configuration; it shows the status of systemd-hibernate.service in which it shows the system entering hibernation and resuming the next day.

GTK Application Global Menu

Another minor issue encountered during my use of Ultramarine Linux 39 KDE Plasma Edition involves the Plasma Global Menu widget and GTK applications when running under a Wayland session. The problem was that GTK applications' menus were not displayed in the widget, while KDE Qt applications' menus were, a known Wayland issue discussed in a KDE bug report and its underlying cause in a freedesktop.org merge request.

This issue is, of course not present when starting Plasma with an X11 session, but it exposes another ostensibly related -- at least in what is visible to the user -- issue in an important GTK application, GIMP. A GIMP instance started in an X11 session behaves in the same way as a GIMP instance started in Wayland session with its menu displayed within the application's window. This is in contrast to the behavior of another important GTK application, Inkscape, where if started in a Wayland session, the menu is not displayed anywhere, neither in the application's window nor in the Global Menu widget, but it is displayed when running under X11. If the problem with GIMP not displaying its menu was limited to the Wayland bug, the menu would not be displayed in the application window in Wayland session, as with GIMP. This indicates a possible problem with GIMP compilation, or some other problem.

Fixes and Enhancements

Install and Configure NVIDIA Driver

The installation of the NVIDIA proprietary driver on the Lenovo Legion 5i Pro, and its configuration to allow switching between Hybrid mode and Discrete mode, is described below. For details see the RPMFusion Optimus Howto and Fedora Quck Docs: How to Set Nvidia as Primary GPU on Optimus-based Laptops.

1. Install the NVIDIA kernel module meta package akmod-nvidia. This causes all necessary components to be installed including xorg-x11-drv-nvidia-power, which is installed separately in RPMFusion documentation.

   sudo dnf install akmod-nvidia

2. Optionally install the CUDA driver.

   sudo dnf install xorg-x11-drv-nvidia-cuda

3. The necessary systemd services, nvidia-sleep.service, nvidia-hibernate.service, nvidia-resume.service should be enabled by default. If they are not, enable them.

   sudo systemctl enable nvidia-{suspend,hibernate,resume}

4. Copy the configuration file distributed by the package to the local system-wide configuration directory.

   sudo cp -p /usr/share/X11/xorg.conf.d/nvidia.conf /etc/X11/xorg.conf.d/nvidia.conf

5. Edit /etc/X11/xorg.conf.d/nvidia.conf and add Option "PrimaryGPU" "yes" so that the contents look like:

   #This file is provided by xorg-x11-drv-nvidia
   #Do not edit
   
   Section "OutputClass"
           Identifier "nvidia"
           MatchDriver "nvidia-drm"
           Driver "nvidia"
           Option "AllowEmptyInitialConfiguration"
           Option "SLI" "Auto"
           Option "BaseMosaic" "on"
           # Added following to allow Optimus Discrete mode
           # see https://rpmfusion.org/Howto/Optimus
           #Option "PrimaryGPU" "yes"
   EndSection
   
   Section "ServerLayout"
           Identifier "layout"
           Option "AllowNVIDIAGPUScreens"
   EndSection

Change Shell to Bash/fish

References

• New kernel versions get stored in /boot/efi and dont show in grub after fedora 39 update
• Fyra Labs Terra Repository
• Fyra Labs Projects
• System76-Scheduler 2.0.1: "Significant" Reduction In CPU/RAM Use, Gamescope Detection
• Directives For the %files list
• Frya Labs Terra Repository
• Terra GitHubRepository system76-scheduler.spec File
• freedesktop.org systemd-sleep Configuration Documentation
• Fedora Quck Docs: How to Set Nvidia as Primary GPU on Optimus-based Laptops