User unable to start xfce session after update

I’ve been running a distromorphed Debian 12 install with xfce for a while without hickups. Updated the base distro to trixie last year without much problems (though i fear this is where i started setting myself up for now).

Just realized the signing key had been out of date for a bit and updated that and ran an apt dist-upgrade. I did not run release-upgrade. Since the reboot neither the user “user” nor my diverging own user “chosen-user-name” can start an xfce session.

When i try to login from lightdm it accepts the password , display blacks out shortly but then goes back to lightdm login screen

From tty i get the X server message and “cannot open display”

/usr/bin/startxfce4: Starting X server
X.Org X Server 1.21.1.16X Protocol Version 11, Revision 0Current Operating System: Linux hostname 6.1.0-39-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.148-1 (2025-08-26) x86_64Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-39-amd64 root=/dev/mapper/vgname–vg-root ro mitigations=auto,nosmt nosmt=force spectre_v2=on spectre_bhi=on kpti=1 spec_store_bypass_disable=on ssbd=force-on l1tf=full,force kvm-intel.vmentry_l1d_flush=always mds=full,nosmt tsx=off tsx_async_abort=full,nosmt kvm.nx_huge_pages=force l1d_flush=on mmio_stale_data=full,nosmt retbleed=auto,nosmt kvm.mitigate_smt_rsb=1 gather_data_sampling=force reg_file_data_sampling=on indirect_target_selection=force vmscape=force random.trust_bootloader=off random.trust_cpu=off intel_iommu=on amd_iommu=on efi=disable_early_pci_dma iommu.passthrough=0 iommu.strict=1 slab_nomerge slab_debug=FZ init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on randomize_kstack_offset=on vsyscall=none debugfs=off kfence.sample_interval=100 vdso32=0 cfi=kcfi ia32_emulation=0 efi_pstore.pstore_disable=1 erst_disable bdev_allow_write_mounted=0 proc_mem.force_override=ptrace amd_iommu=force_isolation intel_iommu=on iommu=force iommu.passthrough=0 iommu.strict=1 efi=disable_early_pci_dma random.trust_cpu=off random.trust_bootloader=off extra_latent_entropy loglevel=0 loglevel=0 quiet rd.emergency=halt rd.shell=0 systemd.unit=multi-user.targetxorg-server 2:21.1.16-1.3+deb13u1 (https://www.debian.org/support)Current version of pixman: 0.44.0Before reporting problems, check http://wiki.x.orgto make sure that you have the latest version.Markers: (–) probed, (**) from config file, (==) default setting,(++) from command line, (!!) notice, (II) informational,(WW) warning, (EE) error, (NI) not implemented, (??) unknown.(==) Log file: “/home/chosen-user-name/.local/share/xorg/Xorg.0.log”, Time: Tue Mar 17 2026(==) Using config directory: “/etc/X11/xorg.conf.d”(==) Using system config directory “/usr/share/X11/xorg.conf.d”xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted)xfce4-session: Cannot open display: .Type ‘xfce4-session --help’ for usage.xinit: connection to X server lost
waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.

saw the seeminly unrelated issue of other users not being added to group privleap but adding didnt change anything and as mentioned “user” also cannot start xfce4

checked .Xauthority and .ICEauthority and they are correctly owned

couldnt find anything telling in the logs but i don’t understand PAM really

Any hints or words of wisdom?

1 Like

It sounds like you’re now running an unsupported hybrid of Kicksecure 17 packages on top of Debian Trixie. Kicksecure 17 packages were only supported on Debian Bookworm, and are currently unsupported on all except for Qubes OS. See:

The recommended way to upgrade a Kicksecure 17 system to Kicksecure 18 is to use the /usr/sbin/release-upgrade script, which has several workarounds in it to make sure the upgrade is more likely to go smoothly. Now that you’ve upgraded the base system to Trixie though, it’s potentially too late to use it successfully. Upgrading your Kicksecure packages to Kicksecure 18 will most likely not work either, since the fixes the release-upgrade script would have applied won’t be applied.

At this point, your best bet is probably to reinstall the system from scratch, either using a Kicksecure 18 image, or using a Debian Trixie image and then distribution-morphing it into Kicksecure 18.

3 Likes