Error installing KDE spin. I think

Help
1

I try to install the KDE ver. Of NixOS from the ISO on the website. After I boot off the USB. When trying to install the OS. I get to 46% of the installation, it stops for a few sec. Then just says it was installed. Then I can check the box to reboot. Then I reboot. After reboot, the system boots and I can log in. But when I open Dolphin. The only folder in the home folder, it is Desktop and Videos, nothing else. I know I can make them. I would like to know did the installation had an error?

2

That’s not a reason to assume the installation failed; NixOS does not create these directories.

You can create them correctly using the xdg-user-dirs package.

If you want them to be automatically created when you install your configuration, you need to make nix run that binary - this can be done with e.g. system.userActivationScripts. home-manager also has an option to do that: Appendix A. Configuration Options.

If you didn’t see any errors during installation, there almost certainly were none. The only thing that can happen is that some of the activationscripts fail, but you would see that on boot as well.

If this is really making you paranoid, you can just run nixos-rebuild switch on your running system at any time. Since your configuration is declarative this will redeploy the exact same system again, without deleting any data. If there were any issues you didn’t spot, that command will show them again.

3

Thanks, I’m new to NixOS. I moved from Ubuntu. That why I thought it was an error. They had the folder for you

4

Desktop environments are responsible for creating those directories – they should install xdg-user-dirs and have support for XDG autostart spec. GNOME does it but it does not seem to work in Plasma for some reason.

1 Like
5

One day I should try a DE so I actually know what to expect from them :sweat_smile:

6

I am author of this bug. This is bug of KDE Plasma. Plasma should create the directories and there is method to disable their creation, but Plasma ignores them. You have 100% always only “Desktop” dir on current 22.11 Plasma. To workaround this bug, do this: in ~/.config/autostart create a file “userdirs.desktop” with this content:

[Desktop Entry]
Exec=xdg-user-dirs-update
TryExec=xdg-user-dirs-update
NoDisplay=true
StartupNotify=false
Type=Application
X-KDE-AutostartScript=true
X-KDE-autostart-phase=1

This will cause KDE to automatically execute the xdg-user-dirs-update script. There is probably an elegant option to create this file through either systemd user service within configuration.nix or output it through nix expression. I have not utilized this approach.

On how to customize the name of these directories, this is from my configuration.nix:

environment.etc."xdg/user-dirs.defaults".text=''
 DESKTOP=Desktop
 DOWNLOAD=Downloads
 TEMPLATES=Documents/Templates
 PUBLICSHARE=Documents/Public
 DOCUMENTS=Documents
 MUSIC=Documents/Music
 PICTURES=Documents/Photos
 VIDEOS=Documents/Movies
'';

Beware, that xdg supports only very thin amount of strings, which are automatically translated/localized. That means, that if you use words outside of this list, they will not be translated into current locale and will be used “as is”. Xdg does not use any translator for this, but just this list: The xdg-user-dirs textual domain So localization options of these directories are very rudimentary.

7

If this works and the identical file in /run/current-system/sw/etc/xdg/autostart/xdg-user-dirs.desktop does not, that sounds more like some Plasma component not seeing XDG_CONFIG_DIRS environment variable.

8

Apparently, it is an issue how the autostart files from xdg-user-dirs interact with systemd.

It should be fixed in next version of xdg-user-dirs: Add a systemd service to run xdg-user-dirs-update (2a63d3f0) · Commits · xdg / xdg-user-dirs · GitLab

9

That bug passes remarkably into the whole picture, thanks a lot @jtojnar!
Until it lands, either use the provided autostart desktop file for KDE. Or here is the systemd user service for NixOS to add to configuration.nix, until this workaround lands.

(edit: this is obsolete, use improved script provided by @peterhoeg below instead // thanks for looking into it and improving it, peterhoeg!! // I replaced pkgs.bash with pkgs.xdg-user-dirs mistake as pointed out by peterhoeg)

systemd.user.services.xdg-user-dirs_workaround={
 description="(Workaround to 2a63d3f0) User folders update";
 documentation=["man:xdg-user-dirs-update(1)"];
 path=[pkgs.xdg-user-dirs];
 wantedBy=["graphical-session-pre.target"];
 unitConfig.RequiresMountsFor="/home";
 serviceConfig.Type="oneshot";
 script="${pkgs.xdg-user-dirs}/bin/xdg-user-dirs-update";
};

Its safe even after said service file lands from upstream, because xdg-user-dirs locks itself after it runs once by creating this anchor (~/.config/user-dirs.dirs) and so long it exists. Anchor contains localized strings and its possible to edit its contents for a custom user paths; or simply remove it for paths to be generated again.

10
  1. xdg-user-dirs-update is not part of bash
  2. you don’t need to set the path since you are going to use an absolute path anyway
  3. make sure it only runs for actual interactive users
  4. you can also gate it behind a check for ~/.config/user-dirs.dirs to play it safe
{
  systemd.user.services.xdg-user-dirs_workaround = {
    description = "(Workaround to 2a63d3f0) User folders update";
    documentation = "man:xdg-user-dirs-update(1)";
    wantedBy = ["graphical-session-pre.target"];
    unitConfig = {
      ConditionPathExists = "!%E/user-dirs.dirs";
      ConditionUser = "!@system";
      RequiresMountsFor = "/home";
    };
    serviceConfig = {
      Type="oneshot";
      ExecStart = "${pkgs.xdg-user-dirs}/bin/xdg-user-dirs-update";
    };
  };  ¤ systemd.user.services.xdg-user-dirs_workaround = {
}
1 Like