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.
What the 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.
Once GRUB is running, the next thing to be determined is: where it should read its configuration file from?
grub-install has the capability to insert the desired value of the GRUB prefix variable directly into the main part of GRUB. This embedded prefix can either fully specify the path, or leave some parts out to be determined at run-time, using architecture-specific defaults.
With a traditional BIOS GRUB, the embedded prefix usually leaves the actual disk specifier out, so the same disk GRUB was loaded from will be used. In that case, the stored prefix will be e.g. (,msdos1)/grub when
/boot is the first primary partition on the disk GRUB is installed to.
With the UEFI GRUB, the embedded prefix usually specifies just the directory, and then it refers to the distribution's directory on the EFI System Partition (ESP). So a typical embedded prefix would be /EFI/debian or /EFI/redhat or similar. The default value for the disk and partition will be "the same partition the UEFI GRUB binary was loaded from".
Some distributions like RHEL will just place the actual configuration for UEFI GRUB directly onto the ESP. Debian and related distributions will usually do one more bit of indirection: the mini-grub.cfg file on the ESP will contain just a few lines that will tell GRUB to read the real configuration file from what will be /boot/grub/grub.cfg once Linux has booted up and mounted all the disks. At its simplest, this mini-configuration will be just three lines:
- Setting the GRUB root to point to the filesystem that contains the real GRUB configuration file (for the upcoming
configfile command), in modern distributions usually using the search command and a filesystem UUID. The oldest implementations of this scheme might have actually used a fixed GRUB partition specification, e.g. set root=(hd0,gpt1)
- Setting the GRUB
prefix variable (to enable GRUB module auto-loading if Secure Boot is not in effect). If the filesystem where the configuration will be loaded is the Linux root filesystem, this line will be set prefix=($root)'/boot/grub'; if /boot is a separate filesystem, this line will be set prefix=($root)'/grub'
- Reading the actual GRUB configuration file with
configfile $prefix/grub.cfg.
If the filesystem that contains the GRUB configuration is on a LVM logical volume, encrypted volume, or a software RAID set, then the first line will be more complex or there might even be additional line(s) as necessary.
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 efibootmgr or grub-install. But 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 sda is 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.
