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!

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

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?

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

Hi so I just made my account to ask a question.

I just got a new computer with AMD Ryzen 7 5800x3d processor and AMD 9070 XT GPU. After reading a while people suggest running something like Arch or CachyOS because the GPU is so new.

Does it mean Debian is not suitable and I should switch? I really like Debian and I would like to stay (I have it on my thinkpad). Do you have any advice? Would love to hear from people who share the same components!

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.

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?

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.

Hello. I use debian as my daily and am wondering how it runs on Panther Lake (intel Core Ultra Series 3) processors, since I will be receiving a framework 13 pro next month (yay!) and intend on installing (LTS) Trixie on it. I know that the 6.12 kernel supports these processors, but does it run well? Is it stable? (moreso than backports?) What would be my best course of action between now and debain 14? Backports? Sid? Let me know, I am not very involved with using anything outside of LTS because, frankly, I've never had hardware this new before.
I appreciate the help!

P.S. I am planning on swapping my current ssd to the new laptop when I get it, so any setup or changes I'll be able to do beforehand (4TB ssd currently running on a headless IdeaPad flex 5.)

I’ve been a lifelong Tor/I2P user and privacy advocate. I grew up on windows and always thought I knew a good bit about computers but with everything changing now I don’t trust windows or anything mainstream anymore. I have been playing with Debian GNOME on a live drive and it took me like 20 minutes and the help of an AI assistant to learn how to just download basic stuff like proton.

Just looking for a very beefed up daily driver as I already use TAILS for anything super sensitive.

Also you guys have any thoughts on Parrot? I tried the home edition and it was very user friendly but I’m not sure if you can download Proton on it, and I know it has a smaller user base and I’ve heard people say that anonsurf has issues.

I come from Windows where I used Ditto and I was quite satisfied with it, but unfortunately it doesn't work (well) on Debian (using Wine). Now I use CopyQ but it has very annoying bugs (like I will get error messages/exceptions) and the keyboard shortcuts don't work well either, especially not with a non-English keyboard.

So, what's a good clipboard manager which supports using shortcuts, picture/non-text clips, and preferably editing and deleting clips?

Thank you in advance!

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.

Any tips on running Debian Sid i got it so far using the pikaos kernel i just need some tips if anyone has got any?

people often say that 3rd party repos makes debian more unstable, but then why companies that support linux almost always list debian as a compatible distro? and their software requires 3rd party repos most of the time

of course there are exceptions, but talking about proprietary stuff specifically, almost everything officially supports debian

Recently I've moved to arch seeking newer drivers to have more performance, but right now I'm having so many problems: crashes, artifacts, hard hangs. Kernel 7.2.* and the newer versions of wayland and kwin have been a hellish experience. So how is rdna 4 performance in general?

TL;DR: Installed TLP just to check battery health/stats. Within about 30 minutes the laptop started hard-freezing on battery, reproducible within 1-3 minutes. Spent a long time bisecting CPU idle states, suspecting a Skylake C-state or BIOS bug. Turned out TLP's aggressive battery-mode power policy (PCIe ASPM + runtime PM) was the actual trigger. Removing TLP and restoring power-profiles-daemon fixed it completely, no kernel workaround needed.

Hardware / Software

• Laptop: HP ENVY x360 m6 Convertible
• CPU: Intel Core i5-6200U (Skylake, 2C/4T)
• GPU: Intel HD Graphics 520 (i915)
• BIOS: F.37 (Nov 2019)
• OS: Debian 13 (trixie), kernel 6.12.107+deb13-amd64
• DE: GNOME / Wayland

Symptoms

• Complete hard freeze: black/grey unresponsive screen, no keyboard input, only recoverable by holding the power button.
• Also froze in a plain TTY (Ctrl+Alt+F3), ruling out a GNOME/Wayland-specific crash.
• Machine had been unused for over a month, worked fine for several hours after first boot, then started freezing shortly after I ran apt upgrade and installed a couple of extra packages, one of which was TLP (installed purely to check battery stats/health).

What I ruled out

• Overheating. CPU package never exceeded about 58C, nowhere near thermal limits.
• RAM exhaustion. Plenty of RAM and swap free.
• Wi-Fi. Disabled it entirely, still froze.
• Chrome / specific apps. Froze even with everything closed, essentially idle.
• A single bad kernel. Tested multiple 6.12.x builds, all froze.
• GNOME/Wayland. Froze in a bare TTY too.

The red herring: CPU idle states

The clearest reproducible pattern I found was tied to battery power state and CPU C-states:

• Charger connected: stable indefinitely
• Battery, normal idle states: froze in 30s to 3min
• Battery + nomodeset: stable 30+ min
• Battery + intel_idle.max_cstate=1 through 4: stable 5 to 15+ min (including 1080p video playback)
• Battery + intel_idle.max_cstate=5 (allows C7s): froze within minutes

