Removing the launcher for that module was an especially asinine move, in a growing list of asinine moves from KDE of late. The justification apparently being to "get people to report bugs instead of working around them, we'll tell them how to find it if they need it"...
I recommend making a .desktop file / application menu entry for it for the future.
Other "hidden" kde things that may be of interest:
kdebugsettings
kcmshell6 kcm_qtquicksettings
kcmshell6 --list in general
qdbus6 org.kde.KWin /KWin org.kde.KWin.showDebugConsole (kwin debug console)

Do you actually have a (session) dbus instance running? How was it started?
The trick is that you want one session bus, and everything in your session to be using the same bus address.
So "DBUS_SESSION_BUS_ADDRESS,unix:path=/run/user/1000/bus" or whatever you are setting the session bus address to needs to be the same as what you passed to dbus-daemon when you started it.

I use OpenRC user services to start (and supervise) dbus-daemon explicitly, so I know that it was launched with '--address ${XDG_RUNTIME_DIR:-"/run/user/$(id -u)"}/bus'. This may not be the case in your setup, which is why I said "Something along the lines of" rather than "copy-paste this".
If you're using dbus-launch, you can a: Manually ensure DBUS_SESSION_BUS_ADDRESS is already set in the environment dbus-launch runs with (and set the same for anything that needs to connect to it) b: Make sure everything that needs to connect to the session bus inherits dbus-launch's environment (since it will set DBUS_SESSION_BUS_ADDRESS itself if it is empty) or c: Use dbus-update-activation-environment as EDX-0 described above.

When you launch applications with dbus-launch or dbus-run-session, you often end up creating a new dbus session just for that application - (so it will start, but it won't be able to do IPC with anything else), or in the case of something like hyprland, starting a session but not propagating the bus address to applications started later (usually because something, like a greeter or launcher, is stripping environment). Launching subsequent applications with dbus-run-session risks starting another isolated dbus session, and you end up  back in scenario 1.

Sounds good on paper, until you realise "ncurses like" means "doesn't actually use ncurses, instead reinvents it in zig". It's not packaged in Debian, and while there are ebuilds for Gentoo, that just makes needing to install the whole zig toolchain for a text box slightly less annoying.

I was getting dangerously close to doing that myself, but between gathering patches from not-dead forks and a couple of my own, I think I might have got tuigreet into a mostly usable state. It's still rust and it's still part of the "1200 crates" ecosystem, which is irritating, but at least that's a toolchain I already have installed for firefox & co.

Honestly, this is all in service of my biennial "can wayland completely replace X yet / can you comfortably run a desktop system without an xserver installed" investigation.
The answer is still "not really" (unless it's GNOME, maybe).

So, uhh, export the correct bus address? There are about 50 ways to set an environment variable system(or session)-wide.
Something along the lines of:

$ cat /etc/profile.d/zz-env-hacks.sh 

#!/bin/sh
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ]; then
    export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR:-"/run/user/$(id -u)"}/bus"
fi

if [ -z "$XDG_RUNTIME_DIR" ]; then
    export XDG_RUNTIME_DIR="/run/user/$(id -u)"
    if [ ! -d "$XDG_RUNTIME_DIR" ]; then
        mkdir -p "$XDG_RUNTIME_DIR"
        chmod 700 "$XDG_RUNTIME_DIR"
    fi
fi

