Your problem was caused by a longstanding bug in Ubiquity. In brief, Ubiquity (the Ubuntu Desktop installer) ignores the specification of the disk to which GRUB should install when you install in EFI mode. That information won't really help you fix the problem, but it's worth knowing. There are a couple of ways of changing your boot disk as you want....
The Easy Solution
The Boot Repair tool should be able to do this semi-automatically. It's been a while since I've used Boot Repair, so I can't provide step-by-step instructions, but it should be able to install GRUB 2 on your /dev/sdb. I'm not 100% sure that it will change what's mounted at /boot/efi in Ubuntu, though. It may also fail if your /dev/sdb doesn't have an ESP or if the tool runs into any other unexpected pitfalls.
The Hard Solution
To solve the problem manually, you should first verify that your /dev/sdb has an EFI System Partition (ESP). This is easily done with various partitioning tools; for instance, with gdisk, you'd list the partitions and look for a partition with a type code of EF00:
$ sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.9
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdb: 15628053168 sectors, 7.3 TiB
Model: TOSHIBA HDWF180
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): A29BEED8-295E-48F3-A7E5-2C1C669A0226
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 15628053134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1128447 550.0 MiB EF00 Unused ESP
2 1128448 3225599 1024.0 MiB 8300 Unused /boot
3 3225600 15628053134 7.3 TiB 8E00 Linux LVM
This example is taken from one of my computers, and it shows an ESP on /dev/sdb1 with the name Unused ESP. Yours likely would not have that name. If you see an ESP, you should double-check that it has a FAT filesystem with the blkid utility:
$ sudo blkid /dev/sdb1
/dev/sdb1: PARTLABEL="Unused ESP" PARTUUID="94c47102a617-4224-9f29-5779220d4b7f"
This example shows that the partition has no filesystem -- they're normally explicitly identified, as in this example on the same computer:
$ sudo blkid /dev/nvme0n1p1
/dev/nvme0n1p1: LABEL_FATBOOT="NVME_SSD" LABEL="NVME_SSD" UUID="6CB1-160F" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="5f63fbfe-1a11-4ed8-80ff-13f1df6f04c0"
Note the TYPE="vfat" description in this case; this ESP (I haven't shown the gdisk output on the NVMe device, but it's got an EF00 type code) is ready for use -- in fact, it's how this particular computer boots.
In any event, if your /dev/sdb has an ESP and if it uses FAT, then it's ready to go. If not, then you'll have to set up an ESP on the drive. That's a whole other issue, so I won't go into it here. Since you say the computer originally booted Windows 10, chances are it has an ESP, but I can't be certain of that, so you should check this detail.
Because your Ubuntu installation is using the ESP from /dev/sda now, you need to change that, and not just for the GRUB installation. You need to edit /etc/fstab: Find the line that defines /boot/efi and alter it to refer to the ESP on /dev/sdb, rather than the one on /dev/sda. For instance, your current /etc/fstab might have a line like the following:
# /boot/efi was on /dev/sda1 during installation
UUID=6CB1-160F /boot/efi vfat umask=0077 0 1
Note that in this example, the ESP is identified as having UUID=6CB1-160F, which is the same UUID code that sudo blkid /dev/nvme0n1p1 showed earlier. (Technically it's not a UUID, but that's another matter....) In your case, I'd expect the UUID to match what blkid shows as being on your /dev/sda1. Use the output of the blkid command on the ESP on /dev/sdb to find the UUID of that partition. For instance, suppose the new ESP's UUID is 66F7-FD24. You'd edit the line in your /etc/fstab to read:
UUID=66F7-FD24 /boot/efi vfat umask=0077 0 1
Save the changes, type sudo umount /boot/efi, and then sudo mount -a. Your /dev/sdb ESP should now be mounted at /boot/efi, which you can verify with df /boot/efi:
$ df /boot/efi
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 562080 14124 547956 3% /boot/efi
Your Linux installation has now mounted the ESP from /dev/sdb on /boot/efi; however, GRUB is still not installed there. Fortunately, that part is easy:
$ sudo grub-install
Under EFI, it's my understanding that grub-install ignores the device specification; instead, it installs GRUB to /boot/efi and sets up an EFI BootOrder variable to match. (A caveat: I use my own rEFInd on most of my computers, not GRUB 2, so I'm less familiar with the grub-install details, and I may be missing something. The documentation isn't exactly crystal-clear on this detail.)
You may want to use efibootmgr to verify the change. Type sudo efibootmgr and check that the first item in BootOrder is not the same as the BootCurrent line; but both of them should be ubuntu items. For instance, here's some output:
$ sudo efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0004,0000,0006,0007,0008,0001,0002,0003
Boot0000* ubuntu
Boot0001* UEFI:CD/DVD Drive
Boot0002* UEFI:Removable Device
Boot0003* UEFI:Network Device
Boot0004* ubuntu
Boot0006* UEFI OS
Boot0007* Hard Drive
Boot0008* CD/DVD Drive
In this example, the computer is currently booted through Boot0000, but it will boot next time through Boot0004. Both are ubuntu items, which point to GRUB 2 on the ESPs on /dev/sda and /dev/sdb, respectively. You can add -v to the efibootmgr command to see more details, like this:
Boot0000* ubuntu HD(1,GPT,5f63fbfe-1a11-4ed8-80ff-13f1df6f04c0,0x800,0x114000)/File(\EFI\UBUNTU\SHIMX64.EFI)
The long string of hexadecimal numbers (5f63fbfe-1a11-4ed8-80ff-13f1df6f04c0) is a GUID, which should match the PARTUUID reported by blkid, as this one does for my computer's /dev/nvme0n1p1, shown earlier.
After rebooting to be sure it's working, if you want to be thorough about this, you can mount the ESP for your /dev/sda somewhere convenient (like /mnt) and delete the EFI/ubuntu directory on that partition. This will eliminate the duplicate GRUB 2 installation.
