Update:

Before opening it up, I decided to have a forensic look at the failed USB stick.

Always reported in dmesg as a Kingston DataTraveler 2.0 device, after going south it was reported as a GENERIC USB Mass Storage device, but there was also idVendor and idProduct data which I had not had a close look at.

--- snip ---
[12061.088773] usb 2-1.3: new high-speed USB device number 18 using xhci_hcd
[12061.216524] usb 2-1.3: New USB device found, idVendor=0c76, idProduct=0005, bcdDevice= 1.00
[12061.216531] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[12061.216535] usb 2-1.3: Product: USB Mass Storage
[12061.216538] usb 2-1.3: Manufacturer: GENERIC
[12061.221201] usb-storage 2-1.3:1.0: USB Mass Storage device detected
[12061.221381] scsi host8: usb-storage 2-1.3:1.0
[12062.249584] scsi 8:0:0:0: Direct-Access     GENERIC  USB Mass Storage 1.00 PQ: 0 ANSI: 4 CCS
[12062.249852] scsi 8:0:0:0: Attached scsi generic sg6 type 0
[12062.250232] sd 8:0:0:0: [sdg] Media removed, stopped polling
[12062.250651] sd 8:0:0:0: [sdg] Attached SCSI removable disk
--- snip ---

According to devicehunt.com:

Not Kingston hardware.
Or so it would seem.

Unfortunately I don't have a complete dmesg printout for the USB stick before it failed, so I cannot say if it was reported with the proper id* codes but I am absolutely sure that it was reported as a Kingston DataTraveler 2.0 device and these should have been idVendor=0951, idProduct=1665.

So there may be a good chance that the dead USB stick may have not been a genuine Kingston device, hence its early? demise.
All I can say for it is that it worked perfectly well for many years.

Best,

A.

Update

@ralph.ronnquist

I went through the whole process again, exactly as detailed in my previous post.
As before, every part of the installer priming process worked exactly as you said it would, the result being as reported.

The only differences were that this time I used another (smaller) *.iso file (devuan_chimaera_4.0.0_amd64_netinstall.iso) and the target was the 4GB SDCard in a USB/SDCard adapter.

The installer was burned to the 8Gb Kingston DataTraveller 2.0 stick to risk only the low capacity SD card in case things went awry again.
The target SDCard was previously cleared, repatitioned and formatted to EXT-4 with the filesystem checked via gparted on my box.   

It was interesting to see that the EFI partition for this *.iso file is only 754 KB, a sharp contrast with the one in the daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso which has grown to a huge 23 MB.

Which begs the question: bloated by over 30X and on account of exactly what?

---

With everything as expected ...

    The Kingston DataTraveller 2.0 stick SD card, as listed by disks:

---
    Partition 1
    Size: 390 MB (390070272 bytes)
    Contents: ISO 9660 (version Joliet Extension) — Mounted at /media/groucho/Devuan 4.0
    Device: /dev/sdc1
    Partition Type: 0x00 (bootable)

    Partition 2
    Size: 754 KB -- 25 KB
    Contents: FAT (16-bit version) —  Mounted at /media/groucho/7E06-DA56
    Device: /dev/sdc2
    UUID: 7E06-DA56
    Partition Type: W95 FAT32 (LBA)

    Free Space: 3.4 GB

    Success:
    Partition 1 has retained its ISO9660 signature and Devuan 4.0 label.
---

... I went ahead with the installation as before, taking the usual precautions (*.iso file SHA256SUM and installation media check).
Everything worked as expected but the installer (as every other time) did not write GRUB where it was pointed to.

So I rebooted my box with the installer, dropped into rescue mode and not without some trepidation, installed GRUB to the target SDCard.

This time it worked.  8^)
Thank you ralph.ronnquist !

I was able to boot into a minimal Devuan Chimaera from which I now need to weed out all unnecessary applications and files.

Comments

I have no way of knowing what caused the sudden death of my 16Gb Kingston DataTraveller 2.0 (as described in another post).
It could could well be that it had been written to just one to many times.
Happens.

That said, the 8Gb Kingston DataTraveller 2.0 I used at the installer media this time has been in use for at least two/three years longer and it is still going strong.

One thing I can say is that the Debian installer in use at the moment by Devuan is not fit for purpose.
At least not for installing to a USB stick from a non-UEFI box to be used in a non-UEFI box.

