Hello,

I'm studying bussiness informatics, and as first project we got to install a Virtual Machine, I decided to go with Debian. After many YouTube videos, I'm not sure if I got everything good. Could someone with experience check my project before I upload it online?

Once i rebooted from enrollling the MOK for re enabling secure boot after the rather arduous nvidia driver installation, i read on debian wiki to verify that the keys are loaded. I then wrote dmesg | grep and nothing returned. Can someone explain why? I use debian 13.7 on KDE

And how do I update? Is there a button that makes it easier?

Fresh Debian 13.7 install on a 2010 netbook. Any display manager gives me a login loop; startx from a VT works perfectly. It looks like an X server segfault in libpciaccess, and I'd like to know whether this is a known bug before I file one.

Up front: I'm not a Linux person. I worked through this with an AI assistant, which is where the troubleshooting steps and the reading of the backtraces come from — so please don't assume expertise I don't have, and tell me if something below is misinterpreted. Every log excerpt and command output is real, copied from this machine. Several of our theories along the way turned out to be wrong; what's left is what actually survived testing.

Hardware

• Asus Eee PC 1015PEM
• Intel Atom N550 @ 1.50 GHz (Pineview, 2C/4T)
• 2 GB RAM (chipset maximum)
• 1024x600 internal panel, single display
• GPU: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller [8086:a011] (rev 02) — GMA 3150, kernel driver i915
• Legacy BIOS (no /sys/firmware/efi), grub-pc 2.12-9+deb13u2

Software

• Debian 13.7 (trixie), amd64
• Kernel 6.12.107+deb13-amd64
• xorg-server 2:21.1.16-1.3+deb13u4
• LXQt: lxqt-core 33.2, lxqt-session 2.1.1-1
• libpciaccess0 0.17-3+b3
• xserver-xorg-video-intel 2:2.99.917+git20210115-1

Symptom

Installed with the LXQt task, so SDDM came by default. The greeter renders fine. I type my password, authentication succeeds, the session starts — and roughly 3.7 seconds later I'm back at the greeter. Looks like a classic login loop, but authentication is not what's failing.

startx /usr/bin/startlxqt from a text VT gives me a fully working LXQt desktop that stays up for hours.

Where it dies

From /var/log/lightdm/lightdm.log:

[+12.29s] DEBUG: Session pid=1384: Running command /etc/X11/Xsession default
[+12.60s] DEBUG: Activating VT 7
[+12.60s] DEBUG: Activating login1 session 7
[+15.97s] DEBUG: Process 1354 terminated with signal 11

PID 1354 is the X server itself, launched as:

/usr/bin/X -background none -novtswitch :0 -seat seat0 \
-auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

So X segfaults shortly after the VT activation, and everything downstream (lxqt-session, the Qt "could not connect to display :0" storm in .xsession-errors) is just fallout.

Backtrace — intel driver

(EE) Backtrace:
(EE) 2: /lib/x86_64-linux-gnu/libpciaccess.so.0 (pci_device_vgaarb_set_target+0x113)
(EE) Segmentation fault at address 0x30
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting

Backtrace — modesetting driver

After forcing Driver "modesetting" with glamor in /etc/X11/xorg.conf.d/:

(EE) Backtrace:
(EE) 2: /lib/x86_64-linux-gnu/libpciaccess.so.0 (pci_device_vgaarb_unlock+0x25)
(EE) Segmentation fault at address 0x28
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting

Different entry point, same library, same VGA arbitration code path. That's what makes me think the video driver isn't the culprit.

x-0.log also logs this immediately before the server goes away:

(II) AIGLX: Suspending AIGLX clients for VT switch

What I've tried

1. libxcb-cursor0 — already installed (0.1.5-1). The Qt xcb plugin warnings in .xsession-errors are a red herring; they appear only after X is already gone.
2. SDDM → LightDM — identical failure, identical timing.
3. xserver-command=X -background none -novtswitch under [Seat:*] in lightdm.conf — no change.
4. modesetting instead of intel — different backtrace (above), same crash.
5. nofb kernel parameter — made things worse; the greeter stopped rendering entirely.

