Basically, nix-env is a footgun and shouldn’t be used.
The -A flag tells nix-env to search for packages using their “attribute name”, which is the name you usually see on e.g. search.nixos.org. it’s the “path” to the package in the big nixpkgs attribute set so imagine that nixpkgs looks e.g. like this:
{
python311Packages = {
qtebrowser = <derivation>;
termite = <derivation>;
};
}
If you use the -A flag, to install termite you would install python311Packages.termite, and nix would go into this attribute set and pick specifically that package. This is sensible behaviour (until you use other commands, see the above link for the issues that arise later).
If you don’t use the-A flag, nix-env does something insane. You see, each package also has a name attribute inside of itself:
{
python311Packages = {
qtebrowser = <derivation from { name = "qtebrowser"; }>;
termite = <derivation built from { name = "termite"; }>;
};
}
If not given the flag, nix-env will go look for the package with a specific name attribute. So you’d install termite instead, and nix-env will go and evaluate every single package in the entire set so it can figure out if one of them has the correct name.
In addition to being stupidly inefficient, multiple packages can and do have the same name in practice. This is especially prevalent since nixpkgs sets “aliases” where one attribute points to a slightly modified version of another attribute - usually with the name unchanged.
So you can get absolutely wild behaviour if you run nix-env -u, such as random downgrades, switching to completely unrelated packages, or, in this case, random warnings from attributes you never intended to evaluate, but do because nix-env needs to evaluate them to check what their name is.
That’s the thing, nix-env -u isn’t installing stuff declaratively through configuration.nix, it installs stuff imperatively into your user profile. If you didn’t have any packages there previously, it probably just evaluated stuff and showed you a bunch of unrelated warnings, but if you’re running this command at all it at least sounds like you do have some imperative packages (conveniently masking the system stuff, another problem, see above link).
Anyway, that’s all likely unrelated to your actual issue. You’re using nvidia, doing optimus, and these are graphics glitches, so that’d be my prime (heh.) suspect. It’s always those pesky third party kernel modules…
Assuming you’re not using a legacy driver, I’d suggest trying an even newer driver than the one you currently have and seeing if that just fixes it, the most recent batch has been quite a bit more stable IME (though admittedly that’s using wayland…). You can also try downgrading to an older version, though be aware there were some pretty critical CVEs recently.
I have a recent snippet explaining how you switch to a manually chosen nvidia driver here - note there has been a new stable release since: All nividia drivers crash or do not work - #7 by TLATER
YMMV, obviously that’s not an optimus config.
If that doesn’t fix it, worst case I suppose you might need to bisect this? Perhaps reverting to the commit just before those gnome changes just to narrow it down?