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.

You should also point out that as it's github, it will require a Microsoft login for rising issues, and probably then also add that noone will want that.

It may depend on what you mean by "Devuan" and "support for".

Technically "Devuan" (as organisation) is merely this small group of people that publish the collection of packages that includes all debian packages except some. Those that require systemd have been forked where possible and they are maintained (by these people) towards providing relevant functionality without systemd; most are forked but a few end up just being excluded from the devuan repositories. Currently supported (i.e. maintained, built and published) architectures are amd64, arm64, armel, armhf, i386, riscv64 and ppc64el (all using debian's architecture labelling).

Though "Devuan" (as organisation) might also be understood to include the people that compose and publish filesystems and disk images that are installations of various kinds using devuan packages. Those works span a more limited range of architectures and they provide support (or not) individually for their published works. I'm aware of people having riscv64 installations of devuan packages but not of anyone publishing such for replication.

Now we

1. go to our fork of https://git.devuan.org/devuan/xorg-server.git

2. check out suites/unstable

3. use dpkg-checkbuilddeps as guide for installing build dependencies

4. build a local Xorg with debian/rules binary

5. temporary "install"  resulting debian/build/main/hw/xfree86/Xorg as /usr/lib/xorg/Xorg

6. perform a verification test

7. edit the code and repeat from d until the misbehaviour goes away without we adding some new misbehaviour

8. update the packaging and version and stuff

9. issue a merge request

10. wait while that gets merged, built and published by others

11. install the fixed version.

Easy Peasy

Good question, though not easy to answer. As I have some idea about the code flow, I can match (try to) it up with the log and in particular trace back from anomalous log entries. For Xorg logs you split it into the temporal strands broken by the times where the user has made a short pause in between the use case steps. Post#13 shows that clearly

Unfortunately Alverstone has hand edited the log before posting -- the log we see is not actually the log they got. But I believe that all log lines are included with their correct timestamps and only certain identifiers have been "mangle mapped" under an idea of protecting personal information.

On that assumption there's now enough for me to build a test case that should repeat the misbehaviour, with in particular the logs of #13 providing basis for log comparison.

The "bad" #13 log at timestamps 169.760--169.768 presents the setup for "the problem device" which appears to be a USB keyboard+mouse combo where after some extra logic event4 gets set up as a mouse data stream and the keyboard data stream setup gets postponed as a "virtual subdevice", at timestamps 169.812--169.812.

By the seatd calls, that uses input device with file descriptors 132.

At 174.228 the log starts showing the switch to VT 3, which in particular results in all input devices being "removed" from Xorg's internal data structures, that all their file descriptors are closed via seatd. Notably the device modules are not unloaded though.

In comparison, log good#13 shows the VT shift-away in log lines 104.675--104.744 with the same activity although logged differently. In particular that the logind log lines calls it "paused".

Next we can trace in the log that the "problem device" is unplugged and plugged back by virtue of Xorg handling the udev events while its VT is inactive. Thereafter the log (at bad#13: 192.148) represents the shift back and activation VT4 followed by (at bas#13:195.493) the Xorg termination.

The strand from bad#13:180.566--180.567 seem to represent the bug that the internal data structure discards the event4 handling and that the libinout module gets unloaded. That would result in that the subsequent VT entry does not re-establish event4 without the user again unplug/plug-in the device. The exact bug requires source review.

Notabley the log strand good#13: 160.359--160.414 where the device is plugged in while Xorg's VT is inactive doesn't present a failing attempt to aqire event4. Instead it gets "opened in paused state" that (in some way) avoids re-establsihing the "virtual sub device".

So, in short, it's a bit like reading the future in tea leaves

mmm enjoying a good laugh is a reality worth pursuing, I think

@T-A-P Can you please stop that useless vertical spacing... you just makes everything even more boring!