[syslinux] isohybrid --uefi - resulting EF00 partition too small

[Mattias Schlenker]

Am 12.03.2013 17:31, schrieb Thomas Schmitt:
> I reported some potential problems with isohybrid.c in may 2012:
>    http://www.syslinux.org/archives/2012-May/017843.html
> But this one is not among them.
>
> After looking into
>    http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/utils/isohybrid.c
> i got a suspicion. Function read_efi_catalogue() does this
>
>    memcpy(count, buf, 2);
>    *count = lendian_short(*count);
>
> Two bytes of block count would rollover 104448 to 38912 = 19 MiB.
>
> This is not a bug of the implementation but of the concept of
> isohybrid option --uefi. It tries to take start address and size
> from the El Torito catalog, rather than inspecting the ISO 9660
> directories.

Thanks for the explanation. Getting the size of the EFI boot image below 
19MiB looks like too much work, so I think it may make sense to do the 
one-step does it all way of xorriso.

>> Did just my large FAT image make me run into some side effects?
> It seems so. El Torito cannot record image sizes above 32 MiB.
>
> Obviously hardly anybody cared up to now.
> I will have to change this rolling over in libisofs before some
> mishap produces -boot-load-size 0 that way.
>
> But a true size of your EFI boot image cannot be stored.
> I can only store 65535 rather than 38912.

OK, shrinking my initramfs to get it somewhere between 38912 and 65535 
blocks will be a few hours of work, but probably much less than either 
switching to a different bootloader (one that allows kernel and 
initramfs to reside elsewhere which will cause different problems) or 
getting it below 38912 blocks.

But the question remains: If the El Torito specification limits the size 
of the image to 32MiB, how does it come that my 53MiB image does not 
cause errors when booting? Do current UEFI implementations just read 
linear data from the CD/DVD as long as it seems to make sense for them?

These limits remind me very much of the late 1990s when we crammed 
everything onto 2.88MiB floppy images (since many BIOSes did not support 
8MiB hard drive images) until relieve came with isolinux and no-emul-boot.


> With a younger xorriso you could try to let it generate the GPT
> together with the isohybrid MBR:
>
>    mbr_file=/usr/lib/syslinux/isohdpfx.bin
>
>    xorriso -as mkisofs \
>       -graft-points \
>       -c boot/isolinux/boot.cat \
>       -b boot/isolinux/isolinux.bin \
>         -no-emul-boot -boot-info-table -boot-load-size 4 \
>         -isohybrid-mbr $mbr_file \
>       -eltorito-alt-boot \
>       -e boot/efi.img \
>         -no-emul-boot \
>         -isohybrid-gpt-basdat \
>       -V LESSLINUX-SEARCH-AND-RESCUE \
>       -o lesslinux-search-and-rescue-uluru-20130312-110347.iso \
>       -r \
>       cdmaster \
>       --sort-weight 0 / --sort-weight 1 /boot
>
> Suitable would be the current release
>    http://www.gnu.org/software/xorriso/xorriso-1.2.6.tar.gz

I think this is the way to go.


> For compilation instructions see
>    http://www.gnu.org/software/xorriso/README_xorriso

Thanks. I already include xorriso 1.2.6 in LessLinux, but the version 
from libisoburn. Basically it would mean to move to a self containing 
build instead of using Ubuntu as a build system, a move that I intended 
earlier and that will be quite easy to accomplish. Are there any 
fundamental differences in GNU xorriso and the xorriso provided together 
with libisoburn? Reading http://www.gnu.org/software/xorriso/ suggests 
that GNU Xorriso is basically a GPL 3 repack of the otherwise identical 
GPL2 liburnia libs?

>  In principle it should be possible to present all your four intended 
> boot starting points in one ISO image. Especially the correct size for 
> the EFI FAT GPT partition should be achievable. It might be, of 
> course, that some boot facility reacts allergic on the parallel 
> existence of these starting points. 

Matthew Garret mentioned some seller of nice aluminum hardware that 
sometimes reacts allergic to this parallel starting points. We'll see. 
If we achieve the situation to have one image that runs on more than 90% 
of all PCs and have to provide another image for less than 10% it is 
relatively easy to handle.

> I repacked your ISO by essentially above command proposal:

>   fdisk reports:
>    Device       Boot      Start         End      Blocks   Id  System
>    less*47.iso2             228      104675       52224   ef  EFI (FAT-12/16/32)
>
> There are two GPT partitions.
> The first one begins at block 0 and ends after block 1413055.
> The second one starts at block 228 and ends after 104675.
>
> xorriso reports
>    Report layout: xt , Startlba ,   Blocks , Filesize , ISO image path
>    File data lba:  0 ,       57 ,    26112 , 53477376 , '/boot/efi.img'
>
> Given the block size factors between xorriso, fdisk, and GPT, this
> all seems to match.
>

Thank you! So my homework now is:

  * reduce the size of the el torito image to <32MiB
  * finally move to the self contained build to be able to use the
    latest xorriso without contaminating the hosts package management
  * use xorriso to build the ISO image in just one step

Have a nice evening!

Regards,
Mattias


-- 
Mattias Schlenker - Redaktion + EDV-Beratung + Linux-CD/DVD-Konzepte
Dietrich-Bonhoeffer-Str. 3 - 40667 MEERBUSCH - GERMANY

Telefon (VoIP "ueberall"), geschaeftlich: +49 341 39290767
Telefon (Festnetz), privat und Fax:       +49 2132 9952906
Mobil:                                    +49 163  6953657
Mobil (SIM in Testgeraeten):              +49 1578 3499550

Bitte fuer geschaeftliche Telefonate vorzugsweise die VoIP-Telefonnummer
+49 341 39290767 verwenden, da ich diese aufs Mobiltelefon routen kann!

http://blog.rootserverexperiment.de/ http://news.mattiasschlenker.de/