Granted, mine may be a bit of a corner case: a user with a ca. 2007 Sun Ultra 24 WS which works perfectly well and does not have UEFI.
And absolutely no need for any forseeable hardware upgrades, save maybe a monitor or a drive.

This thread has had almost 900 views and no one has had much to say about the specifics exposed in it, so it would seem that I am indeed in a corner.

I cannot say for sure that this happens with every Devuan installer *.iso as I decided to use an older one because of its smaller size and the smaller size of the installation.

ie:
Devuan Chimaera netinstall *.iso: 372.00 MB - UEFI installer: 00.754 MB
Devuan Daedalus netinstall *.iso: 477.80 MB - UEFI installer:  23.00  MB

30X more code has been added to the UEFI partition on the road between Chimaera and Daedalus.

Does anyone really know exactly what all that added code does?

Today it is a 'bug' preventing a non-UEFI installation in a USB stick with a lot of hoops to jump through.
Tomorrow it may well be another 'bug' preventing a non-UEFI installation on a hard drive without certain 'characteristics'.
From there to not being able to install Linux on a non-UEFI box there is just a bit more MB of bloat in the installer's UEFI partition.

My sincere thanks to ralph.ronnquist for his knowledge (and patience) both of which are greatly appreciated.

Best,

A.

Nice way to generate landfill.
And force compliance.

The USB stick I used as the installation target had been previously partitioned and formatted on my main Daedalus box using gparted.

To do so, I first deleted all previous partitions by first formatting them as cleared then deleting them and creating a new ms-dos partiton table prior to partitioning and formatting as required. ie: / and an extended partition with a logical /home and /swap.

/ and /home filesystems were checked and passed.

So the installer had no hand in all that, on installation I chose both the drive and the partitions to be used.

I'm sorry, you lost me there.

Use the installer to partition and format the target SDCard?

I recall having used the dead Kingston USB stick as a boot disk (no EFI) at some time or another.
No problem.

Thanks for the quick reply.

Best,

A.

You could check that by trying again with the first card but then make sure to create a DOS table on it before partitioning. (Use expert mode with activated lowest possible priority level, or perhaps use ctrl-f2 shell and fdisk)

There are also usb sticks that don't support boot setup, but they are rare.

No.

But it seems that I have not expressed myself correctly.
My apologies.

The installer USB is a 4Gb SD Card using a USB/SDCard adapter.
Works without issues.

The destination USB stick is a Kingston DataTraveller 16Gb USB2.0 which was ID'd as such by the installer all through the installation process, the last instance being when I selected it as the destination for GRUB.

Every part of the installer (ie: the 4GB SDCard) priming process worked exactly as you said it would, the result being as reported in a previous post:

The installer (ie: the 4GB SDCard) booted exactly as expected, passed the integrity check and went through the entire process without any issue whatsoever.

I have another one of these, a Kingston DataTraveller 8GB USB 2.0 stick I could try this out with or maybe another 4Gb SDCard and use the Kingston as the installer media.

It could well be that the previous Kingston USB stick failed because it was at EOL.
Or not, cannot say.

Let me know what you think.

Best,

A.

An incredibly accurate description of what transpired.

After, clearing and reformatting a 14Gb USB stick, I booted the installer and after selecting language, keyboard and checking the installation media, continued with no issues.

Once the installation was finished, I rebooted my box and F8'ed my way into the boot menu where I selected the USB stick to boot from.

I felt something was not right when the boot menu listed the USB stick as 'Generic USB Mass Storage' instead of 'Kingston DataTraveller 2.0'.
And wrong it was: my box did not boot into the system installed on the USB stick but into its own system.
ie: no OS by the BIOS

"No matter, we've been here before.
I'll just boot into rescue, install GRUB and see what happens" I said to myself.

File manager showed me nothing so I checked with dmesg and there is was:

[  ] usb 4-1.3: new high-speed USB device number 4 using xhci_hcd
[  ] usb 4-1.3: New USB device found, idVendor=0c76, idProduct=0005, bcdDevice= 1.00
[  ] usb 4-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  ] usb 4-1.3: Product: USB Mass Storage
[  ] usb 4-1.3: Manufacturer: GENERIC 
[  ] usb-storage 4-1.3:1.0: USB Mass Storage device detected
[  ] scsi host7: usb-storage 4-1.3:1.0
[  ] scsi 7:0:0:0: Direct-Access     GENERIC  USB Mass Storage 1.00 PQ: 0 ANSI: 4 CCS
[  ] sd 7:0:0:0: Attached scsi generic sg2 type 0
[  ] sd 7:0:0:0: [sdc] Media removed, stopped polling        
[  ] sd 7:0:0:0: [sdc] Attached SCSI removable disk

But the 'Media removed' bit did not look good.

I then checked with fdisk ...

# fdisk /dev/sdc -l
fdisk: cannot open /dev/sdc: No medium found
# 

... and with blkid:

# blkid | grep sdc
# 

gparted does not register /dev/sdc and disks sees it as No Media.

I'd say the installer got angry and nuked the USB stick.

No Media is what I get from disks when I plug in a USB/SD Card adapter with no card inserted.

A USB/SD Card adapter with no card inserted gets the same response from dmesg and fdisk as what I am getting with the USB stick.

It is important to note that the installaton started and continued till the end without issues, selecting the USB stick as destination (/dev/sdc) for GRUB which was correctly identified as 'Kingston DataTraveller 2.0'.

So up to that point, things were looking quite normal.

---
Something is definitely wrong with the installer, the worst that should have happened is that the installation failed.
What has to be done to nuke a USB stick in this manner?

I'll see what testdisk says.

Any ideas?

Best,

A.

Update

Right.

# dd if=/media/storage/isos/daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso of=/dev/sdc skip=1 seek=1 conv=notrunc
978559+0 records in
978559+0 records out
501022208 bytes (501 MB, 478 MiB) copied, 183.526 s, 2.7 MB/s
#

The SD card, as listed by disks:

Partition 1
Size: 478 MB (478150656 bytes)
Contents: ISO 9660 (version Joliet Extension) — Mounted at /media/groucho/DEVUAN501
Device: /dev/sdc1
Partition Type: 0x00 (bootable)

Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdc2
UUID: FAE4-C64A
Partition Type: W95 FAT32 (LBA)

Free Space: 3.4 GB

Success:
Partition 1 has retained its ISO9660 signature and DEVUAN501 label.
Thank you for that.

Now to see if the installer works as expected.
ie: instead of assuming that my box has a UEFI BIOS and screwing everything up in the process.

Best,

A.

If I told you about the things I have imagined that were not there ...

No matter, everything is in order and fdisk does not give us another issue to tangle with.

Let me see if I have this right:

1. burn the *.iso image to the SD card as before.
2. change the partition table as per your instructions.
3. do this ...

dd if=devuan_daedalus_5.0.1_amd64_netinstall.iso of=/dev/sdg skip=1 seek=1 conv=notrunc

... which will restore the ISO9660 signature and DEVUAN501 label to the first partition so that disks will show this ...

Partition 1
Size: 478 MB (478150656 bytes)
Contents: ISO 9660 (version Joliet Extension) — Mounted at /media/groucho/DEVUAN501
Device: /dev/sdg1
Partition Type: 0x00 (bootable)

... and make it visible to the installer.

All that plus the renaming the EFI directories / files so that the it will work (?) properly.

Absolutely no need to apologise for anything.
You have been nothing but helpful and patient.

Confusing and convoluted seems to be the crap Debian installer which should work as expected but does not.
Probably by design more than by incompetence, but that is just me being overy sceptical.

I'll try to get this done today and report back.

Once again, thank you for your help with this.

Best,

A.

To make it work, you'll rather have to "be clever" and restore the disk image apart from the first sector after having changed the partition table. E.g.

dd if=devuan_daedalus_5.0.1_amd64_netinstall.iso of=/dev/sdg skip=1 seek=1 conv=notrunc

The partition table is really just the last 64 bytes of the first secor, and the bytes before that have not been changed by fdisk. Some bytes in some later sectors have changed though, which amounts to losing the label, The suggested copying will restore those without restoring the partition table.

I apologise for making this so confusing and convoluted.

Yes, and with the same fdisk version.

Yes ... 8^°

It got remounted when I unmounted, ejected and inserted it again.
Did not notice.

But then, I think the only partition mounted was Partition 2.
As seen by disks:   <- gparted does not reveal it

---
Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: EFI (FAT-12/16/32)
---

The partition we were editing was not mounted. (IIRC)
I think that if it had been mounted fdisk would have printed out a warning.

Indeed, fdisk says so.
But then it also says 'probably'.

Of course.
I saw the error right after posting so I rewrote the *.iso file and reedited the partition like before.

