Comment 174 for bug 1886148

Revision history for this message
Thomas Schmitt (scdbackup) wrote :

Hi,

> 3. The Dell boots to the grub prompt both in BIOS mode and UEFI mode.
> Success :-) What's next :-P

You could try a GPT partitioned groovy.iso.

In the hope that the automat knows best:

  test -f test.iso && rm test.iso

  xorriso \
    -indev groovy-desktop-amd64.iso \
    -outdev test.iso \
    -boot_image any replay \
    -boot_image any appended_part_as=gpt \
    -boot_image any mbr_force_bootable=off

The "replay" command is supposed to apply the commands to set up the
same boot equipment as the original ISO has. The two following commands
-boot_image switch from MBR partition table to GPT and disable the
forced boot flag, which was inherited from the original's boot flag.

Partition editors should then report GPT in test.iso . Like

  $ /sbin/gdisk -l test.iso
  ...
  Found valid GPT with protective MBR; using GPT.
  ...
  Number Start (sector) End (sector) Size Code Name
     1 64 5714919 2.7 GiB 0700 ISO9660
     2 5714920 5724871 4.9 MiB EF00 Appended2

(The alternative to above replay automat would be what i show in
   https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131/comments/22
 with other numbers. For
   0ca0a6242caffcb7c67497fc659f2b8c groovy-desktop-amd64.iso
 they would be 5715916 and 9952.)

-------------------------------------------------------------------------

About the theory that the position of the EFI partition is too far up:

  test -f test.iso && rm test.iso

  xorriso \
    -indev groovy-desktop-amd64.iso.1 \
    -outdev test.iso \
    -boot_image any replay \
    -rm_r /pool /casper/filesystem.squashfs --

This produces a much smaller ISO with MBR partition table (add above
-boot_image commands to get GPT):

  $ /sbin/fdisk -l test.iso
  ...
  Disklabel type: dos
  ...
  Device Boot Start End Sectors Size Id Type
  test.iso1 * 64 238375 238312 116.4M cd unknown
  test.iso2 238376 248327 9952 4.9M ef EFI (FAT-12/16/32)

It will probably not boot successfully beyond GRUB, because the ~2 GB of
filesystem.squashfs will be painfully missed as soon as the kernel is up.

But if it gets to the Ubuntu GRUB menu then this would indicate that
the start address of the EFI partition matters.

(Another test could be to move the EFI partition of a working USB stick
 high up and to check whether it then does not boot any more.)

-------------------------------------------------------------------------

I refrain for now from proposing to try a partition table layout like
with the older ubuntu ISOs (the barely legal one).

Have a nice day :)

Thomas