Re: Debian GNU/Hurd 2017 released!
Hi,
in
http://ftp.ports.debian.org/debian-ports-cd/hurd-i386/debian-hurd-2017/debian-hurd-2017-i386-NETINST-1.iso
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
table.
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 debian-hurd-2017-i386-NETINST-1.iso
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 :)
Thomas
Reply to: