I am installing Ubuntu 17.04 (but also applies to 16.04) on cheap Acer Aspire ES series. It comes with preinstalled Windows or Linpus Linux. My came with Linpus.

As for many owners of such notebook (discussion 1, discussion 2, discussion 3, discussion 4), I also have the same problem - Ubuntu installs just fine, but system does not boot.

After some experimenting, I used the following commands, and I got the system working and booting fine:

# mmcblk0p1 is my EFI partition
# mmcblk0p2 is my root partition
sudo mount /dev/mmcblk0p2 /mnt
sudo mkdir /mnt/boot/efi
sudo mount /dev/mmcblk0p1 /mnt/boot/efi
for i in /sys /proc /run /dev; do sudo mount --bind "$i" "/mnt$i"; done
modprobe efivars
efibootmgr --verbose
apt-get install --reinstall grub-efi-amd64
grub-install --no-nvram --root-directory=/mnt
chroot /mnt
cd /boot/efi/EFI
cp -R ubuntu/ BOOT
cd BOOT cp grubx64.efi bootx64.efi
cp -R BOOT/ Linux

I am copying "ubuntu" to "BOOT" and "Linux", because Linpus had the same names in the EFI, and I suspect that they are hard-coded in the BIOS.

Also, I have tried with only the last steps -- EFI copy and renames, and it does not work. I am going to do some more complex partitioning including encrypted partitions, so I have some questions:

1. What magic is happening, when I run update-grub?

2. Are commands "modprobe efivars" and "efibootmgr --verbose" are also needed?

1 Answer 1


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:

  • I have just changed the location of the root files from /dev/sda1 to /dev/sda2. Is it enough to change the UUID ( /dev/sda2) in grub.cfg to be able to boot the system from /dev/sda2? I guess, grub-install needs to be called after changing the grub.cfg? Dec 12, 2018 at 15:17

You must log in to answer this question.

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