Guía de configuración del núcleo en Gentoo

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Kernel/Gentoo Kernel Configuration Guide and the translation is 54% complete.

Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎日本語 • ‎한국어 • ‎русский

Este documento tiene la finalidad de presentar conceptos sobre la configuración manual del núcleo y detallar algunos de los problemas de configuración más comunes.

Introducción

Gentoo ofrece dos formas para que los usuarios puedan gestionar la instalación, configuración y actualización del núcleo: la automática (con genkernel) y la manual. Aunque el método se puede verse como más fácil para la mayoría de los usuarios, hay un gran número de razones por las cuales una gran proporción de usuarios Gentoo escogen configurar sus núcleos manualmente:

  1. Mayor flexibilidad
  2. Menores tamaños (del núcleo)
  3. Menores tiempos de compilación
  4. La experiencia del aprendizaje
  5. Aburrimiento severo
  6. Conocimiento absoluto de la configuración del núcleo, o
  7. Completo control

Esta guía no cubre el método automático (genkerne). Si se prefiere utilizar genkernel para gestionar las cuestiones relacionadas con el núcleo, eche un vistazo al artículo sobre Genkernel para más detalles.

Esta guía no persigue documentar el proceso de configuración manual desde el principio hasta el final. El proceso de configuración depende en mayor medida del sentido común y un grado de conocimiento técnico relativamente alto acerca del sistema que se está utilizando. En lugar de esto, se presentan los conceptos de la configuración manual y detallan los problemas más comunes a los que se enfrentan los usuarios.

Nota
Esta guía documento está escrito tomando en cuenta las versiones más recientes del núcleo, para las arquitecturas de computadora más comunes. Algunos detalles pueden ser distintos para núcleos más antiguos o para arquitecturas más exóticas, sin embargo, la mayor parte del contenido seguirá siendo relevante.

En este punto asumiremos que se dispone de las fuentes del núcleo Linux desempaquetadas en el disco duro (usualmente en algún lugar bajo /usr/src) y se supone que se debe saber como entrar en la configuración menuconfig y cómo navegar a través de su sistema de menús basado en ncurses. Si el usuario no tiene estos conocimiento, hay otros documentos disponibles que le pueden ayudar. Se deben leer los siguientes artículos antes de volver a esta guía:

Conceptos de configuración

Lo básico

El proceso general es realmente simple: se presentan una serie de opciones categorizadas en menús individuales y submenús y se selecciona el soporte hardware deseado y las características relevantes del núcleo aplicadas al sistema.

El núcleo incluye una configuración por defecto que se presenta la primera vez que se lanza menuconfig en un conjunto particular de fuentes. Los valores por defecto normalmente son amplios y adecuados, lo que significa que la mayoría de los usuarios tendrán que realizar pocos cambios a la configuración base. Si se decide deshabilitar una opción que estaba habilitada por defecto, se debe asegurar que se tiene una buena comprensión relativamente bien lo que hace la opción y las consecuencias que pueden acarrear su deshabilitación.

La primera vez que se se configura el núcleo Linux, se debe ser conservador, no muy aventurero, y en la medida de los posible, realizar las menor cantidad de modificaciones a los ajustes por defecto. Recuerde también que hay ciertas partes en el ajuste de un sistema que deben ser personalizadas para que el sistema arranque.

Incluidas frente a modulares

La mayoría de las opciones de configuración tienen tres estados: se puede evitar su construcción (N), se pueden construir para formar parte integral del núcleo (Y) o construidas como un módulo (M). Los módulos se almacenan externamente en el sistema de ficheros, mientras que las opciones incluidas forman parte de la propia imagen del núcleo.

Hay una diferencia importante entre opciones incluidas y modulares: con pocas excepciones, el núcleo no hace ningún intento de cargar módulos externos cuando el sistema los necesita, esto se deja por cuenta del usuario para que decida cuándo a cuándo no se debe cargar un módulo. Mientras que otras partes del sistema puedan cargar módulos bajo demanda, se recomienda que construya las opciones de soporte de hardware y características del núcleo incluidas. El núcleo puede entonces asegurar que la funcionalidad y soporte de hardware estén disponibles cuando hagan falta. Esto se hace activando todas las características del sistema (Y). Para que esta configuración sea coherente también es necesario incluir soporte para el firmware en el núcleo. Esto se hace definiendo FW_LOADER=y y CONFIG_FIRMWARE_IN_KERNEL=y en el fichero .config del núcleo o mediante:

KERNEL Habilitar firmware en el núcleo
Device Drivers  --->
   Generic Driver Options  --->
       -*- Userspace firmware loading support
       [*] Include in-kernel firmware blobs in kernel binary

For other parts of the configuration, built-in is an absolute requirement. For example, if the root partition was an btrfs filesystem the system would not boot if btrfs was built as a module. The system would have to look on the root partition to find the btrfs module (since modules are stored in the root partition), but it cannot look on the root partition unless it already has btrfs support loaded! If btrfs has not been built-in then the init process will fail to find the root device.

Soporte del hardware

Beyond detecting the architecture type of the system, the configuration utility makes no attempt to identify what hardware is actually present in the system. While there are default settings for some hardware support, users almost certainly need to find and select the configuration options relevant to each system's hardware configuration.

Selecting the proper configuration options requires a knowledge of the components inside and connected to the computer. Most of the time these components can be identified without taking the lid off the system. For most internal components, users need to identify the chipset used on each device, rather than the retailed product name. Many expansion cards are retailed with a certain brand name, but use another manufacturer's chipset.

There are some utilities available to help users determine what kernel configuration options to use. lspci (part of the sys-apps/pciutils package) will identify PCI-based and AGP-based hardware, this includes components built onto the motherboard itself. lsusb (from the sys-apps/usbutils package) will identify various devices connected to the system's USB ports.

The situation is somewhat confused by varying degrees of standardization in the hardware world. Unless the user selects extreme deviation from the default configuration settings, the IDE hard disks should "just work", as will the PS/2 or USB keyboard and mouse. Basic VGA display support is also included. However, some devices such as Ethernet adapters are hardly standardized at all; for these devices users will have to identify the Ethernet chipset and select the appropriate hardware support for the specific card to get network access.

In addition, while some things just-about-work with the default settings, more specialized options may need to be selected to get the full potential from the system. For example, if support for the appropriate IDE chipset has not been enabled, the IDE hard disks will run very slowly.

Características del núcleo

In addition to hardware support, users need to consider the software features that will be required in the kernel. One important example of such a feature is filesystem support: users must select support for the filesystems in use on their hard disks, as well as any filesystems they might use on external storage devices (e.g. VFAT on USB drives).

Another common software feature example is advanced network functionality. In order to do some kind of routing or firewalling the relevant configuration items must be included in the kernel configuration.

¿Preparado?

Now that the concepts have been introduced, it should be easy to start identifying the system hardware, browsing through the menuconfig interface, and selecting the required kernel options for the system.

The rest of this guide should clear up common areas of confusion, and provide advice for how to avoid common problems which users often run into. Best wishes!

Problemas comunes y áreas de confusión

Los discos SATA son SCSI

La mayoría de sistemas de escritorio modernos incorporan dispositivos de almacenamiento (discos duros y discos CD/DVD) en un bus Serial ATA, en lugar del más antiguo tipo de bus IDE (cable plano).

SATA support in Linux is implemented in a layer referred to as libata, which sits below the SCSI subsystem. For this reason, SATA drivers are found in the SCSI driver section of the configuration. Additionally, the system's storage devices will be treated as SCSI devices, which means SCSI disk/cdrom support will also be required. The first SATA hard disk will be named /dev/sda and the first SATA CD/DVD drive will be named /dev/sr0.

Aunque la mayoría de estos controladores son para dispositivos SATA, libata no diseñó para ser específica de SATA. Todos los controladores IDE comunes también se migrarán a libata en un futuro cercano y en ese momento, las consideraciones mencionadas anteriormente se podrán aplicar también a los usuarios de dispositivos IDE.

KERNEL Configuration options for libata
Device Drivers  --->
 SCSI device support  --->
  <*> SCSI device support
  <*>   SCSI disk support
  <*>   SCSI CDROM support
  [ ] SCSI low-level drivers  ----
  <*> Serial ATA and Parallel ATA drivers (libata)  --->


Nota
Los chipsets no estándar se listan debajo de "SCSI low-level drivers" en la caja del núcleo Configuration options for libata mostrada arriba.

Chipsets IDE y DMA

Despite the introduction of SATA, IDE devices are still very common and depended upon by many systems. IDE is a fairly generic technology, and as such, Linux supports almost all IDE controllers out-of-the-box without any controller-specific options selected.

However, IDE is an old technology, and in its original Programmed Input/Output incarnation, it is unable to provide the transfer rates required for speedy access to modern storage devices. The generic IDE driver is limited to these PIO transfer modes which result in slow data transfer rates and significantly high CPU usage while data is being transferred to and from disk.

Unless a user is dealing with a pre-1995 system, the IDE controller will also support an alternative transfer mode, known as Direct Memory Access (DMA). DMA is much much faster, and CPU utilization is barely affected while data transfers are taking place. If the system is suffering from really poor general system performance while it is using an IDE disk, chances are that DMA is not being used and should be enabled.

Nota
As mentioned earlier, libata is available even for IDE drives. If using libata, then all the drives, including IDE drives, will be using DMA. There is no need to do any further checking or configuration.

When not using libata for IDE disks check for DMA usage and enable it. The following command can be used to determine if DMA is being used:

root #hdparm -d /dev/hda
/dev/hda:
  using_dma = 0 (off)

To enable DMA on IDE devices set the configuration option for the appropriate IDE controller.

KERNEL Configuration options for IDE controllers
Device Drivers  --->
 ATA/ATAPI/MFM/RLL support  --->
  <*> ATA/ATAPI/MFM/RLL support
  <*>   Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
  [*]     PCI IDE chipset support
Nota
Select the correct chipset(s) from the choices listed under "PCI IDE chipset support" in the Configuration options for IDE controllers kernel box above.

Controladores de anfitrión USB

USB es un bus ampliamente adoptado para conectar periféricos externos a una computadora. Una de las razones del éxito de USB es que es un protocolo estandarizado. Sin embargo, los dispositivos controladores de anfitrión (HCDs) implementados en la computadora anfitriona varían un poco. Hay tres tipos:

The information in this article is probably outdated. You can help the Gentoo Wiki by verifying and updating this article.
  1. UHCI es el Interfaz Universal Controlador de Anfitriones (Universal Host Controller Interface). Ofrece soporte para USB 1.1 y normalmente se encuentra en placas base con un chipset VIA o Intel.
  2. OHCI es el Interfaz Abierto Controlador de Anfitriones (Open Host Controller Interface). Ofrece soporte para USB 1.1 y normalmente se encuentra en placas base con un chipset Nvidia o SiS.
  3. EHCI es el Interfaz Controlador de Anfitriones Extendido (Extended Host Controller Interface). Es el único controlador de anfitriones común que soporta USB 2.0 y se puede encontrar normalmente en cualquier computador que soporte USB 2.0.
The information in this article is probably outdated. You can help the Gentoo Wiki by verifying and updating this article.

Most systems come with two of the above interface types: EHCI (USB 2.0), plus either UHCI or OHCI (USB 1.1). To use USB devices, it is important to remember to select both types present on the system. While all USB 2.0 devices are backwards compatible with USB 1.1, a large proportion of USB devices (even the ones being manufactured today) are based on the USB 1.1 interface - why would a USB mouse need more than 1.5Mb/s?

