Handbook:PPC/Installation/Kernel
Optional: Installing firmware and/or microcode
Firmware
Suggested: Linux Firmware
On many systems, non-FOSS firmware is required for certain hardware to function. The sys-kernel/linux-firmware package contains firmware for many, but not all, devices.
Most wireless cards and GPUs require firmware to function.
root #emerge --ask sys-kernel/linux-firmwareInstalling certain firmware packages often requires accepting the associated firmware licenses. If necessary, visit the license handling section of the Handbook for help on accepting licenses.
Firmware Loading
Firmware files are typically loaded when the associated kernel module is loaded. This means the firmware must be built into the kernel using CONFIG_EXTRA_FIRMWARE if the kernel module is set to Y instead of M. In most cases, building-in a module which required firmware can complicate or break loading.
sys-kernel/installkernel
Installkernel may be used to automate the kernel installation, initramfs generation, unified kernel image generation and/or bootloader configuration among other things. sys-kernel/installkernel implements two paths of achieving this: the traditional installkernel originating from Debian and systemd's kernel-install. Which one to choose depends, among other things, on the system's bootloader. By default, systemd's kernel-install is used on systemd profiles, while the traditional installkernel is the default for other profiles.
Bootloader
Now is the time to think about which bootloader the user wants for the system, if unsure, follow the 'Traditional layout' subsection below.
GRUB
Users of GRUB can use either systemd's kernel-install or the traditional Debian installkernel. The systemd USE flag switches between these implementations. To automatically run grub-mkconfig when installing the kernel, enable the grub USE flag.
/etc/portage/package.use/installkernelsys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel
Traditional layout, other bootloaders (e.g. (e)lilo, syslinux, etc.)
The traditional /boot layout (for e.g. (e)LILO, syslinux, etc.) is used by default if the grub, systemd-boot, efistub and uki USE flags are not enabled. No further action is required.
Initramfs
An initial ram-based file system, or initramfs, may be required for a system to boot. A wide of variety of cases may necessitate one, but common cases include:
- Kernels where storage/filesystem drivers are modules.
- Layouts with /usr/ or /var/ on separate partitions.
- Encrypted root filesystems.
Distribution kernels are designed to be used with an initramfs, as many storage and filesystem drivers are built as modules.
In addition to mounting the root filesystem, an initramfs may also perform other tasks such as:
- Running file system consistency check fsck, a tool to check and repair consistency of a file system in such events of uncleanly shutdown a system.
- Providing a recovery environment in the event of late-boot failures.
Installkernel can automatically generate an initramfs when installing the kernel if the dracut or ugrd USE flag is enabled:
/etc/portage/package.use/installkernelsys-kernel/installkernel dracut
root #emerge --ask sys-kernel/installkernel
Kernel configuration and compilation
It's can be a wise move to use the dist-kernel on the first boot as it provides a very simple method to rule out system issues and kernel config issues. Always having a known working kernel to fallback on can speed up debugging and alleviate anxiety when updating that your system will no longer boot.
Now it is time to configure and compile the kernel sources. For the purposes of the installation, three approaches to kernel management will be presented, however at any point post-installation a new approach can be employed.
Ranked from least involved to most involved:
- Full automation approach: Distribution kernels
- A Distribution Kernel is used to configure, automatically build, and install the Linux kernel, its associated modules, and (optionally, but enabled by default) an initramfs file. Future kernel updates are fully automated since they are handled through the package manager, just like any other system package. It is possible provide a custom kernel configuration file if customization is necessary. This is the least involved process and is perfect for new Gentoo users due to it working out-of-the-box and offering minimal involvement from the system administrator.
- Full manual approach
- New kernel sources are installed via the system package manager. The kernel is manually configured, built, and installed using the eselect kernel and a slew of make commands. Future kernel updates repeat the manual process of configuring, building, and installing the kernel files. This is the most involved process, but offers maximum control over the kernel update process.
- Hybrid approach: Genkernel
- We use the term hybrid here but, do note that the dist-kernel and manual sources, both include methods to achieve the same goal. New kernel sources are installed via the system package manager. System administrators may use Gentoo's genkernel tool to configure, build, and install the Linux kernel, its associated modules, and (optionally, but not enabled by default) an initramfs file. It is possible provide a custom kernel configuration file if customization is necessary. Future kernel configuration, compilation, and installation require the system administrator's involvement in the form of running eselect kernel, genkernel, and potentially other commands for each update. This option should only considered for users that know they have a need for genkernel
The core around which all distributions are built is the Linux kernel. It is the layer between the user's programs and the system hardware. Although the handbook provides its users several possible kernel sources, a more comprehensive listing with more detailed descriptions is available at the Kernel overview page.
Kernel installation tasks such as copying the kernel image to /boot or the EFI System Partition, generating an initramfs and/or Unified Kernel Image, updating bootloader configuration, can be automated with installkernel. Users may wish to configure and install sys-kernel/installkernel before proceeding. See the Kernel installation section below for more more information.
Distribution kernels
Distribution Kernels are ebuilds that cover the complete process of unpacking, configuring, compiling, and installing the kernel. The primary advantage of this method is that the kernels are updated to new versions by the package manager as part of @world upgrade. This requires no more involvement than running an emerge command. Distribution kernels default to a configuration supporting the majority of hardware, however two mechanisms are offered for customization: savedconfig and config snippets. See the project page for more details on configuration.
Optional: Signed kernel modules
The kernel modules in the prebuilt distribution kernel (sys-kernel/gentoo-kernel-bin) are already signed. To sign the modules of kernels built from source enable the modules-sign USE flag, and optionally specify which key to use for signing in /etc/portage/make.conf:
/etc/portage/make.confEnable module signingUSE="modules-sign"
# Optionally, to use custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate.
MODULES_SIGN_HASH="sha512" # Defaults to sha512.
If MODULES_SIGN_KEY is not specified the kernel build system will generate a key, it will be stored in /usr/src/linux-x.y.z/certs. It is recommended to manually generate a key to ensure that it will be the same for each kernel release. A key may be generated with:
root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pemThe MODULES_SIGN_KEY and MODULES_SIGN_CERT may be different files. For this example the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
OpenSSL will ask some questions about the user generating the key, it is recommended to fill in these questions as detailed as possible.
Store the key in a safe location, at the very least the key should be readable only by the root user. Verify this with:
root #ls -l kernel_key.pem-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
If this outputs anything other then the above, correct the permissions with:
root #chown root:root kernel_key.pemroot #chmod 400 kernel_key.pem
Installing a distribution kernel
To build a kernel with Gentoo patches from source, type:
root #emerge --ask sys-kernel/gentoo-kernelSystem administrators who want to avoid compiling the kernel sources locally can instead use precompiled kernel images:
root #emerge --ask sys-kernel/gentoo-kernel-binDistribution Kernels, such as sys-kernel/gentoo-kernel and sys-kernel/gentoo-kernel-bin, by default, expect to be installed alongside an initramfs. Before running emerge to install the kernel users should ensure that sys-kernel/installkernel has been configured to utilize an initramfs generator (for example Dracut) as described in the installkernel section.
Upgrading and cleaning up
Once the kernel is installed, the package manager will automatically update it to newer versions. The previous versions will be kept until the package manager is requested to clean up stale packages. To reclaim disk space, stale packages can be trimmed by periodically running emerge with the --depclean option:
root #emerge --depcleanAlternatively, to specifically clean up old kernel versions:
root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-binBy design, emerge only removes the kernel build directory. It does not actually remove the kernel modules, nor the installed kernel image. To completely clean-up old kernels, the app-admin/eclean-kernel tool may be used.
Post-install/upgrade tasks
An upgrade of a distribution kernel is capable of triggering an automatic rebuild for external kernel modules installed by other packages (for example: sys-fs/zfs-kmod or x11-drivers/nvidia-drivers). This automated behaviour is enabled by enabling the dist-kernel USE flag. When required, this same flag will also trigger re-generation of the initramfs.
It is highly recommended to enable this flag globally via /etc/portage/make.conf when using a distribution kernel:
/etc/portage/make.confEnabling USE=dist-kernelUSE="dist-kernel"
Manually rebuilding the initramfs or Unified Kernel Image
If required, manually trigger such rebuilds by, after a kernel upgrade, executing:
root #emerge --ask @module-rebuildIf any kernel modules (e.g. ZFS) are needed at early boot, rebuild the initramfs afterward via:
root #emerge --config sys-kernel/gentoo-kernel
root #emerge --config sys-kernel/gentoo-kernel-bin
Installing the kernel sources
When installing and compiling the kernel for ppc-based systems, Gentoo recommends the sys-kernel/gentoo-sources package.
Choose an appropriate kernel source and install it using emerge:
root #emerge --ask sys-kernel/gentoo-sourcesThis 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 the symlink USE flag 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:
root #eselect kernel listAvailable kernel symlink targets: [1] linux-6.6.21-gentoo
In order to create a symbolic link called linux, use:
root #eselect kernel set 1root #ls -l /usr/src/linuxlrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo
Alternative: Manual configuration
In case it was missed, this section requires the kernel sources to be installed. Be sure to obtain the relevant kernel sources, then return here for the rest of section.
Manually configuring a kernel is commonly seen as one of the most difficult procedures a system administrator has to perform. Nothing is less true - after configuring a few kernels no one remembers that it was difficult! There are two ways for a Gentoo user to manage a manual kernel system, both of which are listed below:
Modprobed-db process
A very easy way to manage the kernel is to first install sys-kernel/gentoo-kernel-bin and use the sys-kernel/modprobed-db to collect information about what the system requires. modprobed-db is a tool which monitors the system via crontab to add all modules of all devices over the system's life to make sure it everything a user needs is supported. For example, if an Xbox controller is added after installation, then modprobed-db will add the modules to be built next time the kernel is rebuilt. More on this topic can be found in the Modprobed-db article.
Manual process
This method allows a user to have full control of how their kernel is built with as minimal help from outside tools as they wish. Some could consider this as making it hard for the sake of it.
However, with this choice 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:
root #emerge --ask sys-apps/pciutilsInside 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.
root #cd /usr/src/linux
The kernel has a method of autodetecting the modules currently being used on the installcd which will give a great starting point to allow a user to configure their own. This can be called by using:
root #make localmodconfigIt's now time to configure using nconfig:
root #make nconfigThe 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.
Enabling 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
Naturally the choice in the last two lines depends on the selected init system (OpenRC vs. systemd). It does not hurt to have support for both init systems enabled.
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.
Enabling support for typical system components
Make sure that every driver that is vital to the booting of the system (such as SATA controllers, NVMe block device support, filesystem support, etc.) is compiled in the kernel and not as a module, otherwise the system may 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 device support
<*> SCSI disk support
Device Drivers --->
<*> Serial ATA and Parallel ATA drivers (libata) --->
[*] ATA ACPI Support
[*] SATA Port Multiplier support
<*> AHCI SATA support (ahci)
[*] ATA BMDMA support
[*] ATA SFF support (for legacy IDE and PATA)
<*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)
Verify basic NVMe support has been enabled:
Device Drivers --->
<*> NVM Express block device
Device Drivers --->
NVME Support --->
<*> NVM Express block device
It does not hurt to enable the following additional NVMe support:
[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
[*] NVMe Target Passthrough support
<M> NVMe loopback device support
<M> NVMe over Fabrics FC target driver
< > NVMe over Fabrics FC Transport Loopback Test driver (NEW)
<M> NVMe over Fabrics TCP target 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:
File systems --->
<*> Second extended fs support
<*> The Extended 3 (ext3) filesystem
<*> The Extended 4 (ext4) filesystem
<*> Btrfs filesystem support
<*> XFS 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 over Ethernet
<*> 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:
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
<*> Unified support for USB4 and Thunderbolt --->
Optional: Signed kernel modules
To automatically sign the kernel modules enable CONFIG_MODULE_SIG_ALL:
[*] Enable loadable module support
-*- Module signature verification
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
Optionally change the hash algorithm if desired.
To enforce that all modules are signed with a valid signature, enable CONFIG_MODULE_SIG_FORCE as well:
[*] Enable loadable module support
-*- Module signature verification
[*] Require modules to be validly signed
[*] Automatically sign all modules
Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->
To use a custom key, specify the location of this key in CONFIG_MODULE_SIG_KEY. If unspecified, the kernel build system will generate a key. It is recommended to generate one manually instead. This can be done with:
root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pemOpenSSL will ask some questions about the user generating the key, it is recommended to fill in these questions as detailed as possible.
Store the key in a safe location, at the very least the key should be readable only by the root user. Verify this with:
root #ls -l kernel_key.pem-r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem
If this outputs anything other then the above, correct the permissions with:
root #chown root:root kernel_key.pem
root #chmod 400 kernel_key.pem
-*- Cryptographic API --->
Certificates for signature checking --->
(/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key
To also sign external kernel modules installed by other packages via linux-mod-r1.eclass, enable the modules-sign USE flag globally:
/etc/portage/make.confEnable module signingUSE="modules-sign"
# Optionally, when using custom signing keys.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem" # Only required if the MODULES_SIGN_KEY does not also contain the certificate
MODULES_SIGN_HASH="sha512" # Defaults to sha512
MODULES_SIGN_KEY and MODULES_SIGN_CERT may point to different files. For this example, the pem file generated by OpenSSL includes both the key and the accompanying certificate, and thus both variables are set to the same value.
Architecture specific configuration
Before starting to configure the Linux kernel, run make pmac32_defconfig to make sure a kernel is created that boots on most 32-bit PowerPC systems:
root #cd /usr/src/linux
root #make pmac32_defconfig
root #make menuconfigMake sure to enable support for Amiga partitions if using a Pegasos system, or Macintosh partitions when using an Apple computer.
Users of NewWorld and OldWorld machines will want HFS support as well. OldWorld users require it for copying compiled kernels to the MacOS partition. NewWorld users require it for configuring the special Apple_Bootstrap partition:
File Systems --->
Miscellaneous filesystems --->
<M> Apple Macintosh file system support
<M> Apple Extended HFS file system support
Don't forget to include support in the kernel for the right Ethernet card! Most newer Apple computers use the SunGEM Ethernet driver. Older iMacs commonly use the BMAC driver.
Device Drivers --->
Network device support --->
Ethernet (10 or 100Mbit) --->
[*] Ethernet (10 or 100Mbit)
<*> Generic Media Independent Interface device support
<*> MACE (Power Mac ethernet) support
<*> BMAC (G3 ethernet) support
<*> Sun GEM support
When booting from FireWire, enable the following options.
Device Drivers --->
IEEE 1394 (FireWire) support --->
<*> IEEE 1394 (FireWire) support
<*> OHCI-1394 support
<*> SBP-2 support (Harddisks etc.)
Do not turn off kernel framebuffer support as it is required for a successful boot. When using an NVIDIA based chipset, use the Open Firmware framebuffer. When using an ATI based chipset, select the framebuffer driver based upon the right chipset (Mach64, Rage128, or Radeon).
Device Drivers --->
Graphics support --->
<*> Support for frame buffer devices
[*] Open Firmware frame buffer device support
<*> ATI Radeon display support
<*> ATI Rage128 display support
<*> ATI Mach64 display support
Console display driver support --->
<*> Framebuffer Console support
To select more than one framebuffer device, it may default to a less than optimal driver. Either use only one framebuffer device or specify which to use by passing the driver to use to the kernel on boot by appending a video line such as
video=radeonfb.Compiling and installing
With the kernel is configured, it is time to compile and install it. Exit the configuration menu and run the following commands:
root #make && make modules_installIt is possible to enable parallel builds using make -j N with N being the integer 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.
When the kernel has finished compiling, copy the kernel image to /boot/. This is handled by the make install command. When using BootX to boot, the kernel will be copied later.
root #make installThis command will copy the kernel image to /boot. If sys-kernel/installkernel is installed it will call /sbin/installkernel instead and delegate the kernel installation. Instead of simply copying the kernel to /boot, Installkernel installs each kernel with its version number in the file name. Additionally, installkernel provides a framework for automatically accomplishing various tasks relating to kernel installation, such as: generating an initramfs, building an Unified Kernel Image, and updating the bootloader configuration.
Deprecated: Genkernel
Genkernel should only be considered by users with a required need that only Genkernel can meet. For others, it is recommended to use the Distribution kernel or manually compile their own as it will make maintaining a Gentoo system a lot more simple. An example of why genkernel is more difficult to manage is the lack of integration with sys-kernel/installkernel. This means a user will not get the same level of automation as provided by the other methods; for example, Unified Kernel Images will need to be created manually when using Genkernel.
Users still wishing to use Genkernel should see the Genkernel article for more information.
Kernel modules
Listing available kernel 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 modules that will be automatically loaded to be listed. Modules cannot be loaded twice; they are either loaded or unloaded. Sometimes exotic hardware requires help to load their drivers.
The modules that need to be loaded during each boot in can be added to /etc/modules-load.d/*.conf files in the format of one module per line. When extra options are needed for the modules, they should be set in /etc/modprobe.d/*.conf files instead.
To view all modules available for a specific kernel version, issue the following find command. Do not forget to substitute "<kernel version>" with the appropriate version of the kernel to search:
root #find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | lessForce loading particular kernel modules
To force load the kernel to 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 within it.
root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf
Note that the module's .ko file suffix is insignificant to the loading mechanism and left out of the configuration file:
/etc/modules-load.d/network.confForce loading 3c59x module3c59x
Continue the installation with Configuring the system.