I don't think alsa's use case modelling comes into play, but rather, possibly, there's some residue effects dealing with 48000 Hz v.s. 44100 HZ sampling rates differently in different programs. The "modern" default is 48000 Hz while the "traditional" default is 44100 Hz. It may be possible that your soundcard gets confused by that; if different applications compete about the soundcard configuration.

If that's the case, the remedy should be to ensure that the "default" PCM playback path (here "default" is the name of the targeted PCM, which is used by applications by default) to end in "plughw" rather than "hw" since that includes software to manage sampling rate translations.

Just a friendly reminer that It's Never Too Early to stop using Microsoft's github

In short I think you can reuse the debian boot setup and just replace the root filesystem.

If your debian system is on an SD-card, then you should copy that whole card (including the MBR sectors), then mount the root filesystem partition (of the copy) on another computer so as to replace the whole filesystem with a devuan/arm64 root filesystem. The latter you can set up using debootstrap, and the best is to just make a "minbase" variant; then you would install the rest oer the network on the target after bootup.

EDIT: BUT do remeber to keep the few extra files in /boot (boot.scr and the dtb tree), AND you should also make sure to keep the 99-uboot script (/etc/initramfs/post-update.d/99-uboot) that makes an uImage of the initrd as hook for update-initramfs....  it requires that you install u-boot-tools and device-tree-compiler. You may also need a light hand-edit of that script which otherwise will want to source enironment settings that are not needed for the function of the script.

then just change it back to http.

btw there are "code" tags to use for enclosing log text.

One might also find grub documentation on the Internet if not installed.

You should verify that the installation sets up the network properly.
One method for that is to:
1. start the installation, and advance to where it is asking for root password
2. then press ctrl-alt-f2 so as to shift to get a shell prompt in VT2
3. type: ping -c 1 deb.devuan.org
which should respond with success.

If not, then the network is not set up for some reason, and that would also be the reason for not connecting to the repository host(s).

Please show the file in that failing use case, when you set RESUME=none and run into the complaint when running update-initramfs.

does it wake up with ctrl-alt-7 ?

if so, which init system do you use? and does it start getty on tty1-6 ?

no! Don't destroy the loopback interface configuration!

Use "man interfaces"

EDIT. Btw the kernel will install an adapter for the wireless card if it has the software to do so. You may use "rfkill" to software-block the adapter, and then no networking will be configured for it. However, you will need that "rfkill" to happen early on, so will probably need to add it into initrd's init scripts. And that is a second cloud of knowledge to gain, perhaps starting with "man initramfs-tools".

The limits on post editing is a dev1galaxy feature introduced by myself in late 2020.

The forum code started with FluxBB 1.5 a couple of years ago, and has then been subject to a few local adaptions (such as "spammer barrier" in 2015, "javascript reduction" in 2017, "improved i18n" in 2019, "trolling barrier" in 2020, "oath login" (failed) in 2022, "styling refresh" in 2023).

Today it sits there in full beauty and perfection, and just waiting for the next one or two responsible code caretakers. Please drop in to #devuan-dev at libera.chat to discuss how to make that a role of yours.

Well, I'd say those scripts are the right ones so adding "sleep 5" early on but not at the very top in them would be the test.
1. add a new line with "sleep 5"
2. run "update-initramfs -u -k all"
3. reboot
If a process race is happening and the cause for the issue, then those "sleep" should delay the decryption handshake enough to allow udev to do its thing beforehand.

It may be worth to consider that the software used for entering a decryption password prior to boot has nothing to do with the kernel or with anything on the encrypted part of the disk.