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?

Note that those are two quite different machine emulations. You should both add the -serial mon:stdio argument pair so that you can operate the qemu monitor and inspect the emulation. The monitor is then connected to stdin/out of the temrinal where you typed the qemu-system-x86_64 ... command, and you will "wake it up" by the C-A c sequence, which gives you the qemu monitor prompt.

At there, @dice would see, by the info block command, that the emulated hardware includes a disk (hd0), a cdrom (cd0) without media, a floppy reader (fd0) without media and an sd card drive (sd0) without media, whereas @fsmithred would instead not see any hard disk, but cd0 with media and fd0 and sd0 without media.

Going back to to OP case, I am guessing that the hardware seen by that boot is as per @dice, which would mean that the boot USB gets set up as the primary disk rather than as a cdrom (which the live-boot expects).

Yes, that's right.

Basically I suspect that that kernel sees a slightly different device enumeation than the live-boot preparation code expected, and wrote in into the initrd boot procedure.

Well, you should do those commands at the (initramfs) prompt rather.

Normally you'd need root permissions to put scripts there, and it will, if executable, run by cron as root.

However, the PATH is a common cause of issues, see e.g. man 5 crontab.