Well, I was considering to write a bug report, but I did not do that because I am pretty sure it will be closed with the comment "works as specified".

Well, what I got from the debianforum.de, the rules in /etc/udev/rules.d have higher priority. Don't know if that is true.

My preference would be to leave the system directory /usr/lib/udev/rules.d alone and save my tweaks in /etc/udev/rules.d, clear distinction. That also was the suggestion from a very experienced person that looked at the problem and suggested the fix.

Yes it sucks. In the meantime I have a long document describing all these tweaks.

BTW: yes you have to create that edit unter /etc yourself. To make it work, either reboot or try a:

# udevadm control –reload
# udevadm trigger

Hi there, I guess the drive that isn't automounted is ext(x)-formatted, isn't it? Well, there is a new quirk in the udev rules from corporate actors inhibiting automount for ext(x)-partitions and others coming in with Trixie. Found that on the German Debian forum.

Check out for a file /usr/lib/udev/rules.d/64-ext4.rules, it reads:

# SPDX-License-Identifier: GPL-2.0-or-later
#
# Copyright (C) 2023 Oracle.  All rights reserved.
# Author: Darrick J. Wong <djwong@kernel.org>
#
# Don't let udisks automount ext4 filesystems without even asking a user.
# This doesn't eliminate filesystems as an attack surface; it only prevents
# evil maid attacks when all sessions are locked.
#
# According to http://storaged.org/doc/udisks2-api/latest/udisks.8.html,
# supplying UDISKS_AUTO=0 here changes the HintAuto property of the block
# device abstraction to mean "do not automatically start" (e.g. mount).
SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext2|ext3|ext4|ext4dev|jbd", ENV{UDISKS_AUTO}="0"

To override this rule you either change the "0" into a "1" with the risk that your change is overwritten from another update, or better write your own rule and save it to /etc/udev/rules.d/65-ext4.rules:

# extX-Dateisysteme automatisch mounten
SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="ext2|ext3|ext4|ext4dev|jbd", ENV{UDISKS_AUTO}="1" 

HTH

Ok, I am on conventional DSL here in Frankonia. No glas fibre yet directly to my home. They are working on that.

I use the standard Telekom DNS service and I at least currently have no issues with deb.devuan.org. And I have a Fritzbox bought on my own, no Speedport from Telekom any more.

Known problem, issues with DNS resolution by the internet providers. There are various threads here in the forum about this issue. They do not like the deb.devuan.org which is not a single IP but a so called round robin of various servers (used for load distribution). You can't do anything really. Only thing to try is to use a different DNS resolver.
And I would skip the "de" and just use http://deb.devuan.org/.....

Just upgraded my workstation to Excalibur. Took 20mins, so far working perfectly.

Thanks to the Devuan team.

During installation you have the choice: you either allow root login and enter a root password, then you have to use a root console for admin tasks. My preferred method. Or you don't do that then you automatically are assigned to the sudoers group and you have to use a sudo before each admin command. Don't try to mix.

The power draw from any SSD is very much depending on the write/read load. The figures given are for full load at full speed plus a bit overhead. The average consumption will be very much lower.

But to be considered: PCIe3 consumes less than PCIe4, less than PCIe5.

Everybody experienced would be very pleased if you could put any console output between code tags, including the command you have used. To write code tags use the button that is labelled code above the editing window, and paste the text between the starter and the end tag. Makes console outputs look like in a console, much more readable and more friendly for the contributors.

I will do this for you as an example by copying your last output and! adding line numbers like a reasonable text editor can do.

 cat /etc/apt/sources.list
1 #deb cdrom:[Devuan GNU/Linux 6.0.0-rc1 excalibur amd64 - netinstall 20250913]/ excalibur contrib main non-free-firmware
2 
3 deb http://deb.devuan.org/merged excalibur main contrib non-free non-free-firmware
4 deb http://deb.devuan.org/merged excalibur-security main contrib non-free non-free-firmware
5 deb http://deb.devuan.org/merged excalibur-updates main contrib non-free non-free-firmware
6
7 #deb http://deb.devuan.org/merged excalibur-backports main contrib non-free non-free-firmware
8
9 # excalibur-updates, to get updates before a point release is made;
10 # see https://www.debian.org/doc/manuals/debi … _backports
11 deb http://deb.devuan.org/merged excalibur-updates main non-free-firmware
12 deb-src http://deb.devuan.org/merged excalibur-updates main non-free-firmware
13
14 # This system was installed using removable media other than
15 # CD/DVD/BD (e.g. USB stick, SD card, ISO image file).
16 # The matching "deb cdrom" entries were disabled at the end
17 # of the installation process.
18 # For information about how to configure apt package sources,
19 # see the sources.list(5) manual.

Your sources.list contains 19 lines of text.

Line 5 and line 11 are (partial) duplicates. Line 11 causes the error messages you are getting.

My advise: get rid of every past line 8 and try again. Attention: there has to be an empty line at the end of the file.

Don't get confused by tux_99's reply. What I gave you is a correct /etc/apt/sources.list for Excalibur. The traditional format.

Now what tux_99 has posted is the new DEB822 format replacing the sources.list in the future. For the time being I would recommend to stay with the traditional format.

All my upgrades on my laptop and in my VMs, I am not missing any logs. Same with a new installation from the released netinstall in a VM. Maybe you used one of the testing editions, and there is something in the back of my mind that rsyslog was missed out on one or two of them.