Ядро/Руководство по конфигурации ядра Gentoo

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


Целью данного документа является ознакомление с понятием ручной конфигурации ядра и разбор наиболее распространённых проблем.

Введение

Gentoo предоставляет два способа настройки конфигурационного файла, установки и обновления ядра: автоматический (с помощью genkernel или Dracut) и вручную. Несмотря на то, что автоматический метод может показаться простым для большинства пользователей, существует ряд причин, по которым достаточно большой процент пользователей выбирает настройку ядра вручную:

  • Большая гибкость и контроль над конфигурацией
  • Меньший размер ядра
  • Сокращение времени сборки
  • Получение опыта в результате обучения
Заметка
While the Distribution Kernel will produce a slightly larger kernel then one configured yourself. It should be noted that Linux will only load the modules it needs so it won't be a huge difference.

Данное руководство не стремится задокументировать процесс конфигурации вручную от начала до конца, поскольку он опирается на определенную долю здравого смысла и относительно высокий уровень знаний о системе. Вместо этого, руководство раскрывает основные представления о конфигурации ядра вручную и достаточно подробное описание наиболее распространенных подводных камней, с которыми сталкиваются пользователи.

Заметка
Данный документ написан с рассчётом на достаточно современные версии ядер и использование наиболее распространённых архитектур. Некоторые вещи разнятся на старых версиях ядра или более экзотичных архитектурах, но львиная доля приведённой ниже информации всё же будет применима.

На данный момент предполагается, что исходный код ядра Linux распакован на жёсткий диск (как правило, в /usr/src), а читатель умеет работать с menuconfig или nconfig и обладает навыками работы с системой меню на базе ncurses. В случае, если данный уровень не достигнут, то, прежде чем продолжить, следует ознакомиться со следующими статьями:

Основные понятия конфигурации

Основные идеи

Общий процесс достаточно прост: предлагаются несколько возможностей на выбор, распределенные по категориям в отдельные меню и подменю, в которых можно выбрать поддержку аппаратного обеспечения и функций ядра, подходящие для системы.

Ядро включает конфигурацию по умолчанию, которая активирует отдельные части исходного кода ядра во время первого запуска команды menuconfig. В целом, предлагается широкий выбор разумных значений по умолчанию, что означает, что большинству пользователей потребуется только внести небольшое количество изменений в основную конфигурацию. Если необходимо отключить параметр, который был включен по умолчанию, убедитесь что вы хорошо понимаете что в точности делает данный параметр и последствия его отключения.

При конфигурации ядра Linux в первый раз, следует придерживаться умеренных настроек и вносить так мало изменений в основные настройки, насколько это возможно. В то же время, следует учитывать, что существуют определенные настройки, которые необходимо изменить, чтобы система действительно могла загружаться.

Сравнение встроенных в ядро параметров и загружаемых модулей ядра

Большинство параметров конфигурации могут находиться в трех состояниях: они могут быть как отключены вовсе (N), встроены прямо в ядро (Y), или собраны в качестве модулей (M). Модули хранятся вне ядра на файловой системе, в то время как встроенные компоненты встраиваются прямо в образ ядра.

Между встроенными и модулями существует важное различие: за некоторыми исключениями, ядро не предпринимает каких-либо попыток загрузить внешние модули, если они нужны системе; это задача пользователя решать, когда загружать модуль. В то время как определенные части системы могут иметь возможность загрузки модулей по требованию и доступны несколько утилит для автоматической загрузки модулей, рекомендуется включение поддержки аппаратного обеспечения и функций ядра непосредственно в само ядро. В этом случае, ядро может гарантировать функциональность и поддержку аппаратного обеспечения при необходимости. Это можно сделать, установив (Y) для каждой необходимой функции ядра. Для этого также требуется включить поддержку встраиваемого (firmware) программного обеспечения в ядре. Подробнее смотрите в статье Linux firmware.

В некоторых частях конфигурации, встроенные функции это абсолютная необходимость. Например, если раздел root расположен на файловой системе btrfs, система не загрузится, если поддержка btrfs была построена в качестве модуля. Системе потребуется обратиться к разделу root чтобы найти модуль btrfs (если модули хранятся на root разделе), но обращения не произойдет до тех пор, пока модуль btrfs не будет загружен! Если поддержка btrfs не была встроена в ядро, init-процесс потерпит неудачу при поиске корневого устройства.

