Desktop Configuration

• Current distribution: Fedora 44 Silverblue
• Current hardware: AMD X570 + 5900X + RX580 Desktop, ThinkPad T16 Gen 1 (Intel)

Data to Back Up

• ~/.gitconfig
• ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/
• ~/Documents/
• ~/Pictures/
• ~/Projects/
• /etc/NetworkManager/system-connections/

Machine Setup

Operating System Installation

1. Initialize a thumb drive using the Fedora Media Writer using an image from Fedora Silverblue.
2. On ThinkPad, enable Microsoft's third-party Secure Boot CA in "BIOS."
3. Boot to the Fedora Silverblue install media.
4. Reclaim disk space. Disk encryption is good; either use Opal (weaker) or LUKS (stronger).

System Configuration

1. Reboot into the newly installed Fedora, enable additional repositories, and set up the first user.

2. Update Fedora using the GNOME Software Center (and reboot).

3. Add third-party repositories and install system-level tools and CLI utilities, then reboot:

   sudo cp brave-browser.repo google-chrome.repo vscode.repo /etc/yum.repos.d/
   rpm-ostree install ansible brave-browser code dbus-tools gh gnome-boxes gnome-tweaks google-chrome-stable libguestfs-tools libvirt-daemon-kvm openssh-askpass podman-compose qemu-kvm steam-devices virt-install virt-manager
   

4. Enable the libvirt socket and install a polkit rule so members of wheel can manage libvirt without an auth prompt (the unix socket is already world-rw on Fedora, so polkit is the only gate; no group membership is needed):

   sudo systemctl enable --now libvirtd.socket
   sudo cp libvirt-wheel.rules /etc/polkit-1/rules.d/49-libvirt-wheel.rules
   

5. Add the Flathub remote system-wide. A raw Fedora installation only has the fedora remote, and enabling third-party repositories during setup adds a filtered Flathub definition, so the playbook's Flatpak installs fail until both are handled:

   sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
   sudo flatpak remote-modify --enable --no-filter flathub
   

6. Configure newly installed packages and desktop environment settings:

   cd ~/Projects/desktop-configuration/
   ansible-playbook --check -vvv local.yml  # Optional Very Verbose Dry Run
   ansible-playbook local.yml
   

7. Disable the GNOME Keyring password (redundant with LUKS on a single-user system): open Passwords and Keys (installed by the playbook), right-click the Login keyring, select Change Password, enter the current password, and leave the new password blank.

8. Authenticate the GitHub CLI:

   gh config set -h github.com git_protocol ssh
   

9. To disable Steam scaling: Steam -> Settings -> Interface -> Scale text and icons to match monitor settings.

LUKS Unlock with TPM2 + PIN

After installing with LUKS encryption, enroll the TPM2 chip so the disk can be unlocked with a PIN instead of a full passphrase. The existing passphrase is kept as a fallback.

Initial Setup

1. Enroll TPM2 with PIN:

   LUKS_DEVICE=$(sudo blkid --match-token TYPE=crypto_LUKS -o device)
   sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 --tpm2-with-pin=yes "$LUKS_DEVICE"
   

2. Add tpm2-device=auto to the options for the LUKS device in /etc/crypttab and regenerate the initramfs to include the crypttab change:

   sudo sed -i 's/discard$/discard,tpm2-device=auto/' /etc/crypttab
   rpm-ostree initramfs-etc --track=/etc/crypttab
   

3. Reboot. The system should now prompt for the TPM2 PIN instead of the full passphrase.

Re-Enrolling After BIOS/Secure Boot Changes

BIOS updates, Secure Boot key changes, or shim updates will change PCR 7 values, causing TPM unlock to fail. The system will fall back to the full LUKS passphrase. To re-enroll:

   LUKS_DEVICE=$(sudo blkid --match-token TYPE=crypto_LUKS -o device)
   sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7 --tpm2-with-pin=yes "$LUKS_DEVICE"

WWAN / Mobile Broadband (ThinkPad)

The ThinkPad T16 Gen 1 has an Intel XMM7560 (Fibocom L860-GL) LTE modem using the iosm kernel driver.

1. Verify the modem is detected by ModemManager:

   mmcli -L
   

2. If the modem is listed but not connected, check its status:

   mmcli -m $(mmcli -L | grep -oP '/Modem/\K\d+')
   

3. Configure the mobile broadband connection in GNOME Settings under Network. The mobile-broadband-provider-info package allows GNOME to auto-detect the carrier APN from the SIM card.

