Posts by Marjorie

Marjorie · Other Issues

might be worth checking that you are sending using the same email address registered with DNG and that is mentioned in the headers of the posts that you are receiving.
I sometimes I have problems like this because when composing a message, that is not a reply, my mail agent defaults to the 'wrong' address (I have several, all on the same server).

Marjorie · Hardware & System Configuration

To be honest I too find searching the forum archive for something can be hard - what would be nice, for me, is the ability to surface just the relevant posts when you search by keyword and author rather than the whole threads that include those posts. It's always worth asking on the forum for solutions at the start - its quite possible someone may remember how a problem has been solved before you are forced to do it all yourself.

Marjorie · Hardware & System Configuration

I thought I'd already posted on this at least once in the distant past in another thread.

And yes I had, covering the main issue of finding a script that worked.

https://dev1galaxy.org/viewtopic.php?pid=34465#p34465 posted 7th Feb 2022 17:05:55

As HOAS says UFW still accesses the nftables back-end (which uses the nftables kernel module) through an iptables translation layer.
If you want to run nftables commands natively you need to do as HOAS suggest.
If you have Chimaera (or above) then use the nftables init script provided by orphan-sysvinit-scripts.
If you have Beowulf or earlier then there is no orphan-sysvinit-scripts. Having installed nftables and put the commands you want run in the config file you need to copy the example file /usr/share/doc/nftables/examples/sysvinit/nftables.init to /etc/init.d/nftables, change the Default-Start and Default-Stop lines (lines 6 and 7) and then make the init file executable by root.
Change the lines:
# Default-Start:
# Default-Stop: 0 1 2 3 4 5 6
to:
# Default-Start: S
# Default-Stop: 0 6
Then run
update-rc.d nftables defaults
as described by HOAS.
This will then read the config file and start nftables at boot.

Marjorie · Hardware & System Configuration

This is the /etc/init.d/nftables I have from several year back when I set up my new mailserver.

It's always worked to date.

Author was: Arturo Borrero Gonzalez <arturo@debian.org>

I think it differs from the current official version in default start and stop.
The 'official' version now has:

# Default-Start:
# Default-Stop:      0 1 2 3 4 5 6

mine is here:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          nftables
# Required-Start:    $local_fs $network $remote_fs $syslog
# Required-Stop:     $local_fs $remote_fs $syslog
# Default-Start:     S	
# Default-Stop:      0 6
# Short-Description: nftables firewall service
# Description:       nftables firewall system service
### END INIT INFO

# Author: Arturo Borrero Gonzalez <arturo@debian.org>

# Do NOT "set -e"

CONF=/etc/nftables.conf

# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="firewall service"
NAME=nftables
BIN=/usr/sbin/nft
SCRIPTNAME=/etc/init.d/$NAME

# Exit if the package is not installed
[ -x "$BIN" ] || exit 0

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

VERBOSE=yes

do_start()
{
	# Return
	#  0 if start OK
	#  2 if start NOK

	# nft v0.4 return 0 if ENOENT $CONF
	if [ ! -r "$CONF" ] ; then
		echo "E: No such $NAME $DESC config file $CONF" >&2
		return 2
	fi

	$BIN -f $CONF || return 2
}

do_stop()
{
	# Return
	#   0 if stopped
	#   1 if already stopped
	#   2 if could not be stopped
	if ! do_status ; then
		$BIN flush ruleset || return 2
	fi
}

do_status()
{
	# Return
	#   0 if no rules
	#   1 if rules
	if [ "$($BIN list ruleset 2>/dev/null | wc -l)" = "0" ] ; then
		return 0
	fi

	return 1
}

case "$1" in
  start)
	[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
	do_start
	ret="$?"
	case "$ret" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	exit $ret
	;;
  restart|force-reload)
	[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
	do_start
	ret="$?"
	case "$ret" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	exit $ret
	;;
  stop)
	[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
	do_stop
	ret="$?"
	case "$ret" in
		0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
		2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
	esac
	exit $ret
	;;
  status)
	if ! do_status ; then
		[ "$VERBOSE" != no ] && log_daemon_msg "Status of ${DESC}: rules loaded" "$NAME"
		[ "$VERBOSE" != no ] && log_end_msg 0
		exit 0
	else
		[ "$VERBOSE" != no ] && log_daemon_msg "Status of ${DESC}: no rules loaded" "$NAME"
		[ "$VERBOSE" != no ] && log_end_msg 1
		exit 1
	fi
	;;
  *)
	echo "Usage: $SCRIPTNAME {start|stop|status|restart|force-reload}" >&2
	exit 3
	;;
esac

Marjorie · Installation

Glad to hear you've got a workround.

It see it has updated in Bookworm to 115.4.0esr-1~deb12u1, but I did a repository refresh and mine still shows 102.15, so obviously just a matter of time unless I pin it.

Marjorie · Installation

Firefox 102.15 is still the version in (my) Daedulus repository this morning. I assume that the rollover to 115.4 won't happen till November. Where did you get it?

Marjorie · Other Issues

It always used to be the case that one used a dummy library to satisfy 'imaginary' systemd dependencies lookups.
On my Daedalus system I note I have the liblogind-compat and liblogind0 packages installed but not the libsystemd0 package.
The description oft the former is
"The libelogind0 library is ABI compatible with libsystemd0.
This package provides the necessary symlinks to allow binaries linked against libsystemd0
to work with libelogind0. For full details of the compatibility see README.Debian."

Marjorie · Desktop and Multimedia

AFAIK Wayland is only available if you use KDE or Gnome, other DMs default to X (I use Cinnamon and X).
Maybe the issue you are having with Firefox is Wayland/rootless start related.
Maybe it's not showing your apps on your default screen.

Are you starting them from a terminal or from Gnome? Starting them from a terminal may show some useful information.

Marjorie · Desktop and Multimedia

I also upgraded from Chimaera, using Cinnamon as DM and (automatically upgraded) Shotwell is working.
I note both my version of Shotwell and my Depends libraries differ from Dutch Master in that the version numbers are higher.

marjorie@grendel:~$ apt show shotwell
Package: shotwell
Version: 0.30.17-1+b1
Priority: optional
Section: gnome
Source: shotwell (0.30.17-1)
Maintainer: Jörg Frings-Fürst <debian@jff.email>
Installed-Size: 6,699 kB
Depends: libc6 (>= 2.34), libcairo-gobject2 (>= 1.10.0), libcairo2 (>= 1.2.4), libexif12 (>= 0.6.21-1~), libgcr-base-3-1 (>= 3.8.0), libgcr-ui-3-1 (>= 3.8.0), libgdata22 (>= 0.15.0), libgdk-pixbuf-2.0-0 (>= 2.25.2), libgee-0.8-2 (>= 0.10.1), libgexiv2-2 (>= 0.10.4), libglib2.0-0 (>= 2.49.5), libgphoto2-6 (>= 2.5.10), libgphoto2-port12 (>= 2.5.10), libgstreamer-plugins-base1.0-0 (>= 1.0.0), libgstreamer1.0-0 (>= 1.0.0), libgtk-3-0 (>= 3.21.5), libgudev-1.0-0 (>= 146), libjson-glib-1.0-0 (>= 1.5.2), libpango-1.0-0 (>= 1.18.0), libpangocairo-1.0-0 (>= 1.14.0), libraw20 (>= 0.16.0), libsoup2.4-1 (>= 2.41.90), libsqlite3-0 (>= 3.5.9), libunity9 (>= 3.4.6), libwebkit2gtk-4.0-37 (>= 2.25.1), libxml2 (>= 2.7.4), shotwell-common (= 0.30.17-1), dconf-cli, default-dbus-session-bus | dbus-session-bus, librsvg2-common
Replaces: shotwell-common (<< 0.26.2-1)
Homepage: https://wiki.gnome.org/Apps/Shotwell
Tag: implemented-in::c, interface::graphical, interface::x11, role::program,
 uitoolkit::gtk, use::organizing, use::viewing, works-with-format::jpg,
 works-with::image, works-with::image:raster, x11::application
