i wrote:
> > i see a quite insane MBR partition table:

Samuel Thibault wrote:
> That's not surprising by nowadays' """ISO""" image standard: they are
> both valid as CD image, usb stick image, etc.

Sure. But normally the MBR has a valid partition table.
Not only the ISOLINUX MBR of Debian x86 ISOs but also the MBR of
My program xorriso writes those partition tables if it is told to do so.
But in the case of the grub_embed MBR there seems to be code where the
partition tables is supposed to be. So it would not be a good idea to
simply add option --protective-msdos-label to the xorriso -as mkisofs run.

> > One should ask the provider of grub_embed

> Ask grub people then :)

I would need to know how the MBR and the subsequent data blocks
are produced. (And for what device an MBR with garbled partition table
would be deemed suitable, if that is known.)

The code in the MBR of grub-mkrescue obviously hops onto the program in
the El Torito boot image. So it can be small enough to leave bytes
446 ff. unused.
I refer to grub-mkrescue because it is the official upstream proposal to
prepare the GRUB2 entrails and the xorrisofs options for a GRUB2 bootable

> > 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.

> Again, a grub issue :)

Do you see the same effects in your tests ?
If not, with what virtual firmware do you test ?

(And why is your /boot/grub/grub_eltorito not needy of xorrisofs
 option --grub2-boot-info ?)

Have a nice day :)


Reply via email to