Wireguard VPN Setup

   sudo nmcli connection import type wireguard file "$filename"

Flipper Zero

USB Access (udev)

Updating the firmware over USB needs udev rules granting the local user access to the serial and DFU interfaces. This covers qFlipper / the Momentum web updater (the Flipper's STM32) and flashing the WiFi dev board (its ESP32-S2). The dev board rule also tells ModemManager to leave the port alone — otherwise it grabs the ttyACM device and the web flasher fails with "Failed to open serial port."

1. Write the rules file:

   sudo tee /etc/udev/rules.d/42-flipperzero.rules > /dev/null <<'EOF'
   # Flipper Zero serial port
   SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", ATTRS{manufacturer}=="Flipper Devices Inc.", TAG+="uaccess"
   
   # Flipper Zero DFU
   SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", ATTRS{manufacturer}=="STMicroelectronics", TAG+="uaccess"
   
   # Flipper Zero WiFi dev board (ESP32-S2): serial access + keep ModemManager off it
   SUBSYSTEMS=="usb", ATTRS{idVendor}=="303a", ATTRS{idProduct}=="0002", ATTRS{manufacturer}=="Espressif", TAG+="uaccess", ENV{ID_MM_DEVICE_IGNORE}="1"
   EOF
   

2. Reload the rules, then unplug and replug the device so the rule applies:

   sudo udevadm control --reload-rules && sudo udevadm trigger
   

Momentum Firmware

Momentum is the custom firmware used here. The web updater is the simplest install:

1. Close qFlipper — only one tool may access the Flipper at a time.
2. Connect the Flipper over USB and open https://momentum-fw.dev/update in a WebSerial browser (Chrome or Edge; Firefox and Safari are unsupported).
3. Follow the prompts and wait for the Flipper to reboot into the new firmware.

Firmware lives in flash while user data is on the SD card, so updating never wipes your files. (qFlipper alternative: copy the release folder into SD/update, then run Update from the Flipper's file menu.)

WiFi Dev Board (Marauder)

Marauder is the most useful firmware for the official ESP32-S2 WiFi dev board (Wi-Fi scanning, sniffing, deauth). Detach the board from the Flipper and flash it standalone through its own USB-C port; the Flipper takes no part in flashing. Reattach it afterward to run the Marauder app.

The case's two plungers are unlabeled but press through to the board's BOOT and RESET buttons (silkscreened B0/RST underneath). To tell them apart, tap one while the board is plugged in: RESET reboots it (LED blinks, the serial device re-enumerates), while BOOT alone does nothing. (Holding BOOT alone for ~10 seconds resets the board's settings to default.)

1. Put the board into bootloader mode: hold BOOT, press and release RESET, wait ~5 seconds, then release BOOT.
2. In Chrome or Edge, open https://fzeeflasher.com, click Connect, and select the board's serial device.
3. Choose Flipper Dev Board as the board, Marauder firmware, version latest, then click PROGRAM.
4. Press RESET once when flashing completes.

Launch the [WiFi] Marauder app on the Flipper with the board attached to use it.

Dev Containers with Podman

VSCode runs on the host (the code RPM), not as a Flatpak — the Dev Containers extension shells out to the container CLI and bind-mounts the workspace, both of which the Flatpak sandbox breaks. The playbook sets "dev.containers.dockerPath": "podman" in the VSCode user settings so the extension drives rootless Podman directly. Caveats when using .devcontainer:

• File ownership / UID mapping: if files created inside the container show as owned by the wrong user, add --userns=keep-id to the project's devcontainer.json:

   "runArgs": ["--userns=keep-id"]
  

• SELinux bind mounts: Silverblue runs SELinux enforcing. If a custom mount hits "permission denied," append :Z to it for per-container relabeling (the workspace mount is handled automatically).

Workarounds

• Intel laptop CPUs sometimes need "panel self refresh" or c-states altered to fix glitches:

   rpm-ostree kargs --append=i915.enable_psr=0
   rpm-ostree kargs --append=intel_idle.max_cstate=2
  

• Missing Flatpak icons (untested fix):

   sudo gtk-update-icon-cache -f /var/lib/flatpak/exports/share/icons/hicolor/
   sudo gtk4-update-icon-cache -f /var/lib/flatpak/exports/share/icons/hicolor/
  

Coexistence with Windows

After a complete wipe of the EFI partition, Windows won't have its required resources to boot.

1. Boot from Windows install media (F8 for the boot menu on Asus boards and F12 on ThinkPad).

2. Use diskpart to assign a drive letter (like G) to the EFI partition (which should be labeled System).

3. Restore boot files:

   G:\EFI
   bootrec /rebuildbcd
   

4. Booting to Windows should now appear as an option from the recovery menus.

5. Use the GUI boot repair tool, or attempt it from the CLI.

6. Review BIOS/firmware settings to restore Fedora Linux as the default.

Upgrading

1. Only if needed: Remove RPM Fusion repositories for current Fedora:

   rpm-ostree remove rpmfusion-free-release-$(rpm -E %fedora)-1.noarch
   

2. Rebase on the next release (and resolve issues with any missing packages):

   rpm-ostree rebase fedora:fedora/$(expr $(rpm -E %fedora) + 1)/x86_64/silverblue
   

3. Only if needed: Add RPM Fusion repositories for next Fedora:

   rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(expr $(rpm -E %fedora) + 1).noarch.rpm
   

4. Reboot.

SSH with a FIDO2 Token

OpenSSH has built-in FIDO2 USB HID support and libfido2 is part of the base image, so nothing extra needs installing. The key is non-resident: the private key lives only inside the token, and the file in ~/.ssh is a key handle (a stub) the token needs in order to sign. The token alone cannot sign without the handle, and the handle alone is useless without the token. Every signature requires a touch, and no PIN is asked for.

Generating the Key

Run this on the host and touch the token when it blinks. If the token has a PIN set, ssh-keygen asks for it once here and never again for signing. Do not add -O resident (it copies the handle onto the token, making token plus PIN sufficient) or -O verify-required (it demands the PIN on every signature). A passphrase on the handle is optional:

   ssh-keygen -t ed25519-sk -C "main-keychain"

Tokens without Ed25519 support need -t ecdsa-sk instead.

Backing Up and Moving the Key Handle

Because the handle is not on the token, it cannot be recovered from the token on a new machine. Copy ~/.ssh/id_ed25519_sk and ~/.ssh/id_ed25519_sk.pub to the new machine (and keep a copy somewhere safe). The handle is not a secret on its own, but with the token it is, so treat the copy like a key.

The SSH Agent

GNOME's default agent (gcr-ssh-agent) deadlocks on FIDO2 -sk keys: to load one, it runs ssh-add against its own socket and then waits on it, so the token is never asked to sign. The playbook masks it and uses OpenSSH's ssh-agent.socket instead, pointing SSH_AUTH_SOCK at it through ~/.config/environment.d. Log out and back in after the first run so the session picks up the new socket.

~/.ssh/config gets AddKeysToAgent yes, so the first ssh of a session asks for the key handle's passphrase, takes a touch, and hands the key to the agent. In a terminal the passphrase is asked for there; GUI clients such as VSCode get a gnome-ssh-askpass dialog (from openssh-askpass, installed above). The agent holds the key until logout, so the passphrase is asked for once per login. After that, signatures need only a touch, signaled by the token's blinking LED.

The agent itself runs without SSH_ASKPASS. It never needs to prompt, and otherwise it would show a "confirm user presence" notice on every signature whose keyboard grab triggers GNOME Shell's inhibit-shortcuts dialog.

Testing

   ssh -T git@github.com     # touch when the token blinks

Removing an Old Resident Key from the Token

Tokens that previously held a resident (-O resident) SSH key still carry that credential. Removing it needs fido2-token, which is easiest to run from a toolbox (containers are privileged and bind-mount /dev):

   toolbox create   # only if no container exists yet
   toolbox enter
   sudo dnf install -y fido2-tools
   fido2-token -L                        # find the token's /dev/hidrawX
   fido2-token -L -r /dev/hidrawX        # list relying parties; SSH keys are under "ssh:"
   fido2-token -L -k ssh: /dev/hidrawX   # list the credential IDs
   fido2-token -D -i <credential-id> /dev/hidrawX

Each of these prompts for the token PIN.

OpenMW

1. Install the Flatpak:

   flatpak install flathub org.openmw.OpenMW
   

2. Download the "backup" file from GOG.

3. Extract the backup:

   mkdir morrowind
   mv setup_tes_morrowind_goty_2.0.0.7.exe morrowind/
   cd morrowind
   innoextract setup_tes_morrowind_goty_2.0.0.7.exe
   mv app/Data\ Files/* ~/.var/app/org.openmw.OpenMW/data/openmw/data/