Nixpkgs: X Windows freezes on launch since upgrading to 17.03

[Sophia-Gold]

Issue description

Ever since I upgraded from 16.09 to 17.03, X Windows freezes immediately after login. I've tried disabling gdm and using the NixOS default display manager (I believe SLiM?) as well as disabling gnome and xmonad. The problem persists unless I disable X server entirely, even with just the default display manager and xterm.

Steps to reproduce

My configuration.nix: https://github.com/Sophia-Gold/configuration.nix/blob/master/configuration.nix)

Journalctl dumps:

• With gdm + gnome3 + xmonad: https://gist.github.com/Sophia-Gold/31d56817b0300cebbc2fbcd6de4e64fa
• With gdm disabled: https://gist.github.com/Sophia-Gold/66d46601d8c99ab0228896dd4be361ac
• With gdm and gnome3 disabled: https://gist.github.com/Sophia-Gold/b9f7246286882b03c8eadcfdaf0e15f9
• Default display manager and xterm: https://gist.github.com/Sophia-Gold/21af626e8744b0186ff6c8866c5477c0
• Successful boot with X server disabled: https://gist.github.com/Sophia-Gold/966e948870605efc7ee881a16191ebed

Technical details

• System: NixOS 17.03
• Nix version: 1.11.9
• Nixpkgs version: 17.03.1853.b7e4857dd9
• Sandboxing enabled: false

[vyp]

I think you probably already tried it, but just to make sure, did you try disabling both gnome3 and xmonad at the same time, so it's just a plain x session?

[Sophia-Gold]

Yup. The journalctl dump is in the gist I called "default display manager and xterm." Especially the fact that neither of the likely suspects, gnome and/or gdm, seem to be the cause is really what's puzzling me.

[vyp]

Thought so. :confused:

Anyway, by the way, are you sure that /path/to/.Xmodmap exists? Because if not, it may just be that the displayManager.sessionCommands are not being completed. But then if that was the case, xterm should not be starting.. so I'm unfortunately out of ideas of what it could be, sorry. :disappointed:

[Sophia-Gold]

Ugh, I feel silly. I'm pretty sure that line is exactly it :woman_facepalming:

Furthermore, I'm pretty sure it should be services.xserver.displayManager.sessionCommand.lib.mkAfter rather than simply services.xserver.lib.mkAfter. I'm not sure where I copied it from.

Can you advise on the proper syntax as well as whether I need to set other sessonCommands? It's not covered in the X Windows section of the manual so this is one of many times I wish the wiki was still extant.

[vyp]

Oh right, well if you don't need to run xmodmap, then you don't need any sessionCommands at all and you can just remove it. :) It's just for running extra commands if you need it, just like an .xinitrc file would, see https://nixos.org/nixos/options.html#displaymanager.sessioncommands.

And that is the correct syntax, the with pkgs; just brings pkgs into scope for the lib.mkAfter ''xmodmap /path/to/.Xmodmap''; part. Although I'm not sure why it's brought into scope, nor what mkAfter even does. :woman_shrugging: With a quick search, it seems like you may have gotten this from https://wiki.haskell.org/Xmonad/Installing_xmonad#NixOS.

There's https://nixos.wiki/ now, but I'm not sure if it's anything like the old wiki.

[Sophia-Gold]

Hmm... I removed both those lines and still am experiencing the same behavior. After login with either gdm or SLiM I see a blank display manager screen with the cursor frozen :slightly_frowning_face:

I was starting to wonder whether it has to do with a broken gnome extension as in #19269, but journalctl makes it seem like they're all loading fine.

The dumps look about the same towards the end whether or not I disable xmonad and/or gnome; here's one with both enabled: https://gist.github.com/Sophia-Gold/95efcf6a10e83f36e0392e781e05c9b1

[vyp]

It shouldn't be an issue with a gnome extension if it still freezes with just a plain x session, so the following:

{
  services.xserver = {
    enable = true;
    layout = "us";
  };
}

The above should start a plain x session and open an xterm window in it. If this fails, we can probably rule out both xmonad and gnome. But yeah again, I'm assuming you've already tried this and seen that it still freezes as you said before? :confused: Oh yeah and also, you're running nixos-rebuild each time after changing the configuration.nix yeah? (Not to come across as patronizing or anything, just making sure.)

[Sophia-Gold]

