Stupid Linux Garbage I Had To Search For And Troubleshoot

Archived here so you don't have to do that.

← Return to Articles

Linux is cool because if something breaks I know I can usually fix it myself instead of waiting for an upstream patch from a corporation to eventually fix my issue.

However, heavy lifting is hard sometimes, and finding results on the internet sucks because of SEO stupidity.

So here's my attempt to solve the problem without making a five-trillion-line Gist and praying to Steve Ballmer that it shows up on Google or Bing or Dog Pile.

May you attain enlightenment:

  1. Getting intimate with software internals.
  2. Stupid solutions that make you slap your head.
  3. Familiarity with the command line.


Last updated

Browsers, Websites, and Extensions

This isn't Linux-specific, but it's worth documenting.

HTML Elements on various websites randomly resize or reflow when you focus them

Last edited .

Symptoms and relations:

  • You've recently installed the DeepL extension to your browser to translate text.

What's happening?

The DeepL extension is fucking awful and will forcibly inject itself into and around contenteditable and textarea nodes on the off chance you want to translate your text into other languages.

How do I fix it?

Uninstall or disable the extension. Sorry, mac.


Proton does not respect the WINEPREFIX environment variable

Last edited .

Thanks to David Foerster on Ask Ubuntu(External).

Symptoms and relations:

  • You're using Steam, or you have Proton installed and plan to use it for games.
  • Setting the WINEPREFIX variable does not seem to have any effect on Proton.

What's happening?

A couple of things.

  1. Steam itself manages the WINEPREFIXes used by Proton when you launch a game through it. The Prefix will be stored in the same /steamapps/ folder that your game is installed under, inside a folder named /compatdata/.

    A screenshot of the steamapps folder, showing the compatdata folder highlighted and some example internals.

    The folders in here are all organized relative to the game's Steam App ID.

    • Non-Steam games will use an automatically generated App ID.
    • Games launched via Proton outside of steam will use a default folder named /0/.

    The folder contains relevant Proton information, and the prefix itself is under a child folder named /pfx/. There will also be backups of old, corrupted prefixes and custom-compiled versions of certain applications, such as GStreamer, in this folder.

  2. Proton is a Python-based wrapper around Wine, setting up game or engine-specific fixes as well as DXVK and managing the WINEPREFIX. Whatever you have the environment variable set to will be overwritten by Proton. Instead of just, you know, checking those environment variables and assuming good faith, Steam just made an entirely new set of environment variables for you to have to look up, and then didn't document them anywhere.

How do I fix it?

The environment variable you should be changing is this:


This will create an entire Proton compatdata folder for you instead of a simple WINEPREFIX.

If you'd like to use this with Steam, you'll need to set it as an "advanced launch option" with this syntax:

STEAM_COMPAT_DATA_PATH="/your/compatdata/path/here" %command%

Windows games on Steam fail to launch with no errors if they're on an NTFS or FAT filesystem

Last edited .

Symptoms and relations:

  • You installed a Steam game to an NTFS or FAT partition.
  • Pressing launch in Steam causes Proton to immediately exit with no error.
  • Setting the environment variable PROTON_LOG=1 generates a log with no output beyond the boilerplate showing system and game information.

What's happening?

I think this is a Wine thing? Largely, though, it's a "Unix permissions and NTFS permissions conflicting" thing, so it's not something Valve can just "patch out" without changing a lot of default settings. Basically, NTFS sucks.

So this error is due to the location of the WINEPREFIX, or more specifically, the Proton compatdata path, which is the Proton-specific variant of a WINEPREFIX.

As far as I know, Wine works by translating a program's Win16 and Win32 API calls into equivalents for your Unix/POSIX compliant system. This means that it doesn't fully implement the Windows/NTFS permission system in your filesystem, it simply translates the existing Unix permissions system into the NTFS permission system on the fly.

But the NTFS permission system is way more nuanced than the Unix system, and as a result some compromises have to be made when you mount an NTFS drive onto Linux. So when you have Steam try to run a game with Proton while its compatdata folder is also on that NTFS drive, then we're converting NTFS permissions into Unix permissions which are being fed into Wine and converted back into NTFS permissions. And if Windows/Wine/the Win32 app decides it needs to change those permissions on the filesystem... the whole system falls apart.

How do I fix it?

You've got a few options.

1. Use a different filesystem.

You can just go full scorched earth and replace the partition with an EXT one, or move the game to a different, non-NTFS partition.

