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 … by doing this:
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…
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
pull up your configuration.nix and add string from step 3:
find the spot in your configuration.nix that looks like:
imports = [
./hardware-configuration.nix
];
add $YOUR_FRAMEWORK_STRING in that list
imports = [
$YOUR_FRAMEWORK_STRING # for me this line is: <nixos-hardware/framework>
./hardware-configuration.nix
];
see if this is working…
unset previous hand-made changes for framework (eg: comment out my PSA about mem_leep_default=deep)
force set the new changes: sudo nixos-rebuild switch --upgrade
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)
(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…
Edit: lol nixos-hardware called out in the third post on this uber thread Well, I guess Matt merging everyone in here will decrease likelihood folks like me will miss it (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.
EDIT
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).
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://gitea@git.lyte.dev/lytedev/foxtrot-nix#nixosConfigurations.live.config.system.build.isoImage) and its worth noting that I stripped all the NixOS kernel patches since they were incompatible with 6.5.7.
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
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!
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.
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.
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 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.
… by doing this:
nixos-hardware/framework at master · NixOS/nixos-hardware · GitHub (stable link)
sleep works as intended (shut lid mid-workstream, had 98% battery; 3 hours later had 97% battery)
Well, I guess Matt merging everyone in here will decrease likelihood folks like me will miss it 
(I’m clearly not the only one, since folks appreciated my one-off tweak). Edit2: typo in bullets’ nestings
