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

Bug#776317: Jessie RC1 amd64 mini image missing efi bootloader


>                 xorriso -as mkisofs -r -J -b isolinux.bin -c boot.cat \
>                         -no-emul-boot -boot-load-size 4 -boot-info-table \
>                         -eltorito-alt-boot \
>                         --efi-boot boot/grub/efi.img -no-emul-boot \
>                         -o $(TEMP_MINIISO) $(TEMP_CD_TREE); \

I did not guess too bad with my repacking experiment.

But this does not explain how the empty FAT partition
got to the end of mini.iso
I see in

  	geniso_hybrid_plus_firmware_partition $(TEMP_MINIISO)

So obviously the appended partition was not intended for EFI
but for additional firmware.

Now if mini.iso gets GPT, then
should add its partition to GPT too.
At its end, it uses fdisk to manipulate the MBR partition
table. Number 2 would have to become 3 then, because slot 2
is already occupied by /boot/grub/efi.img.

I guess that gdisk can do similar for GPT.
Problem is that the GPT backup block needs to be moved
after the end of the partition data which was appended
in line 37:
  cat "$firmware_volume_file" >> "$iso"
I dimly remember that gdisk has a menu item for moving
the backup GPT and/or for re-creating the backup GPT.
The backup GPT would actually have to be re-located whenever
the ISO image gets copied onto a disk device.

It might be that gdisk or other partition editors go on strike
when they see the nested partitions. In this case, we might
need to write MBR and GPT slots on byte level.
(A re-write to geniso_hybrid_plus_firmware_partition.c would
be a good idea then. Byte manipulation in shell is cumbersome.)

It is a bad idea to apply the SYSLINUX program "isohybrid"
to an ISO which was equipped with advanced isohybrid by xorriso.
So one should delete line 26:
  isohybrid -h "$heads" -s "$sectors" "$iso"

> I guess -e is short for --efi-boot?

--efi-boot XYZ does a bit more:

  -eltorito-alt-boot -e XYX -no-emul-boot -eltorito-alt-boot

Since i propose to apply -isohybrid-gpt-basdat, one would
have to switch to -e . E.g.:

-                        -eltorito-alt-boot \
-                        --efi-boot boot/grub/efi.img -no-emul-boot \
+                        -eltorito-alt-boot \
+                        -e boot/grub/efi.img \
+                        -no-emul-boot -isohybrid-gpt-basdat \

-e is quite like -b, including the inappropriate default to
mark the boot image in El Torito as emulated floppy disk.
Therefore option -no-emul-boot must be given.

> I don't suppose I can tempt you into sending a patch against the above
> git repo, can I? ;-)

Seems we are not done with development yet.
There is the problem that i cannot easily test because
i have no EFI and not even a contemporary Debian.

If an authorized developer can set up a suitable environment
for production of mini.iso, i will help to adapt the scripts.
We will have to make decisions. E.g. whether to keep a BIOS-only
version of mini.iso and thus cannot hardcode the partition
number in geniso_hybrid_plus_firmware_partition.

Some experience with gdisk would be helpful. (I guess my
Debian 6 test system can give me hints.)


Alternatively one could really copy the directories and
boot program from /boot/grub/efi.img into the appended
partition and give it the type 0xef.

Having no GPT would avoid problems with the appended
partition. But it might be that some EFI implementations
will not recognize the MBR partition and insist in GPT.

Only tests can tell.

Have a nice day :)


Reply to: