Well, I have my desktop running with Daedalus, lightdm & Cinnamon, up-to-date, openrc and amd64, traditional unencrypted /boot, a luks-encrypted container holding a LVM for / and /swap. Working fine, just tried it, no shutdown delays.

Update: also checked my laptop running Daedalus with similar setup: no problems with shutdown delays.

I looked into my update history. The last update of the cryptsetup-stuff was before Chrismas. Why do we suddenly have a problem?

Ok, another loop. You definitely use a 5600XT for display, not the built in graphics from the CPU? Its a NAVI1, but a later modification. For firmware support you may need to follow HoaS' suggestion.

Backports handling: if you want to install a package from backports, you explicitly must specify this as I showed in my example. Just enabling backports in the sources.list and an install won't pull anything from backports. Intentionally. Pinning makes sure ....

You did not downgrade, but also didn't upgrade. When you pull a package from backports leave backports enabled, or you may get a downgrade later. And you won't get fixes from backports.

Good luck ...

Still got a PC running on a Ryzen7 3700 and a 5500XT, stock Chimaera with backports kernel, my wife's desktop. No kernel parameters required, just firmware-amd-graphics. You should stick to Chimaera until Daedalus is becoming stable.

My desktop was upgraded to a 6700XT, that does not work fine on Chimaera, it need more recent mesa and other stuff. This is running Daedalus. No kernel params, again just firmware-amd-graphics.

New feature dripping down from Debian into testing/unstable = Daedalus & Ceres.

I guess the merge needs to be adapted/completed.

# apt policy
Paketdateien:
 100 /var/lib/dpkg/status
     release a=now
 500 http://deb.devuan.org/merged daedalus/non-free-firmware amd64 Packages
     release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=non-free-firmware,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged daedalus/non-free amd64 Packages
     release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=non-free,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged daedalus/contrib amd64 Packages
     release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=contrib,b=amd64
     origin deb.devuan.org
 500 http://deb.devuan.org/merged daedalus/main amd64 Packages
     release v=5.0,o=Devuan,a=testing,n=daedalus,l=Devuan,c=main,b=amd64
     origin deb.devuan.org
Mit Pinning verwaltete Pakete:

Can only recommend to use UUIDs or labels, everything else is coincidence. Device detection order is ambiguous since a while already.

Linux can deal with both, does not make a real difference.

Meanwhile I have adopted the habit to use gpt wherever possible, even if its not really necessary. The advantage is that you do not have to deal with the limitations of the old MSDOS partitioning scheme: not more than 4 partitions. Or you use 3 plus an extended with logical drives in there (i.e. sda5 as first logical partition in an extended), or sometimes one in the middle is missing. gpt is linear, you just count up.

For such jobs I have a gparted life cd available to boot on usb. Write a new partition table, and then restart the Devuan installer and use manual partitioning.

And to get to another console while installing: use ALT-F2. There you can enter available commands. Back to installer with ALT-F1.

You might need to look for the uuid instead of the device. Check your fstab.

Short update: tried to install the weekly Bookworm into VBox for a check if Debian behaves the same, and failed. The iso is throwing machine checks and complains about the display. Will drill a bit deeper into that and update when I have results.

I am not really an expert on logging, I just use whats available every now and then.

Devuan uses its own package called rsyslog. There is also a doc package for this. Maybe that is a start for you. Somehow the stuff can be configured, and maybe yours is off for some reason.

To the raid: I have had my share of experiences with using Raid0 and later on trying Raid1/10 mainly on U320 SCSI, I would call it a disaster. Thats why I personally would walk away from any Raid if I have the choice of using SSDs instead. A single SSD never will cause the kind of hickups you can experience with Raids. A good backup always is required anyhow, and this is the lifesaver, not a Raid1.

And I think good SSDs are more reliable than any disk drive.