i see a quite insane MBR partition table:

  $ /sbin/fdisk -lu debian-hurd-2017-i386-NETINST-1.iso
  Disklabel type: dos
  Device                               Boot      Start        End    Sectors   
Size Id Type
  debian-hurd-2017-i386-NETINST-1.iso1 ?    3451924861 3662313359  210388499 
100.3G  0 Empty
  debian-hurd-2017-i386-NETINST-1.iso2 ?    2766929882 4653280287 1886350406 
899.5G be Solaris 
  debian-hurd-2017-i386-NETINST-1.iso3 ?      28891953 3082391602 3053499650   
1.4T  0 Empty
  debian-hurd-2017-i386-NETINST-1.iso4      4278184271 4278184271          0    
 0B d4 unknown

The bytes of the MBR stem obviously from this xorrisofs option (learned
from file /.disk/mkisofs in the ISO):

  --embedded-boot boot1/boot/grub/grub_embed

One should ask the provider of grub_embed whether it is intentional to
have a MBR signature in bytes 510 and 511 and to have the cleartext word
"Floppy" in the range where the MBR is supposed to expose its partition
Especially strange is that the MBR code contains lots of zeros in its
first 80 bytes. Can it be that the code should be moved ~ 80 bytes
lower and rather hop over a more plausible partition table beginning at
byte 446 ?

The MBR code itself seems to be functional. I get to a GRUB menu by
  $ qemu-system-x86_64 -enable-kvm -m 4096 -hda 
although the menu switches by every press of an arrow key from dark purple
with horizontal and vertical roll-over to grey cyan with correct geometry.

This menu display defect is not bound to MBR booting. If i erase the MBR
and boot by -cdrom, i get to the same situation.
(It is not 100% sure that -hda uses MBR and -cdrom uses El Torito because
 some virtual BIOSes are known to boot El Torito from -hda and MBR from
 -cdrom. So to be sure, one has to cripple the unwanted boot starting point.
 The default virtual BIOS of Debian 8 qemu is ok in this aspect, nevertheless.)

Have a nice day :)


Reply via email to