In certain cases (e.g. toolchain changes) the size of the created EFI
blob can end up triggering a rounding down which breaks the build.
Example:
debian/util/geniso src/bin-combined/ipxe.iso src/bin-i386-pcbios/ipxe.lkrn \
src/bin-x86_64-efi/ipxe.efi
...
++ stat -c %s src/bin-x86_64-efi/ipxe.efi
+ blocks=896
+ mkfs.msdos -C src/bin-combined/iso.dir.uayAjK/efi.img 896
+ mmd -i src/bin-combined/iso.dir.uayAjK/efi.img ::efi
+ mmd -i src/bin-combined/iso.dir.uayAjK/efi.img ::efi/boot
+ mcopy -o -i src/bin-combined/iso.dir.uayAjK/efi.img \
src/bin-x86_64-efi/ipxe.efi ::efi/boot/bootx64.efi
Disk full
This is due to:
echo $(($(stat -c %s "$EFI") / 1024))
872
echo $(($(stat -c %s "$EFI") / 1024 + 55))
927
echo $(((($(stat -c %s "$EFI") / 1024 + 55)/32*32)))
896 <- Rounds DOWN
This is due to size+55 => 927 being "just below" the next 32 iteration
which would be at 928. In many cases that works fine (I don't know how
the +55 was invented, I guess that is for headers). But in some cases
it caps too much eventually ending up in a too small image file.
Rounding up (in bash) usually is "N+1/divisor". Therefore if add +1 before
the rounding for 32 we'd avoid the issue.
I compared the resulting ISO size with former builds and it was still
well within the range of past builds (869,947,948 - now 884).
