Create a bigger image for the filesystem which holds the EFI binaries

[pasja]

Due to a missing full rebuild I have skipped over the fact that the new EFI binaries are larger than 4Mb totally.

du /usr/share/grml-live/templates/EFI/debian/BOOT/
4696    /usr/share/grml-live/templates/EFI/debian/BOOT/

If one have commit 721a4734446cf9e1dd9b4e4c1360c22821b86986 then the build fails with the unhelpful disk full message.

Luckily the bailout mechanism helps here a lot, it was easy to pinpoint the failing mcopy command and track that back to dd

Now I have done:

• a full rebuild
• write the resulting image with grml2usb to a USB stick
• boot from that USB stick with Secure Boot enabled

Everything was as it should be.

[mika]

@pasja uh nice catch! I'm wondering whether we have a better way to calculate the disk size instead of forcing it to 8MB, or if we don't mind about the 8MB and we actually don't waste any disk space or memory on ISO? Hmmm

[pasja]

Good question! I just went blindly forward and doubled the space in spirit of the age old tradition :) I don't know how often those binaries are changing. It wouldn't be so great if each and every EFI update could trigger a recalculation of needed space...

So personally I am willing to sacrifice that amount of space for pure convenience.

Oooor we could enhance the grml-live script to check the size of the binaries(we know that in advance) and create the image accordingly. Here the tradeoff lies between complexity and reservation of that space.

[mika]

@pasja what do you think about https://github.com/grml/grml-live/pull/132? (We shouldn't increase EFI image when secure boot isn't used, and on i386 it doesn't make sense either, AFAICT)

[pasja]

LGTM, feel free to merge #132

[mika]

Thank you, @pasja!