NixOS on the Framework Laptop 16

Framework Laptop 16 Linux
43

Something important to mention: you don’t have to define absolutely everything through Nix right away, as impermanence also lets you whitelist some folders and files that you’d want to persist.
Which is also how it lets you just have some personal data on your machine :sweat_smile:

You can potentially set a loooot of files to persist for manually for stuff configured outside of Nix and, over time, clean it up.

Regarding your password manager example, this is definitely something that would be persisted, I can’t think of a reasonable way to manage your password database declaratively.

2 Likes
44

I’m also on Nix Unstable. I also tried explicitly enabling a service like systemd-resolved, but that also doesn’t help.
I’ll probably try and do some more debugging this afternoon

45

Let me know if you find something, good luck!

1 Like
46

Its not done, of course, but it probably never will be. Here you go here’s my bad nix config

1 Like
47

I seem to have solved it by switching to systemd-networkd from dhcpcd.
Switching was as simple as adding

networking.useNetworkd = true;
systemd.network.enable = true;

I also disabled the wait-online service to improve boot times by a lot (~5 secs), this shouldn’t cause any drawbacks on non-server clients.

systemd.network.wait-online.enable = false;

So far resuming from sleep didn’t cause DNS resolution to not work.

2 Likes
48

Not sure if this has been posted anywhere yet, but I hacked up a quick way to add the kernel patch from [ANNOUNCEMENT] Adaptive Sync / Freesync / VRR not working to get VRR working under NixOS without waiting for kernel 6.9.

The first file just creates a derivation of the amdgpu kernel module. I saved this as amdgpu-kernel-module.nix in the same folder as my system config file.

{ pkgs, lib, kernel ? pkgs.linuxPackages_latest.kernel }:

pkgs.stdenv.mkDerivation {
  pname = "amdgpu-kernel-module";
  inherit (kernel) src version postPatch nativeBuildInputs;

  kernel_dev = kernel.dev;
  kernelVersion = kernel.modDirVersion;

  modulePath = "drivers/gpu/drm/amd/amdgpu";

  buildPhase = ''
    BUILT_KERNEL=$kernel_dev/lib/modules/$kernelVersion/build

    cp $BUILT_KERNEL/Module.symvers .
    cp $BUILT_KERNEL/.config        .
    cp $kernel_dev/vmlinux          .

    make "-j$NIX_BUILD_CORES" modules_prepare
    make "-j$NIX_BUILD_CORES" M=$modulePath modules
  '';

  installPhase = ''
    make \
      INSTALL_MOD_PATH="$out" \
      XZ="xz -T$NIX_BUILD_CORES" \
      M="$modulePath" \
      modules_install
  '';

  meta = {
    description = "AMD GPU kernel module";
    license = lib.licenses.gpl3;
  };
}

Then in you system config file, you need to call the package, add it as an extra-kernel module and apply the patch, like so:

{ pkgs, config, ... }:
let
  amdgpu-kernel-module = pkgs.callPackage ./amdgpu-kernel-module.nix {
    kernel = config.boot.kernelPackages.kernel;
  };
in
{
# ...your normal config.nix file

boot.extraModulePackages = [
    (amdgpu-kernel-module.overrideAttrs (_: {
      patches = [
        # vrr fix
        (pkgs.fetchurl {
          url = "https://gitlab.freedesktop.org/agd5f/linux/-/commit/2f14c0c8cae8e9e3b603a3f91909baba66540027.diff";
          hash = "sha256-0++twr9t4AkJXZfj0aHGMVDuOhxtLP/q2d4FGfggnww=";
        })
      ];
    }))
  ];
}

This patches a single in-tree kernel module and then loads it as if it were an out-of-tree kernel module. This also means, you won’t need to recompile the whole kernel, this just recompiles the amdgpu module, which takes about 1m30s on my Framework 16.
After applying this patch you can just enable VRR in your favorite compositor or desktop like normal.

I tested this with the linuxPackages_latest package, not sure if it will work with older kernels.

5 Likes
49

Thanks for sharing, initial tests seem good!

1 Like
50

I had been putting it into boot.kernelPatches and recompiling the whole thing and yeah, this seems like a better idea.

51

I also did that at first, but waiting 20 minutes was a bit too long for me

53

Somebody is working on adding the FW in nixos/nixos-hardware: Add framework 16 by jkoking · Pull Request #899 · NixOS/nixos-hardware · GitHub

Mostly the FW13 config + enabling QMK support for now.

3 Likes
54

I’ve been able to get the via instance at keyboard.frame.work to modify my keyboard, and I’ve also been able to get frameworks fork of qmk firmware to work, but I’ve been unable to get a local instance via or vial to work. I’ll probably do some more tinkering this weekend, but I was wondering if anyone had a better understanding of the interaction between qmk and the via keyboard definitions, and if there might be a way to make a local instance work.

55

How’s the gaming performance and stability (w/ the gpu module) for y’all?

I’m crashing a lot in THE FINALS and occasionally in Helldivers. Those games, plus DOOM Eternal, are also stuttering horribly every few seconds.

My guess is the stuttering is from just having a single stick of 32G, but the persistent crashing is unexpected.

I’m on nixos-unstable, using plasma wayland.

56

You really should never use Ryzen products without two sticks of RAM. I would try a second equal stick of RAM (same product, capacity, speed, etc…). I assume you have already checked out protondb for any fixes?

57

I was crashing a lot in helldiver’s, but I was also crashing on arch on my desktop with a 7900xtx, as well as on Windows with the helldiver’s “game ready” driver. That game is just pretty buggy on Radeon in my experience.

58

Hey folks. I’m new to NixOS (played around a bit with setting it up with Hyprland on my desktop on a spare drive) Getting my 16 in a few days for my new work PC and want to run NixOS (probably with KDE for a full-featured DE).

I’ve been reading a good bit about using LUKS for encryption and impermanence to make everything fully configured by Nix. Is this a hassle to set up? How much would this interfere with daily operation in the future? I like the security that gives, but also don’t want to hamstring myself maintaining a setup I don’t fully understand.

Other than that, the PPD and hardware configuration info in this thread is super helpful. Excited to get to tinkering!

59

Hi !
A basic LUKS setup (just a password) is really simple, especially if you use disko, here is how it’s defined in my config.

I wouldn’t say that impermanence in itself is that difficult to setup, but you will have to think about:

  • What FS do you want to use: tmpfs, btrfs or zfs => a classic ext4 setup won’t work. I went for ZFS, but from what I see btrfs is the most common choice out there.
  • What you need to persist, which may be a lot of things (some system files, caches, etc…). Not that it is hard to to do, just something else to keep in mind.
1 Like
60

You can do impermanence with ext4 + LVM if you want. (Personally, though, I haven’t bothered with impermanence yet.)

Here’s the disko configuration I’m using with LVM: isz/goddard/disko.nix at main · quentinmit/isz · GitHub

61

Without relying on tmpfs ? I’m curious, if you have an example please share :pray:

62

I tried to reply with sample configuration, but something in the text (?!) triggered CloudFlare’s blocking logic. So instead, I put my reply in a Gist: