[Bug 1541178] Re: multiple installations forget which grub.cfg to read on efi

[Phillip Susi]

If updating changed the EFI cfg then each install would randomly steal
control of the boot loader from the other, which is not desirable.  It
also would not help the uninstall case unless you happened to uninstall
just after an upgrade in one of the other systems happened to steal
control of the boot.  You need to pick one to be in charge and not have
grub installed in the others.  As for keeping the master up to date, you
just have to run update-grub.


** Changed in: grub2 (Ubuntu)
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to grub2 in Ubuntu.
https://bugs.launchpad.net/bugs/1541178

Title:
  multiple installations forget which grub.cfg to read on efi

Status in grub2 package in Ubuntu:
  Won't Fix

Bug description:
  When multiple copies of Ubuntu are installed on the one machine there
  are multiple copies of /boot/grub/grub.cfg.  In my case there is one
  for 14.04 LTS (on partition 5) and one for a pre-release version of
  16.04 (on partition 11), plus some others.

  During installation on an UEFI machine yet another grub.cfg file is
  written to /boot/efi/EFI/ubuntu/grub.cfg (on partition 2 in my case)
  which apparently does little more than tell grubx64.efi which
  partition to search for the "real" grub.cfg file.  So far, so good.

  The problem is that kernel updates do not update the one and only
  /boot/efi/EFI/ubuntu/grub.cfg only installations do that.  So, the
  most recently installed /boot/grub/grub.cfg (from 16.04 alpha on
  partition 11) continues to be one used even after a kernel upgrade on
  14.04 LTS.

  The result is that one version of Ubuntu continues to run an old
  kernel because the other version of Ubuntu does not know about it.

  This could be solved by rewriting /boot/efi/EFI/ubuntu/grub.cfg with
  every kernel installation, or better still with every run of grub-
  install.  Possibly any existing grub.cfg could be moved to
  grub.cfg.old.

  Also, consider what would happen if a test installation was made along
  side a live installation and then deleted.  The test installation
  would hijack /boot/efi/EFI/ubuntu/grub.cfg to point to the test
  installation's /boot/grub/grub.cfg, which no longer exists, making the
  live installation unbootable.

  Does continuing to run an old kernel mean that this bug report should
  be marked as a security vulnerability?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1541178/+subscriptions