Download-Size: 1,863 kB
APT-Manual-Installed: no
APT-Sources: http://deb.devuan.org/merged daedalus/main amd64 Packages
Description: digital photo organizer

Marjorie · Desktop and Multimedia

deepforest wrote:

are you mean this script?
https://dev1galaxy.org/viewtopic.php?pid=20903#p20903
how use it?
now i am on Deadalus and cant chek it.
but i can do it in future if you talk me how to use those script.

OK. I'm assuming that the only problem we are trying to address is with nvidia-persistenced.

My modiified nvidia-persistenced init script is as follows:

#!/bin/sh -e
#
# NVIDIA Persistence Daemon Init Script
#
# Copyright (c) 2013 NVIDIA Corporation
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# This is a sample System V init script, designed to show how the NVIDIA
# Persistence Daemon can be started.
#
# This sample does not rely on any init system functions, to ensure the
# widest portability possible.
#
# chkconfig: 2345 99 01
# description: Starts and stops the NVIDIA Persistence Daemon
# processname: nvidia-persistenced
#
### BEGIN INIT INFO
# Provides:         nvidia-persistenced
# Required-Start:   $local_fs
# Required-Stop:    $local_fs
# Default-Start:    2 3 4 5
# Default-Stop:     0 1 6
# Short-Description: Starts and stops the NVIDIA Persistence Daemon
# Description:      Starts and stops the NVIDIA Persistence Daemon
### END INIT INFO

NVPD=nvidia-persistenced
NVPD_BIN=/usr/bin/${NVPD}
NVPD_RUNTIME=/var/run/${NVPD}
NVPD_PIDFILE=${NVPD_RUNTIME}/${NVPD}.pid
NVPD_USER=nvpd
NVPD_ACTION=${1}

# Gracefully exit if the package has been removed.
test -x $NVPD_BIN || exit 0

# Get the value of the PID
if [ -f ${NVPD_PIDFILE} ]; then
 read -r NVPD_PID < "${NVPD_PIDFILE}"
# Is the daemon already running?
 if [ "${NVPD_PID}" ] ;then 
  if [ -d /proc/${NVPD_PID} ]
# Daemon is running, so stop it then start anew instance
   then
    case "${1}" in
     start)
      echo "NVIDIA Persistence Daemon already running" 
      NVPD_ACTION=restart
      ;;
     *)
      ;;
    esac
# Daemon not running, but there is a stale PID
   else
    echo "NVIDIA Persistence Daemon, stale PID removed"			
    unset NVPD_PID
    rm -rf "${NVPD_RUNTIME}"
  fi
 fi
fi

case "${NVPD_ACTION}" in
 start)
  echo "Starting NVIDIA Persistence Daemon"
# Execute the daemon as the intended user
  ${NVPD_BIN} --user ${NVPD_USER}
  ;;
 stop)
   echo "Stopping NVIDIA Persistence Daemon"
# Stop the daemon - its PID should have been read in
   [ ! -z "${NVPD_PID}" ] && kill ${NVPD_PID} &> /dev/null
    ;;
  restart)
   $0 stop
   sleep 2
   $0 start
    ;;		
  *) echo "usage: $0 {start|stop|restart}"
    ;;
esac

exit 0

1) With your mouse select all of the script and then copy it, using the "Control" and "c" keys together.

I use Cinnnamon, sudo and the gedit editor and will illustrate using these. If you use su - rather than sudo and another text editor just change to suit.

2) Open a terminal window.

3) in the terminal type:

sudo gedit /etc/init.d/nvidia-persistenced

This should open the nvidia-persistenced init code in the editor.

4) Select all the text with your mouse.

5) Press the 'Control' and' v' keys together to paste my version in place of the existing text.

6) Save the updated code. In 'gedit' there is a save button.

7) Close gedit.

7) in the terminal restart nvidia-persistenced by typing:

