What magic is happening, when I run update-grub?
GRUB is a combination boot manager and boot loader for Linux -- it presents a menu of boot options (the boot manager part) and, when you select a Linux option, it loads the Linux kernel into memory and executes it (the boot loader part). These functions rely on a GRUB configuration file, stored in Ubuntu at /boot/grub/grub.cfg
; the menu is generated based on this configuration file. If the file is absent, GRUB presents a prompt that reads grub>
, which is not very helpful except to experts. If the configuration file contains incorrect information, you might or might not get a menu, and at least some menu items are likely to not work.
What update-grub
does is to scan the computer for OSes and Linux kernels and create a new grub.cfg
file. Ordinarily, this script is run automatically when you install a new kernel (which can happen in an automatic or semi-automatic way, depending on your OS update settings). You can also run update-grub
manually -- say, if you've made changes to another OS you're dual-booting and you want GRUB to recognize those changes. In your case, I'm not sure it was necessary. In theory, it should have been set up when you installed Ubuntu. OTOH, clearly that installation wasn't entirely successful, so maybe grub.cfg
was missing or misconfigured.
Are commands "modprobe efivars" and "efibootmgr --verbose" are also needed?
The modprobe efivars
command loads the efivars
kernel module, which gives the kernel access to EFI variables stored in NVRAM. These variables record things like pointers to specific boot loader files used by the firmware and the order in which those boot loaders are used. Note that the order of control during boot is EFI to GRUB (or other boot manager/loader) to OS kernel (Linux). The OS installation process therefore requires some way to tell the EFI to launch GRUB rather than some other boot loader, and the EFI variables are part of how that's done.
The efibootmgr
tool is another part of this process; it takes options to enable you to view or modify EFI variables. That is, efibootmgr
talks to the kernel, which uses its efivars
module to access the EFI's NVRAM variables. The specific efibootmgr
command you mention, efibootmgr --verbose
, merely displays the current boot variables. Thus, it's not important in the procedure you outlined and could be omitted. OTOH, the grub-install
command, on an EFI system, will ordinarily update the EFI boot variables; but the fact that you passed it the --no-nvram
option told it not to do so. This could create problems, except....
Beyond this, you've copied and renamed GRUB to two other names. One of these is the EFI fallback filename, EFI/BOOT/bootx64.efi
. This is the file that an EFI tries to run as a boot loader if it lacks EFI variables that point it to another name, or if those other entries are invalid or their binaries return to the EFI without launching an OS. Ordinarily, modifying the EFI variables via efibootmgr
(which is one thing that grub-install
will do, if called without --no-nvram
) will make a system bootable. Some computers, though, have buggy EFIs that forget or ignore their EFI variables. On such systems, copying/renaming the boot loader, as you've done, is required to get the system to boot. The fact that your "stock" installation didn't work and you had to jump through these hoops suggests you may have such a computer.
For more reading on these subjects, I recommend: