Hi and welcome. I think it could help the devs the reproduce the issue if you could attach your actual MBR with which the failure occurs.

Yes, that would be helpful.  I'll be happy to provide that.  How many bytes from the start of the disk image are needed?  Does this BB have a mechanism to attach binary data--or--in what form should it be attached?

While attempting to install Devuan ASCII on a test VM, the 'Partition disks' step shows an incorrect existing partition and does not allow me to use the correct existing partitions.  Eventually, I need to install to a physical machine with existing MBR-style partitions (and mdadm-style per-partition RAID10) with an existing installation of SBM (smart boot manager).  The test VM is a simplified mock-up of the eventual physical machine.

The symptoms are independent of whether I use the graphical installer, non-graphical installer, or Advanced Options -> Expert Install.  Symptoms are also independent (for the latter case) of whether I load additional components cfdisk-udeb, mbr-udeb, and parted-udeb.  When I get to the 'Partition disks' step, I choose manual partitioning (tried other options, but none lead anywhere useful).  The installer shows "Virtual disk 1 (vda) - 21.5GB Virtio Block Device" and "#1 21.5 GB fat16".  That appears to indicate the installer mistakenly thinks there is one 21.5 GB FAT16 partition on virtio block device /dev/vda.

In reality, there are four MBR-style partitions on the device: three marked ID 83 (Linux), and one marked ID 82 (Linux Swap / Solaris).  In the expert installer, if I execute a shell, both /proc/partitions and "fdisk -l /dev/vda" show the correct four partitions.  However, the installer still insists it sees only one 21.5GB partition formatted FAT16 (which I'm not sure is even possible given FAT16 size limitations).

Any suggestions to force the 'Partitions disks' installer stage to see the correct existing four MBR-style partitions?

Thanks,

Robert