Для получения более подробной информации, смотрите статью kernel Modules, а также инструкции по конфигурации ядра, используя menuconfig.

Поддержка аппаратного обеспечения

Помимо обнаружения типа архитектуры системы, утилита конфигурации не предпринимает попыток обнаружить какое аппаратное обеспечение имеется на системе. В то время как для некоторого типа аппаратного обеспечения имеются настройки по умолчанию, пользователю почти наверняка потребуется найти и выбрать параметры конфигурации, подходящие для аппаратного обеспечения в каждой системе.

Для правильного выбора опций требует знание внутренних компонентов системы и компонентов, подключенных к компьютеру. В большинстве случаях компоненты могут быть определены без снятия крышки компьютера. Для большинства внутренних компонент, необходимо определить чипсет, используемый для каждого устройства, вместо названия компонента на розничном рынке. Множество карт расширения, продаваемые под определенной торговой маркой, могут использовать чип от другого производителя.

Доступны несколько вспомогательных утилит, которые помогут пользователям определить, какие варианты конфигурации ядра лучше использовать. lspci (часть пакета sys-apps/pciutils ) определяет аппаратное обеспечение, основанное на PCI и AGP, включая компоненты, встроенные в материнскую плату. lsusb (из пакета sys-apps/usbutils ) определяет различные устройства, подсоединенные к USB портам.

Положение в некотором смысле запутывается изменяющейся степенью стандартизации аппаратного обеспечения. До тех пор, пока не происходит сильных отклонения от значений по умолчанию, жесткие диски IDE должны "просто работать", как и PS/2 или USB-клавиатура и мышь. Базовая поддержка дисплея VGA также будет включена. Однако, некоторые устройства, такие как адаптеры ethernet, едва стандартизированы, поэтому чтобы получить доступ к сети, потребуется идентифицировать чипсет ethernet и выбрать подходящую поддержку для сетевой платы.

Кроме того, в то время как некоторые вещи просто работают с настройками по умолчанию, порой, необходимо выбрать более индивидуальные параметры, чтобы извлечь полный потенциал из системы. Например, если поддержка правильного чипсета IDE отключена, жесткие диски будут работать очень медленно.

Драйверы, требующие прошивки, рекомендуется конфигурировать как модули, чтобы легче загружать прошивку с диска. Обычно сюда относят драйверы GPU и сетевые драйверы (если не используется NFS или аналогичная сетевая файловая система).

Функции ядра

Помимо аппаратного обеспечения, необходимо также задуматься об особенностях программного обеспечения, поддержка которого необходима в ядре. Одним из важных примеров такой функции является поддержка файловой системы: необходимо выбрать поддерживаемые файловые системы для использования на жестком диске, а также любые другие файловые системы, которые могут находится на устройствах внешнего хранения (например, VFAT на флеш-накопителях USB).

Другим распространенным примером функции программного обеспечения является расширенная функциональность сети. При необходимости включить маршрутизацию или межсетевую фильтрацию, соответствующие настройки должны быть включены в файл конфигурации ядра.

Готовы?

После ознакомления с базовыми понятиями уже можно достаточно просто определить аппаратное обеспечение, просматривать интерфейс menuconfig и выбирать требуемые параметры ядра для системы.

Остальная часть этого руководства направлена на разъяснение областей часто вызывающих затруднения и объяснение как избежать общих проблем, с которыми сталкиваются пользователи. Успехов!

Настройка ядра

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:

ЯДРО Enabling Gentoo-specific options
Gentoo Linux --->
 [*] 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.

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):

ЯДРО Enabling devtmpfs support (CONFIG_DEVTMPFS)
Device Drivers --->
 Generic Driver Options --->
 [*] Maintain a devtmpfs filesystem to mount at /dev
 [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs

SATA- и NVME-диски

Большинство современных настольных систем поставляются с запоминающими устройствами (жесткий диск и приводы CD/DVD) на шине Serial ATA, вместо более старой шины Parallel ATA IDE (резиновый кабель).

Поддержка SATA в Linux реализована через слой, называемый libata, который располагается уровнем ниже подсистемы SCSI. По этой причине, драйвера SATA находятся в разделе конфигурации с драйверами SCSI. Кроме того, устройства хранения данных могут обрабатываться как SCSI-устройства, а это значит, что необходима поддержка SCSI диска или cdrom. Первый жесткий диск SATA, будет иметь название /dev/sda, а первый привод CD/DVD — /dev/sr0.

Хотя большинство этих драйверов предназначено для контроллеров SATA, libata не была предназначена только для SATA. Все распространенные драйвера IDE также портированы на libata, и все вышеупомянутое также применимо и к пользователям IDE.

ЯДРО Параметры конфигурации для 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) --->
Заметка
Нестандартные чипсеты перечислены под SCSI low-level drivers в Serial ATA and Parallel ATA drivers (libata) как показано в примере выше.
ЯДРО Enable basic NVMe support for Linux 5.x.x (CONFIG_BLK_DEV_NVME)
Device Drivers --->
 NVME Support --->
 <*> NVM Express block device

