Ultramarine Linux is a Fedora based GNU/Linux distribution developed by Fyra Labs, a professional services provider in various information technology areas. The distribution strives to be easy to use, stable, and secure with features that benefit developers as well as casual users. Some of the value it adds to its excellent Fedora base is the inclusion of additional repositories for software not distributed by Fedora, such as the third-party RPM Fusion, which provides among other software, proprietary drivers for NVIDIA GPUs and proprietary multimedia codecs. Fyra Labs also enables its own Terra Repository, which includes some software -- although not proprietary -- that is not packaged by Fedora.
Ultramarine comes in various editions: a KDE Plasma Edition, a GNOME Edition, a Pantheon Edition, and the Flagship Edition featuring the Budgie desktop environment. This article reviews the KDE Plasma Edition release of Ultramarine 39, based on Fedora 39.
Update - 2024-05-30:
Ultramarine Linux 40 have been released. In the new version of the distribution, the KDE Plasma Edition, which is the focus of this article, now comes with the new Plasma 6 desktop environment. Despite the earlier Plasma 5.27 in Ultramarine 39 KDE Plasma Edition, the content in this article is nearly wholly relevant.
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, 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 joins 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 over two years, and an existing openSUSE Tumbleweed installation, which of course comes out-of-the box with this configuration, and has been running reliably for even longer.
Because Fedora's Anaconda installer, also used by Ultramarine, does not support complex hierarchical subvolume layouts, I converted an initial installation of Ultramarine 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.
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.
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 are 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 chose 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 KDE Plasma Edition was not as extensive as in 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, proprietary codecs preinstalled, a better -- arguably -- shell than Bash configured by default, and a promised performance improvement provided by incorporating System76 Scheduler and uresourced. All of these additions provide a fully useable system immediately after installation without requiring users spend time installing, configuring, or enabling them.
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 additions to Fedora are significant in providing a fully usable Fedora system out-of-the-box with improved performance.
The pre-installation activities, i.e., finding the appropriate download link and finding checksums and GPG signatures or keys for ISO verification, can be difficult with some distributions 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 needed files for GPG verification on one of the GitHub pages for the Flagship Edition when I first installed it on my tertiary laptop, but they seem to have disappeared since then. I could not find the GPG signature or public key for the KDE Plasma Edition installation ISO. 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 and should be improved, not only so user's can be assured of an authentic installation medium, but to protect the reputation of the distribution.
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 and the needed resources for authenticity verification using GPG, in addition to download integrity verification, is opened.
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 wrote to a USB thumb drive using dd even seemed to support persistence. The KDE Plasma Edition, however, definitely did 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, vokoscreenNG, I used to record the installation process to convert the initial installation to the openSUSE Btrfs subvolume layout with Snapper integration only had experimental support for Wayland.
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 the launcher for each of the components available in Ultramarine's version of Anaconda, which is a limited set of the possible components. (See the RHEL 9 review to see a more complete set of components available in Anaconda.)
Anaconda provides two alternative components for configuring storage for the installation target. The older and traditional component, and Blivet-GUI, an embedded advanced partitioning program. This was used to initially create Btrfs formatted partitions and create a simple subvolume layout during installation -- as shown in the following set of images -- before modifying the installed system to follow the openSUSE Btrfs subvolume layout with Snapper integration, as described in A Fedora Installation with an openSUSE Style Btrfs Subvolume Layout and Snapper Integration 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 created by systemd-boot will cause the installed system's kernel to be written to the ESP partition, mounted at /boot/efi, instead of being written to /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 such a 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 -- with a thirty-two character alpha-numeric name -- on the Legion is shown in the following image, captured from the KDE Plasma Edition live ISO environment.
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.
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 the default global theme named Ultramarine . The only notable aspect of the distribution 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.
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 repository which distributes software as precompiled RPMs for current versions of Fedora and Red Hat Enterprise Linux, including proprietary Nvidia drivers, is enabled out-of-the box, saving users a little time and effort after installation. More importantly, the inclusion of this repository allows proprietary codecs distributed through the repository to be enabled out-of-the-box.
Ultramarine also includes two of its own repositories to the Fedora 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. Two notable packages installed from the Terra repository are starship and system76-scheduler, both discussed later in the article.
Unfortunately, the available repositories, even with the additional repositories that Ultramarine makes available by default, may not have software packaged as RPMs. One such software is the hblock script for modifying /etc/hosts in order to block ads and malicious hosts. The Fedora user repository COPR is available for software packaged as RPMs that is not available in the other repositories, such as hblock, the installation of which is illustrated in the following image. (Flatpack installation is also enabled in Ultramarine, and fully supported in Discover, KDE's GUI package management application, as described below, as an alternative for software unavailable from the default RPM repositories.)
Package management on Ultramarine is typical and well known as it is closely based on Fedora. The only atypical characteristics related to package management are the availability of the additional repositories enabled by default, mentioned above. However, the most surprising and largest impression I had with regard to package management during my use of Ultramaring Linux 39 KDE Edition was not with the additional repositories, but with the availability of an expansive set of software distributed as Flatpacks not available as RPMs, and the full Flatpack support in KDE's Discover GUI package management application.
Discover allows management of Plasma addons such as themes and widgets -- or in KDE jargon, plasmoids -- and KDE application addons, such as themes for the Konsole terminal emulator in a central location, as an alternative to the K Get New Stuff module in each area of Plasma System Settings which supports addons.
Besides managing KDE specific extensions, it is a full featured package management application which can be used to discover or browser applications, install and remove applications, and perform upgrades of the system. The following set of images show the first update on one of the laptops on which I installed Ultramarine.
In this case Offline Updates were enabled by default. In this mode updates are a two-step process in which packages are downloaded by Discover and written after reboot in a specialized update environment, similar to release upgrades.
The feature that impressed me most, as mentioned above, is the Flatpack integration in Discover, as well as the availability of a large number of applications as Flatpacks, not commonly found as RPM packages. The following set of images shows browsing applications where some available applications are clearly marked as Flatpacks, and the installation of an Electron based unofficial Microsoft Outlook application.
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. But 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 scripts (/usr/share/sddm/scripts/wayland-session and /usr/share/sddm/scripts/Xsession) that are executed at user login and which actually invoke zsh as the login shell. The availability of Bash on the system is also helpful to users in that one of files sourced by zsh, /etc/zprofile, in turn sources one of the files sourced by Bash when it starts, /etc/profile.
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. It also provides an advanced interface for viewing and cycling through completion alternatives.
Besides, the superiority of fish compared to zsh as an interactive shell, the choice of zsh will require users to accept a learning curve if they find its features useful and to accept annoyances due to some zsh characteristics, or change their 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 a configuration in which fish is set as the interactive and Bash set as the login shell -- a configuration I have used in my installations since I was introduced to fish by Garuda, in that there will not be a situation where a user would have to switch to Bash from a fish interactive session to run a command with familiar command line syntax. zsh also has similarity to Bash which precludes, for example, having to execute Bash scripts with the bash -c 'path-to-script' construct, or similar constructs with the same effect, which would be necessary with fish as the interactive shell, while retaining some conveniences similar to what fish provides. 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.
So, it seems that with its choice of zsh as the default login and interactive shell, the distribution has made a compromise which optimizes the user experience, an experience in which an interactive shell session provides some of the conveniences of fish with behavior and syntax -- mostly -- similar to the familiar Bash.
In addition to the non-typical shell with an improved interactive experience, Ultramarine enhances the interactive shell experience with a customized command prompt provided by Starship. Ultramarine 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 Git repository status items if the present working directory is at some level inside the root of a repository. The following image shows the prompt as it would appear with the the default upstream configuration.
Ultramarine Linux incorporates two performance optimizations not typically found in other distributions, one provided by uresourced and the other by System76 Scheduler. A benchmark tool 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 these performance optimization, but in my use of Ultramarine I noticed that starting and stopping a headless VirtualBox virtual machine seem much faster than in the other distributions I use. Plasma desktop effects also seem much quicker and smoother.
This program, which prioritizes certain processes in order to increase responsiveness for users, was originally developed by System76 for use with its Pop Shell. It is installed from 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; if the files are created in the system configuration directory 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.
Ultramarine also includes Another performance optimization not typically found in Linux distributions -- uresourced. According to the project's Git repository README
This daemon will give resource allocations to active graphical users. Which is done by adjusting some user-X.slice and user@X.service resource allocation systemd properties on the fly. One thing this does is giving the active user an overall higher priority in comparison with other users (inactive or remote ssh sessions). But, more importantly, the user gets a memory protection assigned to them. In accordance with https://systemd.io/DESKTOP_ENVIRONMENTS/ this resource allocation will be distributed towards the user's session.slice.
uresourced is provided by an eponymous Fedora package which creates a systemd service, uresoruced.service which starts the executable /usr/libexec/uresourced. The service's status is shown in the following listing, which shows that it not only manages resources for the actual logged in user, uid 1000, and understandably for the sddm user (uid 989) since it starts the user's graphical session, but also, curiously, for the geoclue user uid 999.
brook on Ultramarine-16ITH6 ordinatechnic_content on exp [!?] took 18m50s ❯ sudo systemctl status uresourced [sudo] password for brook: ● uresourced.service - User resource assignment daemon Loaded: loaded (/usr/lib/systemd/system/uresourced.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: active (running) since Sat 2024-05-25 14:05:45 EDT; 1h 31min ago Main PID: 1884 (uresourced) Tasks: 4 (limit: 28370) Memory: 1.0M (peak: 3.8M) CPU: 18ms CGroup: /system.slice/uresourced.service └─1884 /usr/libexec/uresourced May 25 14:05:45 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user@989.service (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100) May 25 14:05:45 Ultramarine-16ITH6 systemd[1]: Started uresourced.service - User resource assignment daemon. May 25 14:18:25 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user-1000.slice (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100) May 25 14:18:25 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user@1000.service (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100) May 25 14:18:25 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user-989.slice (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100) May 25 14:18:25 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user@989.service (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100) May 25 14:18:25 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user-1000.slice (MemoryMin: 262144000, MemoryLow: 0, CPUWeight: 500, IOWeight: 500) May 25 14:18:25 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user@1000.service (MemoryMin: 0, MemoryLow: 0, CPUWeight: 100, IOWeight: 100) May 25 14:18:26 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user-1000.slice (MemoryMin: 262144000, MemoryLow: 0, CPUWeight: 500, IOWeight: 500) May 25 14:18:26 Ultramarine-16ITH6 uresourced[1884]: Setting resources on user@1000.service (MemoryMin: 262144000, MemoryLow: 0, CPUWeight: 500, IOWeight: 500)
The Ultramarine 39 installation defaulted to a Wayland session 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 39's KDE Plasma Edition. For the most part there were no problems with using Wayland instead of X and may not even be noticeable to most users depending on their hardware and the set of applications they use.
The only area where it was noticeable to me was that in a Wayland session -- as far as I could tell -- it is only possible to use an NVIDIA Optimus laptop in Hybrid mode, unlike in an X11 session, where the discrete mode could be entered by adding an option to an Xorg configuration file copied from the system data directory to the system configuration directory, as described below. (There are probably low-level manual methods to switch to the discrete mode in Wayland.)
The difference is also noticeable with the lack of native Wayland support provided by some applications. This was the case with the Vokoscreen-NG screen recording application, which as mentioned elsewhere in this article, does not support Wayland natively. It even warned that Wayland support was not complete. Despite some instability, it actually did function, unlike my first choice of screen recording application, Simple Screen Recorder, which did not work at all under Wayland.
The Flagship Edition did have a minor problem in a Wayland session -- one that I hesitate to mention since I only used it very briefly -- when connecting an external screen. I simply switched to an X11 session for the very brief time I used this edition.
I also experienced some other very minor cosmetic issues with Wayland which are described later in the article in the Issues section.
All three installations of Ultramarine Linux were on NVIDIA 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 Mobile. 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.
for example not using for example not usingDespite 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 connected through HDMI and USB-C/Thunderbolt/Display Port connectors working. It is my understanding that the default graphics configuration on Optimus laptops using the Nouveau driver, all rendering is done by the integrated GPU and the NVIDIA GPU is used on demand, with appropriate environment variables. When the laptop is connected, the Nouveau driver and NVIDIA GPU provide 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 USB-C/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, the characteristics of the default, as installed, configuration of Ultramarine Linux with the FOSS Nouveau driver are described here and shown in the following listings.
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 in the default, as installed state of Ultramarine 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 displaying the output of ls of one of the directories associated with the NVIDIA GPU, /sys/bus/pci/devices/0000:01:00.0/driver. The file named "modules" is a link to /sys/module/nouveau
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 ❯
The messages generated in the journal by kwin_wayland, shown in the following listing also indicate that, in the default state of the Ultramarine installation, the Intel driver is being used for generating 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 impression I had of the Nouveau driver with the Lenovo's NVIDIA GeForce RTX-3050 Mobile is the apparent improvement -- since the introduction of the post-Turing GPUs -- in Nouveau's ability to use and manage the GPU's internal power management features. This is evident when comparing the next two listings.
The first of the two listings shows that at the time the first cat command displayed in the listing was executed, the NVIDIA GPU was fully powered on and in the maximum power consumption mode, the ACPI Device Power State D0 (see Nvidia Optimus on Linux 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 cat command of the previous listing, whose output had indicated that the NVIDIA GPU was in the D0 state, the NVIDIA GPU had entered the lowest power suspended state -- the ACPI Device Power State D3cold, even without the NVIDIA driver being loaded. I think that this is an indication that the Nouveau driver has made progress in Runtime D3 Power Management of relatively newer NVIDIA post-Turing generation GPUs -- something that used to be only possible with the proprietary driver -- or at least in querying the internal power status of such GPUs.
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
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-nvidia package -- which caused dependencies to be installed. In order to be able to switch to discrete graphics mode, a configuration file with an appropriate option had to be created in the system configuration directory ( described further the section, Fixes and Enhancements, below.
The state of NVIDIA Optimus -- only considering use with the proprietary driver -- is the worst on Fedora (and Ultramarine Linux, 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 -- all of which, as of now, only work on Xorg sessions, as mentioned briefly, above in the section Wayland, Wayland sessions default to Hybrid mode graphics with no simple methods for switching to Discrete mode graphics.
Of the Optimus management utilities available on other distributions, 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, 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 distributions' utilities, it is only necessary to issue a command (and to re-login) to switch modes, with extensive options available (more so with Optimus Manager) to also set Optimus related configuration, including the default graphics mode, and in the case of Optimus Manager, even to 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, or issue a simple command with its CLI version, as with the other Optimus management utilities.
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 default X Window System configuration by copying the default configuration file, /usr/share/X11/xorg.conf.d/nvidia.conf, to /etc/X11/xorg.conf.d/nvidia.conf and adding Option "PrimaryGPU". The value of this option is set to "Yes"" for Discrete mode graphics and "No". Without this X configuration option, the graphics mode always defaults to Hybrid mode, the default mode after installation of the proprietary NVIDIA driver, as with the Nouveau driver. Each time a graphics mode switch is desired, the value of the option must be changed between "Yes" and "No", or alternatively -- in the case of a switch to Hybrid mode to Discrete mode -- the option commented out. The following listing shows the contents of /etc/X11/xorg.conf.d/nvidia.conf, with the option set as required for Discrete graphics mode.
#This file is copied from #/usr/share/X11/xorg.conf.d/nvidia.conf provided by xorg-x11-drv-nvidia #Edit this file instead of /usr/share/X11/xorg.conf.d/nvidia.conf Section "OutputClass" Identifier "nvidia" MatchDriver "nvidia-drm" Driver "nvidia" Option "AllowEmptyInitialConfiguration" Option "SLI" "Auto" Option "BaseMosaic" "on" # Added following for the ability to # switch to discrete graphics # and set the default mode to discrete mode # see https://rpmfusion.org/Howto/Optimus Option "PrimaryGPU" "yes" EndSection Section "ServerLayout" Identifier "layout" Option "AllowNVIDIAGPUScreens" EndSection
It seems to me that the other distributions, especially Ubuntu and derivatives, provide a better experience for switching graphics modes. Fedora, in its Gnome edition may have tools for launching applications from the GUI, specifying that the NVIDIA GPU should be used for rendering that application when already in Hybrid mode, but not for switching graphics modes.
The necessary kernel command line options to load the NVIDIA proprietary driver, and prevent the FOSS Nouveau driver from loading, should be set automatically 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.
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 in each mode, provided by nvidia-smi, 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.
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, however, 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 sessions, I have learned that it is not specific to Ultramarine Linux, but caused by a Wayland bug.
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 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 permanently 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 hibernatethe system would
The issue was easily resolvable, such that the system would directly enter 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 shutdownbecame
HibernateMode shutdownand
#HybridSleepMode suspend platform shutdownbecame
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 configuration parameter in the order that they appear in the parameter 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 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 which includes messages that indicated that the system entered hibernation and resumed from hibernation the next day.
Another minor issue that I 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. The first image of the following set of images shows a GTK application important even to KDE users, Inkscape, open in a Wayland session of Ultramarine 39 KDE Plasma Edition, in which the application's menu is not rendered in the Global Menu widget. The second image shows that in an X11 session, Inkscape's application menu is rendered in the Global Menu.
This problem seems to be caused by a known Wayland issue discussed in a KDE bug report, and its underlying cause in a freedesktop.org merge request. However, this seems to only affect versions of Plasma desktop before the recently released Plasma 6, as an Arch Linux installation with Plasma 6.0.3 does not display this issue, as evidenced by the fourth image in the following set which shows another important GTK application, GIMP, and its meru rendered in the Global Menu widget while running in Plasma 6.0.3 under a Wayland session on Arch.
As a Wayland related bug, this issue was not present when starting Plasma in an X11 session, but it exposed another ostensibly related -- at least in user visible behavior -- issue in GIMP. A GIMP instance's application menu in Ultramarine was not rendered in the Global Menu whether it was launched in an X11 or Wayland session, instead it was rendered within the application window in both cases, as shown in the first image of the following set. This was in contrast to the behavior of Inkscape, where if started in a Wayland session, the menu was not displayed anywhere, neither in the application's window nor in the Global Menu widget, but as mentioned above, it was displayed in the Global Menu when running under X11. If the problem with GIMP not displaying its menu was limited to the Wayland bug, the menu would not have been displayed in the application window in a Wayland session, as with Inkscape. This indicates a possible problem with GIMP compilation, or some other problem specific to GIMP.
Also indicating that a compilation or similar problem exists with GIMP, in addition to the menu being displayed in the application's window, whether under a Wayland or X11 session, is that it would not honor the system-wide GTK theme, unlike Inkscape, which did honor the system-wide GTK theme. In the second image in the following set, Inkscape is rendered with the Nord-ish GTK theme set as the system-wide GTK theme, but GIMP, also in the image, does not honor the system-wide GTK theme, instead it is rendered in its native dark theme. Attempting to change the theme had no effect in Ultramarine. The theme could be changed in an Arch X11 session, as shown in the third and fourth images in the following set, where the first of these is before modifying the theme setting and the second is after modifying the theme to follow the system-wide theme. Attempting to change the theme in Arch under Wayland caused GIMP to crash.
The only other issue with Wayland was a minor one in which there was a difference in behavior between X11 and Wayland sessions with respect to certain icons. 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 Developer 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 task manager is a generic one, if the application is not open.
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.
sudo dnf install akmod-nvidia
sudo dnf install xorg-x11-drv-nvidia-cuda
sudo systemctl enable nvidia-{suspend,hibernate,resume,persistenced,powerd}
sudo cp -p /usr/share/X11/xorg.conf.d/nvidia.conf /etc/X11/xorg.conf.d/nvidia.conf
#This file is copied from #/usr/share/X11/xorg.conf.d/nvidia.conf provided by xorg-x11-drv-nvidia #Edit this file instead of /usr/share/X11/xorg.conf.d/nvidia.conf Section "OutputClass" Identifier "nvidia" MatchDriver "nvidia-drm" Driver "nvidia" Option "AllowEmptyInitialConfiguration" Option "SLI" "Auto" Option "BaseMosaic" "on" # Added following for the ability to # switch to discrete graphics # and set the default mode to discrete mode # see https://rpmfusion.org/Howto/Optimus Option "PrimaryGPU" "yes" EndSection Section "ServerLayout" Identifier "layout" Option "AllowNVIDIAGPUScreens" EndSectionTo switch back to Hybrid mode, comment out the parameter or change its value to no.
NVreg_DynamicPowerManagement
be set. For my Lenovo Legion 5i Pro, the appropriate value for this parameter is 0x02
, which enables "fine-grained" power management. This setting is only effective in post-Turing generation Nvidia GPU's and different generations of GPU microarchitectures, will behave differently. (See Nvidia Optimus on Linux and Chapter 22. PCI-Express Runtime D3 (RTD3) Power Management of NVIDIA Accelerated Linux Graphics Driver README and Installation Guide).
options nvidia NVreg_DynamicPowerManagement=0x02or the appropriate value for your particular generation of GPU.