"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.

@rbit: thanks for the reply.
This Arch Linux installation has no grub - booting is devuan's job.
(Inconsistencies: mounting "/boot/efi" in an otherwise empty "/boot" directory is pointless.)

Some points in time:
* Last Arch Linux update: 18-Aug-2025 (kernel "linux-6.16.0-arch2-1")
--> boot entry was existing at the time.
* Package "os-prober": Version 1.83 exists in excalibur since middle of 2024.
--> there must be something else that made 40grub2 delete the boot entry.

... to be continued.

Thanks for the reply.

os-prober is already executed by update-grub, just one detected OS is not shown anymore in the generated boot menu.

It's not a new boot setup.
grub always showed an "Archlinux" boot entry below "Devuan 6" and "Devuan 5".
Probably the entry for "UEFI Firmware Settings" (BIOS) is new.

Maybe that's a point: -"Archlinux" +"UEFI Firmware Settings" ? (no time to check by now)