How to update grub on a dual boot machine?

Question

I have a machine which installed a ubuntu 16.04 on one partition and a ubuntu 16.10 on another. I have a 200m partition which mounts /boot/efi.

Basically I use 16.04 and use the grub installed by 16.04.

Sometimes I get on 16.10 and update the kernel. However, I cannot update the grub of my 16.04 without entering it. So I have to do grub-install on 16.10 in order to boot the new kernel. Then when I come back to 16.04, I update-grub and grub-install, which is stupid I think.

How can I update the grub of 16.04 without entering it, is there a good solution?

Can I do something like updating the grub config file or using another partition as /boot? Is this kind of operation dangerous?

Answer 1

You can directly boot a partition, not a specific kernel. Debian based (not sure about others distributions) add a link in / to newest kernel and second newest also. So you boot link to newest kernel. Turn off os-prober, copy boot stanza for your drive & partition into 40_custom.

Backup current grub.cfg and then edit 40_custom

sudo cp -a /boot/grub/grub.cfg /boot/grub/grub.cfg.backup
sudo nano /etc/grub.d/40_custom

Add an entry like this to 40_custom, use your drive & partition in place of (hd1,1) & sdb1:

menuentry "Install on sdb1" {
    set root=(hd1,1)
    linux /vmlinuz root=/dev/sdb1 ro quiet splash
    initrd /initrd.img
}

Edit grub to turn off os-prober:

sudo nano /etc/default/grub

Add this line to grub so it does not add its entries and update grub:

GRUB_DISABLE_OS_PROBER=true

And update grub with all the changes:

sudo update-grub

Older similar entry, also has UUID version:

How to add a GRUB2 menu entry for booting installed Ubuntu on a USB drive?

Details: How to: Create a Customized GRUB2 Screen that is Maintenance Free.- Cavsfan

https://help.ubuntu.com/community/MaintenanceFreeCustomGrub2Screen

https://help.ubuntu.com/community/Grub2/CustomMenus

Answer 2

You've described a fundamental limitation of GRUB: It relies on configuration files that can be generated only within Ubuntu (or some other OS that supports GRUB). Normally, running sudo update-grub within the OS/distribution that controls GRUB should do the trick. In some cases (but probably not yours), there may be issues that would make this fail, in which case even more awkward hoop-jumping would be required.

There are several alternative approaches:

• My own rEFInd boot manager does not rely on a preconfigured list of kernels; instead, it scans for boot loaders and Linux kernels at boot time, and creates a new boot list dynamically. (There are some caveats relating to filesystem drivers, configuration options, and kernel names; but this works well for typical Ubuntu installations.) This approach makes rEFInd much easier to deal with than GRUB for computers with multiple Linux distributions, since rEFInd will pick up the new kernels whenever you reboot, no matter which distribution you used to install rEFInd and which distribution has new kernel(s).
• If you use a boot loader, like GRUB Legacy or ELILO, that uses a simpler configuration file format that's stored on the EFI System Partition (ESP), you can maintain it manually. This adds effort to kernel upgrades, but if you have multiple distributions, this may be preferable to rebooting into Distribution B when you update Distribution A's kernel. See this page of mine for information on alternative EFI boot loaders for Linux.
• The Boot Loader Specification is a proposal for a way to impose some standardization in boot loader configuration. If adopted, it would make it possible for Distribution A to update its kernel configuration in a way that Distribution B's boot loader would immediately recognize and honor. Personally, I think this proposal has some serious flaws, but it also addresses an important problem. I've seen little evidence that any of the big players (Canonical, Red Hat, Novell, etc.) are getting behind it, so this isn't really a practical possibility today and isn't likely to be one in the near future. I thought I'd mention it so you can consider writing tools yourself that would make Ubuntu compatible with it, and/or lobby Canonical to adopt this approach.

I'm biased, of course, but IMHO right now rEFInd is the best way around the problem you're experiencing. OTOH, rEFInd is not yet an official Ubuntu package (although it should be in the future; it's now in Debian testing, and so should make it into Ubuntu eventually). It also requires some extra hoop-jumping if you want to use Secure Boot.

Answer 3

Well ... how can GRUB know that there was a new kernel installed, when you do not execute the sudo update-grub command ? So this is unavoidable, but reinstalling GRUB on the other hand does not explicitly have to be done - you can choose to boot the new kernel from the advanced boot options in the GRUB menu. Reinstalling GRUB on the main operating system you are using brings more convenience though, because you can boot the other system directly from the first level of the boot menu. Unfortunately there is no other option to handle this dual boot setup ...