The only issue I encountered with steam was after prolonged use. I am pretty sure it was a cooling issue for me as for gaming I use an external keyboard, mouse, and display so I had the lid closed. Once I put a laptop cooler under it there have been no issues.
I have been having issues getting valve index working, but even there I’ve had no crashes when I got the loading environment partially working.
I agree that it sounds like your issue is a hardware issue.
Please elaborate on the /run/system/transient parts. The rest makes sense, but why are you creating a symlink here and then deleting it? Is this to prevent it from restarting on its own by making it fail to create a file in that location? And if so, won’t this method just keep filling up errors in the log?
From what I’ve gathered, the architecture of fprintd with the general authentication stack means that it doesn’t need to be actually started all the time. Rather, it can be dynamically started when needed to authenticate the user. Because of that, simply stopping (or even disabling) the service isn’t actually enough to properly disable fingerprint-based authentication. To do that, the service needs to be masked (ie. symlink its unit file to /dev/null to prevent it from ever being started). The problem is that fprintd’s unit file on NixOS lives on the immutable nix store filesystem, so you can’t just make a symlink there. To get around that, you create a symlink in /run/systemd/transient, which is a volatile (ie. won’t persist between reboots) way of adjusting the unit file for a particular service. By symlinking fprintd.service to /dev/null in the transient directory, we’re effectively masking the unit for as long as the current boot (It will be undone by a reboot), bypassing the RO issue of the nix store.
By creating the masked symlink and reloading the daemon, it becomes impossible for any part of the system to start fprintd, effectively disabling fingerprint authentication. By removing that symlink and reloading the daemon again, fprintd becomes accessible again.
Thanks. That helps a bunch. Your script seems to work well, so I appreciate it.
I have expanded the nixos wiki page on the framework 16 and provided guidance on how to resolve some of the known issues. I have skimmed trough this thread and if I missed anything feel free to point me to a message.
Also: if somebody here more familiar with udev rules and device IDs can help me figure out what is wrong with my attempt to disable the trackpad from being able to wake the device, I’d appreciate some help with that.
My framework 16 suddenly stopped being able to connect to hidden networks.
I’m on kernel 6.8.12, my AP is broadcasting a network with 5Ghz, and WPA3/WPA2 security, model is the WAX610 Netgear. I don’t think it’s my AP I think it’s the laptop because other devices connect to this hidden network fine. I can connect to other networks without an issue but just not hidden networks.
Not sure what logs I should post, so I’ll post NetworkManager’s and dmesg.
-- Boot b505a11d52294afe8d5d496909450d89 --
Jul 05 18:00:25 nixon systemd[1]: Starting Network Manager...
Jul 05 18:00:25 nixon systemd[1]: Started Network Manager.
Jul 05 18:08:41 nixon systemd[1]: Stopping Network Manager...
Jul 05 18:08:41 nixon systemd[1]: NetworkManager.service: Deactivated successfully.
Jul 05 18:08:41 nixon systemd[1]: Stopped Network Manager.
Jul 05 18:08:41 nixon systemd[1]: NetworkManager.service: Consumed 951ms CPU time, 12.3M memory peak, 0B memory swap peak, read 9.2M from disk, written 0B to disk, received 0B IP traffic, sent 912B IP traffic.
Jul 05 18:08:41 nixon systemd[1]: Starting Network Manager...
Jul 05 18:08:41 nixon systemd[1]: Started Network Manager.
Jul 05 18:17:50 nixon NetworkManager[8442]: /nix/store/gnqzwzvlmn3kngkj03qwqsarbs03mcv1-openresolv-3.13.2/sbin/.resolvconf-wrapped: line 888: kill: (8441) - No such process
Jul 05 18:17:50 nixon NetworkManager[8442]: clearing stale lock pid 8441
Jul 05 18:21:24 nixon NetworkManager[6297]: <warn> [1720174884.6955] device (wlp1s0): Activation: (wifi) association took too long, failing activation
Jul 05 18:21:24 nixon NetworkManager[6297]: <warn> [1720174884.8004] device (wlp1s0): Activation: failed for connection 'hypernet'
Jul 05 18:23:09 nixon NetworkManager[6297]: <warn> [1720174989.6953] device (wlp1s0): Activation: (wifi) association took too long, failing activation
Jul 05 18:23:09 nixon NetworkManager[6297]: <warn> [1720174989.8120] device (wlp1s0): Activation: failed for connection 'hypernet'
lines 406-484/484 (END)
dmesg:
[ 1978.795038] wlp1s0: authenticate with 94:a6:7e:9a:ca:e2 (local address=e8:65:38:52:53:ff)
[ 1978.809237] wlp1s0: send auth to 94:a6:7e:9a:ca:e2 (try 1/3)
[ 1978.847584] wlp1s0: authenticate with 94:a6:7e:9a:ca:e2 (local address=e8:65:38:52:53:ff)
[ 1978.857204] wlp1s0: send auth to 94:a6:7e:9a:ca:e2 (try 1/3)
[ 1978.861716] wlp1s0: authenticated
[ 1978.863291] wlp1s0: associate with 94:a6:7e:9a:ca:e2 (try 1/3)
[ 1978.877289] wlp1s0: RX AssocResp from 94:a6:7e:9a:ca:e2 (capab=0x511 status=0 aid=2)
[ 1978.910712] wlp1s0: associated
[ 1978.958920] wlp1s0: Limiting TX power to 21 (24 - 3) dBm as advertised by 94:a6:7e:9a:ca:e2
Is this a known issue and what can I do to solve it? Thanks
Edit: Changing the hidden network to broadcast does not fix the issue. I think the laptop is just not picking up the signal of the specific network? The 2 networks I’m testing it on are from the same AP.
I’m running into an issue where Chromium and Electron programs are using my dGPU instead of iGPU. Anyone know how to fix this?
Not sure if this is normal, but btop is reporting the dGPU as “gpu0” and the iGPU as “gpu1”, so maybe it’s defaulting to the lowest number? Everything else seems to be using the correct device (games on the dGPU and regular programs in the iGPU).
Been a while folks, but how does one disable the internal GPU on this laptop using nixos? 
I’m interested in a specialization but I don’t know what options to set.
Still interested on whether it can be disabled or not, though I suspect not, now.
Also, my issue came about because I wanted to run X-Plan 12, which wasn’t using the dGPU. I figured out I can use this to fix it.
https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME
Not a perfect solution as it requires manually setting a variable. I will try to build a flake or derivation for X-Plane 12 that will set that variable as an option somehow in case anyone else wants it. Will take me a while though. New to this.
Ok new question: is the fact that I am regularly updating my system flake, rebuilding, and garbage collecting the trash going to significantly reduce my SSD life? A regular linux system does update fairly often but I feel like nixos churns the disk more. Is that true or am I imagining it?
How long do you want your SSD to last?
I keep my computers for a long time, so I’d like my SSD to last for at least 10 years. I looked at the datasheet for the SN850X SSD in my FW16, and my SSD is rated for 600 TBW (terabytes written). 600 TB x 1000 GB/TB / (10 years * 365 days/year) = 164 GB/day, so as long as I’m writing less than 164 GB per day, I can expect my SSD to last the 10 years I want it to. I’ve been doing pretty heavy development of Nix expressions lately (which involves a lot of disk activity to unpack, compile, and install), and I’m still seeing less than 100 GB/day. GNOME’s System Monitor will tell you the total amount you’ve written since booting if you’re curious.
NixOS definitely has a reputation for churning a lot more than other distros, especially if you’re on unstable. Every time a library gets updated, NixOS has to update everything that depends on it. Other distros don’t do that and assume that the new library version is still compatible, so their updates are usually a lot smaller.
If you’re running X-Plane 12 (or any other game) through Steam, you can set its launch options (right-click → properties → launch options) to DRI_PRIME=1 %command%. If you have a .desktop shortcut instead, you should be able to change its properties to set the variable. If you want to go the Nix route, take a look at makeWrapper. Changing environment variables like that is so common in Nix that there’s a whole utility to make it easier.
Hmmm, but does your SSD have an MTBF of 10 years? I would suggest checking the manufacturers data sheet for an MTBF figure and then work from there on how long to expect your unit to last. It is not just the TBW figure that comes into play.
They don’t spec it.
I got a little bit distracted while writing that. 
The point I was supposed to be making was that writes don’t really matter much anymore and it’s not worth worrying about.
I’m having a weird USB issue that I suspect is related to dock power. When on my dell usb-c dock, sometimes the keyboard, mouse, and other USB peripherals connected through the dock lose power and disconnect. Tonight I noticed it during near 100% cpu usage while steam was pre-processing vulkan shaders. Is this something I can fix or do I need to get a higher power dock?
Solution to this if anyone else had a similar issue, proton was playing silly buggers with the iGPU and despite being perfectly capable in theory, it would fail when using it. Setting the DRI_PRIME environment variable to 1 when starting a program (in this case using steam launch args works great) fixes this entirely by using the dGPU instead.
Satisfactory as it turns out runs way better on linux using vulkan, as DX12 causes the instant crash I mentioned, or an enormous performance penalty.
I’m sure this isn’t really a Framework issue, but on KDE, my default microphone volume of 100% is insanely loud and boosted sounding.
This isn’t really an issue since I can turn it down, but the real problem is that whenever an audio device is connected or disconnected, it resets to 100%.
Even then, it’s not too bad, but because now my bluetooth cannot stay connected for a damn (on my desktop too), particularly when watching videos at 2x on YouTube, it resets the volume nonstop and destroys all the eardrums in Discord calls.
Any NixOS KDE users having the same issues? Can’t wait for COSMIC to stabilize…
I have documented a similar issue here: Running Guix on Framework 16 - #12 by dileas
I am able to trigger it waking up from suspend consistently, but I have observed that the controllers occasionally die after a while as well.
Seems to be a driver/power thing.
I am having issues with power profiles. I am on the latest unstable and using the latest kernel.
I have the line services.power-profiles-daemon.enable = true; as it was the recommended setting iirc
Yet according to KDE Power there are no power profiles available, and it certainly isn’t running on powersave when on battery.
Anyone know a fix or a better power profile setting?
I recently switched from Fedora40 to NixOS. I have ordered the LED matrix modules, I was wondering if there are packages or settings I need to do to use them? Is there something I can setup before I can tinker with them? I didn’t see it mentioned on the framework 16 wiki or any reference to NixOS.