This is definitely the "I give up" approach.

2. Symlink your compatdata folder.

This is the technical option. Since the problem isn't with the location where the game is stored and is, instead, a problem with the location where the WINEPREFIX is stored, you can simply put the WINEPREFIX somewhere else with normal Unix permissions and it will run fine.

If you don't know what symbolic linking is, read the Wikipedia Page on it(Wikipedia).

It can be tempting to want to symlink all of your compatdata folders to the main one you have at ~/.local/share/steam/steamapps/, and that's a completely valid fix. I don't recommend it, though: Steam's built-in game mover thingy will throw an error that the files couldn't be moved if all of your compatdata folders are pointing to the same place - frustratingly, it will only error after it already tries moving the data, which takes a lot of time. This is because the last step in Steam's moving process is to try to move the compatdata folder. In this case, it will try moving the folder to... the place it currently exists at. This results in an error, and Steam will abort the whole process. It will even leave an orphaned folder that you will have to manually delete in the target steamapps/common folder.

Instead, I recommend making a set of additional compatdata folders with conspicuous names in a folder not managed by Steam, and symlinking to those folders individually, so as not to cause these conflicts.


rEFInd boots the wrong initramfs file for your kernel flavor

Last edited .

Symptoms and relations:

  • You're probably on Arch or a derivative.
  • You are running more than 1 flavor of Linux kernel.
  • After upgrading, booting sends you to an emergency shell.
  • You can prevent the shell by pressing F2 or tab and selecting a very specific kernel, usually the last one that got upgraded.
  • You can also fix it by meticulously managing your refind.conf file, but that sucks and takes time and you have to do this every time you upgrade.

What's happening?

By default rEFInd assumes that the end of a kernel file is its version number: like, vmlinuz-linux-4.8 will obviously match with initramfs-linux-4.8, and so on with flavors like initramfs-linux-zen-4.8.

