Debian operating system

I've heard that Wayland works a lot better now on Nvidia GPUs, so I wanted to give it a try. I've heard that GNOME wants to focus on Wayland, and that it is selected by default. BUT... I can't find it. When checking the server in the terminal, it says X11. And when on the login screen, I can choose between GNOME and GNOME Classic, which is also X11. I really want to at least try it out, as the variable refresh rate and some of the screen taring improvements would really benefit me, but I have not yet found the right package (?) To install.

Just installed Debian 12 on a Dell Inspiron 14 Plus. I know there are those out there who are curious about different machines, and especially the Dell machines that come prepackaged with Windows 11 and all the bloat you can shake a stick at.

Reporting in that it works great, it's lightning fast, it required zero driver installation. It just works, right out of the box.

Now I've messed with a few different Linux packages before, but I've never had it on a main machine. I've done this because I'm highly dissatisfied with Microsoft burying generative AI directly into the operating system so that you're forced to see it, if not interact with it. And who knows what it's doing with your data.

Not going to be me, but now I've got to maybe find a replacement for Photoshop, and figure out how to get Steam on here, and a few of my other work programs. But all-in-all I'm extremely surprised that all I had to do was install it and I was good to go.

I suppose I'll close this out with a question to start some discussion: What are your go-to apps to install right out of the box on a fresh Debian setup?

I am supposing this will not work - simply using dd to copy the booted disk /dev/sda for example to a file on an external hard drive. This would not be a good back as too many system file would be missed. right?

Updating to kernel 6.1.0-18 with Nvidia driver installed, seams broken?

I get a lot of "error processing package" from pdkg, complaining about dependency problems.

Apparently I'm not the only one: https://stackoverflow.com/questions/77974173/dependency-problems-while-updating-kernel-6-1-0-18

New debian user here. I'm using sway and have a script in my waybar config to look for upgrades and indicate if any are available. However, it typically doesn't find anything because I first need to run a sudo apt update first.

I don't really want to figure out someway to do a sudo through this script and was curious how gnome finds updates without me needing to enter a password.

It looks like I can use unattended upgrades to do the apt update.

https://wiki.debian.org/UnattendedUpgrades

though I don't want it to do upgrades until I do a sudo apt upgrade after being notified of upgrades. I created a 02periodic file in /etc/apt/apt.config.d as indicated, but I only included the lines

APT::Periodic::Enable "1";

APT::Periodic::Update-Package-Lists "1";

Will this run an apt update every day for me? Is there any issue I'm unaware of in doing this? Thanks for any help!

Anyone else having this oddity? Debian SID here!

I have a small server in my closet which is running 4 Debian 12 virtual machines under kvm/libvirt. The virtual machines have been running fine for months. They have unattended-upgrades enabled, and I generally leave them alone. I only reboot them periodically, so that the latest kernel upgrades get applied.

All the machines have an LVM configuration. Generally it's a debian-vg volume group on /dev/vda for the operating system, which has been configured automatically by the installer, and a vgdata volume group on /dev/vdb for everything else. All file systems are simple ext4, so nothing fancy. (*)

A couple of days ago, one of the virtual machines didn't come up after a routine reboot and dumped me into a maintenance shell. It complained that it couldn't mount filesystems that were on vgdata. First I tried simply rebooting the machine, but it kept dumping me into maintenance. Investigating a bit deeper, I noticed that vgdata and the block device /dev/vdb were detected but the volume group was inactive, and none of the logical volumes were found. I ran vgchange -a y vgdata and that brought it back online. After several test reboots, the problem didn't reoccur, so it seemed to be fixed permanently.

I was willing to write it off as a glitch, but then a day later I rebooted one of the other virtual machines, and it also dumped me into maintenance with the same error on its vgdata. Again, running vgchange -y vgdata fixed the problem. I think two times in two days the same error with different virtual machines is not a coincidence, so something is going on here, but I can't figure out what.

I looked at the host logs, but I didn't find anything suspicious that could indicate a hardware error for example. I should also mention that the virtual disks of both machines live on entirely different physical disks: VM1 is on an HDD and VM2 on an SSD.

I also checked if these VMs had been running kernel 6.1.64-1 with the recent ext4 corruption bug at any point, but this does not appear to be the case.

Below is an excerpt of the systemd journal on the failed boot of the second VM, with what I think are the relevant parts. Full pastebin of the log can be found here.