It does not hurt to enable the following additional NVMe support:

ЯДРО Enabling additional NVMe support (CONFIG_NVME_MULTIPATH, CONFIG_NVME_MULTIPATH, CONFIG_NVME_HWMON, CONFIG_NVME_FC, CONFIG_NVME_TCP, CONFIG_NVME_TARGET, CONFIG_NVME_TARGET_PASSTHRU, CONFIG_NVME_TARGET_LOOP, CONFIG_NVME_TARGET_FC, CONFIG_NVME_TARGET_FCLOOP, CONFIG_NVME_TARGET_TCP)
[*] 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 system support

ЯДРО Enable file system support (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_BTRFS_FS, CONFIG_XFS_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
 <*> 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)

Note that ext2 and ext3 are redundant since the ext4 driver already supports all ext versions.

USB хост-контроллеры

USB — это общепринятая шина для подсоединения внешних периферийных устройств к компьютеру. Одной из причин успеха USB является то, что это стандартизированный протокол. Однако же, устройства хост-контроллера USB (USB host controller devices (HCD)), размещенные на хосте, немного различаются. Имеются 4 главных вида:

  1. UHCI - Universal Host Controller Interface (универсальный интерфейс хост-контроллера). Он поддерживает USB 1.1, и обычно имеется на материнских платах, основанных на чипсете VIA или Intel.
  2. OHCI - Open Host Controller Interface (открытый интерфейс хост-контроллера). Он поддерживает USB 1.1 и обычно имеется на материнских платах, основанных на чипсете NVIDIA или SiS.
  3. EHCI - Extended Host Controller Interface (усовершенствованный интерфейс хост-контроллера). Это единственный распространенный интерфейс хост-контроллера, поддерживающий USB 2.0 и обычно присутствующий на любом компьютере с поддержкой USB 2.0.
  4. XHCI - eXtensible Host Controller Interface (расширяемый интерфейс хост-контроллера). Это хост-контроллер интерфейс для USB 3.0, который совместим с USB 1.0, 1.1, 2.0, 3.0 и будущими версиями. Включите эту опцию, если ваша плата поддерживает USB 3.0.

Большинство систем поставляются с двумя из перечисленных выше типов интерфейсов: XHCI (USB 3.0) и EHCI (USB 2.0). Для использования USB-устройств не нужно выбирать оба варианта, так как XHCI совместим с более медленными контроллерами USB. Но что бы "обезопасить" себя, пользователь может включить поддержку EHCI; это не причинит вреда, если USB 2.0 контроллер отсутствует в системе.

Если параметры, соответствующие типам USB HCD, отсутствуют в системе, тогда можете получиться эффект 'мертвых' USB-портов. Такой случай определить так: при подключении работающего устройства оно не снабжается питанием или не подает каких-либо признаков жизни.

С помощью отличной команды lspci (из пакета sys-apps/pciutils ) можно относительно легко обнаружить какие устройства HCD присутствуют на системе. Игнорируя контроллер SATA, который также соответствует запросу, легко обнаружить, что эта система требует поддержку EHCI и XHCI:

root #lspci -v | grep HCI
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) (prog-if 30 [XHCI])
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04) (prog-if 20 [EHCI])
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04) (prog-if 20 [EHCI])
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])

Выберите HCD присутствующий в системе. В общем случае, можно выбрать все три варианта для максимальной поддержки, если правильный вариант неизвестен:

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

В ядре Linux версии 3.12.13 и новее OHCI support for PCI-bus USB controllers (CONFIG_USB_OHCI_HCD_PCI) стоит включить, если USB-контроллер это OHCI и используется USB клавиатура или мышь.

Мультипроцессоры, гиперпоточность и многоядерные системы

