Hello:

I recently had a very hard time with a couple of netinstall *.iso images, devuan_chimaera_4.0.0_amd64_netinstall.iso and daedalus/devuan_daedalus_5.0.1_amd64_netinstall.iso while attempting to install a basic Devuan to a small capacity USB stick.

Have a read here to see how I finally managed to get it done.
Dev1 admin's help was crucial, no way I would have found a way out of the problem I was having.

The thing is that (IMO) the Debian installer (not forked by Devuan) definitely has something wrong with it.
I seriously doubt the Debian devs will do anything about it.

I assume that you have already tried basic dd'ing the *.iso to a USB stick (no Ventoy, etc.), with the usual precautions.
ie: *.iso file SHA256SUM prior to burning to USB and installation media check before proceding with the installation.

I so, check here to see the process which allowed me to get the installer to start working.
And even so, it refused to write GRUB to the indicated location so I had to reboot the installer, drop to rescue mode and install it by hand.

While my box is a standard BIOS boot / non-UEFI workstation, it may solve your problem.

Please keep us posted on how you fare with this.

Best,

A.

Hello:

Welcome to Dev1.

You run a Win10 box + VirtualBox 7.0 to run Devuan Chimaera VM?

It is not quite clear to me where the problem lies but it would seem that it is with VirtualBox.
If the issues are indeed with VirtualBox, I'd say that it is something to ask about either in a Win10 or VBox forum.

That said, you may want to consider running a Devuan box + VirtualBox and then drop in whatever VM you want to run.
I would not trust any MSOS box to run my VMs in, but maybe that's just me getting old. 8^°

As always, YMMV.

I have been running VirtualBox in my Devuan installations to host three VMs since Devuan ascii: W98 for a pair of applications I cannot replace and two Devuan Linux, one to run a PiHole+ a recursive DNS and another for testing purposes and such.

Never had any problems.

Best,

A.

Edit: do take 5' to read this article.

Hello:

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.

Hello:

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.

Hello:

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.

Hello:

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.

Hello:

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.

Hello:

You're welcome, but all merit belongs ralph.ronnquist.

Not being at all familiar with all this UEFI crap, I just asked the question because it seemed odd that gparted showed me one thing and disks another.
Maybe it is time for gparted to make the necessary adjustments.

Ralph's explanation as to how it works (+the ascii art) is what set you on the right track.

Best,

A.

Hello:

See my previous post.
The problem also crops up with a Debian *.iso.

Apparently, the Debian installer has not been forked by Devuan, so it is the same one save for some branding and such things.

Could be.
But I need something more straightforward than that.

Thanks for your input.

Best,

A.

Hello:

Yes, that was my thought from the start.
And unless anyone can come up with a better/more reasonable explanation to what is going on, it would seem that that is what we are seeing.

Not a good sign.

BTW:
Installing GRUB as described in my previous post was not followed through with the needed grub-update so I was left with a grub rescue > prompt on my screen ('grub_file_filters' not found) and the USB drive behaving as before.

I recovered my system drive this morning (the easy way) with a Super Grub2 image Super Grub2 for non-UEFI systems.
I was not feeling lucky and did not want to risk screwing up any further.

---
I should learn to do it the old way / manually ie: via grub rescue >.
One day I may not have anything else at hand and then, what?

I have always thought that the day will come when the only way to get anything done properly, securely and without any restraints/controls will be by being proficient in command line at the terminal. Seems it may be sooner than later.

But I digress ...
---

The purpose behind my wanting to install a very small footprint Devuan on small capacity SD/MicroSD cards was to 1. make use of a few I had and 2. put together a Devuan based Clonezilla-Live (it is Debian based) to always have at hand or to boot into from an on-board USB socket my system MB has.

That went awry when I was not able to install Devuan on any card or USB stick (old or brand new), the results being those reported in my OP and others.

It would be great if anyone with non-UEFI hardware could run a test to see if they get the same / similar result.

Thanks in advance.

Best,

A.

Hello:

Update:

# memtester 4096 5
memtester version 4.6.0 (64-bit)
Copyright (C) 2001-2020 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).
--- snip ---

Memtester ran 5 loops for ~360 minutes and all of them came up with no failures, like this one:

--- snip ---
Loop 1/5:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
  Solid Bits          : ok         
  Block Sequential    : ok         
  Checkerboard        : ok         
  Bit Spread          : ok         
  Bit Flip            : ok         
  Walking Ones        : ok         
  Walking Zeroes      : ok         
  8-bit Writes        : ok
  16-bit Writes       : ok

Loop 2/5:
  Stuck Address       : ok         
  Random Value        : ok
  Compare XOR         : ok
  Compare SUB         : ok
  Compare MUL         : ok
  Compare DIV         : ok
  Compare OR          : ok
  Compare AND         : ok
  Sequential Increment: ok
--- snip ---

I think that can most probably rule out any memory corruption issues.
The testing continues.

Best,

A.