So apparently the anacron start/stop script gets invoked every hour as it should, but it fails to perform.

Add set -x on a line after your added date ... in /etc/init.d/anacron, and then wait for next invocation which now logs the whole script execution to /tmp/WTF. This in particular should have the line:

+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s

Seeing that to be so you would next try to force run the weekly scripts again. First ensure any previous run has completed, with

pgrep -a run-parts

returning nothing, and then use

run-parts --verbose /etc/cron.weekly

to see the new, forced weekly run happening.

Good. As you might know, anacron is supposed to provide the extended cron function to make sure that the regular scripts are run even if the machine happens to be down at the nominal trigger time. Since the scripts are not run it is possible that this "chain of control" is broken; that cron fails to run anacron or that anacron fails to run the script(s).

The running of anacron is typically set up using the sysvinit start/stop script, once initially at  boot up, and then regularly by cron with the schedule contol script /etc/cron.d/anacron. Afaict looking at my such script, it includes the particual misfeature of not running anacron imperatively but rather making this dependent on the absence of something. (A small-brain idea appearing as attempted solution to cater for a range of possible installation sites other than this one, but not bad enough for the effort of forking the package)

So, if that something is present then your set up does not run anacron as it should and consequently your weekly script won't be run "automatically". Similarly the boot up run of the script only happens at boot up if it's set up so.

If the preconditions for the regular run/start of anacron are there, the next point of call would be to review and confirm anacron local configuration, at both /etc/anacrontab and /etc/default/anacron. And for debugging purposes also add/change the start/stop script so that it makes some output to, say, /tmp/WTF (eg a date stamp) whenever it's run. Further, to speed up the testing cycle you might set it up for daily trimming rather than weekly since the auto-magic is supposedly the same for that (as configured in the typical installed /etc/anacrontab).

Create a file named /etc/modprobe.d/iwlwifi.conf with content

options enable_ini=N

See man modprobe.d for details.
(That man page belongs to the kmod package, which may and might not be installed)

🤦

Did you try using the USB "address"? The above example shows bus 2 device 7 funciton 0 (well, the last is not shown but my guess).

There's also the possibillity that the filenames are "urlencoded" by the file manager. It would mean that spaces have been replaced with "%20" (and a bit more).

You might try adding the following function:

urldecode() {
    bash -c "printf '%b' '$(echo "$1" | sed 's|%%| |g;s|%|\\x|g;s| |%|g')'"
}

to your /bin/sh script, and then use

convert "$(urldecode $1)" ...

TL;DR; In detail, that urldecode function for dash processes its given argument with sed to replace all %NN with \xNN except for occurrences  of %% which instead are replaced with single %. The resulting string is printed with bash printf using the %b format which makes all \xNN into characters of hexadecimal ASCII code NN.

Note that the sed processing uses space temporarily to make the %%-to-% translation bypass the  %NN-to-\xNN translation. It therefore misbehaves for an input that already has space characters.

That's good information. Only the s* were interesting and in particular the sda* and sdb* entries which are adapters for SATA devices and their partitions. Apparently there is one "drive", sda, with 4 partitions and another, sdb, with 1 partition.

This kind of presents the same hardware picture as your post #34 execpt that it has sda4 instead of sda6.

That difference is probably the cause of your problem... and now we need @fsmithred to draw conclusions

No worries. If you have a camera nearby you could take a picture and then refer to that...

Only those starting with "s" to begin with.

Would you mind reporting what ls /dev/ shows at the (initramfs) prompt.

Thanks. Maybe the support team has improved the feature beyond useful again... I'll have a word with them...

EDIT: there is the possibility the feature has just appeared. Perhaps you, @Altoid, could give it a try.

The steps for a bug report are almost as simple as your fixing of that file:

1. find out which package is concerned (unattended-upgrades)

2. find out which version of that package you'r using (1.11.2)

3. send an email to submit@devuan.org with a useful subject, and the body starting "formally" with 2 lines:

   Package: unattended-upgrades
   Version: 1.11.2

   then followed by a polite and useful treatise outlining the issue and preferrably including a patch that resolves it.

In this particular case, the "bug" is lack of maintaner effort to upgrade the fork of unattended-upgrades. Therefore beowulf got committed with the debian package version.

Your patch will go part of the way towards upgrading the forked package, which also needs any other changes since the last fork version, 0.93.1+vua2.0, including any adaption to the current package building pipline.

As it happens, the maintainer role for that forked package is currently vacant.

Maybe there are some dangling links in some /dev/disk/by-* directory?