Why Linux Desktop is still struggling

#linux #fedora #troubleshooting

It has been 6 months since I switched to using Linux as the main OS on my desktop. I did try to use Linux as a main OS back then when I was in high school and college but I quickly switch back to Windows after a few days. Now as a developer with experience in DevOps, having used Linux in server environments for years, I’m pretty confident that I have a good grasp of Linux, so I thought this time I would have a smoother experience, but boy, was I wrong.

Ubuntu 24.04 LTS

I initially chose Ubuntu LTS because it is a stable version with a server-grade mindset. Stability should be the top priority. However, I was immediately greeted with several problems:

Secure Boot

Upon installing the proprietary Nvidia driver and rebooting, the OS just booted into a black screen because the kernel module was not accepted under Secure Boot.

What actually needs to be “signed” here is typically the DKMS-built kernel module (not the userspace driver). On Ubuntu, DKMS packages are supposed to prompt you to create/enroll a Machine Owner Key (MOK) so the kernel will accept third‑party modules with Secure Boot enabled, but that flow is easy to miss if you reboot at the wrong time or skip the MOK enrollment screen.

It helped me learn how to blacklist the Nvidia driver so the open-source Nouveau driver is used instead, allowing me to get into the OS again. To do this, you can edit the boot parameters in Grub by pressing e and adding modprobe.blacklist=nvidia to the line starting with linux. This tells the kernel not to load the proprietary driver, forcing the system to fall back to Nouveau. I know I can disable Secure Boot in the BIOS, but that is not fun. I love tinkering and learning new things.

The suspend/resume issue

The Nvidia driver has some bugs that can prevent the system from going to sleep or resuming from sleep, often resulting in a black screen. You need to keep your driver up to date and ensure these Nvidia systemd services are enabled to handle the power management transitions correctly:

sudo systemctl enable nvidia-suspend.service
sudo systemctl enable nvidia-hibernate.service
sudo systemctl enable nvidia-resume.service

Note: these services are specifically for NVIDIA’s newer (still described as experimental in NVIDIA’s README) /proc/driver/nvidia/suspend power-management path. The classic/default “kernel callback” suspend path does not require them.

Additionally, you might see advice to set NVreg_PreserveVideoMemoryAllocations=1. That option is only relevant if you’re using the /proc/driver/nvidia/suspend mechanism and want the driver to try to preserve all VRAM allocations across suspend/resume.

If you enable it, you may also need to ensure the driver has a suitable place to save VRAM contents (NVIDIA documents NVreg_TemporaryFilePath=...), and that the chosen filesystem is large enough and supports unnamed temporary files.

The TTY issue

In Linux, you can usually press Ctrl + Alt + F3 (or F4/F5/…) to switch from the GUI to a text console (TTY) to troubleshoot issues when the GUI crashes (often F1 returns to the graphical session). But one day, that combination just stopped working for me. I spent days trying to debug until I figured out it was a bug in a newly updated kernel. When I rolled back to an older kernel, it worked again.

Wayland vs X11

I switched to Wayland because I heard it is the future of Linux and that X11 will be phased out eventually. However, I encountered many graphical glitches with Steam, Wine apps, and GNOME extensions. Later, I figured out those problems were fixed in newer versions of Wayland; when I switched to Fedora, they disappeared.

Again, this shows that the stability mindset of a server environment does not always apply to the Linux Desktop. Things are constantly changing and being fixed, so you often need to stay on the bleeding edge and be ready to troubleshoot new problems that arise when updating. This is when I made the decision to install Fedora, which is what I’m using now.

Fedora 42 (and later upgraded to 43)

The swap partition

When I was using Ubuntu, I ran out of disk space, so I shrunk my Windows partition and created some new partitions to store data. I used LVM because I thought it would help me dynamically extend or shrink partitions when needed, and in that process, I moved the swap partition into the LVM volume. That decision bit me later when installing Fedora.

Fedora installation detects the swap partition and may add a resume=UUID=... kernel parameter (used for hibernation resume). If that resume= points to a swap device that isn’t available when the initramfs tries to resume (wrong UUID, missing device mapping, swap moved, etc.), you can get an early-boot hang.

To fix this, I had to edit the boot command in the Grub menu to remove the resume parameter temporarily.

Once logged in, there are a few “correct” ways to make it permanent depending on how your Fedora bootloader is set up (BLS, UEFI vs BIOS). One relatively robust approach is to remove the argument from all installed kernels using grubby:

sudo grubby --remove-args="resume=UUID=<YOUR_SWAP_UUID>" --update-kernel=ALL

If you prefer editing /etc/default/grub, be aware Fedora’s recommended grub2-mkconfig output path differs between BIOS and UEFI installs (and on Fedora, kernel command line is often managed via BLS entries). For example, on UEFI systems it’s commonly:

sudo grub2-mkconfig -o /etc/grub2-efi.cfg
# Edit /etc/default/grub and remove the resume= part from GRUB_CMDLINE_LINUX
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Ubuntu is broken (and it is Secure Boot again)

