Re: Debian GNU/Hurd 2017 released!

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i found
  https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/build/util/x86-image
which indeed produces a file grub_embed.
But it uses a blob as first part of that file:

  cat "/usr/lib/grub/$platform/boot.img" "$workdir/core.img" > "$outdir/boot/grub/grub_embed"

I have one on my Debian 8:
  -rw-r--r-- 1 root root 512 Mar 23  2015 /usr/lib/grub/i386-pc/boot.img

This blob already has the bytes in the partition table which cause
the insane numbers in fdisk and other partition table interpreters.
Disassembling does not look as if the code would try to hop over
the table beginning at 0x1be. I got this command on my cheat sheet:
  objdump -D -b binary -mi386 -Maddr16,data16 $mbr_file | less
but lack true assembler knowledge.

Nevertheless i can see that the MBR of grub-mkrescue has a "ret" before
the partition table begins and that its jumps go either below 0x1b0 or
above 0x1ff.


Now i wonder whether i should ask Debian's GRUB2 maintainers or directly
at grub-devel about the use cases where this would be appropriate.
I could declare it a matter of coordination among GNU projects. :))


Have a nice day :)

Thomas