Dec 16 14:40:35 omega lvm[307]: PV /dev/vdb online, VG vgdata is complete.
Dec 16 14:40:35 omega lvm[307]: VG vgdata finished
...
Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvbinaries.device: Job dev-vgdata-lvbinaries.device/start timed out.
Dec 16 14:42:05 omega systemd[1]: Timed out waiting for device dev-vgdata-lvbinaries.device - /dev/vgdata/lvbinaries.
Dec 16 14:42:05 omega systemd[1]: Dependency failed for binaries.mount - /binaries.
Dec 16 14:42:05 omega systemd[1]: Dependency failed for local-fs.target - Local File Systems.
Dec 16 14:42:05 omega systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.
Dec 16 14:42:05 omega systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
Dec 16 14:42:05 omega systemd[1]: binaries.mount: Job binaries.mount/start failed with result 'dependency'.
Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvbinaries.device: Job dev-vgdata-lvbinaries.device/start failed with result 'timeout'.
Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvdata.device: Job dev-vgdata-lvdata.device/start timed out.
Dec 16 14:42:05 omega systemd[1]: Timed out waiting for device dev-vgdata-lvdata.device - /dev/vgdata/lvdata.
Dec 16 14:42:05 omega systemd[1]: Dependency failed for data.mount - /data.
Dec 16 14:42:05 omega systemd[1]: data.mount: Job data.mount/start failed with result 'dependency'.
Dec 16 14:42:05 omega systemd[1]: dev-vgdata-lvdata.device: Job dev-vgdata-lvdata.device/start failed with result 'timeout'.

(*) For reference, the disk layout on the affected machine is as follows:

# lsblk 
NAME                  MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda                   254:0    0   20G  0 disk 
├─vda1                254:1    0  487M  0 part /boot
├─vda2                254:2    0    1K  0 part 
└─vda5                254:5    0 19.5G  0 part 
  ├─debian--vg-root   253:2    0 18.6G  0 lvm  /
  └─debian--vg-swap_1 253:3    0  980M  0 lvm  [SWAP]
vdb                   254:16   0   50G  0 disk 
├─vgdata-lvbinaries   253:0    0   20G  0 lvm  /binaries
└─vgdata-lvdata       253:1    0   30G  0 lvm  /data

# vgs
  VG        #PV #LV #SN Attr   VSize   VFree
  debian-vg   1   2   0 wz--n- <19.52g    0 
  vgdata      1   2   0 wz--n- <50.00g    0 

# pvs
  PV         VG        Fmt  Attr PSize   PFree
  /dev/vda5  debian-vg lvm2 a--  <19.52g    0 
  /dev/vdb   vgdata    lvm2 a--  <50.00g    0 

# lvs
  LV         VG        Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root       debian-vg -wi-ao----  18.56g                                                    
  swap_1     debian-vg -wi-ao---- 980.00m                                                    
  lvbinaries vgdata    -wi-ao----  20.00g                                                    
  lvdata     vgdata    -wi-ao---- <30.00g 

Looks like there is another issue in the recently updated kernel 6.1.66 which prevents shutdown with certain WiFi modules. At least my laptop now doesn't shutdown anymore and needs a hard power off 😐

If you are on the stable kernel and use ext4, do not upgrade to linux kernel package 6.1.64-1

It has a bad data corruption bug

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843

I have suddenly found that /usr/games has disappeared off my path. Not only that but my normal otherwise but sudo enabled user seems to have a superuser's path?

rhudson@adam:~$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

rhudson@adam:~$ id -u 1000

What would have changed suddenly? It was not like this yesterday. kpat is in /usr/games and I was able to launch it from task manager yesterday, but not today.

I have rebooted twice so far. I can run kpat by opening it from Dolphin.

I don't want to have to re-install : ^ (

Hi, I am building the Linux kernel, with the following make command to enable multi core compilation: make -j. This ends up freezing the system and eventually some applications get killed (I am using KDE). If I pass an argument to -j, then system compiles normally. However, full multi-core compilation is enabled when no argument is specified.

I am on Debian stable, kernel 6.1.0-13-amd64. Is there a way make system do full multi-core compilation without freezing the system?

