Skip to content. Skip to navigation
Sections
Personal tools
You are here: Home » Tech » Linux » Gentoo » Gentoo Kernel Upgrade Guide
Document Actions

Gentoo Kernel Upgrade Guide

by David Hostetler [modified 20110627:14:57 (Mon)] [posted 20100225:16:59 (Thu)]

When a new version of the linux kernel becomes available on Gentoo, it's a good idea to assimilate it into your system.  Ignoring kernel upgrades leaves you susceptible for longer periods to any security vulnerabilities, makes upgrading more difficult in general whenever you do it,  and complicates the task of keeping the system as a whole updated and running smoothly.

The following processes describes how to update the linux kernel on Gentoo.

  1. Notice that the new kernel has come downstream in portage (sys-kernel/gentoo-sources).  We'll call it vA.B.CD-rEF.  Each new version of the kernel gets its own slot in portage, and they'll pile up whether you use them or not.
  2. Your current kernel source will be /usr/src/linux, symlinked to the actual version folder in /usr/src.
  3. Copy your kernel config to the new version folder:
    • cd /usr/src
cp /usr/src/linux/.config /usr/src/linux-A.B.CD-rEF
  4. Now run menuconfig on the new version.  With the original config in place, menuconfig will use it  as the default for all of the options that are still valid in the new version.  Any new options will get the default value native to the version, and any deprecated options in the config file will be ignored.
    • cd /usr/src/linux-A.B.CD-rEF
make menuconfig
  5. Review anything that concerns you, or browse around for new options.
  6. If you're following my guidelines exactly, be sure to set CONFIG_LOCALVERSION (via 'General setup' -> 'Local version') as the date you're building the kernel: -yyyymmdd.  This ensures that 'uname -r' returns 'A.B.CD-gentoo-rEF-yyyymmdd'.  This is necessary to fully distinguish the kernel from any other builds you might do that use the same literal kernel version.  And it allows software that needs to use the System.map file to be able to find it correctly (again - if you use the naming scheme described below).
  7. When you're finished reviewing the options, just quit menuconfig and say 'yes' when prompted to save the .config file.
  8. Build the kernel:
    • make && make modules_install
  9. Copy the new kernel resources to your boot partition (replacing yyyymmdd with the current date):
    • cp arch/x86/boot/bzImage /boot/kernel-A.B.CD-gentoo-rEF-yyyymmdd
cp System.map /boot/System.map-A.B.CD-gentoo-rEF-yyyymmdd
cp .config /boot/config-A.B.CD-gentoo-rEF-yyyymmdd
    • The kernel itself is the bzImage file.
    • The System.map file is a symbol table used by the kernel (and some debugging tools) to map names to memory addresses.  Some software expects there to be a copy of the table as /boot/System.map-$(uname -r), which is why we went to the trouble of setting CONFIG_LOCALVERSION.
    • I include the .config file just in case I encounter a weird situation and I need to easily recover a specific kernel build, or compare two non-active configs.
  10. Set the new version as the active location for kernel source files (replace <N> with whichever number corresponds to the new version): 
    • eselect kernel list
eselect kernel set <N>
  11. Rebuild anything that is sensitive to the kernel headers: 
    • update-modules
module-rebuild populate
module-rebuild rebuild
  12. Double check that /etc/conf.d/modules contains everything it's supposed to for your system.
  13. Update your boot loader to include the new kernel as an option (preferably the default option, if you're feeling confident).  If you're using grub, just edit /boot/grub/grub.conf and include something like:
    • title  Gentoo Linux A.B.CD-rEF yyyymmdd
root (hd0,1)
kernel /kernel-A.B.CD-gentoo-rEF-yyyymmdd root=/dev/hda4
  14. Reboot!
    • Select your new version in the boot loader, cross your fingers and hope everything works ok.
    • If it doesn't, reboot again and reselect your previous version -- which is specifically why we keep it around.
    • Note that modules that were just built against the new version might not load when you revert back to the previous kernel, so you might have to work with a degraded environment while you're investigating any problem.  But usually you just need to be able to get back into the shell and reconfigure and rebuild the new one and try again.

  15. Once you're satisfied that the new kernel yields a fully functional system, you might want to clean out some (now superfluous) kernel versions.  Look at the contents of /usr/src to see which versions are still available (or use 'eselect kernel list') and just tell emerge to get rid of them (be careful with the version description):

    • emerge --unmerge -avt "<sys-kernel/gentoo-sources-A.B.CD"
    • That cleans out a lot of stuff but won't actually delete the directories in /usr/src, so you'll need to do that yourself.
    • I usually keep the last 2 or 3 versions, just to have some safe fallback options, and have configs to compare against.
    • If you're using 'emerge --depclean' to remove unused/stale stuff, you'll need to protect the few prior kernel versions for which you want to retain the source.  Note that this is strictly optional, since you've copied the pieces necessary for booting the older version into the /boot directory (you just can't easily tweak and rebuild any prior version if you've let emerge remove the source).  To protect a version from --depclean, just insert it into the world profile via:
      • emerge --noreplace =sys-kernel/gentoo-sources-A.B.CD-rEF
      • Just remember that you'll need to explicitly remove that as well, when the time comes.

 

That's it!  Have fun and enjoy keeping up with those crazy kernel hackers.