Stupid Linux Garbage I Had To Search For And Troubleshoot

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.

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/.

   

   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:

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.

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.

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:

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.

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:

For AMD:

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

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.

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.