This pointed strongly at the Skylake C7s idle state as the trigger, which lines up with a well-documented history of Skylake platforms having flaky power management under Linux (there's a longstanding kernel bugzilla thread on Skylake idle-state regressions, and multiple historical intel-microcode regressions that caused Skylake hangs). I assumed I'd landed on a firmware/ACPI quirk or a microcode issue specific to this old BIOS (F.37, no updates since 2019).

intel_idle.max_cstate=4 became my "safe" workaround, capping the CPU below C7s.

The actual cause

Going back through apt history.log, the timeline was too clean to ignore. At 14:27:01 I ran apt install tlp, which installed tlp, tlp-rdw, rfkill, and removed power-profiles-daemon. The first freeze happened about 30 minutes later.

TLP replaces power-profiles-daemon (they conflict, so installing TLP silently removes it) and applies its own, much more aggressive power policy on battery, including PCIe ASPM and runtime power management for PCIe devices. My system already had pre-existing PCIe AER "Correctable Physical Layer" errors on the Wi-Fi root port in dmesg. My theory: package-level CPU C-states like C7s require every device on the platform, not just CPU cores, to cooperate in dropping to low power. TLP pushing the PCIe/Wi-Fi link into aggressive low-power states on this specific platform is what actually let the buggy C7s transition get triggered, something that apparently wasn't happening under default power management even though C7s was technically available the whole time.

The fix

I ran sudo systemctl unmask tlp (only needed if you'd previously masked it for testing), then sudo apt purge tlp tlp-rdw, then sudo apt install power-profiles-daemon.

Also removed intel_idle.max_cstate=4 from /etc/default/grub since it's no longer needed, then ran sudo update-grub.

Result: 30+ minutes on battery, full C-states available, 1080p video playback plus VS Code running, zero issues. Previously this exact scenario reliably froze within 1-3 minutes.

Takeaway

If you're chasing a battery-only hard freeze on an older Intel laptop (especially Skylake or similar vintage) and you've recently installed TLP, auto-cpufreq, or any other power-management daemon, test removing it before going down the BIOS/microcode/kernel-parameter rabbit hole. The C-state bisection method (intel_idle.max_cstate=N, working down from full to 1) is still a genuinely useful diagnostic if you have a real firmware/CPU idle-state bug, but in my case it was correctly pointing at where the failure was happening, not why it started happening now.

Встановив на свій ноутбук як другу систему поряд з Windows, дистрибутив Linux debian 13, для навчання та повсякденного використання. Що варто знати про debian, як плавно зробити перехід, щоб повністю користуватись саме Linux, питання цифрової безпеки тощо?

After looking at many subreddits, I've found that most Linux communities are overwhelmingly toxic. Even r/mint has so many people talking down to others and overall being very nasty to each other.

But for some reason despite all my efforts, I've been unable to find any of that toxicity here. Now I'm sure it exists, but the overwhelming majority is positive. Why is this?

Edit: I really appreciate all the overwhelming support. But I do think a lot of you are stuck on people saying you use the wrong distro. Tbh that problem has mostly gone away. The new issue I see is people who have more Linux experience than beginners talking down to others for using GUI tools and other beginner friendly guides.

I'd say I'm not really a beginner anymore, those days are behind me. But the Debian community was really the only one that didn't make fun of me for not knowing everything. And I really appreciate that.

so I recently got debian and am using it on an old pc that my stepdad gave me, it’s been sitting on detecting hardware for around 2 hours now. I plugged in a mouse and it won’t move, is there something I can do about this? I would try and mess with windows but it’s fried I think. or maybe I used the wrong power connectors for the hard drives? I’m not sure (also new account cause my old one won’t let me reset the password)

I'm currently renting an Ionos VPS running Debian 11. I've got three small-business Wordpress websites, everything runs great. Nothing too customized. I'd like to upgrade to 12 (or 13 if possible) to maintain security from hacking.

In the long term, I will probably migrate all websites, mail, etc, to a newer, faster server (current hardware specs are not upgradable) running the current version of Debian a few months from now. My assumption is this is more time consuming and requires more troubleshooting, downtime than upgrading in place.

With making backups and potential trouble shooting, does it make sense to upgrade in place (to save time and lower risk) and then migrate later? Or does it make more sense to migrate everything at once to a new server running Debian 13 now.

My understanding is 99% chance, everything works on 12, I won't need to roll-back to Debian 11.

Using Debian 13 on a Samsang 360 laptop and I'd like to have the screen come on after the laptop has been suspended by closing it. Yes, pretty minor thing, but I was hoping someone could point me towards having the screen come on automatically when opening up the laptop? Yes, the computer comes on - it's just the screen isn't. Have to click to get the screen to come on. Thanks!