Chroot 23.11 within 22.11 bare-metal because Nvidia

Help
12

Easiest is probably to revert those update commits touching the nvidia driver in a local Nixpkgs checkout of 23.11.

1 Like
13

Now I am highly perplexed. I’ve made /etc/nixos/* as similar as possible to those on my working system (differences are stuff like filesystem UUIDs, version of PHP and required changes to users.users.mounty.

It still boots to a blank screen with a steady text cursor, as described above. The files under /var/log/lightdm are the same, including the final (EE). But there is no coredump in journalctl -e. That’s the only difference. No coredump, everything else the same. I am perplexed.

The only other difference is that the non-working system pulls in the Nvidia drivers version 390.157 and the old working system has 390.151. It could be that, or maybe it’s the version of GCC that’s used to build … something, during the nixos-rebuild run.

1 Like
14

I’m going to try a 23.11 chroot within a 22.11 bare metal. It seems there is no other way.

1 Like
15

Have you given this a shot? That will really be significantly easier IMO

Like, just do a git clone https://github.com/nixos/nixpkgs, get in there with git blame on the nvidia package file to figure out which commit did that (or use the GitHub UI if that’s too difficult), git reset the commit away, and then build your config from that checkout instead of the channel (I think nixos-rebuild -I nixpkgs=/path/to/repo does the trick).

Periodically rebase against upstream to get updates. NixOS being easily manipulated via git is like half the reason to use the distro over alternatives.

No cursed 22.11 + 23.11 mix that will barely work anyway, and your host gets to have actual security updates.

The crux really is knowing that the nvidia driver version is the problem, and that an older one works. Long-term you can consider just overriding the nvidia package in your configuration so you can just use channels as normal.

16

Well I suppose the answer is that I know chroot, but I don’t (yet) understand playing with Nix repositories. But I’m certainly not happy with a chroot solution so I’ll take the time to understand your recommendation. Thank you.

17

Wait. I don’t think this is going to work. Did you see Atemu’s comment in another post?
TL;DR Nvidia drivers 390.151 + kernel 5.15 + 22.11 do work: Nvidia drivers 390.157 + kernel 5.15 + 23.11 do not work.
That is why I think I need a chroot system; because 23.11 uses a newer and likely Nvidia-breaking glibc.
So unless it is possible to hold 23.11 down to glibc 2.35 (or possibly >=2.x and <2.38) I don’t think this is going to work.
If you think it is, where should I start? Can I install 23.11 and hold the version of glibc down?

1 Like
18

I updated to 23.05 (glibc 2.37) as a starting-point. The display seems to work alright but when IntelliJ IDEA is the only desktop app. running, the .cinnamon-wrapp process is consuming around 80% of one core, according to top, which compares unfavourably with 0.2% on the 22.11 machine.
Is it possible to move to 23.11 but hold glibc down to 2.37?
I need more help to understand how to do this with repo. manipulation. Is there a more detailed guide anywhere?

1 Like
19

In theory, yes. You can revert this commit: glibc: 2.37-39 -> 2.38-0 · NixOS/nixpkgs@e861529 · GitHub

In practice, this will mean running an older glibc than what anything has been tested against. You may run into issues with other repackaged binaries. You will also need to compile everything downstream (changing glibc is serious business), which will be painful on a decade-old laptop (for this, using another machine to build and deploying remotely, or using something like peerix may help, but this will probably remain very painful even with a faster build host).

I think you’d be best served by any generic git tutorial (no idea if that one in particular is good, I learned this stuff by osmosis), but I’ll try to take some time writing up a more detailed guide.

1 Like
20

I think this has run long enough. Even NixOS cannot make software work that is not designed for the situation. I’ll continue to use the laptops with the built-in Intel display, but get something else for multi-screen usage. Thanks Tlater and Atemu for your help but let’s draw a line under this.
BTW, Nouveau isn’t coming to the rescue. There’s been no significant movement on them for almost three years.

21

That might still be true but note that the xf86 driver is not really all that relevant here as this sort of thing is handled in the kernel driver. Nouveau should work with the generic modesetting driver. Are you using that?

23

Here’s what I have. The two external displays (Nvidia) are working but the laptop display is blank with a text-mode cursor at top left.

{ config, pkgs, lib, ... }:
{
	services.xserver.videoDrivers = [ "nouveau" ];
	hardware.nvidia.modesetting.enable = true;
}

It seems so close but how do I get the laptop display working too?

  • I did reboot after nixos-rebuild* but it didn’t help.
  • hardware.intel.modesetting.enable = true was rejected by nixos-rebuild.
  • services.xserver.videoDrivers = [ "nouveau" "intel" ]; leaves all screens blank after reboot.
  • services.xserver.videoDrivers = [ "nouveau" "kvm-intel" ]; is the same as without "kvm-intel"; i.e., just the two external displays are working and the laptop display is blank with a text-mode cursor at top left.

I am obviously just floundering around and guessing.

24

Just set services.xserver.videoDrivers to [ "modesetting" ] or reset it back to default.

25

That just switches the display to the laptop and both external screens are now blank.
The configuration is here; is there anything obviously wrong with it?

26

Not that I know of but I’m not an authority on nouveau on old hardware. I’d ask more specialised circles if you want to pursue nouveau. IIRC nouveau developers have an IRC channel somewhere.

This is a dual-graphic laptop, right? Is it somehow possible to disable the Nvidia GPU entirely in the firmware settings and only use the Intel one? That one will give you a lot less trouble.

27

I fixed it. The fix: logging in.

The display manager was using the laptop display only, but when I logged-in, all three screens were used.

It’s nearly there. If I use settings / display to arrange the screens according to their physical layout, it induces a lot of flickering when windows are moved. I think I can get used to the layout not matching physical.

So thanks again Atemu and Tlater; the laptop is useable with 23.11.

[Later] I fixed the 2560 by 1600 resolution issue (I was using DVI not dual-link) and the setup works fine but when I try a 4K and a 1920 by 1080, it is totally weird. Cinnamon Settings / Display shows the two external displays correctly but they are not driven. A monitor-generated NO INPUT message appears on the 4K. Additionally, the 4K has buttons to set the input source (DP / HDMI1 / HDMI2) but these do nothing whilst the 23.11 is connected. If I try to set the display layout in Settings / Display, the laptop becomes pretty much unresponsive although the HDD active LED flashes occasionally. The power button does not initiate a shutdown. I can ssh in and shut down that way. The total workaround is to reduce the resolution of the 4K in Settings / Display down to 2560 by 1600 which looks rubbish but at least it works.
As I’ve no idea what causes the bug, I’ve no idea if it’s something that might be fixed in time. At this stage, I’m relieved to be able to move on to 23.11.

28

Have you tried a few wayland compositors whether they handle this setup better?

29

That looks like a significant change because I can’t keep Cinnamon and just drop-in Wayland in place of X, and in fact it’s not obvious from the various results of NixOS Wayland Cinnamon how to do it, but I’m prepared to let Cinnamon go, if I can get 4K back.

30

The version of cinnamon on stable doesn’t support wayland yet. The one on unstable has “initial” support (which upstream more or less called experimental), but the NixOS module hasn’t added support for that yet. I’d hold off on trying to get cinnamon+wayland working, unless you have a few evenings and the knowledge to crank out a module for it.

Gnome’s wayland session works quite well, and if you’re using nouveau or intel graphics you won’t run into the myriad nvidia driver issues either. If you really want your start menu, KDE is there too.

1 Like
31

Thanks but it seems there is no simple “here’s your configuration.nix” page for Gnome + Wayland. I’ve cobbled-together a Wayland-based desktop and it does indeed solve the 4K problem mentioned above. But it’s based on sway and really hard work. It has a tiling window manager (maybe your choice, but not mine) and no obvious way to get a right-click menu, move windows from one display to another, or set up multiple workspaces. I’m sure all these things are possible, but I don’t want to spend days learning how to do it.

E.g., one guide said to include this in the sway configuration file:

bindsym $mod+c exec grim -g "$(slurp)" /tmp/$(date +'%H:%M:%S.png')

but omitted the absolutely totally obvious to everyone in the universe definition

set $mod Mod4

(or some other Mod key) definition that must precede it.

Surely there must be Gnome + Wayland instructions somewhere?

I realise the above rant is at Wayland + Sway rather than NixOS.

Then I discovered ‘floating’ mode and whilst experimenting with it, managed to induce a complete and total desktop freeze. So back to X + Cinnamon + imperfect resolution for me, for the time being at least.

At least with NixOS, experiments such as the above are easy to perform if you’re version-controlling your configuration. I created a new branch for the Wayland investigation, then was able trivially to switch back to X. And the Wayland configuration is there to try again in say six months.

32

I think I fixed the 4K lockup by reducing the refresh to 30 Hz, so X is working well for me now.
Repeated thanks to Tlater and Atemu for their patience and time on this.