sudo service nvidia-persistenced restart

8) Close the terminal.

Marjorie · Hardware & System Configuration

I have Daedalus with Cinnamon/Ligthdm setup on a 6-core AMD Ryzen 5 5600G and a MSI MPG B550 GAMING PLUS motherboard.
I have a large swap partition like yours on my main LVM2 RAID1 SSDs

Hibernate using pm-utils (sudo pm-hibernate) works well.
I have buttons set up to call this from my panel (Shutdown Menu with Icons applet).
I have pm-hibernate in my sudoers file so I don't need to enter a password to hibernate.
One reason I use pm-utils rather than the built-in hibernate is that way I can call screen-lock when hibernating (and enforce unlock when I resume).

Suspend (sudo pm-suspend) sort of works but I find that with recent kernels and/or my bios it has proven unstable after waking.
Strangely it is also quite slow to waken compared to how it used to be when it worked properly. Not much faster than waking from hibernate.

Automatic activation, through the Cinnamon Power Management settings times out to suspend so I don't use it.
The settings do include a Hybrid sleep and Hibernate after suspend options, but not direct to hibernate. I've not tried the other options.

Marjorie · Desktop and Multimedia

deepforest wrote:

Something progress in my question
This https://www.if-not-true-then-false.com/ … dia-guide/
not working at Ceres but working at Deadalus
PS at Ceres working this solution
apt install nvidia-legacy-340xx-driver 
but have issue with
nvidia-persistenced failed to initialize
https://dev1galaxy.org/viewtopic.php?id=5881

If you use apt to install nvidia-legacy-340xx-driver it may well pull in the original unpatched /etc/init.d/nvidia-persistenced.
Have you tried replacing it with my patched version and then restarting it?

:~$ sudo service nvidia-persistenced restart

Marjorie · Desktop and Multimedia

Not sure what you mean by Debian Ceres 340.108 driver.
Ceres is the Devuan equivalent of Debian Sid.
Playing around with bleeding edge stuff (Sid/Ceres) is asking for trouble.
I would only suggest doing it if you have such new hardware that you can't get it working any other way.
And isn't Nvidia 340.108 a legacy driver? Not exactly new hardware.

Marjorie · Desktop and Multimedia

Not sure about OpenRC, the nvidia supplied nvidia-persistenced is a standard sysVinit script to go in /etc/init.d and I use sysVinit.
In my linked post I include a copy of my patched version.
https://dev1galaxy.org/viewtopic.php?pid=20903#p20903
If you replace the supplied /etc/init.d/nvidia-persistenced with this it should just work and not throw up any errors.
It worked fine on my PC. This PC has AMD not Nvidia graphics but my Nvidia card was still working on another machine last time
I checked.
O course they may have changed the original since 2020, but I doubt it - my 2020 version was originally written in 2013!

Marjorie · Desktop and Multimedia

I thought I'd explained this in my linked 2020 post at https://dev1galaxy.org/viewtopic.php?pid=20903#p20903

The nvidia supplied init (/etc/init.d/nvidia-persistenced) file was borked.
As most other distributions (such as vanilla debian) use a systemd .service file, not a sysvinit init file to initialise they wouldn't get this problem.

