Thanks Ubfan, that is helpful so next time it happens to Ben or someone
else, if they are lucky enough to find this bug report they know what to
do. It is normal for a machine to have multiple EFI entries, and Windows is
ok with that.If you see Grub, you have selected to boot into Linux. All you
have to do is instead choose to boot into Windows via the EFI options.
Supporting multiple boots is part of the design of EFI. So the bug of the
installer does not render Windows unbootable. But it is very annoying none
the less.

On Wed, 9 Nov 2022 at 10:35, Ubfan <email address hidden> wrote:

> Admittedly, clobber means different things to different people, but 100% of
> people who UEFI boot off an sda, and try an Ubuntu install to a USB target,
> and specify the target's EFI as the bootloader location, (without taking
> the
> corrective measures detailed in the bug or askubuntu question 16988), will
> be
> faced with a grub prompt at reboot after removal of the USB target.  Of
> these,
> 98%+ will be in a state of panic or near panic.
>
> For those people: DON'T PANIC.
> A Window only machine, or a dual boot with Windows can ALWAYS use the EFI
> menu
> to boot Windows. This avoids grub completely.The EFI menu is invoked by
> some
> machine specific key at power-up to allow a choice of device or OS to boot)
> The key may be listed on the initial splash screen at power-up, but usually
> one of these: ESC, F1, F10, F12, DEL.
>
> Any OS (think Ubuntu) on the host depending upon grub to boot is stuck
> behind
> the grub prompt without the USB target present. All caused by using the USB
> target's UUID instead of the host's root UUID in the EFI partition's three
> line
> stub file ...EFI/ubuntu/grub.cfg. If you know the partition number x for
> the
> OS root, simply type:
> configfile (hd0,x)/boot/grub/grub.cfg
> and get back to a grub menu, boot the host, then do two things:
> 1)Fix your target -- simply copy the host's EFI files to
> the USB target's EFI to make the USB bootable. You don't need
> the ...EFI/Microsoft... files, but they don't hurt anything.
> 2)Fix the host -- run:
> sudo grub-install /dev/sda
>
> Leaving the USB in place will work, for awhile. The grub menu is produced
> from
> the USB's /boot/grub/grub.cfg file. If you boot the host OS, updates may
> change kernels, and the host's grub.cfg, but not the USB target's grub.cfg
> file. If you don't notice your running kernel is not the latest kernel in
> this
> situation, eventually the USB grub.cfg may be too obsolete to contain any
> kernel left on the host, you can no longer boot, and you have joined the
> "Update Broke My Machine" queue. Boot the USB before this happens and at
> least
> run update-grub if you don't actually update a kernel. This will keep the
> USB's grub.cfg file current.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1396379
>
> Title:
>   installer uses first EFI system partition found even when directed
>   otherwise
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

-- 
Tim Richardson