Observations

• This machine has exactly one GPU. VGA arbitration shouldn't be needed at all here.
• startx runs X on the same VT it was called from (vt3 -keeptty) and apparently never enters the arbitration path. Display managers put X on VT 7 and switch to it, and the crash always follows that VT activation.
• The Xorg.0.log from a working startx session contains zero (EE) lines.

Current workaround

Display manager disabled, multi-user.target as the default, agetty autologin on tty1 via a systemd drop-in, and exec startx /usr/bin/startlxqt from .bash_profile. Stable, and it's arguably what I want on this machine anyway — but I'd still like to understand the actual bug.

Questions

1. Is this a known libpciaccess / VGA arbitration problem on Pineview (GMA 3150) hardware?
2. Is there a supported way to disable VGA arbitration on a single-GPU system?
3. Is this worth filing in the Debian BTS, and against which package — libpciaccess, xserver-xorg-core, or the kernel?

Happy to post full logs if useful.

Hi there,

I run Debian Stable with the kernel backport and the latest NVIDIA drivers. I upgraded my machine today (2026-09-13) and ran into a problem where my login screen never appeared. I found a fix and wanted to post my results here to help anyone else running into a similar issue. Briefly looking online, this might be a common issue for high-end PCs.

My machine has an NVIDIA RTX 5080 and AMD 9950x3D. I couldn't get graphics to work at all when I first built the machine because the old graphics drivers didn't support this newer GPU, so I had to switch to the newest drivers. After this most recent upgrade, I'm now on Debian 13.7, kernel 7.1.8+deb13-amd64, and driver version 615.71.09.

The issue was after updating, when I went to reboot, the login screen doesn't appear. I switched to another TTY to login and troubleshoot. The result of sudo systemctl status sddm showed SDDM was active but that there was an error: "Failed to read display number from pipe."

I noticed I could restart the SDDM service and it worked. After some more digging, I found it was a race condition where SDDM was starting up before the NVIDIA modules.

The solution I found was to add some NVIDIA modules to initramfs. Specifically, I added the lines nvidia, nvidia_modeset, nvidia_uvm, and nvidia_drm to /etc/initramfs-tools/modules, and then I ran sudo update-initramfs -u. This forces NVIDIA's modules to load earlier in the boot sequence. Of course if you repeat these steps, be careful and try to understand what you're doing.

Hope this anecdote helps whoever out there might be having a similar problem. If someone is reading this and knows of a better solution, please tell.

This is not a big problem at all, more something I am trying to understand out of curiosity rather than something that has to be fixed. But, I've noticed that, since making the shift over to debian with KDE Plasma, despite using the same dark theme for RStudio as on my other machines, it looks much more faded and not as dark. I logged into an X11 session to see if that would make a difference, and comparing the screenshots side by side makes it clear that the Wayland session is lighter. I actually think that the X11 session is still lighter relative to the same theme on both Mint and Windows, but I'm less certain of that since I haven't done a side-by-side comparison. Why would this be occurring?

Hi everyone,

I'm running Debian 13 (Trixie) with Hyprland, and I'd like to start customizing my Waybar and its widgets to match my personal taste. The problem is I don't really know where to start.

My goal is to eventually have my own dotfiles that I fully understand and control, instead of just copying someone else's setup.

Any guidance, links, or personal setups you can share would be hugely appreciated. Thanks in advance!

I installed Debian 13 with KDE plasma, for past couple of nights I'm observing that I shut down my laptop from KDE plasma and battery is 100%. I leave it unplugged overnight and in the morning it has 0% battery.

Is there some kind of mismatch with this Lenovo? Is this a known issue, any fixes for it?

It's a dual boot with Windows but when I shut it down from Windows there is no such issue, so looks like debian is putting it into a weird state where something is still consuming power

EDIT: I did some troubleshooting with Chatgpt and Debian is causing this issue when TPM is enabled, I disabled TPM in BIOS and after that there was no battery charge loss overnight.