Re: ISO installer image: GPT versus MBR partitions

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

Hi,

i wrote:
> > ... 3f  0b
> > ... 40  0b
> > ... ==  ==

Florian Pelz wrote:
> Why is 0b underlined?

Too much enthusiasm on my side.


> OK, so I just wrote the Guix git master with ludo’s reproducibility
> patches to a USB drive (boot gets stuck again) and then did:
> sudo dd if=/dev/sdc2 of=mysdc2.img
> When I open it with ghex, I find at position 446:
>    80  00  00  04  01  24  4f  00  00  00  00  80  16  00  00  00

Pinching eyes ...

Bootable flag is set.
Start C/H/S is 4/0/0. (x/y/1 is usual)
Partition type is 1.
End C/H/S is 1/36/15.
Start LBA is 0x80000000 = 2,147,483,648.
Block count is 0x16 = 22.

So what ever did you do to this mysdc2.img ?


> I change it to
>    80  00  02  00  01  01  12  4f  01  00  00  00  3f  0b  00  00
> I dd the changed mysdc2.img back to /dev/sdc2.
>
> Now it boots. :)

Start C/H/S is 0/0/2.
Partition type is 1.
End C/H/S ...  i'm getting too old for decoding MBR C/H/S bit fields.
Start LBA is 1.
Block count is 0x0b3f = 2879.

So Start LBA 0 is indeed the trigger of the problem.
As soon as the partition entry does not point to its hosting block any
more, the (now very probable) loop in EFI cannot happen.


> Strangely, I now have only one entry “GRUB 2.02” in
> the boot selection, but “EFI Boot” (or what it was called) is gone.

What do you see if the partition entry is zeroized entirely ?

(Elsewise i refer to the Futurama quote in my previous mail.)


> Is it a good
> idea to add -k to mformat in grub-mkrescue for the upcoming Guix 1.0
> release (even though you don’t like it)?

We need to ask at grub-devel. I have begun to compose a mail.
You will be Cc-ed.
Does guix-devel want to be Cc-ed ?

New mail:
> MacBook Pro (13-inch, Mid 2010)
> Model Name:            MacBook Pro
> Model Identifier:      MacBookPro7,1
> Boot ROM Version:      MBP71.003F.B00
> SMC Version (system):  1.62f7

I will put this into my mail to grub-devel.

> Serial Number  ...

... but this only if asked for.


Back to old mail:
> Or should mformat be patched instead? Could any of
> this be upstreamed?

That's why i asked Ludovic about our chances with mtools upstream.
I would propose an option to write the usual pseudo-MBR but without that
partition entry.
(Well, maybe somebody there can even remember why a partition entry
 is made by default.)


> What about your MBR repacking?

I will create an option for zeroizing bytes 446 to 461 of the EFI image.

When the dust has settled here, i will ask Ludovic for preparing the
ISO production code for a run with libisoburn's wrapper script
frontend/grub-mkrescue-sed.sh for MBR-only.

At that occasion, the EFI image repairer could be tested, too.

The script has a mode "original" which does not change the xorriso
options submitted by grub-mkrescue. So it produces original GPT.
(It's original purpose is spying on grub-mkrescue's xorriso options.)


> I just doing what I’m told, but I
> don’t quite understand what I’m doing here.

We had a wild ride over boot sectors and partition tables.
I collect my knowledge in libisofs file doc/boot_sectors.txt .

At days when our web certificates are valid, it is available at
  https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt

Hah. Bug #4. No doc/boot_sectors.txt in libisofs tarball.
But it is in GNU xorriso's tarball:
  https://fossies.org/linux/misc/xorriso-1.5.1.tar.gz/xorriso-1.5.1/doc/boot_sectors.txt

For completeness, a reserve address for my grub-mkrescue-xorriso wrapper:
  https://sources.debian.org/src/libisoburn/1.5.0-1/frontend/grub-mkrescue-sed.sh


Have a nice day :)

Thomas