Debian operating system

So I've upgraded to trixie and it comes with apt 3. For some reason the new apt insists on opening the output of some commands in less. For example, "apt list --upgradable" or "apt search" opens the output i less. I can't find how I turn this behavior off. Any advice?

What is the easiest way to track how close to stable release Debian 13 is?

I'd like to get an informed idea about a release date, without relying on outdated and vague news articles.

Thanks!

Are there any suggestions for a firewall with an easy GUI? I want to open a port for kde connect so i can use sms and fling my phone to the back of the room. Thanks in advance

I tested Debian 13 RC1 by installing the Nvidia proprietary driver using:

apt install nvidia-driver

The error from systemctl status dkms is as follows:

× dkms.service - Builds and install new kernel modules through DKMS
     Loaded: loaded (/usr/lib/systemd/system/dkms.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Sun 2025-05-18 07:37:53 +07; 1min 22s ago
 Invocation: da858b6286f04dd6965e54bc964fc78f
       Docs: man:dkms(8)
    Process: 855 ExecStart=/usr/sbin/dkms autoinstall --verbose --kernelver 6.12.27-amd64 (code=exited, status=21)
   Main PID: 855 (code=exited, status=21)
   Mem peak: 6.3M
        CPU: 204ms

May 18 07:37:53 vlegion systemd[1]: Starting dkms.service - Builds and install new kernel modules through DKMS...
May 18 07:37:53 vlegion dkms[1069]: Error! Your kernel headers for kernel 6.12.27-amd64 cannot be found at /lib/modules/6.12.27-amd64/build or /lib/modules/6.12.27-amd64/source.
May 18 07:37:53 vlegion dkms[1069]: Please install the linux-headers-6.12.27-amd64 package or use the --kernelsourcedir option to tell DKMS where it's located.
May 18 07:37:53 vlegion systemd[1]: dkms.service: Main process exited, code=exited, status=21/n/a
May 18 07:37:53 vlegion systemd[1]: dkms.service: Failed with result 'exit-code'.
May 18 07:37:53 vlegion systemd[1]: Failed to start dkms.service - Builds and install new kernel modules through DKMS.

Of course, this problem was fixed by installing 'linux-headers-6.12.27-amd64.'

However, I wonder if 'linux-headers-6.12.27-amd64' should be installed automatically. Is this a bug? How can I check if anyone has reported this already?

I'd like to progressively rate limit ssh connections by 3 per minute, 12 an hour and 24 a day.

I have these rules that don't seem to be working:

tcp dport 22 ct state new limit rate over 24/day drop comment "24+ a day"
tcp dport 22 ct state new limit rate over 12/hour drop comment "12+ an hour"
tcp dport 22 ct state new limit rate over 3/minute drop comment "3+ a minute"
tcp dport 22 ct state new limit rate 3/minute accept comment "Good SSH"

I'm still stuck in debian 10.13, stock kernel 4.19.316-1 (2024-06-25) and nftables v0.9.0 (Fearless Fosdick).

sets are not yet available, as far as I know.

In older versions of Debian I used to be able to pass sec=ntlm,vers=1.0 as options to mount.cifs (and fstab) and it would allow me to mount my shared disk from my AirPort Extreme.

In Bookworm, due to the bundled kernel version, I am now told ntlm is a bad security option. If I try to use ntlmssp, I am told Unable to select appropriate authentication method!. If I use ntlmv2 or remove the sec option, I get Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE.

Funny thing is, if I use smbclient, I can browse my shared drive just fine.

Using a newer version of Samba protocol is not an option since Apple gave up on their products just like Linux gave up on ntlm.

Aside of throwing everything out the window, what can I do to get this working on Bookworm?

Edit: I gave up. Because the maintainers of the kernel decided to remove ntlm support, the only option I had was to downgrade to buster, as it was the last distro to use a pre-6 kernel. Suffice it to say, I'm very disappointed; both in Apple for abandoning their Airport's to use SMBv1, and the kernel devs for further eroding Airport support by removing ntlm. Yes, I get ntlm "bad" (both from an FOSS and security standpoint), but it's still disappointing to be punished simply because I do not wish to litter the landfill with still useful hardware (nor do I wish to spend more money on something I shouldn't need). Anyway, /rant over.