The end result was the same.

---

# blkid /dev/sdg
/dev/sdg: PTUUID="3488f3e0" PTTYPE="dos"
# 
# blkid /dev/sdg1
/dev/sdg1: PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
# 
# blkid /dev/sdg2
/dev/sdg2: SEC_TYPE="msdos" UUID="FAE4-C64A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3488f3e0-02"
# 
# blkid /dev/sdg3
/dev/sdg3: PARTUUID="3488f3e0-03"
# 

What could / would prevent fdisk to make good on its warning?

Thanks for your input.

Best,

A.

Sorry for the delay, I re-did the testing as the SD card had been used in another test.

Note:
My Daedalus fdisk version is 2.38.1-5+deb12u1devuan1

Here it is, from the start:

----

Kingston 4.0GB SD Card
Formatted as 'Cleared'

Listed by gparted:
Size: 3.64 GiB
File system: unallocated

Partition
Path: unallocated    First sector:  0
                    Last sector:   7626751
                    Total sectors: 7626752
Listed by disks:
Size: 3.9 GB (3904897024 bytes)
Contents: 3.9 GB (3904897024 bytes)
Device: 3.9 GB (3904897024 bytes)

---

Writing *.iso image to SD card:

# dd if=/media/storage/isos/daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso of=/dev/sdg
978560+0 records in
978560+0 records out
501022720 bytes (501 MB, 478 MiB) copied, 228.066 s, 2.2 MB/s
#

Detected by dmesg:

$ sudo dmesg
--- snip ---
[ ] usb 6-6: new high-speed USB device number 7 using ehci-pci
[ ] usb 6-6: New USB device found, idVendor=14cd, idProduct=125d, bcdDevice= 1.00
[ ] usb 6-6: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ ] usb 6-6: Product: Mass Storage Device
[ ] usb 6-6: Manufacturer: Generic
[ ] usb 6-6: SerialNumber: 125D20140310
[ ] usb-storage 6-6:1.0: USB Mass Storage device detected
[ ] scsi host8: usb-storage 6-6:1.0
[ ] scsi 8:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[ ] sd 8:0:0:0: Attached scsi generic sg6 type 0
[ ] sd 8:0:0:0: [sdg] 7626752 512-byte logical blocks: (3.90 GB/3.64 GiB)
[ ] sd 8:0:0:0: [sdg] Write Protect is off
[ ] sd 8:0:0:0: [sdg] Mode Sense: 03 00 00 00
[ ] sd 8:0:0:0: [sdg] No Caching mode page found
[ ] sd 8:0:0:0: [sdg] Assuming drive cache: write through
[ ]  sdg: sdg1 sdg2
[ ] sd 8:0:0:0: [sdg] Attached SCSI removable disk
$

blkid output:

# blkid /dev/sdg
/dev/sdg: BLOCK_SIZE="2048" UUID="2023-09-14-08-09-20-00" LABEL="DEVUAN501" TYPE="iso9660" PTUUID="3488f3e0" PTTYPE="dos"
#
# blkid /dev/sdg1
/dev/sdg1: BLOCK_SIZE="2048" UUID="2023-09-14-08-09-20-00" LABEL="DEVUAN501" TYPE="iso9660" PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
#

Listed by gparted:
Size: 3.64 GiB
File system: iso9660
Label: DEVUAN501

Partition
Path: unallocated    First sector:  0
                    Last sector:   7626751
                    Total sectors: 7626752

Listed by disks:

Partition 1
Size: 478 MB (478150656 bytes)
Contents: ISO 9660 (version Joliet Extension) — Mounted at /media/groucho/DEVUAN501
Device: /dev/sdg1
Partition Type: 0x00 (bootable)

Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: EFI (FAT-12/16/32)

Free Space: 3.4 GB

---

*****
Edit Partition 1 with fdisk as per your instructions.
*****

# fdisk -V
fdisk from util-linux 2.38.1
#

# fdisk -l
--- snip ---
Disk /dev/sdg: 3.64 GiB, 3904897024 bytes, 7626752 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3488f3e0

Device     Boot  Start    End Sectors  Size Id Type
/dev/sdg1  *         0 933887  933888  456M  0 Empty
/dev/sdg2       933888 977847   43960 21.5M ef EFI (FAT-12/16/32)
#

# fdisk /dev/sdg

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.

