In computing terms that motherboard is ancient and likely does not support TPM.
Check the motherboard manual and check your firmware is the latest.

Do not use indexes, use the designated device names consistently and totally...

# PlayStation®VR USB Streaming used in 3D Mode Only (HDMI used in 2D Cine Mode)
pcm.psvr_hw {
  type hw
  card 'PlayStation®VR'
  device 0
  channels 2
}

This is an example from my config of a sound device which comes and goes without breaking anything.

There seem st be a lot of confusion in this thread about what a 'machine id' is and what a 'dbus session id' is. They are not the same thing despite dbus using the machine id as a unique but determinable temporary filename.
The reason '~/.dbus/session-bus/' fills up is evidence that the machine id is changing. Under systemd the machine id is never supposed to be changed so the filename never changes and the contents are simply overwritten.

NB This is also why you should avoid changing the machine id once logged in, it can have side-effects on dbus.

root@localhost:~# cat ~/.bash_logout
rm -f ~/.dbus/session-bus/*

@fsmithred, been playing.
Blacklisting md_mod is not sufficient although it does prevent passive loading.
When 'mdadm' is invoked with certain parameters it will then in turn trigger the kernel to load md_mod.
That is why 'chmod ugo-x /usr/share/initramfs-tools/hooks/mdadm' and thus knobbling 'mdadm' fixed it for me.

NB, and knobbling the UDEV rules as well...

@fsmithred

Re script:/etc/modprobe.d/mdadm.conf mine comes from the installed package:

ii  mdadm          4.2-5        amd64        Tool to administer Linux MD arrays (software RAID)

With the execute mode removed from script:/usr/share/initramfs-tools/hooks/mdadm mdadm is not invoked (not installed) in the initramfs.
That in conjunction with sysvinit 'mdadm' service being disabled md_mod is not automatically loaded at boot.

NB: If dm_raid has loaded that would use md_mod.

There seems to be differing methods of activation depending whether md raid is compiled in or a module, plus that udev rule that would run.
I found this type of thing a bane when performing data recovery by attaching faulty\corrupt media to a workstation for repair\recovery.

Kconfig CONFIG_MD_AUTODETECT

file drivers/md/md-autodetect.c

#ifdef CONFIG_MD_AUTODETECT
static int __initdata raid_noautodetect;
#else
static int __initdata raid_noautodetect=1;
#endif

        if (raid_noautodetect)
                printk(KERN_INFO "md: Skipping autodetection of RAID arrays. (raid=autodetect will force)\n");

        printk(KERN_INFO "md: Waiting for all devices to be available before autodetect\n");
        printk(KERN_INFO "md: If you don't use raid, use raid=noautodetect\n");

Devuan follows Debian, so you need to know the Debian release timetable.

Right! I believe your main issue is (esp the HAL stuff) there is hangover files from systemd.
Examine your system carefully for SystemD packages  that have not been purged.
I have never had to do this so someone else may be able to advise you a good way to do so.

Adding 'nofail' *may* enable booting without recovery, it depends on your LVM configuration which I ha
ve not seen.
Either way it wont harm (other than /home not getting mounted on an error)

My mistake, yes.
I searched my personal historic docs and found that I actually modified the shell library that /etc/init.d/cryptdisks pulls in

Check /lib/cryptsetup/cryptdisks-functions and the do_stop() function

--- cryptdisks-functions.orig   2023-10-10 14:51:52.654685939 +0100
+++ cryptdisks-functions        2023-10-10 14:55:10.184788099 +0100
@@ -191,6 +191,19 @@
     devno_rootfs="$(get_mnt_devno /)" || devno_rootfs=""
     devno_usr="$(get_mnt_devno /usr)" || devno_usr=""

+    if [ "$INITSTATE" = "remaining" ]; then
+       if [ -x /sbin/lvm ]; then
+          vgs="$(/sbin/lvm vgscan | sed -n '/"/s/^.*"\([^'\'']*\)".*$/\1/p')"
+          if [ -n "${vgs}" ]; then
+              log_action_cont_msg "\nDeactivating volume groups:"
+              for vg in ${vgs}; do
+                  log_action_cont_msg " \"${vg}\""
+                  /sbin/lvm vgchange -a n ${vg} >/dev/null 2>&1
+              done
+          fi
+       fi
+    fi
+
     crypttab_foreach_entry _do_stop_callback
     log_action_end_msg 0
 }

That was how I dealt with the issue of Debian not supporting LVM on LUKS in 2023, I do not know if that is still required today.
Updating cryptsetup in the future will obviously clobber any changes you make.

Assuming you are using sysvinit...

Just (sudo if not root) for now to prevent apparmor startup at boot

sudo update-rc.d apparmor disable

Once your system is booting properly, turn it back on

sudo update-rc.d apparmor enable

The directory '/etc/udev/rules.d/' is for custom rules created by the administrator (not from an installed package).
I have no idea what that rule is for, if short, post its contents to this thread.

Always fix what is broken first before making 'enhancements'.

For now...you are being presented with the prompt

Ignore all further udev errors and enter nothing but and only the passphrase

Start by dealing with

temporarily suppress apparmor while you error trace.

Then fix

before rebooting.

NB: I never set up my systems to automount crypted mdraid (\home in your case) because of the nightmare when things go wrong.
My preference for sysvinit makes it trivial to boot runlevel 2 and providing that is error free automatically trigger runlevel 3 which then mounts the md also starting any daemons dependant on it.
When an error does occur the system still boots and root can login (over the network if headless) in runlevel 2 and repair the raid.

Trixie has forced dependency on newer versions of python modules which have dropped depreciated API's.
Of greater concern is the list of faults in trixie, prohibiting it's use in any mission critical role.

https://www.debian.org/releases/trixie/ … ssues.html

Credit to golinux for first posting of the link

@RedGreen925
I'm curious, why do you 'exec' when you are also '&' backgrounding ?