Множество компьютеров основаны на многоядерных процессорах, но это не всегда очевидно.

  • Практически все современные процессоры Intel/AMD/IBM поддерживают технологию simultaneous multithreading (SMT), которая также называется hyper-threading. Эта технология позволяет системе задействовать одноядерный процессор как процессор с двумя и более логическими процессорами.
  • Большинство современных процессоров фактически состоят из множества физических процессоров внутри одного корпуса, такие процессоры известны как многоядерные процессоры.
  • Некоторые дорогие (последней модели) системы в действительности имеют множество физических процессоров, установленных на специализированной материнской плате для значительного увеличения производительности по сравнению с однопроцессорной системой. Пользователи таких систем, возможно, будут в курсе, что у них такая система, так как они недешевы.

Во всех этих случаях требуется выбрать соответствующие параметры ядра для получения оптимальной производительности для этих установок:

ЯДРО Конфигурация поддержки мультипроцессорных систем
Processor type and features --->
 [*] Symmetric multi-processing support
 [*] SMT (Hyperthreading) aware nice priority and policy support
 [*] Multi-core scheduler support (NEW)

Следующая опция предназначена не только для управления питанием, но также может быть необходима для определения всех процессоров, доступных в системе:

ЯДРО Управление питанием для мультипроцессорных систем
Power management and ACPI options --->
 [*] ACPI (Advanced Configuration and Power Interface) Support

Сжатые модули ядра

Начиная с версии ядра 3.18.x (и выше) возможно сжатие модулей ядра. Важно установить sys-apps/kmod с нужными USE-флагами перед компиляцией ядра со сжатыми модулями:

ФАЙЛ /etc/portage/package.useВключение поддержки сжатия для kmod
sys-apps/kmod lzma zlib

Перекомпилируйте sys-apps/kmod :

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

Включите сжатие модулей и выберите предпочитаемый метод сжатия:

ЯДРО Включение сжатия модулей
[*] Enable loadable module support Search for <code>CONFIG_MODULES</code> to find this item. --->
 Module compression mode () --->
 ( ) None
 (X) GZIP
 ( ) XZ
 ( ) ZSTD

PPPoE

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):

ЯДРО Enabling PPPoE support (PPPoE, CONFIG_PPPOE, CONFIG_PPP_ASYNC, 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

Обычно make modules_install запускает depmod. Если у sys-apps/kmod не были установлены необходимые USE-флаги (смотрите настройки в package.use в предыдущем шаге) при первом запуске, то, в этом случае, зависимостей не будет. Система не сможет загрузить какой-либо модуль, который был скомпилирован и сжат.

После перекомпиляции kmod, еще раз запустите depmod, чтобы решить эту проблему:

root #depmod -a
root #modprobe <module_name>

Signed kernel modules and SecureBoot

To automatically sign the kernel modules enable CONFIG_MODULE_SIG_ALL:

ЯДРО Sign kernel modules (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:

ЯДРО Enforce signed kernel modules (CONFIG_MODULE_SIG_FORCE)
[*] 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.pem

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.pem
root #chmod 400 kernel_key.pem
ЯДРО Specify signing key (CONFIG_MODULE_SIG_KEY)
-*- 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 signing
USE="modules-sign"
</div>
<divlang="en"dir="ltr"class="mw-content-ltr">
# 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.

Signing the kernel image (Secure Boot)

When signing the kernel image (for use on systems with Secure Boot enabled) it is recommended to set the following kernel config options:

ЯДРО Lockdown for secureboot
General setup --->
 Kexec and crash features ---> 
 [*] Enable kexec system call 
 [*] Enable kexec file based system call 
 [*] Verify kernel signature during kexec_file_load() syscall 
 [*] Require a valid signature in kexec_file_load() syscall 
 [*] Enable ""image"" signature verification support
</div> 
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] 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) --->
</div> 
<div lang="en" dir="ltr" class="mw-content-ltr">
Security options ---> 
[*] Integrity subsystem 
 [*] Basic module for enforcing kernel lockdown 
 [*] Enable lockdown LSM early in init 
 Kernel default lockdown mode (Integrity) --->
</div> 
<div lang="en" dir="ltr" class="mw-content-ltr">
[*] Digital signature verification using multiple keyrings 
 [*] Enable asymmetric keys support 
 -*- Require all keys on the integrity keyrings be signed 
 [*] Provide keyring for platform/firmware trusted keys 
 [*] Provide a keyring to which Machine Owner Keys may be added 
 [ ] Enforce Machine Keyring CA Restrictions