I installed Bookworm, Docker and Frigate (in docker) on an older i5 Dell with a Coral TPU (USB) and an old GeForce 6600 GPU, the TPU and GPU are for use with Frigate frame processing and video conversion. It was working well for months and then I upset the apple cart by adding whisper and Piper in the docker for my Home Assistant (different server) to use. After I got that all working I noticed that Debian would freeze after several hours of no user use (no one logged in either on the console or SSH). This seems to happen now even after I removed the Piper and whisper containers. Thinking it might be a suspend issue I masked all the suspend points and set the power profile to “never” but that did not help. Looking at journalctl does not show anything I can see, it seems to just stop logging at the freeze point, interestingly the ethernet jack still shows activity but no ping :(

What would be the next troubleshooting steps to find what is causing the freeze?

By Jonathan Corbet October 23, 2023

Debian 12 (Bookworm) My Wi-Fi has just started randomly dropping the connection and re-connecting. It seems to connect and pass data normally until it decides to drop again.

I thought I solved this part by disconnecting and re-connecting myself but no it just deactivated and activated just now again.

I also have a wired connection.

Is there any issue with having both a wired connection and a wireless one at the same time?

Does it do any good? That is does the network traffic balance over the two connections give a little more bandwidth?

Update 1: For now until I can reboot I have disabled the wi-fi connection.

Update 2: The Wife works at home on wi-fi and says her connection has been bad this afternoon too. I rebooted and I still have the problem.

cross-posted from: https://monero.town/post/824123

Implements support for waydroid in vso, this includes creating and deleting a waydroid container, as well as using fdroid repositories to install and search for applications.

Listening to high quality audio with Bluetooth headphones is now easier than ever on @Raspberry_Pi thanks to @debian Bookworm and @pipewire!

I have an annoying problem on my server and google has been of no help. I have two drives mirrored for the OS through mdadm, and I recently replaced them with larger versions through the normal process of replacing one at a time and letting the new drive re-sync, then growing the raids in place. Everything is working as expected, with the exception of systemd... It is filling my logs with messages of timing out while trying to locate both of the old drives that no longer exist. Mdadm itself is perfectly happy with the new storage space and has reported no issues, and since this is a server I can't just blindly reboot it to get systemd to shut the hell up.

So what's the solution here? What can I do to make this error message go away? Thanks.

[Update] Thanks to everyone who made suggestions below, it looks like I finally found the solution in systemctl daemon-reload however there is a lot of other great info provided to help with troubleshooting. I'm still trying to learn the systemd stuff so this has all been greatly appreciated!

I'm actually looking forward to trying the new @Raspberry_Pi desktop based on @debian Bookworm.

I've never run a desktop on my Pis, I run them all headless, but I'm curious what the performance is like now with Wayland and Pipewire (both things I run on my actual desktop/laptop).

I've got a Pi4 in an Argon One with m.2 SSD just waiting to try it.

First test will be 4K Netflix/Disney+ in @firefox thanks to that Widevine availability 👌

I've been fighting an install of the latest Gnome iso. Got a working install now, but the CPU is always chugging, even at idle on the desktop. I know that previously this machine was buttery smooth. But now my cursor can't even smoothly move across the screen.

Occasionally, the task tray button area will acknowledge my screen can flip.

More often though, it doesn't show the rotation option.

My Wi-Fi card works, but cuts out if Bluetooth is active. I know this is a sign it isn't using the correct drivers, as this issue didn't exist prior.

Ath10k needs to be loaded, and no amount of installing it via Synpatic puts it where it needs to be.

I'm wondering if since the machine no longer has a battery... can that screw up something in the detection of hardware? Is it possible I'm missing something on a deeper level?

I know this machine was far quicker and smoother on the prior Debian release... and the battery was still present when it was installed... but it became a spicy pillow in the meantime and had to be disposed of.

Still losing my mind over this.

I've been unsuccessful in getting a properly working system today, installing from a freshly downloaded LiveGnome.iso from the Debian page.

The first install actually crashed, because the USB drive was jostled.

The second install went fine, but had no USB support (hub devices seen, but no attached devices seen)

Now I'm doing a third install.

cross-posted from: https://lemmy.myserv.one/post/2233387

If you like Debian and like to help make it better, and also want to use testing please review this guide where I try to cover many common things and improve your experience:

https://makedebianfunagainandlearnhowtodoothercoolstufftoo.computer/doku.php?id=start

Thanks for being a Debian testing user :)

I have been struggling with this for over a month and still keep running into a brick wall. I am building a new firewall which has six network interfaces, and want to rename them to a known order (wan[0-1], and eth[0-3]). Since Bullseye has stopped honoring udev rules, I have created link files under /etc/systemd/network/ for each interface based on their MAC address. The two WAN interfaces seem to be working reliably but they're not actually plugged into anything yet (this may be an important but untested distinction).