Looking at Debian's release-critical bugs, you can see that Trixie is close:
Testing now has fewer critical bugs than Stable, and the number is dropping quickly.
About 200 bugs still need to be fixed to get the number down to where the previous releases were done.

Maybe you can help? Bugs blocking the next release can be as simple as missing translations for the upgrade instructions.

AI models released under open source license without original training data or program are not seen as DFSG-compliant.

The GR is in his discussion step, and may be other vote options are presented.

The discussion can be read in the Debian-vote mailing list, and the resolution could impact other software (scanners, text2speach...) ^[See https://lists.debian.org/debian-vote/2025/04/msg00114.html].

Besides having the latest version available, what do Debian users who run MariaDB wish to see in future versions of MariaDB, or how it is integrated and packaged in Debian?

I am the maintainer in Debian - looking for feedback and ideas.

I'm a retired Unix (AIX) admin and I run some Linux servers at home. But, I'm still using Windows as a desktop. This whole Windows recall thing is the final straw - I'm switching to Linux for desktop. I've done a bit of research and believe Debian is the best fit for me. So, I recently installed it on one of my small servers.

I like it but I find the "half baked" approach to systemd a bit confusing. My default minimal server install has both cron jobs and systemd timers configured for basic system maintenance tasks. For example logrotate is fired twice a day - once by /etc/cron.daily/logrotate and once by /lib/systemd/system/logrotate.service. I'm tempted confirm that everything cron does is actually also done by systemd and then apt purge cron\* && rm -rf /etc/cron*. But, I suspect that might break future package installs and updates?

I'm also not excited by ifup/ifdown - why not just use the capability already included with systemd? This is just a minor thing for me as there's no real duplication I guess.

Is the a Debian based "pure systemd" distro??

I know it's not directly Debian, but...

I'm currently running a Zorin 17 x86_64 vm (in virtualbox, windows 11 host), which uses wayland.
In it i have a Debian 9 stretch aarch64 chroot, which comes with X.

I'd like to test the GUI app i compiled in that chroot, how is that feasible?

For reference, this is how i setup initially:

$ sudo apt install debootstrap qemu-user-static
$ sudo mkdir -p /opt/deb9/sysroot && sudo chown -R myuser:myuser /opt/deb9
$ sudo /usr/sbin/debootstrap --arch=arm64 --foreign --variant=minbase stretch /opt/deb9/sysroot http://archive.debian.org/debian-archive/debian/
$ sudo cp /usr/bin/qemu-aarch64-static /opt/deb9/sysroot/usr/bin/
$ sudo chroot /opt/deb9/sysroot qemu-aarch64-static /bin/bash
	# /debootstrap/debootstrap --second-stage
	# echo 'APT::Install-Recommends "0";' >> /etc/apt/apt.conf.d/99noExtras
	# echo 'APT::Install-Suggests "0";'   >> /etc/apt/apt.conf.d/99noExtras
	# echo 'deb http://archive.debian.org/debian-archive/debian/ stretch main contrib'      > /etc/apt/sources.list
	# echo 'deb-src http://archive.debian.org/debian-archive/debian/ stretch main contrib' >> /etc/apt/sources.list
	# uname -nm | sed -e 's/ /-/' > /etc/debian_chroot
	# apt update
	# apt install -y g++ make cmake automake autoconf libtool git vim pax-utils tree
	# adduser myuser
	$ su myuser
		> do stuff

~~Network isn't really configured so any git push or similar is done outside the chroot.~~

Edit: turns out i needed Debian 11 instead and it was a matter of mapping a lot of env onto the chroot, creating necessary dirs and rbinding.

Script to chroot:

#!/usr/bin/env bash

sudo mount --rbind /proc ${SYSROOT}/proc/
sudo mount --rbind /sys ${SYSROOT}/sys/
sudo mount --rbind /dev ${SYSROOT}/dev/
sudo mount --rbind /run/systemd/resolve ${SYSROOT}/run/systemd/resolve
sudo mount --rbind /run/user/1000 ${SYSROOT}/run/user/1000
sudo mount --rbind /run/mysqld ${SYSROOT}/run/mysqld
sudo mount --rbind /etc/xdg ${SYSROOT}/etc/xdg
sudo chroot ${SYSROOT} qemu-aarch64-static /bin/bash
exit 0

The caveats being MariaDB runs on the host and user 1000 isn't a portable solution.
~/.bashrc of the chrooted user:

export XDG_SESSION_DESKTOP=zorin
export XDG_SESSION_TYPE=wayland
export XDG_CURRENT_DESKTOP=zorin:GNOME
export XDG_SESSION_CLASS=user
export XDG_RUNTIME_DIR=/run/user/1000
export XDG_CONFIG_DIRS=/etc/xdg
export XAUTHORITY=$(ls -a /run/user/1000/.mutter*)
export WAYLAND_DISPLAY=wayland-0

In the last day or so, Emacs GTK on Debian Trixie is locking up my system frequently. It's so bad that I can guarantee a full lock-up within a few minutes of opening Emacs. Env. is Gnome 48 on the Framework 13 and I assume it's XWayland causing the issue. FWIW, the issue doesn't seem to impact on Sway.

Is anyone else seeing similar issues?

I built a new firewall under Debian 12. The machine has eight network ports, and during configuration I accidentally used the same name for a couple of the ports in the files under /etc/systemd/network/*.link. I ended up with two link files referencing two different MAC addresses but naming each of them as WAN0, and once systemd got that configuration it wouldn't let it go.

From what I could find online, normally I would just issue systemctl daemon-reload followed by a update-initramfs -u and after a reboot systemd should have had the updated information... but no dice this time. The way I finally discovered the problem was when I noticed under ifconfig that my wan0 port was pointing to the wrong MAC address (even though the link files had been corrected).

After several hours of fighting with it, I finally managed to get it to work by renumbering all of my link files, and now the information for each port matches up correctly. But my real question here is WHY did systemd refuse to read updated link files? Is there another step I should have taken which was mysteriously never mentioned in any of the dozens of web pages I looked at trying to fix this? I really need to understand the proper process for getting it to correctly use these files so I can maintain the machine in the future.

(God I miss the reliability of udev already)

I have a few (~5) applications where the version in the debian stable repos is to old for me. Examples would be podman and restic. I found out that the version for testing are recent enough. Is it possible to install specific apps from testing while the default is stable?

I'm building a new rack server (Poweredge R620) and am using the option "consoleblank=600" in the GRUB_CMDLINE_LINUX setting. During the setup I used the wrong memory stick and installed Bullseye, and screen blanking was working correctly there. Since I had already finished nearly all the configuration this week, I thought it would be easier to just do a regular dist upgrade than reloading the whole system.

After upgrading to Bookworm and rebooting, I notice that now when the screen blanking is supposed to kick in (which normally just turns off the display), I am instead getting what looks like rolling static on the screen. I have several other R620 racks running Buster so I know the screen blanking should work with this hardware, but this appears to be an issue specific to Bookworm.

Note that even when I try something like setterm -blank 1 or setterm -powerdown 1 I get the same resulting static after 1 minute. To be clear, this is specifically for the command line, I do not run desktops on my servers.

A google search for the problem has been unsuccessful so I'm hoping someone can point me to a solution or help with the proper search terms.

I've been using Fedora for the past few months and Pop OS for some months before that.

Debian was my first choice after Pop because of ideological reasons - non corporate structure mainly. But I couldn't get games to work properly (my PC is only 7-8 months old). So I've been trying Fedora, but the more I learn about Red Hat and it's involvement, it's harder to stick to the distro.

What would be a good way to setup Debian (and KDE, because apparently GNOME is also Red Hat's, although I do like the environment) so that it works well for my use case? The two year old DE and app versions does bother me but I guess I can learn to live with it. Do I try testing? Do I use backports?

PC specs: Ryzen 5 5600 Processor, RX 7600 GPU