Where ""image"" is a placeholder for the architecture specific image name. These options, from the top to the bottom: enforces that the kernel image in a kexec call must be signed (kexec allows replacing the kernel in-place), enforces that kernel modules are signed, enables lockdown integrity mode (prevents modifying the kernel at runtime), and enables various keychains.

On arches that do not natively support decompressing the kernel (e.g. arm64 and riscv), the kernel must be built with its own decompressor (zboot):

ЯДРО zboot (CONFIG_EFI_ZBOOT)
Device Drivers ---> 
 Firmware Drivers ---> 
 EFI (Extensible Firmware Interface) Support ---> 
 [*] Enable the generic EFI decompressor

After compilation of the kernel, as explained in the next section, the kernel image must be signed. First install app-crypt/sbsigntools and then sign the kernel image:

root #emerge --ask app-crypt/sbsigntools
root #sbsign /usr/src/linux-x.y.z/path/to/kernel-image --cert /path/to/kernel_key.pem --key /path/to/kernel_key.pem --output /usr/src/linux-x.y.z/path/to/kernel-image
Заметка
For this example, the same key that was generated to sign the modules is used to sign the kernel image. It is also possible to generate and use a second separate key for signing the kernel image. The same OpenSSL command as in the previous section may be used again.

Then proceed with the installation.

To automatically sign EFI executables installed by other packages, enable the secureboot USE flag globally:

ФАЙЛ /etc/portage/make.confEnable Secure Boot
USE="modules-sign secureboot"
</div>
<divlang="en"dir="ltr"class="mw-content-ltr">
# 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
</div>
<divlang="en"dir="ltr"class="mw-content-ltr">
# Optionally, to boot with secureboot enabled, may be the same or different signing key.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"
Заметка
SECUREBOOT_SIGN_KEY and SECUREBOOT_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.
Заметка
When generating an Unified Kernel Image with systemd's ukify the kernel image will be signed automatically before inclusion in the unified kernel image and it is not necessary to sign it manually.

Architecture specific kernel configuration

amd64

Make sure to select IA32 Emulation and 32-bit time_t if 32-bit programs should be supported (CONFIG_IA32_EMULATION and CONFIG_COMPAT_32BIT_TIME). Gentoo installs a multilib system (mixed 32-bit/64-bit computing) by default, so unless a no-multilib profile is used, these options are required.

ЯДРО Selecting processor types and features
Processor type and features --->
 [ ] Machine Check / overheating reporting 
 [ ] Intel MCE Features
 [ ] AMD MCE Features
 Processor family (AMD-Opteron/Athlon64) --->
 ( ) Opteron/Athlon64/Hammer/K8
 ( ) Intel P4 / older Netburst based Xeon
 ( ) Core 2/newer Xeon
 ( ) Intel Atom
 ( ) Generic-x86-64
Binary Emulations --->
 [*] IA32 Emulation
General architecture-dependent options --->
 [*] Provide system calls for 32-bit time_t

Enable GPT partition label support if that was used previously when partitioning the disk (CONFIG_PARTITION_ADVANCED and CONFIG_EFI_PARTITION):

ЯДРО Enable support for GPT
-*- Enable the block layer --->
 Partition Types --->
 [*] Advanced partition selection
 [*] EFI GUID Partition support

Enable EFI stub support, EFI variables and EFI Framebuffer in the Linux kernel if UEFI is used to boot the system (CONFIG_EFI, CONFIG_EFI_STUB, CONFIG_EFI_MIXED, CONFIG_EFI_VARS, and CONFIG_FB_EFI):

ЯДРО Enable support for UEFI
Processor type and features --->
 [*] EFI runtime service support 
 [*] EFI stub support
 [*] EFI mixed-mode support
 
Device Drivers
 Graphics support --->
 Frame buffer Devices --->
 <*> Support for frame buffer devices --->
 [*] EFI-based Framebuffer Support
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
File Systems
 Pseudo filesystems --->
 <*> EFI Variable filesystem

To enable the Kernel options for the use of SOF Firmware covered earlier:

ЯДРО Enabling SOF Firmware support (CONFIG_SND_SOC_SOF_TOPLEVEL, CONFIG_SND_SOC_SOF_PCI, CONFIG_SND_SOC_SOF_ACPI, CONFIG_SND_SOC_SOF_AMD_TOPLEVEL, CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL)
Device Drivers --->
 Sound card support --->
 Advanced Linux Sound Architecture --->
 <M> ALSA for SoC audio support --->
 [*] Sound Open Firmware Support --->
 <M> SOF PCI enumeration support
 <M> SOF ACPI enumeration support
 <M> SOF support for AMD audio DSPs
 [*] SOF support for Intel audio DSPs

