[Top][All Lists]

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

Re: [Bug-xorriso] Test Proposal for [bug #46716] Protective MBR partitio

From: Thomas Schmitt
Subject: Re: [Bug-xorriso] Test Proposal for [bug #46716] Protective MBR partition is not marked as bootable
Date: Wed, 30 Dec 2015 15:28:38 +0100


Alexander E. Patrakov wrote:
> So, I can agree with making this (or the variant without efi.img 
> duplication) the default layout for grub-mkrescue,

My goal for now would be to get at least two alternative layouts
into grub-mkrescue. Changing the default could break other people's
well working stuff.

Your immediate goal of a MBR bootable flag will be served by
the new xorriso -as mkisofs option for dummy MBR partition.
You will simply add the option to your grub-mkrescue options.
So we do not need a change in grub-mkrescue default.

As alternative to alternative modes inside grub-mkrescue i could
offer to hand over grub-mkrescue-sed.sh to the GRUB project and
to volunteer as its maintainer.
(Where to install an optional grub-mkrescue helper script ?)

In this case i would ask for a less ambiguous naming of the local
disk tree
with the files. A visible difference to other temporary files
would be nice.
How about
(or longer if it does not have to stay within the old POSIX file
 length limit) ?

It looks like "mbr_only" can be equipped with HFS+ and APM
without spoiling its goal of stainlessly implementing UEFI 2.4,
2.5.1 and table 16. I call it "mbr_hfs".
(One just has to remove from "mbr_only" the sed expression
    -e "s/-hfsplus .*CoreServices\/boot.efi//"
 so that the HFS+ options survive.)

Nevertheless without HFS+ this mode will yield the smallest
ISO of all modes. So probably grub-mkrescue should leave HFS+
to the other modes and remove all Mac specific files from
the ISO to save even some more blocks.

The mode "mjg" with two MBR partitions (and thus with bootflag)
would be compliant to the same part of the specs, with the possible
pitfall or lifebelt that a GPT is present where nobody should
expect or interpret it.
Any mislead reader of that GPT will get put back on track of
the MBR partition.

I will soon commit the changes which make possible to avoid
the duplication of ESP with "mjg" and "mbr_*".

Then i'll implement the bootflag enforcing option to make
"original" bootable on your old BIOS board.

A new xorriso-1.4.3 tarball will be uploaded when this is ready.


> I would also like 
> to see a wiki page describing the rationale for each element of this 
> layout in one place.

The whole topic of grub-mkrescue could need more documentation.
Since years i riddled how the user selects the boot equipment.
Now i know that the trick is to run apt-get "install" or "remove"
of Debian packages grub-pc-bin, grub-efi-ia32-bin, grub-efi-amd64-bin.

(Did anybody except me try a EFI bootable ISO without BIOS support ? :))

I will have to learn how to build GRUB2 from upstream and where
to select the supported boot firmwares.
For now i have the excuse that working with Debian binaries
keeps me from opening new cans of worms.

>  - why is GPT present at all?
>   - how do we know that it is used by at least one system, despite the 
> absence of the 0xee MBR partition?

Main problem of documentation is that only UEFI and El Torito
are sufficiently specified by public documents.
PC-BIOS handling of MBR relies on tradition and hearsay.
Mac x86 boot firmware is as manifold as it is obscure.

Even with specs, there is boot firmware around which does
not care for the finer details of those specs.

One could start a list "What boots by what":

A few different ISOs could serve as indicators:

1) "original" BIOS-only ISO to find those which need no EFI.
   I.e. grub-mkrescue with only gru-pc but no grub-efi-*.

2) "mbr_only" with only grub-efi-ia32-bin

3) "mbr_only" with only grub-efi-amd64-bin

4) new "mbr_hfs" with HFS+ via APM but no GPT
   with grub-pc, grub-efi-ia32-bin, and grub-efi-amd64-bin

5) "original" (which has HFS+ via APM and GPT)
   with grub-pc, grub-efi-ia32-bin, and grub-efi-amd64-bin
   Without bootflag enforcing, in order to have one ISO which
   has none and thus fails on your old BIOS board.

What does not boot with one of the first three cannot be an
x86 PC firmware unless it is EFI addicted to GPT.
In this case, number 4 should boot on non-EFI HFS+ x86 Macs.

Number 5 would boot on ill EFI which unconditionally needs GPT
(and on most of the others except those which insist on MBR

Not only booting from HDD but also from CD would need such
classification. (One may use DVD or BD instead of CD.)

An experimenter on a larger collection of real hardware would
need five USB sticks, five CDs, and a clipboard to record
the machine types and 10 success/failure bits.

Please wait for the next xorriso-1.4.3 tarball so that the
tests are done with the ISOs which have no duplicate ESP
(and thus a little El Torito CD adventure if the first
 partition shall make the ISO mountable).

Have a nice day :)


reply via email to

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