Code review comment for lp:~dannf/debian-cd/lp1692876

Hi,

> https://code.launchpad.net/~dannf/debian-cd/lp1692876-2
> would you mind taking a look to see that I've accurately understood?

1974: Ok.
      It removes the BIOS options which would get wiped away by the
      subsequent -eltorito-alt-boot (and then again by the built-in
      -eltorito-alt-boot of --efi-boot).

1975: Ok.
      The still surplus -eltorito-alt-boot is gone.
      Here you created the capability to boot from USB stick.
      The option -no-emul-boot is still (harmlessly) surplus, because
      of the implicit -eltorito-alt-boot at the end of --efi-boot.
      So -no-emul-boot, which would be necessary with -e, has no no
      boot image to apply to.

1976: Ok.

1977: Ok.
      (Now get xorriso-1.4.8 to get its beneficial ISO size claim which
       protects the EFI partition from mishaps by established procedures
       which rely on /sbin/isosize being equal to image file size.)

> Two things I did not (yet) include are the change from -efi-boot to -e

There is no hard need to do so. If you stay with --efi-boot, then you
should remove the -no-emul-boot option.
If you switch to -e, then the -no-emul-boot will be necessary.

> and the addition of -no-pad.

This will save 300 KiB of image size.

> I'm not sure I understand the difference the former makes in our use case.

Effectively there is no difference.
The surrounding implicit -eltorito-alt-boot options of --efi-boot are not
really needed here, because you only have one El Torito boot image.
The implicit -no-emul-boot of --efi-boot would have to be given explicitely
if you switch to -e.

-eltorito-alt-boot is just a spearator between the definitions of boot
images. It's harmless to pile this option up, unless it splits a boot
image from its options. I.e. this would be bad:

  -e /boot/grub/efi.img -eltorito-alt-boot -no-emul-boot

because -e would have no -no-emul-boot. This would cause the catalog
entry of the boot image to bear the mark for floppy emulation.
UEFI specs demand that it must be marked for no emulation (although
the EFI partition image is not a plain binary but rather a FAT filesystem).

> The latter seems to be for images that are not intended to be burned,
> while this one certainly could be. Is there a reason
> that it is no longer relevant?

The traditional padding is a somewhat misguided preparation for burning
onto CD media with write type Track-At-Once (TAO). I tried to explain the
real problem to the Linux SCSI people in
  https://www.spinics.net/lists/linux-scsi/msg94638.html
Having surplus bytes at the end of the CD prevents Linux from incidentially
trying to read the two unreadable final "run-out" blocks which get added
by TAO.

For users it is only important to know that any image that is too big
for CD does not need this padding, because it cannot be burnt by CD TAO.

Additional precaution is that the burn programs for CD add an own padding
by default, just out of the same misguided idea of the problem.
(My programs do it too. Who am i to change such an old tradition ?)

But there were versions of blkid which run into the TAO problem regardless
of padding. This caused my post to linux-scsi above.
I assume that they are not around any more. The Linux bug still is.

Have a nice day :)

Thomas