Re: Is --protective-msdos-label incompatible with -isohybrid-mbr?

[Martin Whitaker]

On 08/11/2020 09:05, Thomas Schmitt wrote:
> Hi,
>
> Martin Whitaker wrote:
> > On booting from a USB stick, I get [at boot time] the error message:
> >   isolinux.bin missing or corrupt.
>
> Yes. --protective-msdos-label prevents the adjustment of the MBR template
> isohdpfx.bin so that it knows where the El Torito boot image isolinux.bin
> is. The message text stems from this MBR code when it wakes up and feels
> lonely.
>
> The option --protective-msdos-label was introduced on request of GRUB
> development. It is obviously very unusual that this option is combined
> with -isohybrid-mbr.
> -isohybrid-mbr strives for a mountable ISO 9660 partition, which thus
> to start at block 0 (if not -partition_offset 16 is used).
> --protective-msdos-label strives for a first partition which begins at
> block 1 and thus is not mountable. As said, a wish from GRUB development.
>
> The two options override each other. The last one in the list of program
> arguments is the winner.
>    -isohybrid-mbr /dvdbuffer/debian-8.1.0-amd64-netinst.mbr \
>    --protective-msdos-label \
> produces a GRUB-ish partition table
>    --protective-msdos-label \
>    -isohybrid-mbr /dvdbuffer/debian-8.1.0-amd64-netinst.mbr \
> produces isohybrid.
>
> So my advise is to simply omit --protective-msdos-label unless you switch
> to GRUB as BIOS boot loader. And even then i deem the result suboptimal.

Thanks for the quick response!

As background, I'm investigating this in order to add UEFI support to 
the Mageia 32-bit netinstall ISOs. Currently they are created using 
'isohybrid -o 1'. The reason for starting the protective partition at 
sector 1 is that some old, buggy BIOSs would go into an infinite loop if 
the first partition started at sector 0. I was trying to keep the MBR 
boot structure exactly the same, because that has been proven to work 
over many years. We have users still using very old hardware.

I've already switched the other Mageia ISOs to use GRUB, so maybe that 
is the only solution. But I'll do some trials with -partition_offset 16 
to see if that is a workable alternative.

Martin