The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Command (m for help): t
Partition number (1,2, default 2): 2
Hex code or alias (type L to list all): c

Changed type of partition 'EFI (FAT-12/16/32)' to 'W95 FAT32 (LBA)'.

Command (m for help): n
Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3): 3
First sector (977848-7626751, default 978944):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (978944-7626751, default 7626751):

Created a new partition 3 of type 'Linux' and of size 3.2 GiB.

Command (m for help): w
The partition table has been altered.
Syncing disks.
#

Detected by dmesg:

$ sudo dmesg
--- snip ---
[ ] usb 6-6: new high-speed USB device number 8 using ehci-pci
[ ] usb 6-6: New USB device found, idVendor=14cd, idProduct=125d, bcdDevice= 1.00
[ ] usb 6-6: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ ] usb 6-6: Product: Mass Storage Device
[ ] usb 6-6: Manufacturer: Generic
[ ] usb 6-6: SerialNumber: 125D20140310
[ ] usb-storage 6-6:1.0: USB Mass Storage device detected
[ ] scsi host8: usb-storage 6-6:1.0
[ ] scsi 8:0:0:0: Direct-Access     Mass     Storage Device        PQ: 0 ANSI: 0 CCS
[ ] sd 8:0:0:0: Attached scsi generic sg6 type 0
[ ] sd 8:0:0:0: [sdg] 7626752 512-byte logical blocks: (3.90 GB/3.64 GiB)
[ ] sd 8:0:0:0: [sdg] Write Protect is off
[ ] sd 8:0:0:0: [sdg] Mode Sense: 03 00 00 00
[ ] sd 8:0:0:0: [sdg] No Caching mode page found
[ ] sd 8:0:0:0: [sdg] Assuming drive cache: write through
[ ]  sdg: sdg1 sdg2 sdg3
[ ] sd 8:0:0:0: [sdg] Attached SCSI removable disk
$

blkid output:

# blkid /dev/sdg
/dev/sdg: PTUUID="3488f3e0" PTTYPE="dos"
#
# blkid /dev/sdg1
/dev/sdg1: PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
#
# blkid /dev/sdg2
/dev/sdg2: SEC_TYPE="msdos" UUID="FAE4-C64A" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="3488f3e0-02"
#
# blkid /dev/sdg3
/dev/sdg3: PARTUUID="3488f3e0-03"
# 

Listed by gparted:
Size: 3.64 GiB

File System
File system: unallocated
Size: 456.00 MiB
Path: unallocated
First sector: 0
Last sector: 933887
Total sectors: 933888

File system: fat16
Size: 21.46 MiB
Label:
UUID: FAE4-C64A

Partition
Path: /dev/sdg2
Name:
Flags: lba
First sector: 933888
Last sector: 977847
Total sectors: 43960

File system: unknown
Size: 3.17 GiB
Label:
UUID:

Partition
Path: /dev/sdg3
Name:
Flags:
First sector: 978944
Last sector: 7626751
Total sectors: 6647808

---

Listed by disks:

Unallocated space
478 MB (478150656 bytes)
Device: /dev/sdg

Filesystem
Partition 2
Size: 23 MB — 2.1 MB free (90.8% full)
Contents: FAT (16-bit version) — Mounted at /media/groucho/FAE4-C64A
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: W95 FAT32 (LBA)

Partition 3
Size: 3.4 GB (3403677696 bytes)
Contents: Unknown
Device: /dev/sdg3
Partition Type: Linux

---

I only have one other Linux box to check this:

$ uname -a
Linux eee-dev3 5.10.0-0.deb10.16-686-pae #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) i686 GNU/Linux
$

# fdisk -V
fdisk from util-linux 2.33.1
#

$ sudo fdisk -l
--- snip ---
Disk /dev/sdb: 3.7 GiB, 3904897024 bytes, 7626752 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3488f3e0

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdb1  *         0  933887  933888  456M  0 Empty
/dev/sdb2       933888  977847   43960 21.5M  c W95 FAT32 (LBA)
/dev/sdb3       978944 7626751 6647808  3.2G 83 Linux

$ sudo blkid /dev/sdb
/dev/sdb: PTUUID="3488f3e0" PTTYPE="dos"
$
$ sudo blkid /dev/sdb1
/dev/sdb1: PTUUID="3488f3e0" PTTYPE="dos" PARTUUID="3488f3e0-01"
$
groucho@eee-dev3:~$ sudo blkid /dev/sdb2
/dev/sdb2: SEC_TYPE="msdos" UUID="FAE4-C64A" TYPE="vfat" PARTUUID="3488f3e0-02"
$
sudo blkid /dev/sdb3
/dev/sdb3: PARTUUID="3488f3e0-03"
$