I think I've identified the problem, though I'm unclear why it got triggered during an install. The problem occurs when there is an existing nvidia-persistence running on the system. When this is the case starting nvidia-persistenced fails with the above error message (as it can't get a lock on the PID file).
I've therefore added/modified a few line of code to correct this: if a running nvidia-persistenced exist it stops it and then starts a new instance. This ensures that nvidia-persistenced starts in its enabled state as that is the default.

This was 4 years ago (and 10 years since that file was created) so maybe it's now something else.

Marjorie · Desktop and Multimedia

Indeed. It may however be helpful (albeit not essential), but it seems only on machines/servers that don't run X persistently.

"Under Linux systems where X runs by default on the target GPU the kernel mode driver will generally be initalized and kept alive from machine startup to shutdown, courtesy of the X process. On headless systems or situations where no long-lived X-like client maintains a handle to the target GPU, the kernel mode driver will initilize and deinitialize the target GPU each time a target GPU application starts and stops. In HPC environments this situation is quite common. Since it is often desirable to keep the GPU initialized in these cases, .. "

https://docs.nvidia.com/deploy/driver-p … index.html

Marjorie · Desktop and Multimedia

nvidia-persistenced has no real purpose unless you want to use CUDA.

If you don't need CUDA then you can just delete it, nvidia works fine without it.

There was (is still?) a bug in the code that dates back to 2014 that can lead to it not initialising properly.

See my post dating back to April 2020.

https://dev1galaxy.org/viewtopic.php?pid=20903#p20903

Marjorie · ARM Builds

ExposeGlobalistsMadness wrote:

So what are common Devuan users to do? Starting up ntp fails again (sudo service ntp start), even though the clock somehow updated automatically much later during this same session!

I use chrony. It seems to work reliably.

https://chrony-project.org/comparison.html

NB. the comparisons shown on this page are with ntp not with ntpsec.

Marjorie · Off-topic

vanbinsbergen wrote:

I made a desktop choice at installation. That i remember. Which one, i don't :-)
I'm gonna check it out, i'll let you know if it worked for further generations who stumble upon this post.

If you have Cinnamon then there an option Menu>Preferences>System Info that will tell you about your system.

Also in a console/terminal you can run neofetch, or for absolutely everything inxi -F (if not already installed both come in packages with the same names).

On my system neofetch provides this:

marjorie@grendel:~$ neofetch
   ..,,;;;::;,..                   marjorie@grendel 
           `':ddd;:,.              ---------------- 
                 `'dPPd:,.         OS: Devuan GNU/Linux 5 (daedalus) x86_64 
                     `:b$$b`.      Host: MS-7C56 1.0 
                        'P$$$d`    Kernel: 6.1.0-11-amd64 
                         .$$$$$`   Uptime: 1 day, 15 hours, 59 mins 
                         ;$$$$$P   Packages: 2892 (dpkg) 
                      .:P$$$$$$`   Shell: bash 5.2.15 
                  .,:b$$$$$$$;'    Resolution: 1920x1200 
             .,:dP$$$$$$$$b:'      DE: Cinnamon 5.6.8 
      .,:;db$$$$$$$$$$Pd'`         WM: Mutter (Muffin) 
 ,db$$$$$$$$$$$$$$b:'`             WM Theme: Blue-mint (Menta) 
:$$$$$$$$$$$$b:'`                  Theme: TraditionalGreen [GTK2/3] 
 `$$$$$bd:''`                      Icons: menta [GTK2/3] 
   `'''`                           Terminal: gnome-terminal 
                                   CPU: AMD Ryzen 5 5600G with Radeon Graphics (12) @ 3.900GHz 
                                   GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series 
                                   Memory: 5729MiB / 13876MiB

Marjorie · Installation

You can certainly do it from Bullseye (11) to Chimaera (4).
The instructions are here:
https://www.devuan.org/os/documentation … o-chimaera

The instructions you quote for Stretch (10) to Beowulf (3) are the 'official' Devuan instructions.
https://www.devuan.org/os/documentation … to-beowulf
and should also still work, at least on bare metal, as the source and destinations systems are both essentially frozen.
This does assume that the repositories are still there: Beowulf is now quite old.

If you coming from Bullseye (or earlier) you can convert that and then upgrade to Daedalus: although the upgrade process to Daedalus hasn't yet been formally documented several of us have done it and reported back to the Forum as to how we did it. It's pretty straightforward.

As to converting from Bookworm to Daedalus there aren't as yet any instructions for this on the Devuan site.
I have seem some discussion of the issues on the Devuan DNG list and it doesn't seem quite as straightforward if systemd is already installed (as you seem to have found).
The problem seems to be with removing systemd at Pid 1, and not locking the system.
Others more involved than me may be able to better answer how, if at all, this can be done.
And if it is possible then no doubt the instructions on how to do it will be published when Daedalus goes live.

Marjorie · Installation

Just surmising that there's no one here who:

1) has chosen Gnome as their DM and
2) has an Nvidia graphics card and
3) has chosen to try Wayland and has got it working successfully.

Marjorie · Installation

On your second point nvidia-persistenced has no real purpose unless you want to use CUDA.

If you don't need CUDA then you can just delete it, nvidia works fine without it.

There was (is still?) a bug in the code that dates back to 2014 that can lead to it not initialising properly. Nothing to do with systemd, just poor code.

See my post dating back to April 2020.

https://dev1galaxy.org/viewtopic.php?pid=20903#p20903

Marjorie · Other Issues

Bookworm is now on version 12.1 which is usually taken as a sign that initial bugs have been sorted and sysadmins. can safely upgrade.

So I would expect Daedalus, which exactly the same packages as Bookworm in most cases should equally be ready, apart from the installation isos which are still being tested.

Most security updates appear on Daedalus as soon as they appear on Bookworm since Devuan merges Bookworm packages with the very limited number of 'devuan modified' packages. For example the Zenbleed AMD firmware patch appeared very quickly.

For myself, having upgraded my desk PC from Chimaera to Daedalus a few weeks ago without issue I've now upgraded my two others machines, one a mail server and all seems good.

Marjorie · Off-topic

I'm not affected personally as my AMD 5600G is Zen3 not Zen2,

Nevertheless a AMD-microcode fix for Chimaera, Daedalus and Unstable landed this morning as a security update.

However as the end of that security-tracker (https://security-tracker.debian.org/tra … 2023-20593) it says:

3.20230719.1 ships the first batch of fixes, only for 2nd gen Epyc CPUs, further
CPUs to follow in later releases

This is the one we have now got. Epyc is a database CPU.

So there are still fixes to come for the other Zen2 (Ryzen) CPUs which aren't fixed yet.

More info here:

https://web.archive.org/web/20230724143 … bleed.html

If you haven't got the microcode fix there is a workaround mentioned in this article:

Workaround
It is highly recommended to use the microcode update.
If you can’t apply the update for some reason, there is a software workaround: you can set the chicken bit DE_CFG[9].
This may have some performance cost.
Linux
You can use msr-tools to set the chicken bit on all cores, like this:
# wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))

Marjorie · Devuan

GNUser wrote:

Yesterday I upgraded from Chimaera to Daedalus without any issues. Here are the steps I followed:

Edit /etc/apt/sources.list to point to daedalus
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade # at the end there are some errors having to do with old version of linux kernel
$ sudo apt-get autoremove --purge # this removes the packages that caused errors
$ sudo apt-get dist-upgrade # now it completes without any errors
$ sudo apt-get autoclean
Reboot

I'm assume that we will be providing a note on how to upgrade as well as how to install from new and how to convert from Debian.
So I thought it might be useful to document my experience and any trip hazards I encountered.

I upgraded just over a week ago, using the same steps as described above.
Where it asked about if I wanted to accept new default config files I chose to keep those I already had.
I was already using the most recent backported 6.1 kernel prior to the upgrade.
A simple replace edit of sources list is however not entirely sufficient as you should add the 'non-free firmware' to each line.
With that change I had no problems in the upgrade as such.

I use unattended-upgrades to install any security package updates daily.
I had to change the line "o=Devuan,n=chimaera-security" to "o=Devuan,n=daedalus-security" in /etc/apt/apt.conf.d/50unattended-upgrades.

My motherboard (a MSI B550) use a custom chip to monitor fan speeds in particular.
There is a corresponding kernel module but it was not loaded. I ran

sudo modprobe nct6687.ko

to load it and then sensors could see it.

Grub no longer runs osprober by default. If you have been using it to create grub menu items to boot to alternative OS on your machine you will need to as root restore it in the file /etc/default/grub by un-commenting the line

#GRUB_DISABLE_OS_PROBER=false

and then run update-grub as root.

Also relating to grub the menu on my PC now works with my usb keyboard (it didn't on Chimaera).

rsyslog creates fewer log files, such as /var/log/mail.{info,warn,err}. The messages are still there in /var/log/mail.log.
If you have another program reading any of these, e.g. fail2ban, you will need to get it to read /var/log/mail.log instead.
Similarly /var/log/{messages,debug,daemon.log} are also no longer being updated. Their messages are still there in /var/log/syslog.
All these (and their log-rotated counterparts) can now be removed.
Logrotate itself is working as expected on my PC.

Just for info. I run Cinnamon. After the upgrade Gnome programs (such as Evolution and System Monitor) now duplicate the Max/Min/Close symbols and Title that are in the Window Title Bar in the top line of the program. Nothing fatal but it looks odd.

There are some changes in Bookworm (and hence Daedelus) that don't affect my PC but might others e.g. the packages that set the system clock and reduced accessibility support.
Changes to Bookworm (and by default Daedulus) are covered in the release notes' Chapter 5 Issues to be aware of for bookworm https://www.debian.org/releases/bookwor … on.en.html

The officially official Devuan Forum!

#1 Re: Other Issues » I can read but not send to the DNG mailing list » 2024-01-15 15:35:08

#2 Re: Hardware & System Configuration » nftables init script » 2024-01-15 11:02:33

#3 Re: Hardware & System Configuration » nftables init script » 2024-01-12 22:57:01

#4 Re: Hardware & System Configuration » nftables init script » 2024-01-12 15:26:16

#5 Re: Installation » Whoopsie ... Firefox-esr 115.4 breaks things » 2023-10-30 12:12:52

#6 Re: Installation » Whoopsie ... Firefox-esr 115.4 breaks things » 2023-10-30 11:40:18

#7 Re: Other Issues » installing Appimagelauncher » 2023-09-27 21:34:23

#8 Re: Desktop and Multimedia » Browsers won't launch » 2023-09-14 19:31:12

#9 Re: Desktop and Multimedia » [SOLVED] Shotwell dependency confusion » 2023-09-14 19:11:12

#10 Re: Desktop and Multimedia » Devuan Ceres - X not starting at kernel 6.4 + 340.108 driver » 2023-08-26 19:55:47

#11 Re: Hardware & System Configuration » [Solved] Howto hibernate » 2023-08-24 22:36:20

#12 Re: Desktop and Multimedia » Devuan Ceres - X not starting at kernel 6.4 + 340.108 driver » 2023-08-24 14:58:18

#13 Re: Desktop and Multimedia » nvidia-persistenced failed to initialize » 2023-08-24 14:51:30

#14 Re: Desktop and Multimedia » nvidia-persistenced failed to initialize » 2023-08-22 21:10:32

#15 Re: Desktop and Multimedia » nvidia-persistenced failed to initialize » 2023-08-21 18:45:59

#16 Re: Desktop and Multimedia » nvidia-persistenced failed to initialize » 2023-08-18 17:03:23

#17 Re: Desktop and Multimedia » nvidia-persistenced failed to initialize » 2023-08-18 14:33:55

#18 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-08-17 20:09:30

#19 Re: Off-topic » make desktop looks like windows 11 » 2023-08-17 13:15:25

#20 Re: Installation » Devuan 5 daedalus gnome wayland doesn't work with nvidia » 2023-08-14 20:01:12

#21 Re: Installation » Devuan 5 daedalus gnome wayland doesn't work with nvidia » 2023-08-14 11:17:57

#22 Re: Installation » Devuan 5 daedalus gnome wayland doesn't work with nvidia » 2023-08-08 14:09:59

#23 Re: Other Issues » Ceres AMD64 unable to install wine32 » 2023-07-27 15:59:16

#24 Re: Off-topic » Zenbleed - CVE-2023-20593 » 2023-07-26 13:26:19

#25 Re: Devuan » Devuan 5 Daedalus Release (Debian 12 - Bookworm) | Looking for info » 2023-07-17 10:31:57

Board footer