x86

Вследствие ограничений в 32-битном адресном пространстве на архитектуре x86, ядро с настройками по умолчанию поддерживает только 896 Мб оперативной памяти. Если система обладает большим количеством памяти, будут доступны только первые 896 Мб, если только не включена поддержка "верхней памяти" (high memory support).

Заметка
Это ограничение характерно для архитектуры x86 (IA32). Другие архитектуры свободно поддерживают большие количества памяти без каких-либо настроек.

Поддержка верхней памяти по умолчанию не включена, потому что она накладывает небольшую дополнительную нагрузку на систему. Не волнуйтесь, дополнительная нагрузка незначительна по сравнению с подъемом производительности или доступностью большего количества памяти!

Выберите вариант 4 Гб, если ваша система имеет более 4 ГБ оперативной памяти:

ЯДРО Включение поддержки верхней памяти для архитектуры x86
Processor type and features --->
 High Memory Support --->
 (X) 4GB
 ( ) 64GB

Compiling and installing

With the configuration now done, it is time to compile and install the kernel. Exit the configuration and start the compilation process:


root #make && make modules_install
Заметка
It is possible to enable parallel builds using make -jX with X being an 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:

root #make install

This 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.

Сокращенное обозначение настроек ядра

Введение

При прочтении о конфигурации ядра, часто настройки описываются как CONFIG_<something>. Это сокращенное обозначение является тем, что используется в конфигурации ядра внутренне, и то, что можно обнаружить в файле конфигурации ядра (будь это /usr/src/linux/.config или автоматически созданный файл /proc/config.gz). Конечно же, использование сокращенных обозначений бесполезно если их нельзя перевести в действительное местонахождение настроек ядра. Утилита make menuconfig позволяет это сделать.

Перевод параметра CONFIG_FOO в действительное местонахождение настроек

Предположим, неоходимо включить параметр CONFIG_TMPFS_XATTR. Запустите меню конфигурации ядра (make menuconfig) и нажмите /. Это откроет поле поиска. В это поле введите CONFIG_TMPFS_XATTR.

Следующий вывод является результатом этого поиска:

ЯДРО Результат поиска "CONFIG_TMPFS_XATTR" в 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
(1) -> Virtual memory file system support (former shm fs) (TMPFS [=y])
 Selected by: TMPFS_POSIX_ACL [=n] && TMPFS [=y]

Вывод работы команды содержит много интересной информации.

Запись Описание
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.

С помощью этой информации можно довольно легко перевести любые требования CONFIG_*. Вкратце, это означает что пользователю необходимо:

  1. включить настройки, описанные в поле Depends on
  2. перейти к указанному местоположению Location
  3. переключить значение, указанное в Prompt:
Совет
Обратите внимание на число в круглых скобках; пользователи могут перейти к этому параметру (или рядом, если в меню параметр отключен), нажав этот номер в меню поиска. В примере выше, нажатие клавиши 1 на клавиатуре, перебросит к параметру или возле него.

Другая документация по конфигурации ядра

До сих пор обсуждались только основные концепции и специфические проблемы, относящиеся к конфигурации ядра, без углубления в подробности; подробности оставлены для изучения пользователю. Однако, другие части документации Gentoo предусматривают специализированные подробности для рассматриваемых тем.

Эти документы могут быть полезны при конфигурации специфичных областей ядра. Хотя это предупреждение было упомянуто ранее в этом руководстве, запомните: пользователям, которые только начали осваивать конфигурацию ядра, не следует смело изменять любые настройки в ядре. Сначала настройте базовое и загружающееся ядро, всегда можно вернуться к настройке позже, чтобы добавить поддержку звука, печати и так далее.

