Optional: Installing firmware and/or microcode
Before getting to configuring kernel sections, it is beneficial to be aware that some devices require additional firmware to be installed on the system before they will operate correctly. This is often the case for network interfaces, especially wireless network interfaces commonly used in both desktop and laptop computers. Modern video chips from vendors like AMD, Nvidia, and Intel, often need external firmware files to be fully functional. Most firmware for modern hardware is available in the sys-kernel/linux-firmware package. On systems using graphics cards from these vendors, it is wise to emerge this firmware package in order to have it available before configuring and compiling the kernel.
emerge --ask sys-kernel/linux-firmware
In addition to discrete graphics hardware and network interfaces, CPUs also can require firmware updates. Typically this kind of firmware is referred to as microcode. Newer revisions of microcode are sometimes necessary to patch instability, security concerns, or other bugs in CPU hardware.
Microcode updates for AMD CPUs are typically distributed with the aforementioned linux-firmware package. Microcode for Intel CPUs can be found in the sys-firmware/intel-microcode package, which will need to be installed separately. See the Microcode article for more information on how to apply microcode updates.
Kernel configuration and compilation
Now it is time to configure and compile the kernel sources. There are three approaches for this:
- The kernel is manually configured and built.
- A tool called genkernel is used to automatically build and install the Linux kernel.
- A Distribution Kernel is used to automatically build and install the Linux kernel like any other package.
Manual configuration is explained as the default choice since it is the best way to optimize an environment.
The core around which all distributions are built is the Linux kernel. It is the layer between the user programs and the system hardware. Gentoo provides its users several possible kernel sources. A full listing with description is available at the Kernel overview page.
Installing the sources
When manually installing and compiling the kernel for mips-based systems, Gentoo recommends the sys-kernel/mips-sources package.
Choose an appropriate kernel source and install it using emerge:
emerge --ask sys-kernel/mips-sources
This will install the Linux kernel sources in /usr/src/ using the specific kernel version in the path. It will not create a symbolic link by itself without
USE=symlink being enabled on the chosen kernel sources package.
It is conventional for a /usr/src/linux symlink to be maintained, such that it refers to whichever sources correspond with the currently running kernel. However, this symbolic link will not be created by default. An easy way to create the symbolic link is to utilize eselect's kernel module.
For further information regarding the purpose of the symlink, and how to manage it, please refer to Kernel/Upgrade.
First, list all installed kernels:
eselect kernel list
Available kernel symlink targets:  linux-3.16.5-gentoo
In order to create a symbolic link called linux, use:
eselect kernel set 1
ls -l /usr/src/linux
lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-3.16.5-gentoo
Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true - after configuring a couple of kernels no one remembers that it was difficult!
However, one thing is true: it is vital to know the system when a kernel is configured manually. Most information can be gathered by emerging sys-apps/pciutils which contains the lspci command:
emerge --ask sys-apps/pciutils
Inside the chroot, it is safe to ignore any pcilib warnings (like pcilib: cannot open /sys/bus/pci/devices) that lspci might throw out.
Another source of system information is to run lsmod to see what kernel modules the installation CD uses as it might provide a nice hint on what to enable.
Now go to the kernel source directory and execute make menuconfig. This will fire up menu-driven configuration screen.
The Linux kernel configuration has many, many sections. Let's first list some options that must be activated (otherwise Gentoo will not function, or not function properly without additional tweaks). We also have a Gentoo kernel configuration guide on the Gentoo wiki that might help out further.
Activating required options
When using sys-kernel/gentoo-sources, it is strongly recommend the Gentoo-specific configuration options be enabled. These ensure that a minimum of kernel features required for proper functioning is available:
Gentoo Linux ---> Generic Driver Options ---> [*] Gentoo Linux support [*] Linux dynamic and persistent device naming (userspace devfs) support [*] Select options required by Portage features Support for init systems, system and service managers ---> [*] OpenRC, runit and other script based systems and managers [*] systemd
When using sys-kernel/vanilla-sources, the additional selections for init systems will be unavailable. Enabling support is possible, but goes beyond the scope of the handbook.
Make sure that every driver that is vital to the booting of the system (such as SCSI controller, etc.) is compiled in the kernel and not as a module, otherwise the system will not be able to boot completely.
Next select the exact processor type. It is also recommended to enable MCE features (if available) so that users are able to be notified of any hardware problems. On some architectures (such as x86_64), these errors are not printed to dmesg, but to /dev/mcelog. This requires the app-admin/mcelog package.
Also select Maintain a devtmpfs file system to mount at /dev so that critical device files are already available early in the boot process (CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT):
Device Drivers ---> Generic Driver Options ---> [*] Maintain a devtmpfs filesystem to mount at /dev [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs
Verify SCSI disk support has been activated (CONFIG_BLK_DEV_SD):
Device Drivers ---> SCSI device support ---> <*> SCSI disk support
Now go to File Systems and select support for the filesystems that will be used by the system. Do not compile the file system that is used for the root filesystem as module, otherwise the system may not be able to mount the partition. Also select Virtual memory and /proc file system. Select one or more of the following options as needed by the system (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, and CONFIG_TMPFS):
File systems ---> <*> Second extended fs support <*> The Extended 3 (ext3) filesystem <*> The Extended 4 (ext4) filesystem <*> Reiserfs support <*> JFS filesystem support <*> XFS filesystem support <*> Btrfs filesystem support DOS/FAT/NT Filesystems ---> <*> MSDOS fs support <*> VFAT (Windows-95) fs support Pseudo Filesystems ---> [*] /proc file system support [*] Tmpfs virtual memory file system support (former shm fs)
If PPPoE is used to connect to the Internet, or a dial-up modem, then enable the following options (CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY):
Device Drivers ---> Network device support ---> <*> PPP (point-to-point protocol) support <*> PPP support for async serial ports <*> PPP support for sync tty ports
The two compression options won't harm but are not definitely needed, neither does the PPP over Ethernet option, that might only be used by ppp when configured to do kernel mode PPPoE.
Don't forget to include support in the kernel for the network (Ethernet or wireless) cards.
Most systems also have multiple cores at their disposal, so it is important to activate Symmetric multi-processing support (CONFIG_SMP):
Processor type and features ---> [*] Symmetric multi-processing support
In multi-core systems, each core counts as one processor.
If USB input devices (like keyboard or mouse) or other USB devices will be used, do not forget to enable those as well (CONFIG_HID_GENERIC and CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD):
Device Drivers ---> HID support ---> -*- HID bus support <*> Generic HID driver [*] Battery level reporting for HID devices USB HID support ---> <*> USB HID transport layer [*] USB support ---> <*> xHCI HCD (USB 3.0) support <*> EHCI HCD (USB 2.0) support <*> OHCI HCD (USB 1.1) support
Preparing the configuration
On the Origin 200/2000, Indigo2 Impact (R10000), Octane/Octane2 and O2, a 64-bit kernel is required to boot these systems. For these machines, emerge sys-devel/kgcc64 to create a cross-compiler for building 64-bit kernels.
Many of the systems supported have sample .configs hiding in amongst the kernel source. Not all systems have configs distributed in this way. Those that do, can be configured using the commands mentioned in the table below.
|Cobalt Servers||make cobalt_defconfig|
|Indy, Indigo2 (R4k), Challenge S||make ip22_defconfig|
|Origin 200/2000||make ip27_defconfig|
|Indigo2 Impact (R10k)||make ip28_defconfig|
All of the Gentoo installation images provide a kernel config option as part of the image itself, accessible as /proc/config.gz. This may be used in many cases. It is best though if the kernel source matches closely the kernel that is currently running. To extract it, simply run it through zcat as shown below.
zcat /proc/config.gz > .config
This kernel config is set up for a netboot image. That is, it will expect to find a root filesystem image somewhere nearby, either as a directory for initramfs, or a loopback device for initrd. When executing make menuconfig, don't forget to go into General Setup and disable the options for initramfs.
Customizing the configuration
Once a configuration is found, download it into the kernel source directory, and rename it to .config. From there, run make oldconfig to bring everything up to date according to the instructions above, and customize the configuration before compiling.
cp /path/to/example-config .config
Just press the ENTER (or Return) key at each prompt to accept the defaults for now ...
In the Kernel Hacking section, there is an option named "Are You Using A Cross Compiler?". This tells the kernel Makefiles to prepend "mips-linux-" (or mipsel-linux ... etc) to gcc and as commands when compiling the kernel. This should be turned off, even if cross-compiling. Instead, if a cross-compiler needs to be called, specify the prefix using the CROSS_COMPILE variable as shown in the next section.
There is a known issue with JFS and ALSA on Octane systems where the ALSA fails to work. Given the experimental nature of JFS on MIPS, it is recommended that people avoid using JFS for the time being.
Compiling and installing
Now that the kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process:
On 64-bit machines, specify CROSS_COMPILE=mips64-unknown-linux-gnu- (or mips64el-... if on a little-endian system) to use the 64-bit compiler.
To compile natively:
make vmlinux modules modules_install
Cross-compiling on target machine, adjust the mips64-unknown-linux-gnu- accordingly:
make vmlinux modules modules_install CROSS_COMPILE=mips64-unknown-linux-gnu-
When compiling on another machine, such as an x86 box, use the following commands to compile the kernel & install modules into a specific directory to be transferred to the target machine.
make vmlinux modules CROSS_COMPILE=mips64-unknown-linux-gnu-
make modules_install INSTALL_MOD_PATH=/somewhere
When compiling a 64-bit kernel for the Indy, Indigo2 (R4k), Challenge S and O2, use the vmlinux.32 target instead of vmlinux. Otherwise, the machine will not be able to boot. This is to work around the PROM not understanding the ELF64 format.
It is possible to enable parallel builds using
make -jXwith X being the number of parallel tasks that the build process is allowed to launch. This is similar to the instructions about /etc/portage/make.conf earlier, with the MAKEOPTS variable.
The above will create vmlinux.32, which is the final kernel.
When the kernel has finished compiling, copy the kernel image to /boot/.
On Cobalt servers, the bootloader will expect to see a compressed kernel image. Remember to gzip -9 the file once it is in /boot/.
cp vmlinux /boot/kernel-3.16.5-gentoo
For Cobalt servers, compress the kernel image:
gzip -9v /boot/kernel-3.16.5-gentoo
Optional: Building an initramfs
In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs.
Without an initramfs, there is a risk that the system will not boot properly as the tools that are responsible for mounting the file systems require information that resides on unmounted file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.
If using genkernel, it should be used for both building the kernel and the initramfs. When using genkernel only for generating an initramfs, it is crucial to pass
--kernel-config=/path/to/kernel.configto genkernel or the generated initramfs may not work with a manually built kernel. Note that manually built kernels go beyond the scope of support for the handbook. See the kernel configuration article for more information.
To install an initramfs, install sys-kernel/dracut first, then have it generate an initramfs:
emerge --ask sys-kernel/dracut
The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:
Now continue with Kernel modules.
Alternative: Using genkernel
If a manual configuration looks too daunting, then consider using genkernel. It will configure and build the kernel automatically.
genkernel works by configuring a kernel nearly identically to the way the installation CD kernel is configured. This means that when genkernel is used to build the kernel, the system will generally detect hardware it was built for support with at boot-time, just like the installation CD does. genkernel may be a useful solution for those users who may not be comfortable compiling their own kernels. Note that genkernel does not automatically generate a custom kernel configuration the hardware on which it is being run.
Now, let's see how to use genkernel. First, emerge the sys-kernel/genkernel ebuild:
emerge --ask sys-kernel/genkernel
Next, edit the /etc/fstab file so that the line containing /boot/ as second field has the first field pointing to the right device. If the partitioning example from the handbook is followed, then this device is most likely /dev/sda1 with the ext4 file system. This would make the entry in the file look like so:
nano -w /etc/fstab
/dev/sda1 /boot ext4 defaults 0 2
Further in the Gentoo installation, /etc/fstab will be configured again. The /boot setting is needed right now as the genkernel application reads in this configuration.
Now, compile the kernel sources by running genkernel all. Be aware though, as genkernel compiles a kernel that supports almost all hardware, this compilation will take quite a while to finish!
If the root partition/volume doesn't use ext4 as filesystem it might be necessary to manually configure the kernel using genkernel --menuconfig all and add support for this particular filesystem in the kernel (i.e. not as a module). Users of LVM2 will probably want to add
--lvmas an argument as well.
Once genkernel completes, a kernel, full set of modules and initial ram disk (initramfs) will be created. We will use the kernel and initrd when configuring a boot loader later in this document. Write down the names of the kernel and initrd as this information is used when the boot loader configuration file is edited. The initrd will be started immediately after booting to perform hardware autodetection (just like on the installation CD) before the "real" system starts up.
ls /boot/vmlinu* /boot/initramfs*
Configuring the modules
Hardware modules are optional to be listed manually. udev will normally load all hardware modules that are detected to be connected in most cases. However, it is not harmful for automatically detected modules to be listed. Sometimes exotic hardware requires help to load their drivers.
List the modules that need to be loaded automatically in /etc/modules-load.d/*.conf files one module per line. Extra options for the modules, if necessary, should be set in /etc/modprobe.d/*.conf files.
To view all available modules, run the following find command. Don't forget to substitute "<kernel version>" with the version of the kernel just compiled:
find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less
For instance, to automatically load the 3c59x.ko module (which is the driver for a specific 3Com network card family), edit the /etc/modules-load.d/network.conf file and enter the module name in it. The actual file name is insignificant to the loader.
mkdir -p /etc/modules-load.d
nano -w /etc/modules-load.d/network.conf
Continue the installation with Configuring the system.