Framework NixOS (Linux) users self-help

my original PSA here about `mem_sleep_default` is wrong~ish

tl;dr anyone who comes across this big, unified nixos+framework thread that Matt’s kindly maintaining is a prime candidate to at least read the configs nixos-hardware/framework at master · NixOS/nixos-hardware · GitHub (and consider using them per the README, if not also contributing).

new PSA for nixos users (particularly new-to-nixos like I am)

I don’t have edit access to that^ post anymore, so I’m starting a new PSA for nixos users: don’t use^ this tip. Or rather, you probably don’t want that tip, and instead use the more robust route maintained by other folks for you: the nixos-hardware project :tada: … by doing this:

  1. figure out your framework laptop’s “generation”; for me it’s “11th” gen…
    there must be a faster way to look up your generation? eg: via order page? but whatever, here’s steps I used…
      1. Framework | Sign in → find your laptop
      1. under “order summary” the “configuration” field shows your chip’s identifier (for me it’s i7-1165G7)
      1. load Framework | Framework Laptop Comparison
      1. ctrl+f for your chip from step 2
      1. scroll down to “processor options” table (this will force a header-row to float down with generation indicators)
      1. for me i7-1165G7 shows “13 (11th Gen Intel Core)”
  1. lookup your framework generation in the table here GitHub - NixOS/nixos-hardware: A collection of NixOS modules covering hardware quirks. (stable link) (ctrl+f for framework)

  2. follow GitHub - NixOS/nixos-hardware: A collection of NixOS modules covering hardware quirks. (stable link) which I’ll summarize here for convenience:

    1. add and update the nixos-hardware nixos “channel” by running:
    sudo nix-channel --add \ \
    sudo nix-channel --update
    1. copy the string on the right side (for me it was <nixos-hardware/framework>; for you it might be <nixos-hardware/framework/13th-gen-intel>); let’s call it $YOUR_FRAMEWORK_STRING

    2. pull up your configuration.nix and add string from step 3:

      1. find the spot in your configuration.nix that looks like:
      imports = [
      1. add $YOUR_FRAMEWORK_STRING in that list
      imports = [
       $YOUR_FRAMEWORK_STRING # for me this line is: <nixos-hardware/framework>
  3. see if this is working…

    1. unset previous hand-made changes for framework (eg: comment out my PSA about mem_leep_default=deep)
    2. force set the new changes: sudo nixos-rebuild switch --upgrade
    3. reboot to be sure all’s well

I think it’s self-explanatory why a collective of configurations is better than hand-maintaining duplicate versions on your own (and likely not as complete). If you want to see what your generation’s nixos-hardware configuration is in this repo, click into your subfolder here: nixos-hardware/framework at master · NixOS/nixos-hardware · GitHub (stable link)

If you’re curious why the 11th gen does not have mem_sleep_default=deep line any longer, see this PR: framework laptop 11th gen: Improve sleep power efficiency by obj-obj · Pull Request #717 · NixOS/nixos-hardware · GitHub.

(I really wanted to make this a separate post for higher visibility, but as it’s been merged into this thread, I’ll leave it be)

but why did you post the tip above then? doesn't it work?

Yes the original tip works, but I just didn’t look closely at the larger repo when I copied that xps13 config (until now). If you’re reading this and you’re a nixos expert, please comment with more guidance (and/or confirmation even). I certainly didn’t figure this out via any official nixos docs/wiki (would’ve been nice), so I feel like I should document how I stumbled upon this…

  • I recently loaded this old mem_sleep_default=deep post and looked at the original github link in my inline-comment, to jog my memory…
  • I commented out my own PSA’s fix, and following this nixos-hardware repo’s instructions (summary above)
  • I rebooted my machine and tested
    • :white_check_mark: sleep works as intended (shut lid mid-workstream, had 98% battery; 3 hours later had 97% battery)
    • :white_check_mark: improvement: to take advantage of this fprintd default already set (stable link), I tested fingerprint unlock (after running fprintd-enroll), and confirmed gdm3 and sudo both behave as expected. This hadn’t actually worked for me for a long time.

Edit: lol nixos-hardware called out in the third post on this uber thread :slight_smile: Well, I guess Matt merging everyone in here will decrease likelihood folks like me will miss it :+1: (I’m clearly not the only one, since folks appreciated my one-off tweak). Edit2: typo in bullets’ nestings


Yeah I was pondering the same the other day, given the various success and failure stories with different Linux distros around here.

Maybe a small script that checks the relevant settings from /sys to report what has been configured correctly or not.


While I generally agree a central collection being helpful, it’s also highly specific to NixOS at a current point in time, because modules like nixos-hardware are merged with the “builtin” modules that a NixOS release ships with. And due to how merging works the magic happens because of the sum of all the modules.
A form of magic where the outcomes is really hard to translate into the non-NixOS world.
I guess this is kinda a rant-like argument for my idea above - the checkscript.

Dang, thanks for all the digging @jon. I was already using nixos-hardware but didn’t realize PR #717 was created.

Hey friends ---- a situation emerged approaching the 2-year mark of daily driving my batch 5 with my power button.

I don’t know if it’s battery or button press, but basically it has no way of turning on without being plugged in. Also, it will interpret the moment of plugging in as “power on”, so the button is effectively doing nothing.

I can unplug it after boot sequence starts and things are basically fine. (battery life is of course not super great, but I haven’t invested a lot of time into optimizing my OS for that).

Anyone have ideas or advice?

Is there some reason you suspect this behaviour is related to NixOS?

Always test against a live USB of Fedora or Ubuntu LTS. If the power behavior is not present there, it’s your config. If it is present in the live environments, then I’d open a ticket and link to your thread here pointing out clearly you did indeed, test the Live USB approach to triage.

Hey, all! Let me know if a separate thread would be preferable and I’ll post elsewhere.

I’m trying to install NixOS on my Framework 13 with a Ryzen 7640U mainboard, but cannot get the ISO to boot from my USB drive. Fedora Workstation 39 Beta booted just fine from the same flash drive and I dd’d the ISO to the flash drive the same way:

dd if=$ISO of=/dev/sda status=progress bs=1M

I’m guessing the issue has something to do with the way the ISO boots. NixOS, to my knowledge, boots in a different way than other distros, but I have another system that can boot off this drive, so I would consider this a bug in the BIOS. Correct me if I’m wrong!

The BIOS of the 7640U mainboard as of today is on 3.02, which I understand has issues with certain Linux kernels, but I tried building my own NixOS ISO using Linux 6.5.7 (the Fedora install currently on it is 6.5.6) and that didn’t seem to resolve the issue in any way. The USB drive still does not boot on the Framework but does boot on my current laptop, a Lenovo T480.

For anybody interested, the flake for this is here (you can build it with nix build git+ssh:// and its worth noting that I stripped all the NixOS kernel patches since they were incompatible with 6.5.7.

I’m guessing my next step is to go ahead and try GitHub - nix-community/nixos-anywhere: install nixos everywhere via ssh [maintainer=@numtide] to convert the Fedora installation into a NixOS one?

Either way, I’d love to know that my shiny, powerful new laptop will boot my bootable media, even if it is kind of wacky. Ultimately, I’m very much wanting to run NixOS on this thing since I run it everywhere else. I know it’s not officially supported, but I also know that there are other people out there that will want this like me and I’m willing to put in effort on my end to make it happen, but I suspect we’re stuck waiting on the 3.03 BIOS upgrade to hopefully fix this bug (even though the official reason for the BIOS upgrade seems mostly related to amdgpu graphics driver issues). That thread is here for posterity: Laptop 13 AMD Ryzen 7040 BIOS 3.03 and driver Release


This is a perfect place to ask and folks here should be able to help. :slight_smile:

Got mine up!

Didn’t change any configuration yet - it’s still based on the 11th gen nixos-hardware flake. Also didn’t use usb boot for that matter since I’m using my previous hard drive.

That’s weird. If I have some time soon, I’ll see if I can build the ISO and boot from it from my machine now that mine is up and running with the 7640U. At least you can run Fedora!

1 Like

I’ll give that a shot! Glad somebody has it working!

Thank you! I’ll respond here as well if I get it up and running.

Ooh can you confirm that your BIOS is 3.02, @kjhoerr ?

Confirmed! JFP30.03.02 reported in BIOS

There does seem to be some kind of hiccup, when first booting the scaling is off and it only logs in as an X session, but logging out and logging back in fixes it. I’m assuming that’s connected to the amdgpu shenanigans

Weird. Yeah I tried popping the SSD out and installing NixOS to it using another machine and booted it up just fine on that machine, but it fails to boot on the Framework.

@lytedev, just to cover all the bases: did you disable secure boot in the BIOS?

(I saw the same screen come up over and over again while I was trying to boot different installers. That is, until I disabled secure boot.)

1 Like

That sounds precisely like the kind of entirely silly thing I would forget to do. I’ll try it later tonight and report back!

Out of curiosity or ignorance, though, why would a Fedora ISO boot just fine?

The Fedora loader/efi thing (super technical term) is most probably signed by a trusted party or Fedora’s keys are pre-loaded in the bios.

I had the same issue you did (took an updated NixOS install from another computer and dropped it into the Framework and had the same message). You can manually register the efi’s from the NixOS boot/efi partition into your Framework’s secure boot database or just disable secure boot.

Disabling Secure Boot solved it for me. Everything is booting and working as I hoped and dreamed.

My ego is very tiny and I feel very stupid, but I’m elated to play with my new laptop in full now!

Thank you all!

Edit: A more clear error message on the BIOS side might go a long way to reduce incoming support requests like my dumb self! :wink:


To note for anyone running AMD, the nixos-hardware default module ‘framework’ sets nvme.noacpi=1 kernel param which is affecting standby. There’s some useful configuration in that module aside from that, so if you want to keep the module import you can force override the kernel param list with something like:

boot.kernelParams = lib.mkOverride 999 (builtins.filter (p: p != "nvme.noacpi=1") config.boot.kernelParams);

There’s also the common AMD cpu and gpu modules which are useful for import.

AFAIU it’s not a generic module, it’s a misnamed config specifically for the 11th Gen Intel version, retained under that name for backwards compatibility reasons. It also (via the generic “laptop” config) enables TLP, which Framework explicitly recommends against on the AMD version, so, I dunno.

Yeah, I just had it enabled since I migrated from the 11th gen. Just wanted to put it out there in case other people run into the same thing.

The framework folder definitely needs some restructuring, but obviously making necessary changes makes it backwards incompatible, which I guess is up to the maintainers. It will definitely need to change with the impending FW16 release.

I made PR #765 for nixos-hardware to add a 7040 config for now so other people can target it.


I didn’t bother with any harware specific configs on my 7040. Running the unstable channel and used the latest kernel with

 boot.kernelPackages = pkgs.linuxPackages_latest;

As far as I can tell, everything is working fine with KDE (with 3.03 BIOS everything is working great!). Up to 8 hours with light web browsing and screen at 25% brightness.

Edit: added “Up to” on the battery life as YMMV