If the relevant options corresponding to the USB HCD types present on the system are not selected, then 'dead' USB ports may be experienced. This case can be determined if a working USB device is plugged in, but it does not get power or respond in any way.

A neat lspci trick (from the sys-apps/pciutils package) makes it relatively easy to detect which HCDs are present on system. Ignoring the FireWire controller which was also matched, it is easy to spot that this system requires OHCI and EHCI support:

root #lspci -v | grep HCI
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI])
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI])
01:0b.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 61) (prog-if 10 [OHCI])

Select the HCDs present on the system. In general select all three options for maximum support, or if the correct option is uncertain:

Device Drivers  --->
 USB support  --->
  <*> Support for Host-side USB
  ---   USB Host Controller Drivers
  <*>   EHCI HCD (USB 2.0) support
  <*>   OHCI HCD support
  <*>   UHCI HCD (most Intel and VIA) support

En la versión 3.12.13 de núcleo y posteriores, se tiene que habilitar OHCI support for PCI-bus USB controllers (CONFIG_USB_OHCI_HCD_PCI) si el controlador es un OHCI y se utiliza un ratón o teclado USB.

Multiprocessor, Hyper-Threading and multi-core systems

Many computer systems are based on multiple processors, but not always in an immediately obvious way.

  • Many of Intel's CPUs support a technology which they call hyper-threading. This technology enables a single CPU to be viewed by the system as two logical processors.
  • Most Intel/AMD CPUs actually consist of multiple physical processors inside a single package, these processors are known as multi-core processors.
  • Some high-end computer systems actually have multiple physical processors installed on specialized motherboards to provide a significant performance increase over a uniprocessor system. System users will probably know if they have such a system, since they are not cheap.

In all of these cases, the appropriate kernel options must be selected to obtain optimum performance from these setups:

KERNEL Configuration for multi-processing support
Processor type and features  --->
 [*] Symmetric multi-processing support
 [*]   SMT (Hyperthreading) scheduler support
 [*]   Multi-core scheduler support (NEW)

La siguiente opción únicamente habilita las características de gestión de la energía, sin embargo, puede ser también un requisito para que todas las CPUs estén disponibles en el sistema:

KERNEL Gestión de la energía en sistemas multiprocesador
Power management and ACPI options  --->
 [*] ACPI (Advanced Configuration and Power Interface) Support

Soporte para memoria alta en x86

Due to limitations in the 32-bit address space of the x86 architecture, a kernel with default configuration can only support up to 896MB RAM. If a system has more memory, only the first 896MB will be visible, unless high memory support has been enabled.

Nota
Esta limitación es específica a la arquitectura x86 (IA32). Las demás arquitecturas soportan naturalmente grandes cantidades de memoria, sin requerir afinamientos en la configuración.

El soporte para la memoria alta no está activado por defecto porque introduce un pequeño costo en términos de rendimiento. No se distraiga por esto, ¡Esta carga es insignificante en comparación con el aumento del rendimiento por disponer de la memoria adicional!

Elija la opción de 4GB a menos que su sistema tenga instalados más de 4GB de RAM

KERNEL Habilitar el soporte de memoria alta en x86
Processor type and features  --->
 High Memory Support  --->
  (X) 4GB
  ( ) 64GB

Módulos del núcleo comprimidos

From kernel version 3.18.x (and up) compression of kernel modules has been possible. gzip and xz compression are available. It is important to emerge sys-apps/kmod with the proper USE flags before compiling a kernel with compressed modules:

ARCHIVO /etc/portage/package.useHabilitar el soporte de compresión para kmod
sys-apps/kmod lzma zlib

Haga emerge de nuevo de sys-apps/kmod:

root #emerge --ask --oneshot --changed-use sys-apps/kmod