Arch decided to be different and spunky and doesn't put version numbers on its kernels whatsoever, so rEFInd fucks up and assumes that -zen is the version number it's looking for. As a result it will just load a random initramfs and vmlinuz file and assume they both work together. (Ok, it's not random, but it's based on which file got touched last so it's effectively random.)

How do I fix it?

  1. Open up /boot/EFI/refind/refind.conf
  2. Search for "extra_kernel_version_strings"
  3. If that line is commented out, uncomment it.
  4. Whatever is in there, make sure the last thing in the list is linux without anything else after it.

Here's what mine is set to:

extra_kernel_version_strings linux-rt-lts,linux-lts,linux-rt,linux-hardened,linux-zen,linux

While you're there, consider uncommenting the fold_linux_kernels option as well, which will split all your various flavors into individual bootable buttons instead of putting them all under one generic "Arch Linux" bootable option.


After a fresh install, random Steam games fail to launch with cryptic, unsearchable error messages

Last edited .

Symptoms and relations:

  • You're on Arch Linux.
  • You have a dedicated graphics video card.
  • You selected to install steam as an optional install package during your archinstall process.
  • SteamVR gives you "Error 308: A Component Is Not Working Correctly".
  • Capcom games crash with "ERR03: Failed to Initialize DirectX11".

What's happening?

Valve wants all your games to run properly when you install Steam, so as a part of its package install process it will try to install proper packages as dependencies to run things like DXVK and 32-bit drivers for your hardware.

During the archinstall process, though, it doesn't know anything about your hardware and will just assume the correct graphics device, installing the AMD or Intel drivers in the process.

Needless to say, your card won't care at all about these other drivers.

How do I fix it?

For NVidia:
pacman -S nvidia-utils lib32-nvidia-utils
For AMD:

Check the Arch Wiki(External) for specifics, but try one of these:

pacman -S vulkan-radeon lib32-vulkan-radeon && pacman -R amdvlk lib32-amdvlk pacman -S amdvlk lib32-amdvlk && pacman -R vulkan-radeon lib32-vulkan-radeon

Pacman will complain that installing this will conflict with some other provider of vulkan-driver and lib32-vulkan-driver, just have it remove the other one and tell it everything is going to be okay.


Edits to xorg.conf fail to apply, even though the file saves correctly and errors still make X11 exit

Last edited .

Symptoms and relations:

  • You're on Manjaro Linux.
  • Regardless of how much you change xorg.conf, somehow it seems to completely ignore whatever you write.
  • NVidia users will find that nvidia-settings settings don't persist after a reboot.

What's happening?

Manjaro doesn't use xorg.conf. At least, it does, but not directly. Anyway, quit touching it.

Arch doesn't generate an xorg.conf anymore by default, but that breaks spectacularly in edge cases. Because Manjaro is specifically designed to be user friendly, it overengineers a nice conf file setup particular for your computer when you first install it in a way that will ideally scale up well as you change your hardware.

Part of this setup involves not editing the main xorg.conf and instead importing a bunch of smaller conf files that it can swap out as it needs. These are found in /etc/X11/mhwd.d/, and are - of course - managed by mhwd.

How do I fix it?

Edit the files in /etc/X11/mhwd.d/ instead, or at least go to the linked folder from there and make your own conf to activate with mhwd.

On Xorg, Putting a game in fullscreen makes the whole system slow to a near-freeze until you Alt+Tab out

And also:
Steam Remote Play fails to pick up hardware-accelerated games on Xorg

Last edited .

Symptoms and relations:

  • You're on NVidia.
  • You're using proprietary drivers.
  • You're on Xorg.
  • You turned display compositing off, either per-game or manually.
  • Playing a game in fullscreen causes the entire system to immediately slow down so much it's almost like it froze.
    • Pressing Alt+Tab will resume the computer eventually like nothing happened.
  • oom_kill does nothing.
  • Making the game render in borderless windowed mode doesn't fix the problem.
  • If you make the game windowed, and then position the window perfectly so the entirety of the monitor is taken up by the game, the system freezes.
  • Turning on the compositor fixes the freeze but then the program lags.
  • Steam Remote Play does not stream hardware-accelerated windows, but the program otherwise works fine.
  • If the fullscreen game is in the background, everything is fine.
  • Sometimes after updating your driver, X11 will completely crash on boot until you downgrade.

What's happening?

Driver bug relating to the "force full composition pipeline" setting. Popped up in version 455 and comes back occasionally as a regression.

How do I fix it?

Open nvidia-settings and click "X Server Display Configuration".

Click "Advanced..." to show the full display settings.

For each monitor you have plugged in, switch to it with the dropdown labeled "Selection:" and uncheck the boxes labeled "Force Composition Pipeline" and "Force Full Composition Pipeline".

Screenshot of the NVidia settings dialogue.

Click "Apply", and optionally save your xorg.conf with the "Save to X Configuration File" button.

You may experience screen tearing. Don't buy an NVidia card next time.

On an older DVI monitor, some video modes are completely missing

Last edited .

Symptoms and relations:

  • You're on NVidia.
  • Your monitor is from like 1999.
  • You're using DVI.
  • You know for an absolute fact your monitor is specifically 720p, but every time you try to set that resolution specifically you can't find it. All you have are 1280x768 and 1280x1024.

What's happening?

Computers are fucking STUPID is what's happening.

So when the first few HDTVs and HD monitors came out some computers were still stuck with Extended VGA modes, and that meant they had no clue how to output to progressive scan TVs.

So the idea was instead you just tell your monitor to output to a 4:3 resolution and the TV would squish it to be 720p. Then make your video player display a stretched fullscreen image and presto, you can watch your DVDs on your computer!

Unfortunately, it's now $CURRENT_YEAR and your modern day graphics card has no qualms outputting a grid of pixels, but the EDID on your TV is saying "Nooo I don't support that! Don't break your TV tuner!"

Windows just doesn't care and forcibly puts 720p as one of the resolutions available if it detects similar resolutions being reported by the TV (though that doesn't stop it from trying to set 1280x768 as the default.) X11 is a bit more strict, though, and will read the EDID and take it at its word, meaning that the resolution you need just doesn't show up.

How do I fix it?

Pop open your xorg.conf or equivalent.

You've probably read in the NVidia docs(External) that you should use options like Option "ModeValidation" "NoEdidModes" or Option "UseEdidFreqs" "false".

These are wrong and the actual option isn't even in this part of the NVidia Docs. In fact, the first option straight up got deprecated without warning and doesn't work anymore. Computers are awesome (sarcasm).

The actual option you want is this:

Option "ModeValidation" "AllowNonEdidModes"

In fact, it's probably not a good idea to enable that for every single monitor or you'd be flooded with possible resolutions. You can enable non-EDID modes for individual outputs like this:

Option "ModeValidation" "DVI-D-0:AllowNonEdidModes"

You can get the names of your outputs from xrandr.