GDM starts slowly when noto-fonts-cjk is installed

[aparten]

On unstable, when noto-fonts-cjk is added to fonts, GDM displays a blank screen for several minutes before the greeter appears. Sometimes the greeter doesn't start, and the "Something has gone wrong" screen appears instead. This issue does not occur when using SDDM or LightDM, or with any other noto-fonts packages.

[jgillich]

Are you sure this is related to the fonts? GDM also gives me a blank screen on multiple machines, and I don't use them.

[aparten]

I tried testing this configuration and the issue still occurs:

{ config, pkgs, ... }:

{
  imports = [
    ./hardware-configuration.nix
  ];

  # Use the gummiboot efi boot loader.
  boot.loader.gummiboot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  fonts.fonts = [ pkgs.noto-fonts-cjk ];

  system.stateVersion = "16.03";

  services.xserver = {
    enable = true;
    desktopManager.gnome3.enable = true;
    displayManager.gdm.enable = true;
  };
}

If I remove the "fonts" line, GDM works fine.

[abbradar]

FWIW I remember having applications (several ones, can't remember exactly which but I mostly use GTK2) eating 100% of CPU resources with those fonts installed -- had to remove them.

[aparten]

I've looked into this again, and I've found more information.

• The issue also affects SLiM and LightDM, although I thought LightDM was working. SDDM is not affected.
• All of these display managers show 100% CPU usage during startup.

The CPU usage seems to come from rebuilding the font cache. I ran fc-cache --really-force --verbose and it shows 100% CPU usage while building Noto, so it seems likely that fontconfig has something to do with the issue.

[abbradar]

Try #12668 for a potential fix.

[aparten]

@abbradar That fixed the issue for LightDM and Slim, but now GDM just only shows a blank screen, even without noto-fonts-cjk.

[abbradar]

@aparten I cannot confirm this in a VM, because for me GDM keeps showing a black screen even on current unstable channel. I was using this expression:

let

  config = { config, pkgs, ... }:
    {
      services.xserver.enable = true;
      services.xserver.displayManager.gdm.enable = true;

      users = {
        mutableUsers = false;
        extraUsers.root.password = "";
        extraUsers.user = {
          uid = 1000;
          password = "";
          isNormalUser = true;
        };
      };
    };

  nixos = import <nixpkgs/nixos> {
    configuration = config;
  };

in nixos.vm

Can you give a minimal working example of your configuration?

[lucabrunox]

@aparten does it happen on metal machine or kvm?

[aparten]

@abbradar @lethalman The problem happens on baremetal using this config:

{ config, pkgs, ... }:

{
  imports = [
    /etc/nixos/hardware-configuration.nix
  ];

  # Use the gummiboot efi boot loader.
  boot.loader.gummiboot.enable = true;
  boot.loader.efi.canTouchEfiVariables = true;

  services.xserver = {
    enable = true;
    displayManager.gdm.enable = true;
    displayManager.gdm.debug = true;
  };

  users.extraUsers.alec = {
    isNormalUser = true;
    uid = 1000;
    home = "/home/alec";
    extraGroups = [ "wheel" "systemd-journal" ];
  };
}

[abbradar]

Just to be sure (because I get black screens either way in VM) -- on the same nixpkgs tree but without my patches for fontconfig cache, does GDM work?

[aparten]

I've gotten the font patches working now. Apparently GDM wasn't working properly with my test config because I hadn't enabled GNOME. Once I did that, everything worked fine.

[abbradar]

Fix pushed to staging in https://github.com/NixOS/nixpkgs/commit/53e0f8b1cdf36574bfede6e62e2ac2739c3ef804

[abbradar]

BTW, this GDM behavior should be reported as a bug I think.

[vcunat]

@lethalman should know how much GDM and GNOME3 depend on each other in nixos (as for our current "support").

[lucabrunox]

@vcunat no idea, never used gdm with anything else than gnome. Probably some service that is enabled by gnome3 is required by gdm, but gdm doesn't enable it.

[vcunat]

So, I think that means we don't really support it (yet) :-) An issue could be opened, but it's possible it will just be sitting there indefinitely...