You can uncomment excalibur-security and excalibur-updates. They've been active since around when trixie was released.

Look at the whole device in hexedit to see if there's any code at the beginning. I don't have any usb stick that I haven't re-partitioned to tell you what it should look like. Maybe image the image it with dd if you want to examine it later.

I think I may have seen similar on a 128 or 256G and didn't think much about it before I re-partitioned. Or I could be imagining it. FWIW, my 128 and 256G sticks suck compared to 32. They're s - l - o - w.

I read about micro-sd cards hidden inside usb sticks. Last time I looked at them in the store, they had combo packs with "USB and micro-sd". They no longer hide the micro-sd - they let you insert it into the usb housing yourself.

It looks like lightdm is set to stop on every runlevel and not to start on any runlevel. The stops and starts are set in /etc/init.d/lightdm. The beginning of that file should look like this:

#! /bin/sh
### BEGIN INIT INFO
# Provides:          lightdm
# Should-Start:      console-screen kbd acpid dbus hal consolekit
# Required-Start:    $local_fs $remote_fs x11-common
# Required-Stop:     $local_fs $remote_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Light Display Manager
# Description:       Debian init script for the Light Display Manager

If it does not have the same Default-Start and Default-Stop runlevels, you need to think about when and how that happened. Check to see when the file was last edited. That might give you a clue.

I have no other ideas right now.

Thanks for the bug report.
clearlooks-phenix-lightpurpy-theme is fixed in version 7.0.1-6. I couldn't build it for excalibur-proposed-updates, so I built it for ceres. It does install and work in excalibur.

You can download the package here :
https://pkgmaster.devuan.org/devuan/poo … -6_all.deb

(or apt download <package> if you have ceres enabled in sources)

@greenjeans
I replaced 90-alsa-restore.rules with what you posted above. Got error in dmesg:

I checked upstream and there's one character difference between what's posted above (---) and what's on github (+++).
https://github.com/alsa-project/alsa-ut … e.rules.in

--- 90-alsa-restore.rules	2025-10-13 23:59:29.972000000 +0000
+++ 90-alsa-restore.rules.upstream	2025-10-14 01:12:30.304000000 +0000
@@ -8,7 +8,7 @@
 ENV{ALSA_CARD_NUMBER}="$attr{device/number}"
 
 # mark HDA analog card; HDMI/DP card does not have capture devices
-DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0p", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"
+DRIVERS=="snd_hda_intel", TEST=="device/pcmC$env{ALSA_CARD_NUMBER}D0c", RUN+="/bin/sh -c 'echo ALSA_CARD_HDA_ANALOG=$env{ALSA_CARD_NUMBER} >> /run/udev/alsa-hda-analog-card'"
 
 # check for ACP hardware
 TEST=="device/device/acp3x-dmic-capture", GOTO="alsa_hda_analog"

I just realized that the rc1 desktop-live iso is still using lightdm. I made a new iso today and made sure slim was installed. It seems to be fixed. Please test.
https://files.devuan.org/devuan_excalib … p-live.iso

sha256sum

186c0f8a994d7a1223c16f3cee2763c099e2a4e29fcab9fdef3dbee7a48dc824  devuan_excalibur_6.0.0-rc2_amd64_desktop-live.iso

Edit: This one has the wrong version of the Release Notes. I'll wait to hear about slim before I make a new iso.

Clarification: Debian and Devuan packages are not incompatible. They are exactly the same packages. We filter out and fork the packages that require systemd. If you use debian sources with devuan sources, you'll still get mostly the same packages, but you won't have the filter, and you'll probably screw up your system by installing things that do require systemd.

anacron is useful for systems that are not running 24 hours a day, like laptops for example, so that scheduled cron jobs will run somewhat according to their schedules. It's safe to remove it if you don't need it.

Here's a thought. If you only run the computer for short times, you might be shutting down while it's trying to run a job. Only way I can think of to check this would be to look in syslog right before you shut down. If cron is active, wait for it to finish and then see if shutdown is faster.

Fixed in trixie and forky/sid. (i.e. excalibur and freia/ceres) Older versions not affected.
https://security-tracker.debian.org/tra … 2025-32463

(I duck-searched the CVE with the words 'debian security' - first hit.)

Oh, interesting. I don't have that one. I have:

ii  acpi-fakekey                     0.143-5.1                     amd64        tool to generate fake key events
ii  acpi-support                     0.143-5.1                     all          scripts for handling many ACPI events
ii  acpi-support-base                0.143-5.1                     all          scripts for handling base ACPI events such as the power button
ii  acpid                            1:2.0.33-2+b1                 amd64        Advanced Configuration and Power Interface event daemon

I don't know what you need, but -support and -support-base are probably good ones to try first.

I think there is a significant security risk - if there's a vulnerability in some piece of software that gives an attacker access to your session, they don't have to bother with escalating privileges because they're already root. Imagine running a web browser as root and allowing all unknown entities to run javascript as root on your machine. Up until recently, xorg always ran as root. It was changed because it was a security risk.

See if this fixes it:

 gpg --keyserver keyserver.ubuntu.com --refresh-keys