[Top][All Lists]

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

Re: [Bug-xorriso] ISO installer image: GPT versus MBR partitions

From: Thomas Schmitt
Subject: Re: [Bug-xorriso] ISO installer image: GPT versus MBR partitions
Date: Sat, 20 Apr 2019 18:32:07 +0200


Florian Pelz wrote:
> mkfs.fat fatfs.img
> sudo mount fatfs.img /mnt/img
> sudo cp -r /mnt/efiimg/efi /mnt/img/
> Hooray!  It boots!

So it is indeed the filesystem hull, which is to blame.

We still need to find out whether the partition entry is the culprit.
So please do the experiment with the Guix EFI partition image in
partition 2 of the USB stick and

   dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2

The partition entry in the Guix EFI partition image has all the
properties of the thing we are looking for:
- Not in the FAT filesystem, but also not outside of it.
- Plausible to be differently approached from USB stick and DVD.
- Self referring enough for an endless inspection loop in EFI.

> It uses mkfs.fat for creating FAT partitions, but maybe this
> particular EFI partition is created by grub-mkrescue?

      rv = grub_util_exec ((const char * []) { "mformat", "-C", "-f", "2880", 
"-L", "16", "-i",
            efiimgfat, "::", NULL });

This run produces an image file with partition 1, starting at LBA 0.
A remark below
      /* install fake partition table pointing to itself */

(But why does grub-mkrescue.c create a 2.8 MB floppy where Guix has a
 1.4 MB floppy image ? Does Guix use a patched version of grub-mkrescue ?)

Under the assumption that it is really the partition entry, i snooped ahead:

mformat options -2 and -k can suppress the production of the partition
entry. Option -2 is for some exotic floppy format from the 1990s.

Option -k seems better, but if i use it, program "file" becomes sparing
with words:

  $ file /u/test/mformat.fat
  /u/test/mformat.fat: DOS floppy 1440k

It can be mounted by Linux and offers free space, though.

More similar to the current FAT image hull is the result of

   dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2

I actually did with a copy of partition 2:
   dd if=/dev/zero bs=1 count=16 seek=446 conv=notrunc of=test.img
and the report of "file" did not change. fdisk reports no partitions
in test.img any more.

Assuming that we cannot easily convince GRUB to use mformat -k or to
switch to some other FAT creator, i currently ponder the opportunity
to let my man-in-the-middle script do this dd patching of the EFI image
before it gets copied into the ISO.

Second correction of my statement about zapping the partition entry:

i wrote:
> The 16 bytes written to /dev/sdc1 would deface the GPT's "protective" MBR
> and thus make the GPT invalid.

Wrong again. Because it is a grub-mkrescue ISO, it hit byte 446 ff of
the ISO Primary Volume Descriptor. Funnily this is the place where
xorriso placed its hallmark:
   XORRISO-1.5.0 2018...
So the misplaced dd was effectively without effect.


Have a nice day :)


reply via email to

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