Thanks. It would be due to firefox, or a plugin.

The particular request is noted as a security issue for "punbb", from 2011, but not a concern for this forum. The point is rather that there is no reason for anyone to attempt an unserviceable URL, and therefore anyone doing so is deemed to be of dubious intention. There have been some 7000 such the last month.

The lockout is at network level, where it gains a plain text (no SSL) response, with an advice of a course of action to take by anyone who, like in this case, is unjustly caught. But, your method is fine too.

ok. Why did you install iptables from backports?

Seems odd; something must have gone wrong with your upgrade.

a) what's your sources.list (and sources.list.d/*) ?

b) what's your pin preferences

c) what does "apt-get -s dist-upgrade" say (the "-s" means "simulate", i.e., "just analyze what would be done, but don't do it")

It might not work well given that the C-A-Del handler command processing is terminated together with lightdm. You will almost certainly need to spawn a separate script for the actions, and perhaps that it also needs to escape the user cgroups, as it might otherwise be killed together with lightdm anyhow. Apart from that, it's easy

Though, the return to X might then also need attention; or does X start happily on tty7 while it's in use by a running getty?

I'd rather suggest that utilizing runlevels (and init) is the "simple" approach.

EDIT: or, it might be possible to shift to, say, tty1 instead, and then not start getty for tty7 at all. The "simpler" line would then be:

sudo chvt 1 ; sudo lightdm stop

I.e., first shift to tty1, then kill lightdm (and the C-A-Del handling). The return to X would be the command

$ sudo lightdm start

If that works, I would call it simpler

As the dongle behaves in your Debian and mis-behaves in your Devuan, there must be some difference in the code involved, obviously. The start point for tracking that down would be in the versions: of the kernels, of the ath modules and firmwares, of the hotplug handlers, etc. Perhaps you can make a table. Then it would be possible to experiment by aligning versions where possible, and by inspecting the differences more exactly otherwise.

btw, there is also the iw tool (from wireless-tools) for

# iw dev wlan0 scan

Rumours has it that sometimes that works where iwlist fails.

Right, the kernel uses the ec and button drivers for dealing with the lid switch. In my lsmod I have a button module, used by nouveau and i915. I don't have an  ec module, so that's probably built-in, and maybe so is the button module for you(?)
(my kernel is linux-image-4.9.0-5-amd64 version 4.9.65-3+deb9u2 from ascii-security)

If button is built-in, blacklisting is not an option, and according to modinfo button there are only the two parameters lid_report_interval and lid_init_state, which don't appear to be useful here.

But, maybe you have a thinkpad_acpi module, or some other module, that registers as button driver? A quick glance at
modinfo $(lsmod | sed 's/\s.*//') might lead to something...

The other end of the chain is at X, and perhaps installing that xserver-xorg-input-evdev would lead to something...

Maybe you have xserver-xorg-input-evdev installed, and it grabs the lid switch as input device for X?
Check /var/log/Xorg.0.log where it says Lid Switch.

On my keyboard, ctrl-- (control minus) zooms in and ctrl-+ (control plus) zooms out. This is surf2=2.0-9 from (current) ascii.

If it's slim you could possibly achieve auto-login by editing /etc/slim.conf, and then only change #default_user devuan to be default_user caluser (i.e., remove the # and choose user name wisely), as well as changing #auto_login no to be auto_login yes (i.e., remove the # and change to  yes).

To explore deeper, you might want to try

# PM_DEBUG=true pm-suspend >& LOG 

Reviewing that LOG file might tell you something about why suspending fails.

From the log snippets, it looks to me to be an X issue, that after launch, X says it's ready (signals) before it's actually waiting for connections. So sometimes it fails when the connection attempt is made. This causes lightdm to try another launch, but the second launch fails before giving any signal. So now lightdm is awaiting the signal from X, while the first X is sitting there waiting for connections.

If you would have a side entrance (eg ssh) ot the system you could check up if it might be this situation.

But I don't really know what to do about it. If any part of this is scripted, eg lightdm, it might be possible to insert a delay between receiving the ready signal and attempting a connection. Or something.

It looks like it takes every space character as a delimiter, whereas awk sees space sequences as delimiting units.