update-grub, at least in Debian and its relatives like Ubuntu, is basically just a wrapper around
grub-mkconfig. So it creates/updates/regenerates the GRUB configuration, not the actual bootloader itself.
grub-install actually does depends on which version of GRUB you are running: traditional BIOS GRUB or UEFI GRUB?
With the traditional BIOS GRUB,
grub-install will (re)write the part of the GRUB embedded in the Master Boot Record, and encode into it the physical disk block numbers from where to read the next part of GRUB. It will also determine from which partition the actual GRUB configuration file (
/boot/grub/grub.cfg) will be read. An important factor here is the
/boot/grub/device.map file, which tells GRUB how BIOS's (and therefore GRUB's) device numbering maps to Linux disk devices.
With the UEFI GRUB, the main part of the GRUB bootloader will be located as a file in the EFI System Partition, typically as
/boot/efi/EFI/<name of distribution>/grubx64.efi or similar. This bootloader pathname is stored in system NVRAM (= the place where BIOS settings are stored) in the UEFI boot variables. The main part of GRUB may be completely self-contained (and must be if Secure Boot is in use!) or it may load additional functionality as GRUB modules, typically from the
/boot/grub directory of the Linux distribution it's part of.
The UEFI boot variables will identify the disk the system should use to look for the EFI System Partition and the bootloader file inside it. You can view these variables yourself, using
efibootmgr -v command. The
grub-install command will update those variables, unless you use the
--no-nvram option to specify otherwise.
As a result, with both traditional BIOS and UEFI, running
grub-install can update your bootloader to read a completely different GRUB configuration file on a completely different disk - although the details of that process will be completely different.
With UEFI, you can actually change your boot device selection from within the OS, with either
grub-install is a massive overkill for that: if both your installations are UEFI and have their own separate ESP partitions, they will have their own UEFI boot variables and selecting between them can easily be done with
efibootmgr, or indeed in the UEFI BIOS settings.
With traditional BIOS, it's a bit messier: you'll want to make sure each installation's
/boot/grub/device.map identifies the disk of that specific installation as
hd0, and the other one as
hd1. Then use
grub-install to only write the bootloader to each installation's own disk; never to the "opposite" disk. That way, both disks will be completely stand-alone and bootable even if the other disk is completely removed. You can add a menu item on the configuration files of each GRUB that will allow you to boot the "opposite" installation, if you want. Or you can just use the BIOS to select the disk to boot from.
The thing you must know that the boot order selector of traditional BIOSes will usually work by making the disk selected for booting the "first" disk for BIOS functions, and so GRUB's
hd0 will always refer to "the disk that is currently selected for booting in BIOS".
So, if you are currently booting from
/dev/sda (so BIOS says
hd0), and you want a GRUB menu item on that disk to switch to
/dev/sdb's boot menu, you'd use something like:
menuentry "Switch to /dev/sdb"
# flip the disk mappings and reload configuration
drivemap -s (hd0) (hd1)
set root=<the identifier for sdb's partition that contains grub.cfg>
configfile /boot/grub/grub.cfg # or just /grub/grub.cfg is /boot is a separate partition
... and likewise on /dev/sdb's GRUB configuration too.