Yep, but "the latest version in ubuntu" means nothing to me, in the sense that I am not going to download ubuntu to check which version is included in it.
The hint was that if you follow the given article (which is good), then at least at first try FOLLOW IT to the letter (i.e. using the EXACT SAME software, and NOT a different version/release/whatever), this is "generic advice", but specifically there were (and possibly still are) quite a lot of issues in Suslinux 5.x and 6.x (though as said not necessarily connected with your booting issues)
For the record:
Bootsect normally applies to the bootsector (or VBR or PBR) the appropriate boot CODE (and does NOTHING to the MBR) leaving the DATA untouched.
IF the /mbr switch is used than also the CODE of the MBR is updated (still the DATA in the MBR remains untouched).
The DATA in the bootsector (or VBR or PBR), in the case of NTFS represented also by the file $Boot, is written by the FORMAT command.
The DATA in the MBR is written by Disk Manager (or diskpart).
What we don't know (until now) is WHAT is preventing the boot (at least until the BOOTMGR choices), possible culprits are:
- the way the .vhd has been partitioned/formatted
- the specific memdisk (or more generally syslinux) version
- something else
If you exclude #1 and #2 above, we may proceed to look for the "something else".
As a completely different approach, since your booting worked fine with Duet, why not giving Clover a try?