Those Debian bugs refer to the creation of the /EFI/Boot/bootx64.efi bootloader, implemented these days with the --removable qualifier on grub-install, and addressed in bug 1453980 for still ignoring the --uefi-secure-boot which should force the use of shimx64.efi instead of grubx64.efi.
This bug is the USB target install problem(s) of:
1) Ignoring user input on which device to install the bootloader,
(User inputs /dev/sdc, install uses /dev/sda instead).
This leaves the ESP of the USB target empty, so the device is unbootable.
2) The bootloader files improperly dumped into the ESP of internal disk, /dev/sda,
include a grub.cfg file which links back to the grub.cfg file on the USB target,
leaving the host system unbootable without the USB present.
Bug 1229488 in additional mentions the wrong nvram changes made to the host machine
when a USB install is done, changing the shim entry to grub, and leaving a
secure boot enabled host unbootable.
Even adding a "none" option for bootloader would be an improvement, since then
the host system would not be messed up.
This is the underlying problem which boot-repair addresses after the fact.
Those Debian bugs refer to the creation of the /EFI/Boot/ bootx64. efi bootloader, implemented these days with the --removable qualifier on grub-install, and addressed in bug 1453980 for still ignoring the --uefi-secure-boot which should force the use of shimx64.efi instead of grubx64.efi.
This bug is the USB target install problem(s) of:
1) Ignoring user input on which device to install the bootloader,
(User inputs /dev/sdc, install uses /dev/sda instead).
This leaves the ESP of the USB target empty, so the device is unbootable.
2) The bootloader files improperly dumped into the ESP of internal disk, /dev/sda,
include a grub.cfg file which links back to the grub.cfg file on the USB target,
leaving the host system unbootable without the USB present.
Bug 1229488 in additional mentions the wrong nvram changes made to the host machine
when a USB install is done, changing the shim entry to grub, and leaving a
secure boot enabled host unbootable.
Even adding a "none" option for bootloader would be an improvement, since then
the host system would not be messed up.
This is the underlying problem which boot-repair addresses after the fact.