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)

@callmetango: Thanks for providing a xlibre package for devuan.

Unfortunately, the installation would remove the proprietary nvidia driver and virtualbox on my excalibur box.

Most likely.
I don't "gui" system maintenance and hardly know synaptic. A more correct first reply might have been "Yes, this should do the trick.".

From my point of view, dist-upgrade just works.

@fsmithred: thanks for sharing.