Sorry for the length but I wanted to get everything from the screen printout as it happened, from the start and not have to come and go from other posts.
Please let me know if you need more data.

Thank you for your help.

Best,

A.

When you plug in the USB (on another linux) without mounting it, what does blkid /dev/sdg and blkid /dev/sdg1 say? I'd expect it to be like

/dev/sdg1: BLOCK_SIZE="2048" UUID="2023-09-14-08-12-43-00" LABEL="DEVUAN501" TYPE="iso9660" PTUUID="0650bbcb" PTTYPE="dos" PARTUUID="0650bbcb-01"

Indeed ...

I tried it just to see if the warning fdisk printed would effectively materialise.
And it would seem it did, see below.

No, but not a problem.
I dd'd another (smaller) installer which was the one I originally intended to use (devuan_daedalus_5.0.1_amd64_netinstall.iso)

Here's the output of what I just did:

[root@devuan ~]# fdisk /dev/sdg

Welcome to fdisk (util-linux 2.38.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The device contains 'iso9660' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Command (m for help): t
Partition number (1,2, default 2): 2
Hex code or alias (type L to list all): c

Changed type of partition 'EFI (FAT-12/16/32)' to 'W95 FAT32 (LBA)'.

Command (m for help): n
Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3):
First sector (977848-7626751, default 978944):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (978944-7626751, default 7626751):

Created a new partition 3 of type 'Linux' and of size 3.2 GiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

This is the result:

# fdisk -l /dev/sdg
Disk /dev/sdg: 3.64 GiB, 3904897024 bytes, 7626752 sectors
Disk model: Storage Device
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3488f3e0

Device     Boot  Start     End Sectors  Size Id Type
/dev/sdg1  *         0  933887  933888  456M  0 Empty
/dev/sdg2       933888  977847   43960 21.5M  c W95 FAT32 (LBA)
/dev/sdg3       978944 7626751 6647808  3.2G 83 Linux
#

gparted shows this for /dev/sdg:

- 456 MiB of unallocated space      ### not reported as bootable or ISOIMAGE.
- /dev/sdg2    FAT16 21.46 MiB
- /dev/sdg3 3.17 GiB unformatted partition

disks utility shows the same thing:

------------------------------------------------
Partition 1
Size: 478 MB (478150656 bytes)
Contents: Unknown
Device: /dev/sdg1
Partition Type: 0x00 (Bootable)     ### reported as bootable but not as ISOIMAGE.

Partition 2
Size: 23 MB (22507520 bytes)
Contents: FAT (16-bit version) — Not Mounted
Device: /dev/sdg2
UUID: FAE4-C64A
Partition Type: W95 FAT32 (LBA)

Partition 3
Size: 3.4 GB (3403677696 bytes)
Contents: Unknown
Device: /dev/sdg3
Partition Type: Linux
------------------------------------------------

Does this USB stick boot?
Yes, it does.
And faster, from the GRUB welcome to installer menu in a flash.

The problem is that the installer fails as it cannot find the ISOIMAGE:

--- snip ---
mount: mounting LABEL=DEVUAN501 on /cdrom failed: No such file or directory.
[  39.XXXX ] random: crng init dome
mount: mounting UUID= on /cdrom failed: No such file or directory.
mount: mounting LABEL=DEVUAN501 on /cdrom failed: No such file or directory.
--- snip ---
*** failed to mount the cdrom
*** Staring emergency shell ...

BusyBox v1.35.0 (Debian 1:1.35.0-4+b3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty: job control turned off
/ # _

Re: your edit, found while posting this:

Yes.

Yes.

Yes.

All that was done, the EFI directory and files were renamed.

But it seems fdisk does not issue idle warnings:

The device contains 'iso9660' signature and it will be removed by a write command.

So, no ISOIMAGE, no installation.

If I use disks to edit that 'unknown' bootable 478MB dev/sdc1 partition and make it W95 FAT32 (LBA) (Bootable) it remains unknown and as such, inaccesible.

That can't be undone but it is not a problem as I can dd the *.iso again.
Let me know if there's anything else I can do.

Thank you very much for your help.

Best,

A.