What I've found is that I might get the interfaces renamed correctly when logging in from the keyboard, and this continues to work for multiple reboots. However if I SSH into the machine (which of course is my standard method of working on my servers) it seems to destroy systemd's ability to rename the interface on the next boot. I have played around with the order of the link file numbers to ensure the renumbering doesn't have the devices trying to step on each other, but to no avail. Fixing this problem seems to come down to three different solutions...

• I can simply touch the eth*.link files and I'm back up afte a reboot.
• Sometimes I have to get more drastic, actually opening and saving each of the files (without making any changes). WHY these two methods give me different results, I cannot say.
• When nothing else works, I simply rename one or more of the eth*.link files, giving them a different numerical order. So far it doesn't seem to matter which of the files I rename, but systemd sees that something has changed and re-reads them.

Another piece of information I ran across is that systemd does the interface renaming very early in the boot process, even before the filesystems are mounted, and that you need to run update-initramfs -u to create a new initrd.img file for grub. OK, sounds reasonable... however I would expect the boot behavior to be identical every time I reboot the machine, and not randomly stop working after I sign in remotely. I've also found that generating a new initrd.img does no good unless I also touch or change the link files first, so perhaps this is a false lead.

This behavior just completely baffles me. Renaming interfaces based on MAC addresses should be an extremely simple task, and yet systemd is completely failing unless I change the link files every time I remote connect? Surely someone must have found a reliable way to change multiple interface names in the years since Bullseye was released?

Sorry, I know this is a rant against systemd and this whole "predictable" naming scheme, but all of this stuff worked just fine for the last 24 years that I've been running linux servers, it's not something that should require any effort at all to set up. What do I need to change so that systemd does what it is configured to do, and why is something as simple as a remote connection enough to completely break it when I do get it to work? Please help save my sanity!

(I realize essential details are missing, but this post is already way too long -- ask what you need and I shall provide!)

tl;dr -- Systemd fails to rename network interfaces on the next cycle if I SSH in and type 'reboot'

Debian 12.1 (6.1.0-11-amd64) running LXD/LXC and on an unprivileged container setting security.idmap.isolated=true seems to fail to update the owner/group of the container's files.

Here is an example:

# lxc launch images:debian/12 debian
(...)

# lxc config get debian volatile.idmap.base
296608

# lxc stop debian
Error: The instance is already stopped

# lxc config set debian security.idmap.isolated true

# lxc config get debian security.idmap.isolated
true

# lxc start debian

Now if I list the files on the container volume I'll get they're all owned by the host root user:

# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 24
drwxr-xr-x 1 root   root  154 Sep  5 06:28 .
d--x------ 1 296608 root   78 Sep  5 15:59 ..
lrwxrwxrwx 1 root   root    7 Sep  5 06:25 bin -> usr/bin
drwxr-xr-x 1 root   root    0 Jul 14 17:00 boot
drwxr-xr-x 1 root   root    0 Sep  5 06:28 dev
drwxr-xr-x 1 root   root 1570 Sep  5 06:28 etc

I tried multiple versions of LXD/LXC. This happens with both 5.0.2 from apt as well with 4.0 and 5.17 (latest) from snap.

Interestingly enough I have another Debian 10 (4.19.0-25-amd64) running and older LXD 4 from snap and on that one things work as expected:

# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 0
drwxr-xr-x 1 1065536 1065536  138 Oct 29  2020 .
d--x------ 1 1065536 root      78 Oct 14  2020 ..
drwxr-xr-x 1 1065536 1065536 1328 Jul 24 19:07 bin
drwxr-xr-x 1 1065536 1065536    0 Sep 19  2020 boot
drwxr-xr-x 1 1065536 1065536    0 Oct 14  2020 dev
drwxr-xr-x 1 1065536 1065536 1716 Jul 24 19:08 etc

As you can see on this systems all the files are owned by 1065536:1065536.

Update:

I tried to probe around the maps with lxc config show debian in both machines and I saw this:

Machine running Debian 10:

security.idmap.isolated: "true"
(...)
volatile.idmap.base: "1065536"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'
volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'

Machine running Debian 12:

security.idmap.isolated: "true"
(...)
volatile.idmap.base: "231072"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":231072,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":231072,"Nsid":0,"Maprange":65536}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":231072,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":231072,"Nsid":0,"Maprange":65536}]'
volatile.last_state.idmap: '[]'

Why didn't it populate volatile.last_state.idmap: '[]'?

How can I fix it? Thank you.