steam on fedora (2026-01-29)

steam continues to be a bit inconsistent and sometimes fails to start on my fedora wayland install, but so far the best results have come from updating the steam desktop file (which you can find with the command locate steam.desktop), changing the exec line to:

Exec=/usr/bin/steam --disable-gpu --disable-gpu-compositing --disable-gpu-sandbox --in-process-gpu %U

this stops hardware acceleration from kicking in, which can sometimes cause issues with amd drivers. hilariously, i'm yet to have any gpu issues with a game itself, just the program that runs the games

update!

i've also found that some xwayland weirdness from niri can also cause it to not start. try running wl-copy --clear if steam isn't starting. yep, it's that stupid

drive format and proton quirks (2026-01-29)

i've set up quite a few multi-drive linux devices with home servers / backup servers, but i've found file permissions really annoying. your server is a media device and you just have a second drive to hold music and videos and the like, formatting it in ntfs is a great way to leapfrog the problem. it's less secure, but there isnt any code running on the drive, and if someone gets at your movies then who really cares

i learned pretty quickly that this line of thinking doesnt work for my home pc because my other drives are meant to be used for storing steam games, but wine looks at its config files (stored with the game) and confirms that theyre not owned by root before starting. ntfs just shows every file as owned by root but with 777 permissions, so wine (and therefore proton) will complain, just silently, with no error message

i figured this out using PROTON_LOGS=1 %command% in the launch options for the specific game, which is actually extremely useful for figuring out other bugs and led me to this precise error

the upshot is to just suck it up and learn how to deal with ext4 and file permissions on your secondary drives, unless you need to share that drive with a windows install

cobalt-web (2025-10-08)

this sort of deserves to be in its own self-hosted section, but i want to get it out now instead of waiting for that to happen. cobalt is a very slick website that packages up a bunch of media download tools into a simple search-like interface. it's very convenient, and while they say they don't save any of your searches (and they probably don't) you can be certain of the fact by just self-hosting the thing. unfortunately, about a year ago (~ september 2024) they took the web-element of the self-hosted program offline, saying that you can just link your own api to their website, or self-host the website yourself with a reverse proxy. i've read through the discussion and i sort of get it, but i also don't know why they would say "there is a problem with the way the website is served via docker, but instead of fixing it, or highlighting that it's an issue, we're just going to undermine the point of self-hosting and remove the functionality altogether". bizarre. anyway, here's my current cobalt docker-compose. it uses cobalt 7, which still provides a webapp. i'm going to do some more digging and see if i can use the most recent version of the api with the old web container, but i haven't got that quite work yet. i also probably don't need to have watchtower on it anymore since i'm suppressing updateds, but i want to keep it there for when i get the aforementioned api working. also also, i'm shifting the port of the api because portainer uses 9000 by default. i should probably just get rid of portainer though. make sure to update the urls with your server's local ip!

services:
  cobalt-api:
    image: ghcr.io/imputnet/cobalt:7
    restart: unless-stopped
    container_name: cobalt-api
    init: true
    ports:
      - 9002:9000/tcp
    environment:
      API_URL: "http://192.168.0.2:9002"
      API_NAME: "api"
    labels:
      - com.centurylinklabs.watchtower.scope=cobalt
  cobalt-web:
    image: ghcr.io/imputnet/cobalt:7
    restart: unless-stopped
    container_name: cobalt-web
    init: true
    ports:
      - 9001:9001/tcp
    environment:
      WEB_URL: "192.168.0.2:9001"
      API_URL: "http://192.168.0.2:9002"
    labels:
      - com.centurylinklabs.watchtower.scope=cobalt
  watchtower:
    image: ghcr.io/containrrr/watchtower
    restart: unless-stopped
    command: --cleanup --scope cobalt --interval 900 --include-restarting
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

nobara configuration (2025-07-08)

i run nobara on a thinkcentre m710q and it works pretty well! but you need to do a little bit of configuration to make it behave on this specific hardware. first up, once you've completed installation you should reboot, jump into tty with ctrl + alt + f2. from here you can log in and check the boot journal with journalctl -b and look for errors. there will be some! my process was basically to skim the journal, fix the issues i could, reboot, check, rinse and repeat.

update

run a sudo dnf update first up to get all the packages up to date

enable ssh

openssh should already be installed, but if not grab it with sudo dnf install openssh-server.

sudo systemctl enable sshd
sudo systemctl start sshd

this'll let us check fix the computer if it starts acting up at boot time

weird locale issues

vconsole acts up if your config isn't set to US or has extra nonsense in it, so we need to wipe it and rebuild the boot image with dracut

sudo touch ~/vconsole.conf
echo 'KEYMAP="us"' > ~/vconsole.conf
sudo rm /etc/vconsole.conf
sudo mv ~/vconsole.conf /etc/vconsole.conf
sudo dracut -vf

falcond profile directory

falcond doesn't make a user directory for some reason, so do that here

sudo mkdir /usr/share/falcond/profiles/user

remove yumex

i simply could not get yumex to behave and it's only useful for installing software if you don't know how to use the terminal, which you clearly do.

sudo dnf remove yumex

🚧👷‍♂️ this page is still in construction! watch this space! 👷‍♀️🚧