Настройки "базово-рабочего" ядра помогут в последующей конфигурации, поскольку пользователь будет знать, что может нарушить базовую работу систему, а что нет. Разумно будет сохранить базовую (рабочую) конфигурацию ядра в другой каталог, а не в каталог с исходным кодом ядра до добавления новых функций или поддержки аппаратного обеспечения.

  • Статья ALSA описывает в подробностях параметры, требуемые для звуковой карты. Следует заметить, что ALSA является исключением из предложенной схемы сборки компонентов не в качестве модулей: систему ALSA намного проще сконфигурировать, если компоненты являются модульными.
  • Статься Bluetooth описывает параметры, необходимые для использования устройств Bluetooth.
  • При использовании закрытых графических драйверов NVIDIA для улучшенной производительности 3D-графики, в руководстве по NVIDIA перечисляются параметры, которые требуется выбрать или отключить.
  • В числе прочих вещей, в руководстве по управлению питанием объясняется как настроить ядро для управления частотой центрального процессора и для функций энергосбережения и режима сна.
  • Руководство по USB описывает конфигурацию, необходимую для использования распространенных USB-устройств, таких как клавиатуры и мыши, запоминающие устройства и USB-принтеры.

Устранение проблем

Изменения конфигурации не вступают в силу

Среди пользователей весьма распространенной ошибкой является то, что они делают изменения в конфигурации, но затем совершают небольшую ошибку в процессе загрузки в только что настроенное ядро. Они перезагружаются в образ ядра, не являющийся тем, который они только что сконфигурировали, замечают, что проблема, которую они пытались решить, все еще присутствует и приходят к выводу что изменения конфигурации не решили проблему.

Процесс компиляции и установки ядер находится за рамками этого документа; обратитесь к руководству по обновлению ядра за общими инструкциями. Вкратце, процесс получения изменённого ядра заключается в следующем:

  1. конфигурация
  2. компиляция
  3. монтирование раздела /boot (если он ещё не примонтирован)
  4. копирование нового образа ядра в /boot
  5. убедитесь, что загрузчик ссылается на новое ядро
  6. перезагрузка.

Если какой-нибудь из финальных шагов пропущен, изменения не вступят в силу.

Можно проверить соответствует ли загруженное ядро с недавно скомпилированным ядром. Это можно сделать, изучив дату и время компиляции ядер. Предполагая, что используется архитектура x86 и исходный текст ядра установлены в /usr/src/linux, можно использовать следующую команду:

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

Приведенная выше команда отобразит дату и время компиляции ядра, загруженного в настоящий момент.

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

Приведенная выше команда отображает дату и время когда образ ядра был скомпилирован в последний раз.

Если временные отметки из предыдущих команд отличаются более чем на 2 минуты, это означает что в процессе переустановки ядра была сделана ошибка и система загружена не с новым образом ядра.

Модули не загружаются автоматически

Как указано в этом документе ранее, система конфигурации ядра скрывает под собой большие изменения в поведении при выборе компонента ядра в качестве модуля (M), вместо встроенного (Y). Важно повторить это снова, так как много пользователей попадают в эту ловушку.

При встраивании компонента в ядро, код встраивается в образ ядра (bzImage). Когда ядру требуется использовать этот компонент, оно может инициализировать и загрузить его автоматически, без вмешательства пользователя.

При выборе компонента в качестве модуля, код встраивается в файл модуля ядра и устанавливается на файловую систему. В основном, когда ядру требуется использовать этот компонент, оно не может найти его. За некоторыми исключениями, ядро не совершает попыток загрузки этих модулей — эта задача оставлено пользователю.

Если поддержка сетевой платы включена в качестве модуля, и затем обнаруживается что сеть не доступна, это, возможно, потому что модуль не загружен — можно, либо сделать это вручную, либо система должно быть настроена для автоматической загрузки модулей во время запуска системы.

Если нет особых причин сделать по-другому, то можно сохранить время компилируя эти компоненты прямо в образ ядра, так чтобы ядро могло автоматически произвести эти небольшие настройки самостоятельно.

Смотрите также

  • Genkernel — утилита созданная Gentoo, которая используется для автоматизации процесса сборки ядра и initramfs.
  • Dracut — an initramfs infrastructure and aims to have as little as possible hard-coded into the initramfs.
  • Installkernel — a collection of scripts to automatically install new kernels and update bootloader configuration
  • proc filesystem (Security Handbook) — динамическое изменение параметров и переменных ядра на лету.


Authorship information
This page is based on a document formerly found on gentoo.org.
The following people contributed to the original document: Daniel Drake, Curtis Napier, Justin Robinson, Lukasz Damentko, Jonathan Smith, nightmorph

Editors: please do not add yourself here. Contributions are recorded on each article's associated history page, this list is only present to preserve authorship information, as wiki history does not allow for any external attribution.