(or the relevant part thereof) will probably do it, though I don't have a Debian/Devuan install with a GUI to confirm.
Something similar could also go in your users shell profile or some other script that is sourced during hyperland (which I also don't use) startup of course.

The list of packages this byzantine "installer" looks for (and tries to install, including tampering with sources.list to add unstable on some distros *barf*) can be found in installer/distros.dat after unpacking the .run file.
However, since it has no explicit entries for any version of "devuan" and the OP didn't bother to tell us which options were passed to the internal install script or provide the output in --debug mode (which likely would have told them exactly what it failed to find and why), I suppose we'll all have to guess.

So much for, and I reiterate with more emphasis:

@deepforest If you're going to install software from outside the repos, on a distro that upstream doesn't even claim to support (note Debian being "present in supported distros" does not mean it will detect Devuan successfully), you get to keep all the pieces. Even if you get this to install, it will louse up your system with untracked files in unusual locations, just as the wiki warns.

We might be inclined to help, but if you want to do unsupported, not-recommended, oft-warned-against things to your system, you need to put in more effort than "Why do not want to install" - starting with at least a cursory investigation of how the installer works and gathering useful debug output.
This is not Windows, we do not run executable installers from manufacturer websites. Installing software from the stable repositories is "easy mode", running (or porting from) unstable, building from source, or using third-party scripts is "expert mode" and comes with the expectation that you are able and willing to put energy into solving your own problems.

Riiight, so, people not wanting to do your homework for you or run unknown install scripts for software they don't need is "lazy"... Guess I'll be "lazy" too then, good luck.

foo-devel is a RedHat thing, the script knows nothing about Devuan and it's a near-certainty that it's just misdetecting the distro... Which, again, had deepforest provided the output of hplip-install --debug we would know rather than have to take educated guesses at.

I mean, it took me all of about a minute to extract the install script and see it had a debug flag, surely Mr. "runs unstable and installs things from SourceForge" could have done that too

*Aside, if anyone is wondering why I'm not spoon-feeding the answer (besides just generally being a bastard OFC), it's right here in the attitude:

Why would anyone here know (or care) about some random executable "installer"? As already stated (more than once) the packages in the repos work fine, and that's what people who don't want a broken system use.
If you really want to know, ask whoever provided that .run file - or extract it and look at whatever pre-install checks it's doing yourself, since it's probably just a bunch of shell concatenated with a compressed archive. My bet is that it's looking for Ubuntu package names or specific versions, but that's for you to determine if you insist on installing "fresh" software in weird formats.

cdemu works fine without systemd, it's only needed for dbus activation of the daemon - which you can do any way you would usually start a user daemon.
If the debian package (wherever you got it, since it's not in the stable repos AFAIK) has a depend on systemd, remove it and rebuild the package... Or just install cdemu from source to begin with.

And? You're running unstable with a bleeding-edge kernel and ancient out-of tree proprietary drivers. Did you expect that not to break?

Either patch the nvidia nonsense yourself or wait for Debian to do so. Nvidia probably never will, they're regularly behind on kernel kernel changes with their current driver, let alone one released over six years ago.

The only "flaw" here is the usual confusion regarding partitions, filesystems, and the x86 boot process.
isohybrid is a hack, and writing an iso image to a USB device does not create a normal partition table - that's the whole point, to be bootable from optical media it needs to look exactly like a CD to the BIOS routines.
CDs don't have partitions or an MBR, the raw iso9660 filesystem starts at sector 17 and the space before that is an "unused" system area to be used by [insert system-specific boot hackery here] - often syslinux and/or a partition table defining an ESP for UEFI in a bootable GNU/Linux image.
Thus what you usually end up with is a disk where the partition table does not reflect reality, intentionally, the first few reserved sectors contain an el-torito CD boosector, an MBR, a GPT, syslinux, or some combination of those, and the whole mess appears to be a simple iso filesystem to anything that doesn't look too hard.

All this will confuse traditional partitioning tools, especially if the device was previously partitioned and whatever you used to write the image didn't remove the existing partition table (and backup), RAID headers, or whatever else was on there.
It's not a "flaw" in parted, iso9660 on anything but optical media was just never supposed to be a thing and the spec for what should be at the start of the disk is intentionally vague.

Ed. Also, this.

Having a bootable iso image and other filesystems on one device simultaneously is even more of a hack, and generally requires installing a (second) bootloader that can chainload an iso9660 [insert system-specific hackery here] boot record or handle loop-mounting the filesystem and locating the kernel image itself... This is why grub-imageboot and ventoy exist, and it's also why they are so complicated and unreliable.

On the OP: Make sure the device is properly clean, first with a (fast) tool like wipefs, and if that doesn't do it, nuke the entire device with a (slow) cp or dd from /dev/zero. Check the latter can write the entire expected size of the device - if it can't then what you have is likely a hardware problem.
As for "takes ~2s", you're probably just seeing write-cache. Try oflag=direct to bypass kernel caches (see dd manpage).

That's okay golinux, go back to sleep. You weren't doing anything useful around here anyway.

Not really, though plasma-pa is better integrated than kmix and IIRC the kde-standard metapackage pulls plasma-pa or kmix, with preference to the former.
ALSA not working is likely one of the usual suspects (e.g. muted master PCM or wrong default card), but OP was futzing with pipewire and close to a reasonable solution, so that's what I rolled with. (also an excuse to taunt gotard OFC, no reason to miss one of those)

You ran the first as root and the second as a user, so environment is obviously going to be different. If you want to know why you got "cannot open display:", test under the same conditions you got "cannot open display:".

Almost certainly an xdg .desktop file dropped by the gparted package (dpkg -L gparted) and looking in it will tell you which command is being called. This is GNU/Linux, there is no "standard" anything and not everyone runs XFCE.

Ed. Anyhow, this is all irrelevant. Your polkit install doesn't work:

Do you have an appropriate (GUI) agent installed (e.g. xfce-polkit)?

Package: polkit-1-auth-agent
State: not a real package
Provided by: cinnamon (6.4.10-2), gnome-flashback (3.56.0-1), gnome-shell (48.7-0+deb13u2), lxpolkit (0.5.6-2), lxqt-policykit (2.1.0-1), mate-polkit (1.26.1-4+b1), phosh
             (0.46.0-3), polkit-kde-agent-1 (4:6.3.6-1), ukui-polkit (1.2.2.2-1.1+b1), xfce-polkit (0.3+v20220621-3~excalibur1)

Also see fsmithred's comment WRT pinentry above.

The pcmanfm package recommends lxpolkit or polkit-1-auth-agent, xfe does not. If nothing else you have installed depends on polkit-1-auth-agent, it's possible you (auto)removed it.