Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition

[Thomas Schmitt]

Hi,

> On the other hand, in the Windows world this rarely causes any confusion
> since no Windows version I've encountered so far contains native tools
> to write an ISO (or any other image file) to a USB stick as Unix' "dd"
> command would.

A Wallace Line for ISO-zooa. This explains a lot.


> that "just dd it to a USB key" feature of isohybrid is
> mainly useful to people who already have some kind of Unix running.

Rufus has a "DD" mode, meanwhile with auto-detection of worthy ISOs:
  https://github.com/pbatard/rufus/issues/1148


> [Disk Management GUI refusal ...]
> That may be another reason that dd-able ISOhybrid files are mostly
> used for Linux installs (since Linux does not have that restriction) and
> not used for Windows install media.

Actually in GNU/Linux and similar systems it is darn dangerous to dd
an ISO onto a USB stick. You normally need privileges which suffice to
overwrite your system disk.

I wonder whether it was Vladimir Serbinenko or H. Peter Anvin who
first had the idea to let MBR x86 boot code hop onto the El Torito
no-emulation boot image. I guess the term "isohybrid" is by hpa.


> On the other hand, all 64-bit EFI firmware versions I encountered so far
> (to be honest, I believe all of them were "designed to run Windows"), do
> EFI boot from the *first* MBR-style partition of an *external* drive
> (e.g. USB), if the partition type is either 0x0B or 0x0C, the partition
> is marked bootable, and it contains a FAT32 filesystem with an
> /EFI/BOOT/BOOTX64.EFI file on it.

This is quite what the rumors say, if i replace their riddling details
by yours.
It also matches what Florian reports about his USB stick's partitioning.

In contrast, UEFI 2.4, 5.2.1 Legacy Master Boot Record (MBR):

  "Table 14. Legacy MBR Partition Record
   [...]
   BootIndicator : Byte Offset 0 :
   0x80 indicates that this is the bootable legacy partition. Other
   values indicate that this is not a bootable legacy partition.
   This field shall not be used by UEFI firmware.
   [...]
   If an MBR partition has an OSType field of 0xEF (i.e., UEFI System
   Partition), then the firmware must add the UEFI System Partition GUID
   to the handle for the MBR partition using InstallProtocolInterface().
   This allows drivers and applications, including OS loaders,
   to easily search for handles that represent UEFI System Partitions."


> if it did not work, people would complain quickly.

Yeah. This is the reason why i care to learn. Big truck slipstream.
(Even if i afterwards need to get hot water and iodine ...)


> On the other hand, if I partitioned the USB stick in GPT
> mode and used an EFI System Partition as primary partition, Windows
> would not assign a drive letter to it when I attach it, and older OSes
> would not be able to read the stick at all.

I am a big fan of MBR partition table with partition of type 0xEF.
Therefore i provide a script-in-the-middle for grub-mkrescue to be
submitted as option --xorriso=
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/frontend/grub-mkrescue-sed.sh
It can let grub-mkrescue produce a partition layout like:

  Device                     Boot Start   End Sectors  Size Id Type
  grub-mkrescue-offst16.iso1 *       64 24171   24108 11.8M 83 Linux
  grub-mkrescue-offst16.iso2      24172 29931    5760  2.8M ef EFI (FAT

(Made with xorriso options -partition_offset 16 -iso_mbr_part_type 0x83)
Partition 1 is mountable as ISO 9660. The whole device too. The latter
claims the full image size including EFI partition as its filesystem size.

------------------------------------------------------------------------

Many thanks for sharing this info. It will help me a lot when next time
i see optimistic proposals about how to make ISOs bootable from USB stick.

If anybody knows a public document where the tolerant firmware habit is
adopted by some standards entity (or market power), then i would be glad
to learn.


Have a nice day :)

Thomas