See this bug:
https://bugs.archlinux.org/task/16702#comment80122
And this blogpost:
http://losinggeneration.homelinux.org/2009/10/16/why-arch-linuxs-kernel-upgrades-suck/
So far I haven't found a good solution, but I will update if I do.
One thing to keep in mind beyond grub, the kernel, and initrd is /usr/lib/modules/. When the linux package updates the old package deletes it's folders in /usr/lib/modules/ and the new kernel adds its new modules. If you want both kernels working, you're going to want both sets of modules. And /usr/src/ contains the kernel headers (needed to build new modules, such as the nvidia drivers), so you'll probably want to keep those, too.
The steps I guess would be something like:
1. Detect linux package is going to be upgraded.
2. Backup what it's going to delete on uninstall (/usr/src/$(uname -r), /usr/lib/modules/$(uname -r), /boot/{vmlinuz-linux,initramfs-linux.img,initramfs-linux-fallback.img})
3. Let pacman do its upgrade
4. Restore everything in 2 (probably giving a new name to the stuff in /boot
5. Edit grub or whatever.
Alternate steps (somewhat less good)
1. Let pacman update
2. Detect kernel was updated
3. from /var/cache/packman/pkg/linux-${previous_version}-pkg.tar.xz extract /usr/src/, /usr/lib/{modules,extramodules}, and /boot/vmlinuz (renaming the one in /boot, obviously)
4. run mkinitcpio with the -k option to build the old init
5. Edit grub or whatever
In this alternate method, you loose your 3rd party modules (virtual box, ATI/Nvidia, etc), but it might be something you could run from cron and automagically detect kernel updates have occured.
In legacy bios systems, the bios looks up the Master Boot Record (MBR) of the disk it is set to boot. This is the first 512 bytes of the disk and contains the first stage of the bootloader process, this will be grub in your case. The sole job of this stage is to locate and load the second stage normally on the drive that contains /boot. The MBR has these paths hardcoded into it and in order to change them you must reinstall the MBR from the system (or chroot of the system) you want it to point to using grub-install. If you can boot the system then this is trivial, but if you cannot then you must use a livecd and chroot into your system; see the instructions here on how to do that.
However, in your case the antergos grub config will not have the ubuntu distro in it so you will lose the ability to boot that until you add it. You can also configure the ubuntu grub config to boot antergos by default if this is your intended goal. Either approach is acceptable and depends on what you want to achieve.
Best Answer
I think most distributions have moved additional kernels into the advanced options sub menu at this point, as TomTom found was the case with his Arch.
I didn't want to alter my top level menu structure in order to select a previous kernel as the default. I found the answer here:
http://www.humans-enabled.com/2014/08/how-to-set-default-grub-kernel-boot.html
To summarize:
1) Find the
$menuentry_id_optionfor the submenu:2) Find the
$menuentry_id_optionfor the menu entry for the kernel you want to use:3) Comment out your current default grub in
/etc/default/gruband replace it with the sub-menu's$menuentry_id_optionfrom step one, and the selected kernel's$menuentry_id_optionfrom step two separated by>.In my case the modified
GRUB_DEFAULTis:4) Update grub to make the changes. For Debian this is done like so:
Done. Now when you boot, the advanced menu should have an asterisk and you should boot into the selected kernel. You can confirm this with
uname.Changing this back to the most recent kernel is as simple as commenting out the new line and uncommenting
#GRUB_DEFAULT=0:then rerunning
update-grub.