Then I tried to get back into Ubuntu from Fedora’s Grub menu. It refused to boot. After struggling for a while, I figured out the issue lies in how Secure Boot works with multiple distributions.

When Secure Boot is enabled, the first thing loaded is a small “shim” from the OS vendor (like Fedora or Ubuntu). This shim is signed by Microsoft, so the motherboard’s firmware trusts it.

An important nuance: shim carries (and temporarily adds) the distribution’s own Secure Boot key, and optionally MOK keys, so the trust chain typically becomes “this distro’s shim → this distro’s GRUB → this distro’s kernels/modules (or MOK-signed ones)”.

Because I was using Fedora’s shim/GRUB path, it was trying to boot Ubuntu in a way that didn’t line up with Ubuntu’s signing/trust setup, and Secure Boot blocked it.

The fix is to modify Fedora’s Grub configuration to “chainload” Ubuntu’s shim instead of trying to boot its kernel directly. By adding a custom entry to /etc/grub.d/40_custom, I can tell Grub to hand control back to Ubuntu’s trusted shim:

menuentry 'Ubuntu (via Shim)' {
    search --no-floppy --fs-uuid --set=root <YOUR_EFI_PARTITION_UUID>
    chainloader /EFI/ubuntu/shimx64.efi
}

After adding this and regenerating GRUB’s config, I could finally dual-boot both systems without disabling Secure Boot. (Again, the exact grub2-mkconfig -o ... path depends on BIOS vs UEFI.)

Nvidia driver (again)

When installing an “out-of-tree” driver in Linux, the driver must be compiled against the kernel headers. This compilation process happens synchronously on Ubuntu; you must wait for it to finish before the terminal or GUI tells you the installation is complete. But in Fedora, this happens asynchronously. The command will claim the installation has finished, but the compilation actually continues in the background.

The compilation can run after installation, or it can run at boot if akmods detects that the driver hasn’t been built for the current kernel yet. The problem is that this boot-time process may have little/no visual indicator: you can end up staring at a blank screen while the module build finishes.

If you want to avoid “mystery waiting”, you can explicitly trigger and wait for the build before rebooting:

sudo akmods --force

So after you install Nvidia drivers on Fedora, either leave your PC on for a little while or, if you need to reboot immediately, don’t panic if you see a black screen. Just wait; it will boot into the desktop eventually.

Hardware decoding

If you use an Nvidia GPU, hardware video decoding in browsers often won’t work out of the box. This is because most Linux browsers use VA-API (the common Linux video acceleration API), and NVIDIA historically hasn’t provided a first-party VA-API implementation for its proprietary driver.

To bridge this gap, you can install nvidia-vaapi-driver, which is a VA-API implementation that uses NVIDIA’s NVDEC as a backend (it’s primarily designed for Firefox).

sudo dnf install nvidia-vaapi-driver

After installation, you may need to set environment variables (especially on newer libva) so VA-API loads the NVIDIA driver:

  • LIBVA_DRIVER_NAME=nvidia

NVD_BACKEND can be used to select a backend (direct is the default in upstream, and egl exists too), but you don’t necessarily need to set it unless you’re troubleshooting.

In Firefox, upstream documents a couple of required about:config tweaks depending on your Firefox version.

  • media.ffmpeg.vaapi.enabled = true (required up to Firefox 137)
  • media.hardware-video-decoding.force-enabled = true (required since Firefox 137)

They also note MOZ_DISABLE_RDD_SANDBOX=1 is required, and on X11 you may need gfx.x11-egl.force-enabled = true.

The UI lag when CPU usage at 100%

When you run something that consumes 100% of the CPU (especially if it fully saturates all cores), the UI can start lagging, video will stutter, and scrolling will be choppy. This isn’t unique to Linux, but Linux desktops can be particularly sensitive if your workload leaves little CPU time for the compositor and input handling.

Changing kernels can help in some cases, but it’s not a guaranteed fix (for example, the “Zen kernel” is mainly a patchset and still uses the mainstream Linux scheduler).

Practical mitigations that often help more reliably:

  • Don’t saturate the machine completely (e.g. compile with make -j$(nproc --ignore=1) or similar).
  • Run heavy jobs at a lower priority: nice -n 19 <command> (and optionally ionice for disk-heavy tasks).
  • Use cgroups/systemd scopes to limit CPU weight for background builds.

I haven’t fully solved this yet on my setup, but these reduce the pain without touching Secure Boot.

Conclusion

There are so many things that can break in the Linux Desktop experience. I can’t imagine an average user going through all of this and still keeping their sanity. There are so many low-level choices: which distro, X11 vs. Wayland, KDE or GNOME, Vulkan or OpenGL, Qt or GTK, and so on.

In other OSs like Windows or macOS, there is no such fragmentation. Microsoft provides the Windows Display Driver Model (WDDM) and the Desktop Window Manager (DWM), while Apple has its tightly integrated Quartz, Metal, and Core Graphics stack. These are single, unified paths that every hardware vendor and software developer must follow.

While this fragmentation is a blessing for freedom and customization, it is a curse for the “it just works” experience. For an average user, the polish of a unified system is hard to beat.