Habilite al compresión de módulos y seleccione un método de compresión preferido:

KERNEL Habilite la compresión de módulos
Enable loadable module support --->
  [*]   Compress modules on installation
  Compression algorithm ()  --->
    <X> GZIP
        XZ

Usually make modules_install runs depmod. If sys-apps/kmod did not have the proper USE flags set (see the package.use step above) the first time it was run, then the dependency list will be empty. The system will therefore be unable to load any modules that were built compressed.

Una vez se haya recompilado kmod, lance de nuevo depmod como solución a este problema:

root #depmod -a
root #modprobe <module_name>

Notación corta para la configuración del núcleo

Introducción

When reading about kernel configuration, often times settings are described as CONFIG_<something>. This short-hand notation is what the kernel configuration actually uses internally, and is what will be found in the kernel configuration file (be it /usr/src/linux/.config or in the auto-generated /proc/config.gz file). Of course, using short-hand notation would not do much good if this cannot translate this to the real location in the kernel configuration. The make menuconfig tool makes this possible allows.

Traducir CONFIG_FOO a la localización real de la configuración

Suppose the CONFIG_TMPFS_XATTR feature needs to be enabled. Launch the kernel configuration menu (make menuconfig) and press the / key. This will open a search box. In the search box, type CONFIG_TMPFS_XATTR.

Lo siguiente es una salida del resultado de esta búsqueda:

KERNEL Resultado de buscar CONFIG_TMPFS_XATTR en menuconfig
Symbol: TMPFS_XATTR [=n]
Type  : boolean
Prompt: Tmpfs extended attributes
  Defined at fs/Kconfig:138
  Depends on: TMPFS [=y]
  Location:
    -> File systems
      -> Pseudo filesystems
        -> Virtual memory file system support (former shm fs) (TMPFS [=y])
  Selected by: TMPFS_POSIX_ACL [=n] && TMPFS [=y]

Esta salida ofrece un montón de información interesante.

Entry Description
Symbol: TMPFS_XATTR [=n] This identifies the kernel configuration entry being searched for. It also shows that this setting is currently not enabled ([=n]).
Type: boolean The setting searched for is a boolean (which means it can be one of two options: enabled or disabled). Some settings are numbers or strings.
Prompt: Tmpfs extended attributes This is the text found in the make menuconfig entry that controls the variable (TMPFS_XATTR) in the .config file. It is essentially the variable name in a more human readable format.
Depends on: TMPFS [=y] Before this entry can be seen CONFIG_TMPFS must be enabled. In this case it is already done (hence the [=y]) but if this is not the case, first look for (and enable) CONFIG_TMPFS.
Location: ... This is the location in the make menuconfig structure where the setting can be found. Remember, the setting to look for is Tmpfs extended attributes.
Selected by: TMPFS_POSIX_ACL [=n] && TMPFS [=y] If the settings described here are both enabled (in this case the first one is not), then CONFIG_TMPFS_XATTR will be automatically enabled and will not be possible to be disabled until one of these settings is de-selected.

With this information, it should be possible to translate any CONFIG_* requirements fairly easily. In short, it means a user must

  1. Enable the settings described in the Depends on field;
  2. Navigate where Location: points;
  3. Toggle the value referred to by Prompt:;

Otra documentación sobre la configuración del núcleo

So far only general concepts and specific problems related to kernel configuration has been discussed; precise details have been left up to the user to discover. However, other parts of the Gentoo documentation collection provide specialized details for the topics at hand.

Such documents may be helpful while configuring specific areas of the kernel. Although this warning was mentioned previously in this guide, remember: users who are new to kernel configuration should not be adventurous when attempting to configure their kernels. Start by getting a basic system up and running, support for your audio, printing, etc., can always be added at a later date.

