bug: getting error "attribute 'nix-lib-nmd' missing" when doing "home-manager switch" on darwin
Are you following the right branch?
- [X] My Nixpkgs and Home Manager versions are in sync
Is there an existing issue for this?
- [X] I have searched the existing issues
Issue description
Upon running home-manager switch I got the error attribute 'nix-lib-nmd' missing.
I am using darwin. I have updated all channels. Here's the output of nix-channel --list:
$ nix-channel --list ~
darwin https://github.com/LnL7/nix-darwin/archive/master.tar.gz
home-manager https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz
And here's the error trace:
$ home-manager switch ~
error:
… while calling the 'derivationStrict' builtin
at //builtin/derivation.nix:9:12: (source not available)
… while evaluating derivation 'home-manager-generation'
whose name attribute is located at /nix/store/4968h3bbp11pj1k44w412b7ckads1ixk-nixpkgs/nixpkgs/pkgs/stdenv/generic/make-derivation.nix:300:7
… while evaluating attribute 'buildCommand' of derivation 'home-manager-generation'
at /nix/store/4968h3bbp11pj1k44w412b7ckads1ixk-nixpkgs/nixpkgs/pkgs/build-support/trivial-builders/default.nix:87:14:
86| enableParallelBuilding = true;
87| inherit buildCommand name;
| ^
88| passAsFile = [ "buildCommand" ]
(stack trace truncated; use '--show-trace' to show the full trace)
error: attribute 'nix-lib-nmd' missing
at /Users/pedro/.nix-defexpr/channels/home-manager/docs/default.nix:10:12:
9|
10| nmdSrc = pkgs.nix-lib-nmd;
| ^
11|
Thank you for supporting this project, and let me know if I can do anything to help pinpoint the cause.
Maintainer CC
@rycee
System information
- system: `"x86_64-darwin"`
- host os: `Darwin 23.2.0, macOS 10.16`
- multi-user?: `yes`
- sandbox: `no`
- version: `nix-env (Nix) 2.15.1`
- channels(root): `"nixpkgs"`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`
Try updating Nixpkgs.
This looks like a duplicate of #4903 but yeah updating nixpkgs doesn't seem to help. I believe it's something new changed when migrating from sourcehut to the binary cache. Edit: my bad the other issue is newer so that's the duplicate
Having the same issue on Fedora 39, attempting to install Home Manager on a fresh installation of Nix with nix run home-manager/master -- init --switch.
same issue on Fedora Kinoite 39. using command: nix-shell '
What Nixpkgs version are you using? Did you update the version as suggested?
I was on 2.17.1, upgraded to 2.18.1, issue persists but not on Darwin so not sure if that is related
❯ nix-shell -p nix-info --run "nix-info -m" this path will be fetched (0.00 MiB download, 0.00 MiB unpacked): /nix/store/2bk3cqpj26fi3fwgshgg3k0fxwz0h55g-nix-info copying path '/nix/store/2bk3cqpj26fi3fwgshgg3k0fxwz0h55g-nix-info' from 'https://cache.nixos.org'...
- system:
"x86_64-linux"- host os:
Linux 6.5.0-14-generic, Ubuntu, 23.10 (Mantic Minotaur), nobuild- multi-user?:
yes- sandbox:
yes- version:
nix-env (Nix) 2.18.1- channels(root):
"nixpkgs-23.11"- nixpkgs:
/nix/var/nix/profiles/per-user/root/channels/nixpkgs
I was on 2.17.1, upgraded to 2.18.1, issue persists but not on Darwin so not sure if that is related
I still have the issue on Darwin. I'm not using Flakes.
Which commit of Nixpkgs do you run? Still no one with this issue have answered that.
I can see for example the Nixpkgs path pointing to a channel of nixpkgs-23.11 but we don't know if the channel is up to date.
I'm on master
Which commit of Nixpkgs do you run? Still no one with this issue have answered that.
I can see for example the Nixpkgs path pointing to a channel of nixpkgs-23.11 but we don't know if the channel is up to date.
I'm using home-manager as a module with nix-darwin, both channels are on master and uptodate.
allright, it works after setting nixpkgs.pkgs to latest (this is for nixpkgs-23.11-darwin branch):
nixpkgs.pkgs = import (builtins.fetchTarball "https://github.com/NixOS/nixpkgs/archive/fc4e67c811b7681e72a0324be0144d627005ab3d.tar.gz") {};
The cause of the issue and a workaround for it can be found here: https://github.com/nix-community/home-manager/issues/4903#issuecomment-1893985197
As a workaround until the flake.lock is updated, it should be possible to override the flake input via --override-input, e.g.
nix shell --override-input nixpkgs github:NixOS/nixpkgs/nixos-unstable home-manager/master
Run your desired home-manager commands inside this shell and they should work. If you want to freshly install home-manager, run
nix run --override-input nixpkgs github:NixOS/nixpkgs/nixos-unstable home-manager/master -- init --switch
met same issue with flake home-manager standalone in wsl2
home-manager release-23.11 nixpkgs tag 23.11
Running nix-channel --update on MacOS as root fixed problem for me.
Channels:
# root
nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-23.11-darwin
# user
nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-23.11-darwin
home-manager https://github.com/nix-community/home-manager/archive/release-23.11.tar.gz
@fightingdreamer also on macOS, I have solved it differently, do you understand how the root channels relate to user channels? I would think there shouldn't be any relation in nix-darwin since darwin-rebuild runs as user
@andreivolt IMHO user channel is overlaying the root channel for user installed packages, but home-manager probably pulls dependencies from root channel.
Trough there is one difference:
I'm using home-manager as a module with nix-darwin, both channels are on master and uptodate.
I using pure nix with home-manager on MacOS, that maybe related to different channel resolution logic.
Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.
If you are the original author of the issue
- If this is resolved, please consider closing it so that the maintainers know not to focus on this.
- If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
- If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
If you are not the original author of the issue
- If you are also experiencing this issue, please add details of your situation to help with the debugging process.
- If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.
Memorandum on closing issues
Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.
Hey,
Apologies for the long delay coming back to this. I managed to solve this by using a flake to finely control my dependencies and overcome a stale version of nixpkgs. Other methods in this thread may solve it as well.
Thank you everyone for chiming in, especially the maintainers.