This was kind of convenient for me as I have very recently migrated to daedalus myself and hadn't yet set up bluetooth here. To do so, I did as follows:

# apt-get install --no-install-recommends alsa-utils blueman bluez-alsa-utils

That provides a virual soundcard named bluealsa for alsa, and this uses dbus to obtain the headphone "sink" from the bluetooth device management (actually bluez) with blueman as a handy GUI tool for operating the bluetooth devices.

bluez-alsa-utils unfortunately installs as if systemd would be around, so some additional hands-on is needed for registering the bluealsa dbus service. You need to add the following text file:

Then you run blueman as non-root user for the device management, to pair and connect the headphones. (Keep it running in the background, though if it works well it install a control button in the panel)

Note that you need the mac address for the headphones for playing to them. (E.g, after pairing you can bring up the "info" page for the headphones by right-clicking, and there select and copy the "Address" line for later pasting).

For testing this you may try the following (with your mac address rather than mine):

$ aplay -D bluealsa:30:21:DC:50:9E:89 /usr/share/sounds/alsa/Rear_Center.wav

Next, if you want to direct audio to bluealsa by default, you may state that in your ~/.asoundrc, eg:

pcm.!default headphones

pcm.headphones {
    type bluealsa
    device 30:21:DC:50:9E:89
    profile a2dp
}

There's a lot to be known about alsa configuration....

If "Installed Daedalus" actually means "dist-upgraded to Daedalus" there is the possibility that you overlooked adding the (new) non-free-firmware section onto the sources.list lines.

Other than that, I don't know much about nvidia cards.

You need firstly to install bluez. This package and it's sub packages handles the actual connectivity between the computer and the headphones. Conceptually bluez represents the computer endpoint for the "wireless wiring' to your headphones.

In addition to that, you need the pieces of software that links the sound system with the bluez device management. This part depends on which sound system you are using.

Plain alsa or pulsaudio are possibly the two main alternatives for audio setup, but there are others.

For plain alsa you would need the bluez-alsa-utils package which implements the "virtual soundcard" that plays to and records from bluethooth headsets. It will also need manual configuration changes to tell the sound system how to channel audio through it.

For pulsaudio you instead would need the pulsaudio-module-bluetooth package. Upon installation it updates the pulseaudio configuration to some extent but there might also still be additional hands-on needed. I no longer use pulsaudio though so someone else will need to guide you for that.

@fsmithred, your second user doesn't have access to graphics, and you also need to direct Xorg to the VT concerned as it otherwise will try to use "the next free", an action that requires root permission (or more specifically access to /dev/ttyN for VT N).

Thus, with graphics access, you might have success with startx -- :1 vt$(tty|tr -c -d '[0-9]')
That last bit is vtN where N is the number in the output of the tty command.

Everything that is available for a sources.list point is described in its "Packages" file that is downloaded to your computer with the "apt-get update" command. All the Packages files are held in /var/lib/apt/lists/. To download all daedalus packages you could do something like the following:

awk '$1=="Package:"{P=$2}$1=="Version:"{print P "=" $2}' \
    /var/lib/apt/lists/deb.devuan.org_merged_dists_daedalus_*_binary-amd64_Packages | \
   xargs -n1 apt-get download 

It's a lot.

Firstly you should confirm that the nvme module is duly included and loaded in the initrd.

If you choose the "generic" option for initramfs modules, the required modules would likely be included but it might still be necessary to mention them in /etc/initramfs-tools/modules to make sure they are loaded (in case auto-detection doesn't work). Check in your artix linux which modules are need.

1. If the hardware works with Debian 12 it should work with Devuan 5 since that's the same software apart from the squashing of the systemd infestation. You will need to analyse more in detail which software was used in the working setup and make sure the same software is used, possibly in later versions.

2. How come your nvme drive is not named /dev/nvmen0?

Apparently your machine runs multiple dhclient processes competing about the interfaces.

Which networking do you use? Do you use ifupdown (which primarily is configured with /etc/network/interfaces) or something else, or several?

Note that the updated Devuan daedalus installer ISO set 5.0.1 now also handles the use case of booting from CDROM on UEFI.

The issue indeed was that the boot loader got confused about the iso9660 block size (2k) differing from the expected block size (512) for the EFI filesystem. To fix that we forked syslinux, added a corrective patch and published to Devuan experimental. The patched software was next used for building the updated ISO set.

@yemuyin presumably the computer clock is off by 51.5 hours. You'll need to correct that.

@hunter0one, did you verify read-write access to the USB device node concerned?

Obviously you have read access but you do need write access right as well. Use e.g. lsusb to figure out which "bus id" it has, en then chech that /dev/bus/usb/xxx/yyy.

I guess you've confirmed file access mode for /dev/videoN .. you need rw I think.