Reminds me of those old disruption tactics

Who would the fifth column be working for in this case? Guix?

just seems like extremely poor communication and more "open letter" bullshit that's really a nothing burger. Seems like one or two people said "we're disbanding!" while based on some threads I've read the remaining team was like "yeah...we really didn't want to"

It's not a good look for the project when these people constantly get on the forums and post this stuff. just privately quietly resign. It's two people or even one person who wasn't happy and decided to nuke the ship on their way out.

You know if someone decided to set up a PR firm that focused purely on the Linux and FOSS communities they would make an absolute killing because NONE of these people know how to communicate jack all. it's the same for every project. every single one.

Not even a year. May as well hook the nix org up to a steam generator to make use of all the human resources they burn thru.

Reminds me of those old disruption tactics for occupied territories: drag everything through committees, micromanage and obstruct, make everyone's work just that much little bit harder than it needs to be...

It's doubly tough because I can see where a lot of people are coming from on some issues, but others feel like they shouldn't be issues at all. Mostly just a systemic failure, as they said. Good communication is hard to accomplish: boundaries and expectations and all that; even harder when the framework and environment works against you.

Sad to hear of more churn. Wishing them (and their future replacements) much good luck.

thanks everyone, i have confirmed the system rebooted properly at 9am today. i just used the direct path without the package variable thing.

thank you for the information!

"${pkgs.systemd}/bin/systemctl --no-block reboot";

maybe something like this, but for testing just touch a file and see if it actually is triggering for you

just swapped it to remove the ${pkgs.coreutils} but i suspect thats not right either

Just /run/current-system/sw/bin/reboot actually would work, although it relies on your system closure containing a reboot binary. That's a reasonably safe assumption to make on a NixOS system, but you might not want to do this with other packages.

the path i used was the output of which reboot

The reason that doesn't work is that the structure of packages and the structure of a NixOS fiile system are different. Consider this:

$ ls -l $(readlink $(type -P reboot))
lrwxrwxrwx 33 root root 9  1. Jan 1970  /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot -> systemctl

So the systemd package in the nix store has a bin subdirectory containing its binaries. However:

$ ls -l /bin/reboot
ls: cannot access '/bin/reboot': No such file or directory
$ ls -l /bin/*
lrwxrwxrwx 1 root root 74 Aug  1 06:31 /bin/sh -> /nix/store/dddwfz7nph37q3cjky9lhpy9kb90rrrx-bash-interactive-5.3p15/bin/sh

NixOS doesn't, at least not really (/bin/sh must exist because the system syscall uses it). Instead binaries for "installed" packages (the technical term would be "packages which are part of the system closure") are symlinked to /run/current-system/sw/bin:

$ type -P reboot
/run/current-system/sw/bin/reboot
$ ls -l /run/current-system/sw/bin/reboot
lrwxrwxrwx 9 root root 66  1. Jan 1970  /run/current-system/sw/bin/reboot -> /nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot

More accurately, building a NixOS system creates a sort of meta-package that contains a link farm to all installed binaries in the sw/bin directory, and that meta-package is symlinked to /run/current-system at activation/boot. (Not all package contents are symlinked into this meta-package, also see the NixOS option environment.pathsToLink.)

Putting that together with what string interpolation of packages does... well, you kinda just have to look at/know the contents of the package you are referring to:

$ nix repl
Nix 2.34.8
Type :? for help.
nix-repl> pkgs = import <nixpkgs> { }

nix-repl> "${pkgs.systemd}/bin/reboot"
"/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot"

nix-repl> "${pkgs.systemd}/run/current-system/sw/bin/reboot"
"/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/run/current-system/sw/bin/reboot"

One of these paths exists, the other doesn't.

Side note: You're looking at the old and mostly abandoned wiki, don't use that. There's an official wiki which is better. This particular article happens to be the same in both, but the old wiki also has tons of outdated and terrible articles like For Beginners or NixOS Woke Invasion.

So long Garnix! It will be missed

thank you so much for the information!

For installed packages, you can use readlink:

$ readlink $(type -P reboot)
/nix/store/axx9bvf0dmah41f39ds9xdkds1lsz6z9-systemd-261/bin/reboot

The NixOS search can also search for binaries. It seems that busybox also provides a reboot which I guess might be useful for weird systemd-less deployments?

If you want to search for any file across all packages, there's also nix-index, which scrapes Hydra for output files and builds a database which you can then query with nix-locate.

excellent, thank you! in the future, how would i determine which package and path to use?

basically modified this.

the path i used was the output of which reboot

just swapped it to remove the ${pkgs.coreutils} but i suspect thats not right either

This line:

${pkgs.coreutils}/run/current-system/sw/bin/reboot

is incorrect, as you've mixed a package path with an absolute path. Additionally, on my system at least, reboot is a part of pkgs.systemd and not pkgs.coreutils.

So this should work:

${pkgs.systemd}/bin/reboot

Or, since systemd is always installed on NixOS systems, you can use the absolute wrapper path:

/run/current-system/sw/bin/reboot

${pkgs.coreutils}/run/current-system/sw/bin/reboot

This doesn't look right

thanks for replying. the system has about a 24hr uptime from me rebooting last night, so it did not reboot at 9am.

autoreboot.timer Loaded: loaded (/etc/systemd/system/autoreboot.timer; enab> Active: active (waiting) since Thu 2026-07-30 19:36:04 CDT> Invocation: 0ebb672bd44e4efbb2a11aace109043b

Trigger: Sat 2026-08-01 09:00:00 CDT; 10h left                 Triggers: � autoreboot.service

Sat 2026-08-01 09:00:00 CDT 10h Fri 2026-07-31 09:00:02 CDT 13h ago autoreboot.timer autoreboot.service

hmm looks like everything ran except it didn't actually reboot. ill investigate more.

thank you!

Override your substitutes in the rebuild command itself

nixos-rebuild switch --option substituters "https://cache.nixos.org/" --option extra-substituters ""

The reboot service isn't running because it's not time to reboot.

systemctl status autoreboot.timer

systemctl list-timers --all

Yeah, i was using Void but atm i'm using Guix. From what i can tell Guix doesn't have an implementation for it either, but my current setup works so that's good lol. I just have a shepherd service that executes the script in my users' .nix-profile as root. The tmpfiles.d method is basically what this project is doing as well. I ended up not using it because of that, but i also don't like that it adds more projects that you have to depend on to get it working compared to the manual setup that we're doing.

Thanks for the heads up!

The new hostwide flag is very convenient. It probably won't work for me because I'm sticking to stock SteamOS for now, and it's very immutable. But I'm giving it a try asap!

Ah. You're on Void. Indeed, it does look like Void doesn't have an implementation of systemd-tmpfiles. Here is the file from my system, it's only creating a single symlink, which is basically the same thing you are doing:

[moonpie@nefertem home-manager]$ cat /etc/tmpfiles.d/non-nixos-gpu.conf 
L+ /run/opengl-driver - - - - /nix/store/2r6vmqh1vkivsrmr6n1vh1862i2qndqz-non-nixos-gpu

Oops, the below is for artix. I was nosy but not nosy enough and I saw a comment where you mentioning you used void after you wrote all of this. I'm gonna leave it here since it was an enjoyable rabbit hole.

I did some digging, and it looks like it is possible to use systemd-tmpfiles outside of systemd. It's just a binary that creates files/directories/symlinks based on a format, so it's pretty easy to extract, or reimplement entirely.

Artix has their own, an extraction from the systemd package: https://packages.artixlinux.org/packages/system/x86_64/etmpfiles/

It looks like that package is required by the base package, which is the core package set declaring the minimal dependencies needed to have a working system, so it's highly likely you have it installed.

I think it automatically starts too, but I can't find a hard source for this. Based on this page: https://wiki.artixlinux.org/Main/Migration#Download_the_Artix_packages it looks like etmpfiles is needed before you select/install the init system, which suggests that. This reddit post, where a user has an issue where etmpfiles isn't installed, so their service manager complains and dies.

If you have a service named something related, like tmpfile or the like, then it does autostart.

Oh that's cool that they actually acknowledge the issue now and have adressed it like this. It looks it does still assume systemd though? Since it's using tmpfiles.d. Since i'm on a non-systemd distro i'll probably keep using my own script that runs at boot through my service manager. I've updated my config a little since then cause i used to symlink from my home folder, which caused issues on my server where multiple users needed the drivers. I now symlink it directly from the store. Also looking back at my old comment, i did end up trying to use rocm and it worked just fine.

Coming back to these docs a year later, it looks like something like it's possible to enable it for everything by default by setting targets.genericLinux.enable to true. Seems the docs have been updated: https://home-manager.dev/manual/unstable/usage/gpu-non-nixos.html#sec-usage-gpu-non-nixos

Huh. The page was updated, reviewing it a year later. It does look like there is an option to automatically give GPU to all Nix/home-manager programs now. If you set targets.genericLinux.enable to true, then it should work.

Ah yes, I got it working, the issue was unshare-pgid which had already been sort of raised in nixpak.

In my case, I used bubblewrap.newSession (which is equivalent of --new-session). Idk why that worked out finally with --unshare-pgid, but I'd rather not spend more time on this.

I like the idea of let binding the package declaration to use it in the config as well. I'll probably use that. Thanks!

Firstly, did you get it working? I notice your latest commit seems to mention that you got it working

One thing I would recommend is to declare the iamb package separately in a let... in statement.

let
   iamb = (mknixpak blah blah blah)

....
....

in

 userconfig.programs.iamb = {
      enable = true;
      # By using "iamb", instead of pkgs.iamb, it means we are using the nixpak wrapped version here
      package = iamb
      settings = {
        profiles.user.user_id = "@username:instance.com";
        settings = {
          image_preview = { };
          username_display = "displayname";
          user_gutter_width = 15;
        };
      };
    };

This make it so that iamb is the nixpak wrapped version instead, in the userconfig. This would probably also make it so that you don't need to declare it explicitly in your systemPackages.