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?

1 Answer 1


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:

  1. 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)
  2. 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'
  3. 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.

  • 5
    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
    Commented Jun 27, 2019 at 23:03
  • 1
    "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
    Commented Jan 29, 2020 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
    Commented Jan 29, 2020 at 17:36
  • 1
    I had to print this out and read it thrice. But now I really got it. This is the best explanation with the whole context (beyond .cfg-creation) by and far. Thank you!
    – Frank N
    Commented May 2, 2021 at 10:42
  • 1
    @FlexMcMurphy I added description of how GRUB typically finds its configuration file in both legacy and UEFI cases.
    – telcoM
    Commented Nov 27, 2021 at 12:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .