https://dev1galaxy.org/viewtopic.php?pid=62815#p62815
Should solve it.

Edit2: Post heavily edited!

Purpose: Modify 'mullvad-vpn_2025.14_amd64.deb' to include sysv-init scripts.
Output: 'mullvad-vpn_2025.14~1sysv_amd64.deb'

'DEBIAN/postinst':
  mullvad service is NOT enabled at boot time (intentionally)
  systemctl lines are commented out: --> no need for systemctl on devuan; then on systemd also NOT enabled at boot time
  alternatively: systemctl lines can stay --> updated "docker-systemctl-replacement" needed
Enable service: see post above "forte  #9"

The following is a script to create the modified debian package. Adjust to your flavour.

$ cat modify_mullvad_deb.sh

#!/bin/bash
### recreate mullvad-deb-package for devuan
# https://unix.stackexchange.com/questions/138188/easily-unpack-deb-edit-postinst-and-repack-deb
# e.g.: (do as root!)
mkdir tmp
dpkg-deb -R mullvad-vpn_2025.14_amd64.deb tmp
## edit / patch  DEBIAN/postinst
# comment-out lines starting with 'systemctl' ?
sed -i 's/^systemctl/# systemctl/g' tmp/DEBIAN/postinst
# patch for systemctl (docker-systemctl-replacement)
sed -i -e 's/"\/usr\/lib\/systemd\/system\/mullvad-daemon.service"/mullvad-daemon.service/' \
       -e 's/"\/usr\/lib\/systemd\/system\/mullvad-early-boot-blocking.service"/mullvad-early-boot-blocking.service/' \
    tmp/DEBIAN/postinst
# create sysv-init scripts
mkdir -p tmp/etc/init.d
sysd2v.sh tmp/usr/lib/systemd/system/mullvad-early-boot-blocking.service > tmp/etc/init.d/mullvad-early-boot-blocking
sysd2v.sh tmp/usr/lib/systemd/system/mullvad-daemon.service > tmp/etc/init.d/mullvad-daemon
sed -i 's/"MULLVAD_RESOURCE_DIR=/MULLVAD_RESOURCE_DIR="/' tmp/etc/init.d/mullvad-daemon     # correct entry
chmod +x tmp/etc/init.d/mullvad-daemon tmp/etc/init.d/mullvad-early-boot-blocking
chmod g-w tmp/etc/init.d/mullvad-daemon tmp/etc/init.d/mullvad-early-boot-blocking
# re-pack
dpkg-deb -b tmp mullvad-vpn_2025.14~1sysv_amd64.deb

## installation
# cp mullvad-vpn_2025.14~1sysv_amd64.deb /tmp     # user "_apt" can not access files in /root/*
# apt install /tmp/mullvad-vpn_2025.14~1sysv_amd64.deb

#-----------------------------------------------------------------------------#
# Supplemental:
#
## sysd2v.sh   (to create sysv-init scripts)
# https://web.archive.org/web/20210412005920/http://www.trek.eu.org/devel/sysd2v/
# wget https://cgit.git.savannah.nongnu.org/cgit/sysvinit.git/tree/contrib/sysd2v.sh
# chmod +x sysd2v.sh; cp sysd2v.sh /usr/local/bin
#
# systemctl    (updated script - if installed package throws errors)
# git clone https://github.com/gdraheim/docker-systemctl-replacement
# cp docker-systemctl-replacemen/files/docker/systemctl3.py /usr/local/bin/systemctl

"EDIT" in post #1 is the explanation.

"encrypted" has to be slower (and LVM makes it worse). How much depends on the encryption method andcomputer hardware.
Encrypted zeros are no longer zeros, except the encryption sucks.

Or in short: No, you're doing it wrong.

 $ sudo apt-get install enlightenment

should do it.
I gave it a try once, but my brain doesn't work this way.

The mount options in the example ("user,noauto") are working with pcmanfm and in a terminal. So probably anywhere else too?!.

Btw. Interesting method to mount a partition using pci-ids. Didn't know tthat. Apreciated.

Can you login via ssh from another computer?
Or boot daedalus and do a chroot into the excalibur installation?
To reconfigre the keyboard:

sudo dpkg-reconfigure keyboard-configuration

gkrellm is just working and maintained - 13 houes ago, says https://git.srcbox.net/gkrellm/gkrellm

On my AM4-mainboard, the best collection of temperature sensors is at /sys/class/hwmon/hwmon[0-4]/temp[1-9]_input
This does not include the GPU, which gkrellm covers.

@Micronaut
I do not know how or where gkrellm gathers information, but it found a lot of temperature sensors on cpu, gpu, nvme, network, gigabyte-wmi, thermal_zone[0,1]. And presented them as a list to choose from to display. Only the (data-grave-)HDD's temperature was missing.
It's a good and convenient tool to monitor temperatures (and more).

@_mAL_4_th3_fl00r #1 : beside that the commands are to execute from right to left ... what is "cmac; .z" doing?

Ups!

I read RedGreen925 post and thought it was an update from the OP.

Sorry for the confusion.

sources file looks good.
((The repos "excalibur-backports", "excalibur-proposed-updates",  "excalibur-updates", "excalibur-security" are probably not existing by now, but will when excalibur becomes stable.))

Assuming you did:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

Is there an error message afterwards?

Edit: I got this wrong!
('strike through' does not work on code blocks)

@rbit
Good to know.

Solution:
After an Arch Linux upgrade today in a chroot environment, update-grub creates the usual boot entry again.
The reason remains unclear.
It was NOT a problem with debian's grub / os-prober package.
Best guess: *Something* went wrong during the Arch Linux upgrade at 18-Aug-2025.

Thanks for all the replies and regards.

.
.
PS: chroot into Arch Linux as follows:

# mkdir /tmp/arch_chroot
# mount /dev/nvme0n1p3 /tmp/arch_chroot
# cd /tmp/arch_chroot
# mount -t proc /proc proc
# mount --make-rslave --rbind /sys sys
# mount --make-rslave --rbind /dev dev
# chroot /tmp/arch_chroot  /bin/bash
# source /etc/profile
# export PS1="(chroot) ${PS1}"
# packman -Syu
# exit

And unmounting the file system (maybe there is a better way).

# echo 'WD is still /tmp/arch_chroot'
# umount dev/shm
# umount dev/pts
# umount dev
# umount sys/fs/cgroup
# umount sys/fs/pstore
# umount sys/kernel/security
# umount sys/kernel/config
# umount sys/firmware/efi/efivars
# umount sys
# umount proc
# cd
# umount /tmp/arch_chroot

In case of umount errors: mount | grep arch_chroot shows remains.