You might try the usual tricks, like issuing a sysrq unraw or sak at an unresponsive login prompt, booting into runlevel 1 or S from the kernel command line, or at a pinch just passing sulogin (or even just sh) as init to boot direct to a shell and bypass normal startup altogether.

The "recovery shell" you mention is probably either runlevel 1 (or the synonymous "single") as above, or an initrd shell you'll be dropped into if the root fs is unavailable. Pretty sure Devuan has those and always has.

The apparmor stuff is probably harmless, for some unfathomable reason it keeps getting pulled in unless you pin it, then complains because it's not configured properly. In all it's kind of difficult to diagnose something like this from here without seeing the boot process.

Personally I think Devuan should move to openrc as default, and pool init documentation (and service scripts) with Gentoo, Artix, Alpine and Nitrux (and maybe even GhostBSD, which is pretty cool as far as BSD desktops go ).
But that's just me. While it does still do what it should, I have no particular love of sysv, insserv or LSB.

Browsers aside, I prefer "If you not having problems with discourse, then you need to worry.", or simply "If you're using discourse, you have a problem."
That thing is the most obnoxious "forum" software I have ever had the misfortune to encounter.

Of course, and the link I dropped points to the Devuan package index.

$ apt show dma
Package: dma
Version: 0.13-1+b1
Priority: optional
Section: mail
Source: dma (0.13-1)
Maintainer: Arno Töll <arno@debian.org>
Installed-Size: 165 kB
Provides: mail-transport-agent
Depends: ucf (>= 0.28), debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.33), libssl3 (>= 3.0.0)
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
Homepage: https://github.com/corecode/dma
Tag: implemented-in::c, interface::daemon, mail::smtp, mail::transport-agent,
 protocol::smtp, protocol::ssl, role::program, works-with::mail
Download-Size: 52.1 kB
APT-Manual-Installed: yes
APT-Sources: http://deb.devuan.org/merged daedalus/main amd64 Packages
Description: lightweight mail transport agent

Sure:

deb http://deb.devuan.org/merged daedalus main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged daedalus-security main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged daedalus-updates main contrib non-free non-free-firmware
deb http://deb.devuan.org/merged daedalus-backports main contrib non-free non-free-firmware

The real elephant in this room is, is anyone in the know actually going to answer the OP's question:

Additionally:
[When] do users of Devuan stable need to convert? How will this be handled?

This:

Clearly doesn't apply to Devuan, and there is nothing in the Daedalus release notes. Do we actually have a plan yet, or are we still at the "futile arguments" stage?

Don't get me started on this idiotic HiDPI and "fractional scaling" nonsense everyone is so keen on these days (not least because it's the wayland "way").

We have DPI, a real physical property of the display device to base font scaling on, which would work just swimmingly if X didn't lie and always return 96DPI (which is a bug/regression) and GUI toolkits didn't ignore server DPI because of it.

But instead of patching the bug and fixing the mess of toolkits assuming buggy behaviour and doing their own thing, now we're hardcoding 96DPI all over the place (I'm looking at you, wayland and GTK) and adding expensive (and often blurry or unreliable) global scaling in the compositor...
So instead of selecting a preferred font size and automatically getting correct rendering for the connected display, the user gets fonts sized for an "average" display of 15 years ago and has to poke a "make it bigger" slider like a caveman until it doesn't look too horrible.
This, apparently, is progress.

Indeed, and that's my main problem with wayland (and systemd, and almost everything else Redhat-IBM is doing ATM).
It's not that the software is bad, it's the way it's being agressively pushed on users and downstream distributions regardless of whether it or they are ready, by creating dependencies and intentionally breaking compatibility in ways that effectively force the use of the entire RH software stack.

Sentiment to the effect of "this is you wakeup call" "drive adoption" "force users to..." "time is up" "get with the program" etc. are not difficult to find amongst the developers involved, and this further speaks to the idea that Redhat-IBM believes they control enough of GNU/Linux development to dictate terms to other projects, end-users, and the rest of the community.
This is obnoxious, it smacks of corporate interests, and flies in the face of the "bazaar" development model that gave us so much freedom of choice to begin with.

The console bell is something I find incredibly irritating, so while do I know how to kill it with fire I'm probably of rather less use when it comes to the opposite.

