grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Schmitt
Subject: Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition
Date: Thu, 09 May 2019 23:06:40 +0200

Hi,

Vladimir 'phcoder' Serbinenko wrote:
> > have a look at windows install CD/DVD.

Chris Murphy wrote:
> I think there's no partition whatsoever, plain UDF.
>  LABEL="CCCOMA_X64FRE_EN-US_DV9"

debian-user has a thread about a similar image: CCCOMA_X64FRE_JA-JP_DV9
  https://www.mail-archive.com/address@hidden/msg741966.html

The thread starter, Mark Fletcher, inspected it by
  xorriso -indev .../Win10_1809Oct_v2_Japanese_x64.iso \
          -report_system_area plain -report_el_torito plain
There is an ISO 9660 superblock and El Torito boot images for BIOS and
EFI. No MBR signature, no other partition table known to xorriso.
  https://www.mail-archive.com/address@hidden/msg741984.html

And then RESOLVED:
  https://www.mail-archive.com/address@hidden/msg742063.html
  "The issue was Secure Boot. Specifically, in the case of my test machine,
   it's too old to support secure boot, and in the case of the final target
   machine, secure boot was turned off in the BIOS so that I could boot
   Buster which is what this machine was previously running. When I
   switched the CSM and also turned on Secure Boot (both settings needed to
   be changed) in the BIOS, the machine finally booted from the USB stick,
   and all proceeded smoothly from there."

Whatever happened there, it looks like it has booted via El Torito.
That's contrary to all belief and known specs.


> https://drive.google.com/open?id=1JgPv8EBHDn5A7hTEwewGK1MuFHvHbJnr
>
> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |......
> *
> 00008000  01 43 44 30 30 31 01 00  20 20 20 20 20 20 20 20  |.CD001.

Absolutely zero System Area. No BIOS boot code for hard-disk-like devices.
The first non-zero bytes are the ISO 9660 Primary Volume Descriptor.


> 00008800  00 43 44 30 30 31 01 45  4c 20 54 4f 52 49 54 4f
>  |.CD001.EL TORITO|

Here begins the El Torito Boot Record.


> 0000b000  01 00 00 00 4d 69 63 72  6f 73 6f 66 74 20 43 6f  |....Micr
> 0000b010  72 70 6f 72 61 74 69 6f  6e 00 00 00 4c 49 55 aa  |rporatio
> 0000b020  88 00 00 00 00 00 08 00  05 02 00 00 00 00 00 00  |........
> 0000b030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |........
> 0000b040  91 ef 01 00 00 00 00 00  00 00 00 00 00 00 00 00  |........
> 0000b050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |........
> 0000b060  88 00 00 00 00 00 01 00  07 02 00 00 00 00 00 00  |........

El Torito Boot Catalog announces images for BIOS and EFI.


> 00009800  00 42 45 41 30 31 01 00  00 00 00 00 00 00 00 00  |.BEA01...

... and there is UDF, of course ...


So how could this boot if not via El Torito ?

It is known that OVMF boots El Torito from virtual hard disk.
Tianocore's EDK-2 indiscriminately registers FAT filesystems from GPT,
MBR partition table, and El Torito. At least at it's Pre-EFI stage:
  https://github.com/tianocore/edk2/blob/master/FatPkg/FatPei/Part.c
  https://github.com/tianocore/edk2/blob/master/FatPkg/FatPei/Eltorito.c

But can Microsoft Inc. really bet on all firmwares to ignore specs and
traditions ?
(I feel lost right now. Vladimir, are you somewhere out there ?)


Have a nice day :)

Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]