Some examples found online say that update-grub should be run AFTER grub-install. Others reverse the order. Which is correct?

If I have two Linux installations (one on sda and one on sdb), if I run update-grub on the sda installation, it will place the sda installation at the top of the boot menu. If I run update-grub on the sdb installation, it will place the sdb installation at the top of the menu.

Assuming DEFAULT=0, this should, theoretically, allow me to select my OS by selecting the boot device in the BIOS. Does "grub-install /dev/sda" change the sda boot menu to correspond to the last "update-grub", regardless if it was run from the sda or sdb version of Linux?


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.

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.

| improve this answer | |
  • so run update-grub before grub-install (not that it should make a difference, but for UEFI) or the opposite? – Gaia Jun 27 '19 at 22:21
  • 3
    grub-install installs the binary part(s) of GRUB, update-grub produces just the configuration file. If you need to completely reinstall your GRUB, I'd say run grub-install first. It may actually run update-grub for you as part of the job - if it doesn't, you can then run it yourself afterwards. – telcoM Jun 27 '19 at 23:03
  • "own UEFI boot variables" --> So if I understood correctly in a UEFI setup, the UEFI boot vars in NVRAM are like an array that specify the boot disk? What happens if one disk fails; can one specify a fallback / multiple values of this array? Furthemore if I understood, the user can always bypass the UEFI boot var by merely manually specifying the boot disk (effectively what the UEFI boot var is doing)? Thank you. – ninjagecko Jan 29 at 17:26
  • 1
    @ninjagecko Your understanding is correct but perhaps incomplete. The UEFI boot variables specify not only the partition UUID to boot from, but the pathname of the bootloader file, a human-readable name, and an optional parameter field. And yes, you can specify multiple (sets of) values, specify the order to attempt them in, and even tell the system to boot a specific option out of the normal order for just this once, then resume using the normal order. These are all standard features of the UEFI spec; the firmware authors can, provide even more options if they want. – telcoM Jan 29 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.