That said, (assuming we're talking about a real hardware pc-speaker here, not pc-speaker emulation) I'd probably start with going through the configuration items (inputrc / xset etc.) and potential permissions issues listed in the usual places. Most of it is biased towards eradicating the bell, but such advice should also work in reverse.

That the 'beep' command works suggests to me that your problem is likely either terminal configuration related, or something (e.g alsa or pulseaudio) is trying to redirect bell output to your sound card.
In the alsa case, IIRC that's controlled by e.g. SND_HDA_INPUT_BEEP and SND_HDA_INPUT_BEEP_MODE in the kernel config. As for pulse... Don't use, don't know, sorry.

Ed. Out of interest, does this beep?

#!/usr/bin/env python
"""Beep PC Speaker using Linux evdev API.

To make /dev/input/by-path/platform-pcspkr-event-spkr device available, run:

    root# modprobe pcspkr
"""
import ctypes
import math
import os
import time

EV_SND = 0x12  # linux/input-event-codes.h
SND_TONE = 0x2  # ditto
time_t = suseconds_t = ctypes.c_long

class Timeval(ctypes.Structure):
    _fields_ = [('tv_sec', time_t),       # seconds
                ('tv_usec', suseconds_t)] # microseconds

class InputEvent(ctypes.Structure):
    _fields_ = [('time', Timeval),
                ('type', ctypes.c_uint16),
                ('code', ctypes.c_uint16),
                ('value', ctypes.c_int32)]

frequency = 440  # Hz, A440 in ISO 16
device = "/dev/input/by-path/platform-pcspkr-event-spkr"
pcspkr_fd = os.open(device, os.O_WRONLY)  # root! + modprobe pcspkr
fsec, sec = math.modf(time.time())  # current time
ev = InputEvent(time=Timeval(tv_sec=int(sec), tv_usec=int(fsec * 1000000)),
                type=EV_SND,
                code=SND_TONE,
                value=frequency)
os.write(pcspkr_fd, ev)  # start beep
try:
    time.sleep(0.2)  # 200 milliseconds
finally:
    ev.value = 0  # stop
    os.write(pcspkr_fd, ev)

Not very much... At least in theory. Primarily the ability to have /usr be a separate partition (or network mount) not required to boot the system, which hasn't been a common configuration for several decades now.
In practice, it's a bunch of needless disruption and a whole lot of packaging and testing work to ensure there are no file collisions or other jank, for the sake of some RedHat "improvements" and the usual "systemd doesn't support that, so let's make sure nobody else can either".

Personally I'm going with "IDRGAF unless it breaks my system, but I'll switch when I'm good and ready and I'll be proper annoyed if anyone tries to force it down my throat."
For the record, that doesn't mean I don't think it's stupid. It's just the kind of stupid that (probably) won't set anything on fire if handled carefully.

Standard-issue plug for Gentoo's "Unavoidable if you're running systemd, otherwise here's a profile option and a migration script, do whatever you like with them" approach here.

You, me, and probably everyone else as well.

With all the hyperbole and shouting, I'd be surprised if anyone has the slightest clue what the OP's actual problem is... Some ill-defined hatred of 64bit (20-ish years too late)? Generalised railing against the inevitability of Andy and Bill's law?
Originally it sounded like some problem with xfce, but now? At least the thread is a mildly entertaining read. vOv

While it might be easier, I really have no idea what qbittorrent or appimages have to do with compiling transmission.
How is this even remotely relevant or helpful?

@jemadux: You are extremely unlikely to find all the third-party sources (and correct versions) transmission needs as Debian/Devuan packages, at least not for a bleeding-edge version that isn't in any repository.

Closer investigation would suggest that only the "Source code" tarballs are incomplete (likely autogenerated), and the .tar.xz archive (i.e. this) is in fact what you want. Or just pull from github directly as I already suggested.

Also, less gratuitous full-quoting would be nice.

Apt has been able to handle local files on the command line for some time now, dependency resolution and all.
The problem at hand (after fixing missing sources) however has nothing to do with apt, Debian, or Devuan, and everything to do with poor quality packaging of commercial software... As usual.

Try https://newsgroup.xnview.com/viewtopic.php?t=41533