Yup, commenting out everything but xterm is displaying the same behavior as previously. I should note it does load a prompt, but it doesn't tile to cover the full screen and the cursor and keyboard remain frozen.

My assumption that my regular setup (gdm + gnome3 + xmonad) doesn't get past the display manager is just based on it freezing on a blank screen of the gdm color rather than loading my desktop background.

I'm by no means an expert on debugging with journalctl, but it seems to support this: as you can see in the numerous dumps I posted above, in all the cases when I have X Windows enabled it seems to load fine, connect to WiFi, and then doesn't show any obvious errors while it remains frozen. From what I can tell it never even tries to load a desktop and/or window manager.

And yes, my general practice with changes like this is to run nixos-rebuild boot and then boot from GRUB default (whereas when just adding packages I'll use nixos-rebuild switch). Please do feel free to be patronizing...unless anyone can reproduce this based on my configuration.nix then we're starting to rule out anything other than human error :confused:

[Sophia-Gold]

I realized I should also mention the odd chance of it being hardware specific (it's an ASUS gaming laptop) as I've had some odd issues with suspend/hibernate/freeze. However, I assumed that was all due to gnome.

[vyp]

Wait, what do you mean commenting out everything but xterm?

And yes from my understanding, it should "load a prompt", i.e. an xterm window, and from memory it's not fullscreen. So if it does get to opening an xterm window, then I believe it means at least it's gone past the display manager.... :thinking:

After it supposedly freezes, can you still access the virtual TTYs by pressing ctrl+alt+F1? Because if you can, then it probably means the keyboard is working okay and it would be something to do with just X then. Also the other thing that could be happening if ctrl+alt+F1 works is that when you try to type in the xterm shell prompt, it simply doesn't display anything because the window may not have focus, but you cannot focus it because you cannot move the mouse, so that might make it seem like the keyboard also doesn't work even though it might.

I also thought this line (from your first dump in the original post of this thread) https://gist.github.com/Sophia-Gold/31d56817b0300cebbc2fbcd6de4e64fa#file-journalctl-gdm-gnome3-xmonad-L1414 could be of interest? And also the last line there as well?

Also the other thing you could try is to get a live usb/disk of a graphical distribution (of any distro) and live boot into it and see if your hardware (mouse and keyboard) work, cause it may even just be that linux doesn't support it yet.. :disappointed: And of course remember to check for the kernel version if your hardware does work (i.e. uname -a) on it, so that you can set that in NixOS. Alternatively you could also just try using a newer kernel and see if anything changes: https://nixos.org/nixos/manual/index.html#sec-kernel-config. For example to get the latest kernel, boot.kernelPackages = pkgs.linuxPackages_latest.

I'm sort of clueless as to what it could be though. :confused:

[Sophia-Gold]

I meant commenting out everything in services.xserver except the two lines you posted above.

I believe I attempted to launch a TTY from xterm (I certainly have on most of these tests before simply holding down the power button), but should try again and circle back.

I was initially suspicious of those lines from journalctl as well, but (like many things in there) I have little idea what they mean.

As mentioned in the title of this issue, I noticed the change when switching from 16.09 to 17.03. Although, I do understand that's unlikely the cause and more likely a change that occurred simultaneously with it...for example a kernel update. I was under the impression that not specifying a kernel version keeps me up to date with the latest, but that appears not to be the case since my current build is using 4.9.6. I'll update it and circle back if the problem persists.

[vyp]

Ok well I'm sort of out of ideas then for now, will update if I think of anything else, but I think that's probably unlikely. :confused:

But also, "launch a TTY from xterm"? As in you tried running a command in xterm? But I thought you couldn't use xterm?

[Sophia-Gold]

I meant launching a TYY using the keyboard shortcut, not the tty command that returns the current session.

Can you please confirm what kernel version Nix defaults to when none is specified? Someone on irc specifically told me I'd get the latest as default so I'd like to know whether adding the line you suggested would actually change anything or whether my conflict could be with the latest version (again, the one X Server works fine from is 4.9.6...I suppose I could also try specifying that in a 17.03 build).

[Sophia-Gold]

I've ruled out a kernel issue. As mentioned, the build that successfully launches X Server has 4.9.6. All problematic builds have had the same subversion (not sure how to specify a patch version in my config) until I recently tried 4.14 to no effect. At least I know the information I was given on irc about Nix defaulting to the latest kernel version was inaccurate.

I also suspected it could be the same issue documented here: https://github.com/NixOS/nixpkgs/issues/23545 as I had xmonad xmonad-contrib and xmonad-extras declared both in environment.systemPackages and windowManager.xmonad.extraPackages. I deleted the former in my config as well as ~./.xmonad yet the issue persisted. I even tried commenting out everything related to xmonad in services.xserver for good measure.

Finally, as far as org.freedesktop.PackageKit I do get some warnings from it on my successful build on lines 1374, 1378, and 1379: https://gist.github.com/Sophia-Gold/00929dd4a77eaed4d8d92a465d4d084d. Afaik, PackageKit is unnecessary when using gnome with Nix and may be the culprit per here: https://github.com/NixOS/nixpkgs/issues/21230 since I'm still on Nix 1.11.9. However, I'm not aware how to disable it (or other freedesktop packages for that matter). Would services.packagekit.enable = pkgs.lib.mkForce false do it?

Alternatively, I wonder if issues with PackageKit were resolved with 1.2? It appears to have been stable for some time now (https://github.com/G-Node/nix/releases), but nix-env upgrade still leaves me with 1.11.6 for 16.09 or 1.11.9 if I call nixos-rebuild switch first to get 17.03.

[vyp]

Yes so right now the linux kernel version is set to 4.9 (the first line in this snippet):

https://github.com/NixOS/nixpkgs/blob/5f0a7cded718d0092229ba078cb7f0f7733bf636/pkgs/top-level/all-packages.nix#L12473-L12478

And using linuxPackages_latest gets you 4.13, which is the latest stable release of linux right now. But of course, what these attributes are actually set to on an installation may be different depending on the NixOS version, since that means a different nixpkgs version.

And yeah, if not even just a plain X session works, it's probably not to do with xmonad (but fair, I know you're just documenting what you've tried).

However, I'm not aware how to disable it (or other freedesktop packages for that matter). Would services.packagekit.enable = pkgs.lib.mkForce false do it?

I don't know how to disable it, but looking at https://gist.github.com/Sophia-Gold/31d56817b0300cebbc2fbcd6de4e64fa#file-journalctl-gdm-gnome3-xmonad-L1414 again (I missed this before), it seems to be a gnome thing (".gnome-shell-wr")? My journalctl doesn't seem to mention org.freedesktop.packagekit anywhere either when I use X with just the herbstluftwm window manager. So it seems like it's probably not the issue then. And even then, looking at its description on wikipedia, it seems pretty useless to Nix (seems to be some sort of front end for package managers, in which none of the backends mention Nix), so it would seem harmless even if it cannot work. But of course you can try that!

Alternatively, I wonder if issues with PackageKit were resolved with 1.2? It appears to have been stable for some time now (https://github.com/G-Node/nix/releases), but nix-env upgrade still leaves me with 1.11.6 for 16.09 or 1.11.9 if I call nixos-rebuild switch first to get 17.03.

I'm assuming you meant 1.12 not 1.2, and https://github.com/NixOS/nix not the neuroscience information exchange format! :stuck_out_tongue_closed_eyes:

But I don't think Nix 1.12 has been released yet. I don't know how to upgrade Nix the package manger itself (it just seems gets upgraded automatically with the rest of the distribution for me), but are you sure it's nix-env upgrade and not nix-env --upgrade? But in any case I think the latest release of Nix is only 1.11.15, and as I said above, packagekit is probably not the issue if it's a gnome thing (sorry for mentioning it initially).

[Sophia-Gold]

Thank you for clearing up how kernel updates work, even though we've ruled that out as the cause.

And wow, I must have written this before coffee to have linked to Nix, the neuroscience information exchange format :rofl: At least I know my Nix version is up to date...

I agree it really does seem like a gnome issue, specifically with GDBus, and whatever extensions are causing trouble are just still present when I launch into xterm. I'm at loss, though. I know you can specify gnome packages with services.dbus.packages = with pkgs, but most users don't seem to need to.

Fwiw, the issue I linked to above about PackageKit says it's totally unnecessary with Nix and links to another issue with how to fix it until 1.12 hits stable, although it seems to make more sense to just disable it...if services.packagekit.enable = pkgs.lib.mkForce false does in fact do that.

[Sophia-Gold]

I don't use version control on my configuration.nix that often, but looking at my commits now it appears I _did_ switch to gdm right around the time this all broke. Now that I'm starting to realize commenting things out and then rebuilding often doesn't delete everything they've installed I wonder if that could be it.

[vyp]

launch into xterm

I keep getting a bit confused, you mean launched into X right? Because xterm is the terminal emulator. But anyways, so if packagekit is related to gnome, but if the issue still happens with just:

{
  services.xserver = {
    enable = true;
    layout = "us";
  };
}

which should not be using gnome at all, then packagekit should not be the cause to your freezing problem.

Fwiw, the issue I linked to above

Oh right I missed this :see_no_evil:, so packagekit does have a Nix backend. So I guess to disable it you could also try:

{
  nixpkgs.config.packageOverrides = pkgs: {
    packagekit = pkgs.packagekitoverride {
      enableNixBackend = false;
    };
  };
}

Now that I'm starting to realize commenting things out and then rebuilding often doesn't delete everything they've installed I wonder if that could be it.

I'm assuming you're referring to unused /nix/store paths? (i.e. the garbage that can be collected with nix-collect-garbage.) That shouldn't be an issue at all. In fact, this not being an issue is like the whole point of declarative configuration. :stuck_out_tongue:

[Sophia-Gold]

I was referring to things like how in the issue I linked to about xmonad it appeared to be the config file, ~/.xmonad, hanging around that was causing the problem so it seems like sometimes one does need to manually clean things. At least this is my current hypothesis to explain why the fact that xterm freezes after loading could be due having once built gdm or PackageKit or whatever else. Otherwise, I truly have no idea what's going on here.

[vyp]

Yes so ~/.xmonad being a program configuration file that xmonad uses, it will obviously affect things if xmonad is enabled. But if not enabled, then the ~/.xmonad file laying around should not be affecting things. So similarly, if you only have the enable = true; and layout = "us"; attributes for services.xserver, it means that gnome is not enabled, and therefore any such program files laying around from a previous installation of gdm or packagekit should not affect anything. (Because iirc the default display manager is slim.)

[Sophia-Gold]

No idea what's going on when I boot to xterm then. I'll try disabling PackageKit just for the sake of it when I'm able to reboot, but am not particularly hopeful it will have any effect.

[vcunat]

Hmm, except for the gdm case (which gets struck earlier), I think the real error line is

.../bin/xauth: file /home/sophia/.Xauthority does not exist

You could try some proposals found on the internet (like these), but I would first try a different DM – I have personally good experience with lightdm. GDM tends to be difficult to package well in NixOS and wasn't much used/maintained by NixOS people around 17.03 AFAIK; slim is the default but that's been heavily disputed as it's been unmaintained upstream for many years now.

[Sophia-Gold]

@vcunat thanks for chiming in!

Lightdm got my hopes up because it didn't freeze like GDM and SLiM, but still didn't launch Gnome or XMonad. I was also able to use ctrl-alt-1, surely able to just being able to use the keyboard/touchpad in general, although it just gave me a black screen with no TTY prompt. Ctrl-alt-7 didn't bring me out of it as well.

Here's the journalctl dump from that: https://gist.github.com/Sophia-Gold/71858c4a6f15ab37d1c285ffa047c3ba. It doesn't have that xauth error, although does still complain about PackageKit (I haven't tried disabling it yet).

I should also probably mention the 16.09 build I'm able to boot into _does_ use GDM (I'm not sure how to check the version to see if it changed with the NixOS upgrade since I don't have it installed in systemPackages).

[vyp]

Lightdm got my hopes up because it didn't freeze like GDM and SLiM, but still didn't launch Gnome or XMonad. I was also able to use ctrl-alt-1, surely able to just being able to use the keyboard/touchpad in general, although it just gave me a black screen with no TTY prompt.

XMonad doesn't open a terminal or do anything by default, you have to use keybindings to open a terminal, but I'm assuming you knew that? (Just making sure you know that xmonad is indeed not being launched.) Not sure about what happens when using xmonad with gnome though.

Anyway so this might mean that a plain X session is not the problem, and the problem might be to do with either xmonad or gnome (if it isn't the lack of the .Xauthority file).

[Sophia-Gold]

Yup. I tested all iterations of my X Server services when opening this issue.

The problem really does appear to be PackageKit at this point. I tried disabling it with the override you suggested above, but it doesn't seem to have worked since I still get the same errors (this is back with GDM btw): https://gist.github.com/Sophia-Gold/9fb518967b9ef0264575e987ea173724.

Also, apologies but it appears I was looking at the wrong date in Git when I suspected GDM. The last build I can boot into, and the last using 16.09, was from May 22nd. Here's the log for my configuration.nix: https://github.com/Sophia-Gold/configuration.nix/commits/master. The only changes committed on that day and the following one involve disabling XMonad and adding some trivial packages.

[vcunat]

Eww, kernel errors related to the nouveau driver. You can try to either (1) use the unfree driver as it tends to work better overall services.xserver.videoDriver = "nvidia"; or (2) use a different kernel version, hopefully free from that bug. 16.09 used 4.4.x kernel and those will still be supported upstream for about half a year, or you may try a newer one, but there's no longterm-support version newer than the default 4.9.x yet, so you'd have to be switching over time (to 4.13 ATM).

[Sophia-Gold]

The unfree driver breaks X entirely for me. It boots into a tty and the keyboard is glitchy and barely responsive :disappointed:

[Sophia-Gold]

Oh, wait. Also I was on 4.9 even when using 16.09 and tried 4.13 on 17.03. Neither changed anything. Should I try 4.13 with the unfree driver?

[vcunat]

Hmm, strange that it's breaking so much. Yes, I would probably try 4.13 with both unfree and the free driver (separately).

[Sophia-Gold]

Same behavior (no display manager, straight to tty) with boot.kernelPackages = pkgs.linuxPackages_latest. I tried that previously without specifying the unfree driver and saw no changes.

[Sophia-Gold]

I got a bit fatigued in troubleshooting this, but had to upgrade to 17.09 for one package so was hoping that would help (it didn't). At this point, I'm pretty sure it's a hardware specific issue with the graphics card...especially since I'm unable to disable either the Nvidia card or integrated graphics in BIOS. I need a new laptop anyway :slightly_frowning_face:

[Sophia-Gold]

I also appear to be missing a ton of packages after upgrading to 17.09, including google-chrome and my password manager. Lovely...

[vyp]

Perhaps then look into ways of running hardware tests for your laptop, if possible?

I don't know why you would be missing packages though. :( To begin with, maybe try setting your environment.systemPackages to only include google-chrome (temporarily) and see if that still works or not.

[Sophia-Gold]

Well, I was able to install pass with nix-env but obviously I can't do that with Chrome unless I set up a separate config.nix for allowUnfree. I'm still using Chrome now, but it's 55.

@7c6f434c was very helpful on irc and suspects this machine may just be screwed as far as graphics goes, which I seemed to have confirmed from the BIOS.

[7c6f434c]

For Chrome you can run NIXPKGS_ALLOW_UNFREE=1 nix-env -iA google-chrome…

[7c6f434c]

I mostly said that everything with Nvidia is partially messed up as far as graphics goes…

I would also try with videoDrivers = lib.mkForce ["modesetting"]; maybe.

[Sophia-Gold]

I thought you also mentioned something to the effect of this laptop possibly having graphics wired in an odd manner, which would explain my shock at learning I have no control over it in the BIOS.

The actual specs refer to the GeForce GTX 960M as a "graphics coprocessor," which makes me wonder if they're just using that term for marketing or if the motherboard is actually designed so it replaces integrated graphics. It seems like possibly the latter, which is kind of horrible.

I'm constantly reminded that reinstalling from scratch is pointless with NixOS, but since I have no idea what upgrade in the 17.03 channel led to this I'm tempted to just boot from a disk image and add in bits of my configuration.nix until I find it. I suppose bisecting it would achieve the same ends, but considering I've tried all combinations of the likely culprits and never even been able to boot into just an xterm I'm suspicious some of the garbage left behind when removing packages could be misleading when troubleshooting.

[vcunat]

It is possible. My old notebook has both integrated GPU (i3) and dedicated one (nvidia), and it's only able to use the dedicated one, on any OS. (But it was a rather cheap notebook.)

[7c6f434c]

I would expect that if an Asus system cannot switch off Nvidia GPU, it
has no other GPU wired to the video outputs.

Booting from a CD might help in terms of making sure… but maybe some
special tricks are necessary with that video card, then you need to find
a generic description and then adapt it to NixOS…

[Sophia-Gold]

Well, it worked before I switched channels to 17.03 so I can probably fix it as long as I can isolate exactly which package(s) I need to override to an earlier version. I guess I'll see if I get around to that before I get around to purchasing a new laptop...

[Ekleog]

(triage) Is this still an issue with more recent releases?

[arianvp]

(triage) is this still an issue?