After updatting from 23.05 to 24.05 I get graphical bugs and nix-env -u deprecated warnings

1

Hi ultra noob here, I followed the manual instructions to upgrade from 23.05 to 24.05 ( I did not upgrade to 23.11 ):

sudo nix-channel --add https://channels.nixos.org/nixos-24.05 nixos
sudo nixos-rebuild switch --upgrade

I had some errors which I fixed in /etc/nixos/configuration.nix

for example change ffmpeg_5 to ffmpeg_full, etc.

Minor things like log in and such.

The rebuild finished successfully, just in case I restarted the PC.

Upon restart I am plagued by graphical bugs, many surfaces aren’t drawn or the labels are missing.

Then I tried :

sudo nix-env -u

To see if something missed the update and I got the following warnings :

trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpathHook instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpathHook instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead
trace: warning: cudaPackages.autoAddDriverRunpath is deprecated, use pkgs.autoAddDriverRunpath instead
trace: warning: cudaPackages.autoAddOpenGLRunpathHook is deprecated, use pkgs.autoAddDriverRunpathHook instead
trace: warning: cudaPackages.autoFixElfFiles is deprecated, use pkgs.autoFixElfFiles instead
trace: warning: eww now can build for X11 and wayland simultaneously, so `eww-wayland` is deprecated, use the normal `eww` package instead.
trace: warning: lxd has been renamed to lxd-lts
trace: warning: lxd-unwrapped has been renamed to lxd-unwrapped-lts
trace: warning: nixfmt was renamed to nixfmt-classic. The nixfmt attribute may be used for the new RFC 166-style formatter in the future, which is currently available as nixfmt-rfc-style
trace: warning: nvtop has been renamed to nvtopPackages.full
trace: warning: nvtop-amd has been renamed to nvtopPackages.amd
trace: warning: nvtop-intel has been renamed to nvtopPackages.intel
trace: warning: nvtop-msm has been renamed to nvtopPackages.msm
trace: warning: nvtop-nvidia has been renamed to nvtopPackages.nvidia
trace: warning: writeReferencesToFile is deprecated in favour of writeClosure

So then I tried

sudo nix-env -e autoAddDriverRunpath

But the system says the package does not exist.

I am on Xorg X11, on a really old Optimus PC with NVidia (using propietary drivers), everything was working mostly fine before the update.

I checked the release notes and many of the nix-env -u errors seams to be related to package names being re arranged but I have no clue how to solve them.
The release notes also mention GNOME GTK renderer changes which might be related to my graphical problems.

Do I really need to do a full reinstall or is there something I missed from the update?

Thanks in advance.

2

Full reinstall usually doesn’t change anything in NixOS.

Using nix-env -i and nix-env -u without -A can be problematic. You might be getting random variants in case of some packages, as they have the same .name (but different “attribute name/path”).

That’s most likely closely related to the warnings that you get, but I don’t think it’s related to the graphical bugs. At least unless you have some kind of mess in active channels. Generally it’s good to use everything from a single nixpkgs commit (both nixos-rebuild and nix-env). Especially stuff using OpenGL can suffer if the commits differ too much.

2 Likes
3

The warnings are a known issue. They are unrelated to what you have installed, all warnings listed in aliases.nix will be printed by nix-env command which traverse Nixpkgs trying to match derivation names.

4

Thanks a lot. I only use a single channel ( stable ), and the things that weren’t installed in declarative fashion through configuration.nix were installed through Flatpak.
I reverted to 23.11 for the time being.

@jtojnar Yes I had seen that post but I don’t fully understand it.

5

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?

1 Like