Getting the basics of a kernel operational will help users in later configuration steps because the user will know what is breaking their system and what is not. It is always wise to save the base (working) kernel configuration in a folder other than the kernel's sources folder before attempting to add new features or hardware.

  • The ALSA article details the configuration options required for sound card support. Note that ALSA is an exception to the suggested scheme of not building things as modules: ALSA is actually much easier to configure when the components are modular.
  • The IPv6 router guide describes how to configure the kernel for routing using the next generation network addressing scheme.
  • If the closed-source nVidia graphics drivers will be used for improved 3D graphics performance, the nVidia Guide lists the options that should and should not be selected on such a system.
  • Amongst other things, the Power Management guide explains how to configure the kernel for CPU frequency scaling, and for suspend and hibernate functionality.
  • If running a PowerPC system, the PPC FAQ has a few sections about PPC kernel configuration.
  • The Printing guide lists the kernel options needed to support printing in Linux.
  • The USB Guide details the configuration settings required to use common USB devices such as keyboards, mice, storage devices, and USB printers.

Solución de problemas

Cambios de configuración que no tienen efecto

It is very common for users to make a configuration change, but then make a small mistake in the process of actually booting to their newly configured kernel. They reboot into a kernel image that is not the one they just reconfigured, observe that whatever problem they were trying to solve is still present, and conclude that the configuration change does not solve the problem.

The process of compiling and installing kernels is outside the scope of this document; refer to the Kernel Upgrade Guide for general guidance. In short, the process to get a modified kernel is the following: 1) configure, 2) compile, 3) mount /boot (if not already mounted), 4) copy new kernel image to /boot, 5) Make sure the bootloader will reference the new kernel, 6) reboot. If one of those final stages has been missed, then the changes will not properly take effect.

It is possible to verify if the kernel that has booted matches the newly kernel compiled on the hard disk. This is performed by examining the date and time of the kernel's compilation. Assuming the system architecture is x86 and the kernel sources are installed at /usr/src/linux, the following command can be used:

root #uname -v
#4 SMP PREEMPT Sáb Jul 15 08:49:26 BST 2006

The above command will display the date and time the currently booted kernel was compiled.

root #ls -l /usr/src/linux/arch/i386/boot/bzImage
-rw-r--r-- 1 dsd users 1504118 Jul 15 08:49 /usr/src/linux/arch/i386/boot/bzImage

The above command displays the date and time that the kernel image on the hard disk was last compiled.

If the time stamps from the above commands differ by more than 2 minutes, it indicates a mistake was made during kernel reinstallation and the system has not booted from the newly modified kernel image.

Los módulos no se cargan automáticamente

As mentioned earlier in this document, the kernel configuration system hides a large behavioral change when selecting a kernel component as a module (M) rather than built-in (Y). It is worth repeating this again because so many users fall into this trap.

When selecting a component as built-in, the code is built into the kernel image (bzImage). When the kernel needs to use that component, it can initialize and load it automatically, without any user intervention.

When selecting a component as a module, the code is built into a kernel module file and installed on the filesystem. In general, when the kernel needs to use that component, it will not be able to find it. With some exceptions, the kernel makes no effort to actually load these modules — this task is left up to the user.

If building support for a network card as a module, and it is discovered the network is not accessible, it is probably because the module is not loaded — either this must be done manually or the system must be configured to autoload the module at boot time.

Unless a user has a reasons to do otherwise, some time can be saved by building these components directly into the kernel image, so that the kernel can automatically configure these small settings by itself.

Ver también

  • Genkernel. Una herramienta para automatizar el proceso de construcción del núcleo y del initramfs.
    This article is based on a document formerly found on our main website gentoo.org.
    The following people have contributed to the original document: Daniel Drake, Curtis Napier, Justin Robinson, Lukasz Damentko, Jonathan Smith, nightmorph
    They are listed here as the Wiki history does not provide for any attribution. If you edit the Wiki article, please do not add yourself here, your contributions are recorded on the history page.