Mismatching Qt versions between home-manager and system nixpkgs

Help
1

My config

I use nixos, and standalone home-manager, and plasma-manager.

The main symptom

KDE connect broke:

❯ kdeconnect-app
qrc:/qt/qml/org/kde/kdeconnect/app/WelcomePage.qml:13:1: QML WelcomePage: Created graphical object was not placed in the graphics scene.
Cannot mix incompatible Qt library (6.8.2) with this library (6.9.1)
KCrash: Application '.kdeconnect-app-wrapped' crashing... crashRecursionCounter = 2
[1]    26993 IOT instruction (core dumped)  kdeconnect-app

Interestingly, system monitor tells me that I have Qt version 6.8.2 and KDE Plasma Version 6.3.3. and KDE Frameworks Version 6.12.0.

The most likely issue

I installed kdeconnect with homemanager.
But home-manager.inputs.nixpkgs.follows = "nixpkgs";, so I don’t see why this should be a problem.

I have kate installed both for the entire system as well as with home-manager. Look at this:

❯ ls -lisa /run/current-system/sw/bin/kate
30286670 4 lrwxrwxrwx 2 root root 65  1. Jan 1970  /run/current-system/sw/bin/kate -> /nix/store/07sxmymcldi48icr7b2ys9vjamklbvsx-kate-24.12.3/bin/kate

ls -lisa ~/.nix-profile/bin/kate
31199874 4 lrwxrwxrwx 6 root root 65  1. Jan 1970  ~/.nix-profile/bin/kate -> /nix/store/gswxcv4s4kmcrc7069lpqashvhpics6l-kate-25.08.0/bin/kate

This kinda smells bad, yet I have no idea how it happened and how to make them sync again.

Some more stuff, most likely unrelated

Possibly related github issue, but on the other hand this should be too old to be relevant now.

Another possibly related bug, but I just manually deleted all ~/.cache/$something/qmlcache and the error doesn’t really change. (Although I’m not sure whether there might be some different cache directory I forgot.)

One more possibly related issue now that I think about it, some stylings are broken sometimes, mainly kate. Since this is a kde app, it shouldn’t be this issue. On the other hand, why would it somehow not use the Breeze style that I applied everywhere?

Update

I deleted the flake.lock in both the private and the public repo, updated everything, there is a single version of nixpkgs in there now, and yet, all the issues persist :/

Update 2

After booting, I have a nixos 25.05. After doas nixos-rebuild switch --flake . I have a nixos 25.11. I have absolutely no idea why this isn’t persistent, and why it’s wrong after the next booting. the hell.

Troubleshooting: Kde/Qt issues. using hm and pm
2

What command tells you this? And what’s the output of nixos-rebuild list-generations?

3

guesses, other things to check:

  • that updates to the boot manager are happening properly, such that you’re actually booting new generations and not stuck at an old one
  • that you don’t have an autoupdate service that’s looking at an old config (stale channels rather than flakes) and “upgrading” you to an older revision in the background later, which you discover at the next boot
4

What command tells you this?

nixos_25_05
nixos_25_05953×679 64.9 KB

And what’s the output of nixos-rebuild list-generations?

❯ doas nixos-rebuild list-generations
ls: cannot access '/nix/store/2pcjcww53jjir5j239w0kwi3z63z1gdg-linux-6.12.43/lib/modules': No such file or directory
ls: cannot access '/nix/store/mm4j675zx2w5fjiq84wyapa5r87crh7m-linux-6.12.42/lib/modules': No such file or directory
ls: cannot access '/nix/store/mm4j675zx2w5fjiq84wyapa5r87crh7m-linux-6.12.42/lib/modules': No such file or directory
Generation   Build-date           NixOS version           Kernel   Configuration Revision  Specialisation
115 current  2025-08-27 00:11:06  25.11.20250825.3b9f00d  Unknown                          *
114          2025-08-24 22:46:14  25.11.20250819.2007595  Unknown                          *
113          2025-08-21 23:33:39  25.11.20250819.2007595  Unknown                          *
112          2025-07-15 22:51:41  25.11.20250627.30e2e28  6.12.34                          *

And yeah, that shouldn’t have an error

❯ nix --version
nix (Lix, like Nix) 2.91.1
5

I have no autoupdate service I’m aware, and I’m not using channels.

But the boot loader stuff might be a really good hunch:

(output abbreviated, showing only the default entry which I’m always booting with)

❯ bootctl status

Default Boot Loader Entry:
     type: Boot Loader Specification Type #1 (.conf)
    title: NixOS (Generation 115 NixOS Xantusia 25.11.20250825.3b9f00d (Linux 6.12.43), built on 2025-08-27)
       id: nixos-generation-115.conf
   source: /boot//loader/entries/nixos-generation-115.conf (on the EFI System Partition)
 sort-key: nixos
  version: Generation 115 NixOS Xantusia 25.11.20250825.3b9f00d (Linux 6.12.43), built on 2025-08-27
machine-id: 49098e1ec2804c839d34f9bae282d575
    linux: /boot//EFI/nixos/2pcjcww53jjir5j239w0kwi3z63z1gdg-linux-6.12.43-bzImage.efi
   initrd: /boot//EFI/nixos/bq0yl516vvdjigb3jqg7zsymfjn4pllm-initrd-linux-6.12.43-initrd.efi
  options: init=/nix/store/w6599qr8nj27q0l920434lnjc4awam01-nixos-system-blackbox-25.11.20250825.3b9f00d/init loglevel=4 lsm=landlock,yama,bpf nvidia-drm.modeset=1 nvidia-drm.fbdev=1 nvidia.NVreg_PreserveVideoMemoryAllocations=1 nvidia.NVreg_OpenRmEnableUnsupportedGpus=1

Might even be a “fucked up nvidia driver ting” in the end? :thinking:

6

This has nothing to do with nvidia.
What’s bootctl status and nixos-version say if you run those before vs. after running any rebuilds? Just trying to confirm if there is actually a difference here.

Also, please share your bootloader config. (The config link you shared appears to be 500-ing.)

7

Before

❯ bootctl status
System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (setup)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

Random Seed:
 System Token: set
       Exists: yes

Available Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977)
     File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 257.7)
           └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 257.7)

Boot Loaders Listed in EFI Variables:
        Title: NixOS-boot
           ID: 0x0002
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977
         File: └─/EFI/NixOS-boot/grubx64.efi

        Title: Linux Boot Manager
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: UEFI OS
           ID: 0x0009
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977
         File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977)
        token: nixos

Default Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: NixOS (Generation 115 NixOS Xantusia 25.11.20250825.3b9f00d (Linux 6.12.43), built on 2025-08-27)
           id: nixos-generation-115.conf
       source: /boot//loader/entries/nixos-generation-115.conf (on the EFI System Partition)
     sort-key: nixos
      version: Generation 115 NixOS Xantusia 25.11.20250825.3b9f00d (Linux 6.12.43), built on 2025-08-27
   machine-id: 49098e1ec2804c839d34f9bae282d575
        linux: /boot//EFI/nixos/2pcjcww53jjir5j239w0kwi3z63z1gdg-linux-6.12.43-bzImage.efi
       initrd: /boot//EFI/nixos/bq0yl516vvdjigb3jqg7zsymfjn4pllm-initrd-linux-6.12.43-initrd.efi
      options: init=/nix/store/w6599qr8nj27q0l920434lnjc4awam01-nixos-system-blackbox-25.11.20250825.3b9f00d/init l>

and the other:

❯ nixos-version
25.05.20250330.52faf48 (Warbler)

Then the switch

❯ doas nixos-rebuild switch --flake .

Afterwards

System:
      Firmware: n/a (n/a)
 Firmware Arch: x64
   Secure Boot: disabled (setup)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported

Random Seed:
 System Token: set
       Exists: yes

Available Boot Loaders on ESP:
          ESP: /boot (/dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 257.7)
               └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 257.7)

Boot Loaders Listed in EFI Variables:
        Title: NixOS-boot
           ID: 0x0002
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977
         File: └─/EFI/NixOS-boot/grubx64.efi

        Title: Linux Boot Manager
           ID: 0x0001
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977
         File: └─/EFI/systemd/systemd-bootx64.efi

        Title: UEFI OS
           ID: 0x0009
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977
         File: └─/EFI/BOOT/BOOTX64.EFI

Boot Loader Entries:
        $BOOT: /boot (/dev/disk/by-partuuid/f3e963a5-4e59-8a48-b3c0-e6e492936977)
        token: nixos

Default Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: NixOS (Generation 115 NixOS Xantusia 25.11.20250825.3b9f00d (Linux 6.12.43), built on 2025-08-27)
           id: nixos-generation-115.conf
       source: /boot//loader/entries/nixos-generation-115.conf (on the EFI System Partition)
     sort-key: nixos
      version: Generation 115 NixOS Xantusia 25.11.20250825.3b9f00d (Linux 6.12.43), built on 2025-08-27
   machine-id: 49098e1ec2804c839d34f9bae282d575
        linux: /boot//EFI/nixos/2pcjcww53jjir5j239w0kwi3z63z1gdg-linux-6.12.43-bzImage.efi
       initrd: /boot//EFI/nixos/bq0yl516vvdjigb3jqg7zsymfjn4pllm-initrd-linux-6.12.43-initrd.efi
      options: init=/nix/store/w6599qr8nj27q0l920434lnjc4awam01-nixos-system-blackbox-25.11.20250825.3b9f00d/init l>

and the version:

❯ nixos-version
25.11.20250825.3b9f00d (Xantusia)

I also checked

❯ bootctl list

and it lists 4 configurations, all of them nixos 25.11

Bootloader config

What do you mean, the link is 500ing?

In my private config for this device there is this config part

 boot.loader = {
     systemd-boot.enable = true;
     efi.canTouchEfiVariables = true;
 # these comments specifically mean that I removed these lines at some point, mostly for reasons I cannot remember.  
 #     efi.efiSysMountPoint = "/boot"; # is the default
 #     grub = {
 #       enable = true;
 #       efiSupport = true;
 #       devices = [ "nodev" ];
 #       useOSProber = true;
 #     };
   };
8

So you switched from grub to systemd-boot?
The EFI vars don’t seem to mention it but… do you still have grub on that drive, that you might be accidentally booting into?

1 Like
9

This is probably a red herring. I mean, it’s not surprising, you’re using nixpkgs-unstable: flake.nix · main · jules / juless-nixos-config · GitLab

Unstable’s version number will tell you the version of the next stable version, because that’s what’s in development. You likely just never updated your flake.lock before (deleting and rebuilding will make nix recreate it from scratch, with the most recent commits for all inputs), or previously had a stable nixpkgs in there.

Regarding the actual issue you’re describing, your configuration is extremely unorthodox. Doing stuff like putting nixpkgs overrides in the pkgs arg of nixosSystem is inadvisable, there are options for that. You do similar things for mkHome, and you don’t seem to use the home-manager module? It’s very hard to read your configuration, I can’t spot immediately how the nixpkgs input → NixOS/home-manager.

What’s your full deployment flow?

10

do you still have grub on that drive, that you might be accidentally booting into?

Indeed, that it what happened. Thank you!

(Although I’m still a bit flabberghasted that a) there was nothing in the logs indicating I wasn’t booting from the default boot loader entry and b) that it took several months for any problems to manifest. KDE truly is stable)

11

This is probably necessary anymore since the problem is solved, but I think it might still be interesting why I’m doing things the way I’m doing them.

there are options for that

In that case I’m not aware of them/was thinking I’m already using them.

using nixos-unstable (it’s not nixpkgs-unstable)

Well, that is what everybody around me is doing, and problems there seem to get fixed, whereas the stable version has bitrot but no devs. Haven’t really had any problems with that yet, and in the rare cases where there where some, I installed only those specific packages from a stable version. worked fine enough so far. Might change that if it doesn’t.

home-manager

You do similar things for mkHome, and you don’t seem to use the home-manager module?

No, it’s standalone home-manager.

> Full deployment flow

I have a private config repo, with a single input (the very repo I linked you to) containing very concise system configs consisting only of

  • the hardware-config.nix, and driver stuff, and booting stuff
  • very short statement like
    my.gaming = true;, activating the options in my main config
  • things I like to call “kinda secret, but not really” – vpn endpoints, public urls of my offsite backup servers, my authorizedkeys for my server stuff – nothing cryptographically relevant, yet I don’t want to be readable by the entire internet

this config mostly just calls the builders of the public repo

the reason for that is that I can show other people all the interesting stuff / everything I need to show but not giving away the part I don’t want

12

Oh, I didn’t mean to imply using unstable was an issue (as long as you’re aware that using unstable can result in you having to fix things since there are no stability guarantees whatsoever); I’m just trying to explain why you’re seeing a change in version. Upon re-reading your message, I get what’s going on and why @waffle8946 asked they did, I completely misread that, several times o\

I meant deployment, not repository structure. I wanted to figure out how you’re using the home-manager/nixos-rebuild commands, in case the schism was happening at CLI time. Obviously that isn’t the case, so the point is moot. Again, I misunderstood what you meant with the upon-boot and upon-switch thing.

Using nixpkgs.overlays, nixpkgs.config & co. should be preferred. home-manager has the same set of options.

This way the module system can take over building the pkgs arg, and you get all the benefits of composition and upstream maintenance.

Pushing your own, already-resolved pkgs into the nixosSystem call is possible, but having read through the code regarding this, it’s quite hairy; I believe it’s mostly intended for testing, it’s definitely not the way users are intended to modify the pkgs arg.

1 Like