Handbook:Alpha/Installation/Kernel

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:Alpha/Installation/Kernel and the translation is 100% complete.
Alpha Handbook
Установка
Об установке
Выбор подходящего источника для установки
Настройка сети
Подготовка дисков
Установка файла stage
Установка базовой системы
Настройка ядра
Настройка системы
Установка системных утилит
Настройка загрузчика
Завершение
Работа с Gentoo
Введение в Portage
USE-флаги
Возможности Portage
Система сценариев инициализации
Переменные окружения
Работа с Portage
Файлы и каталоги
Переменные
Смешение ветвей программного обеспечения
Дополнительные утилиты
Дополнительные репозитории пакетов
Расширенные возможности
Настройка сети OpenRC
Начальная настройка
Расширенная настройка
Модульное построение сети
Беспроводная сеть
Добавляем функциональность
Динамическое управление


Необязательно: Установка файлов прошивки и/или микрокода

Файлы прошивки

Linux Firmware

Перед тем, как приступить к настройке ядра, полезно будет помнить, что некоторые аппаратные устройства требуют установки в систему дополнительной, иногда не совместимой с принципами FOSS (free (as in freedom) and open source software/свободное и открытое программное обеспечение), прошивки, прежде чем они будут работать правильно. Чаще всего это касается беспроводных сетевых интерфейсов, обычно встречающихся как в настольных, так и в портативных компьютерах. Современные видеочипы от таких производителей, как AMD, Nvidia и Intel также часто требуют установки внешней прошивки для обеспечения полной функциональности. Большинство прошивок для современных аппаратных устройств можно найти в пакете sys-kernel/linux-firmware.

Рекомендуется установить пакет sys-kernel/linux-firmware перед первоначальной перезагрузкой системы, чтобы прошивка была доступна в случае необходимости:

root #emerge --ask sys-kernel/linux-firmware
Заметка
Установка определённых пакетов прошивок часто требует принятия соответствующих лицензий на прошивку. При необходимости посетите раздел руководства о принятии лицензии для получения помощи.

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

SOF Firmware

Важно
Use of this firmware requires enabling certain Kernel options and is only supported on AMD64 currently. Enabling these options are only necessary if a manual configuration is planned, as the Distribution Kernels have them enabled already. The necessary options are covered in architecture specific kernel configuration.

Sound Open Firmware (SOF) is a new open source audio driver meant to replace the proprietary Smart Sound Technology (SST) audio driver from Intel. 10th gen+ and Apollo Lake (Atom E3900, Celeron N3350, and Pentium N4200) Intel CPUs require this firmware for certain features and certain AMD APUs also have support for this firmware. SOF's supported platforms matrix can be found here for more information.

root #emerge --ask sys-firmware/sof-firmware

Микрокод

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

Обновления микрокода для процессоров AMD распространяются в вышеупомянутом пакете sys-kernel/linux-firmware. Обновления микрокода для процессоров Intel находятся в пакете sys-firmware/intel-microcode, который необходимо установить отдельно. См. статью Микрокол для получения дополнительной информации о том, как применять обновления микрокода.

Конфигурация и компиляция ядра

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

От наименьшего вмешательства к наибольшему:

Полностью автоматический подход: Distribution-ядра
Проект Distribution Kernel используется для конфигурации, автоматической сборки и установки ядра Linux, связанных с ним модулей и (опционально, но по умолчанию включено) файла initramfs. Новые обновления ядра полностью автоматизированы, поскольку они обрабатываются через менеджер пакетов, как и любой другой системный пакет. В случае необходимости можно предоставить пользовательский конфигурационный файл ядра. Это наименее сложный процесс и идеально подходит для новых пользователей Gentoo, так как работает "из коробки" и требует минимального участия системного администратора.
Гибридный подход: Genkernel
Новые обновления ядра устанавливаются через системный менеджер пакетов. Системные администраторы могут использовать инструмент Gentoo genkernel для общей конфигурации, автоматической сборки и установки ядра Linux, связанных с ним модулей и (опционально, но не включено по умолчанию) файла initramfs. Можно предоставить пользовательский файл конфигурации ядра, если необходима кастомизация. Будущая конфигурация, сборка и установка ядра требуют участия системного администратора в виде выполнения eselect kernel, genkernel и, возможно, других команд для каждого обновления.
Полностью ручная настройка
Новые исходные тексты ядра устанавливаются с помощью системного менеджера пакетов. Ядро конфигурируется, собирается и устанавливается вручную с помощью команды eselect kernel и множества команд make. С новыми обновлениями ядра повторяется ручной процесс конфигурирования, сборки и установки файлов ядра. Это самый сложный процесс, но он обеспечивает максимальный контроль над процессом обновления ядра.

Основой, вокруг которой строятся все дистрибутивы, является ядро Linux. Оно является прослойкой между пользовательскими программами и аппаратным обеспечением системы. Хотя руководство предоставляет своим пользователям несколько возможных источников ядра, более подробная информация с более детальным описанием доступна на странице {{|Link|Kernel/Overview|Общие сведения о ядре}}.


Установка исходного кода ядра

Заметка
Этот раздел актуален только при использовании следующих методов genkernel (гибридного) или ручного подхода к управлению ядром.

При установке и компиляции ядра для систем на базе alpha Gentoo рекомендует использовать пакет sys-kernel/gentoo-sources.

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

root #emerge --ask sys-kernel/gentoo-sources

Данная команда установит исходный код ядра Linux в /usr/src/, используя в названии версию ядра. Эта команда не установит автоматически символьную ссылку, пока вы не укажете USE-флаг symlink для выбранного исходного кода ядра.

Обычно, символьная ссылка /usr/src/linux указывает на исходный код текущего работающего ядра. Однако, эта символьная ссылка не создаётся по умолчанию. Создать её поможет kernel модуль для eselect.

Чтобы подробнее узнать, зачем нужна эта символьная ссылка и как ею управлять, смотрите Kernel/Upgrade.

Для начала, просмотрите список установленных ядер (в виде исходного кода):

root #eselect kernel list
Available kernel symlink targets:
  [1]   linux-3.16.5-gentoo

Для того, чтобы создать символьную ссылку linux, используйте:

root #eselect kernel set 1
root #ls -l /usr/src/linux
lrwxrwxrwx    1 root   root    20 мар  3 22:44 /usr/src/linux -> linux-3.16.5-gentoo

Альтернатива: Genkernel

Заметка
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.

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

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

Учтите: хотя использование genkernel для поддержки ядра обеспечивает системным администраторам больший контроль над обновлением ядра системы, initramfs и других опций, это требует затрат времени и усилий для выполнения будущих обновлений ядра по мере выпуска новых источников. Тем, кто ищет автоматический подход к обслуживанию ядра, следует использовать distribution-ядра.

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

Группа лицензий на "программное обеспечение, распространяемое в бинарном виде"

Если пакет linux-firmware был уже установлен, перейдите к разделу установки.

Поскольку по умолчанию для пакета sys-kernel/genkernel включен USE-флаг firwmare, пакетный менеджер также попытается установить пакет sys-kernel/linux-firmware. Перед установкой linux-firmware необходимо принять лицензии на "программное обеспечение, распространяемое в бинарном виде".

Эта группа лицензий может быть принята для всей системы путем добавления @BINARY-REDISTRIBUTABLE в переменную ACCEPT_LICENSE в файле /etc/portage/make.conf. Лицензия также может быть принята только для пакета linux-firmware с помощью добавления в файле /etc/portage/package.license/linux-firmware.

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

Для упрощения, примеры разрешения лицензий:

root #mkdir /etc/portage/package.license
ФАЙЛ /etc/portage/package.license/linux-firmwareРазрешения лицензий на "программное обеспечение, распространяемое в бинарном виде" для linux-firmware
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Установка

Итак, установите пакет sys-kernel/genkernel:

root #emerge --ask sys-kernel/genkernel

Генерация

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

Заметка
Если для корневого раздела/тома используется файловая система, отличная от ext4, может потребоваться вручную настроить ядра с помощью genkernel --menuconfig all, чтобы добавить встроенную поддержку ядра для данной файловой системы (т.е. не собирать файловую систему как модуль).
Заметка
Пользователи LVM2 должны добавить --lvm в качестве аргумента к команде genkernel ниже

.

root #genkernel --mountboot --install all

По завершению работы genkernel будут сформированы ядро, полный набор модулей и файловая система инициализации (initramfs). Ядро и initrd нам понадобятся позднее. Запишите название файлов ядра и initrd, так как они нам понадобятся при настройке загрузчика. Initrd запускается сразу после ядра для определения оборудования (как при загрузке установочного CD), перед запуском самой системы.

После завершения работы genkernel, ядро и начальная файловая система ram (initramfs) будут сформированы и установлены в каталог /boot. Соответствующие модули будут установлены в каталог /lib/modules. initramfs будет запущена сразу после загрузки ядра для автоматического определения оборудования (как при загрузке "живого" (live) загрузочного диска).

root #ls /boot/vmlinu* /boot/initramfs*
root #ls /lib/modules

Альтернатива: Ручная настройка

Введение

Заметка
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.

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

Однако одна вещь является истиной: при ручной конфигурации ядра очень важно понимать свою систему. Большую часть сведений можно почерпнуть, установив пакет sys-apps/pciutils, который содержит в команду lspci:

root #emerge --ask sys-apps/pciutils
Заметка
Находясь внутри изолированного окружения chroot, можно спокойно игнорировать любые предупреждения pcilib (например, pcilib: cannot open /sys/bus/pci/devices), которые могут появляться в выводе lspci.

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

Остаётся перейти в каталог с ядром и выполнить make menuconfig, который запустит экран меню конфигурации.

root #cd /usr/src/linux
root #make menuconfig

В конфигурации ядра Linux есть много-много разделов. Сначала пройдёмся по пунктам, которые должны быть обязательно включены (иначе Gentoo будет работать неправильно или же вовсе не запустится). Также в вики есть Руководство по настройке ядра Gentoo, которое поможет понять более тонкие детали.

Включение обязательных параметров

При использовании sys-kernel/gentoo-sources, строго рекомендуется включить Gentoo-специфичные настройки. С помощью них включается необходимый минимум настроек ядра для корректной работы:

ЯДРО Включение Gentoo-специфичных настроек
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

Выбор в последних двух строках зависит от того, какую систему инициализации вы выбрали — OpenRC или systemd. Ничего страшного не случится, если вы включите поддержку обоих систем.

При использовании sys-kernel/vanilla-sources, этих вспомогательных настроек не будет. Вы можете включить нужные настройки вручную, но это выходит за рамки данного руководства.

Включение поддержки основных компонентов системы

Убедитесь, что все драйверы, необходимые для загрузки системы (такие как контроллер SATA, поддержка блочных устройств NVMe, поддержка файловой системы и другие) собраны прямо в ядре, а не в виде модуля. В противном случае, система может не загрузиться.

Далее следует выбрать тип процессора. Также рекомендуется включить возможности MCE (если они доступны), чтобы пользователи системы могли получать оповещение о любых проблемах с оборудованием. На некоторых архитектурах (например, x86_64) подобные ошибки выводятся не в dmesg, а в /dev/mcelog. А для него понадобится пакет app-admin/mcelog.

Также включите Maintain a devtmpfs file system to mount at /dev, чтобы критически важные файлы устройств были доступны на самом раннем этапе загрузки (CONFIG_DEVTMPFS и CONFIG_DEVTMPFS_MOUNT):

ЯДРО Включение поддержки devtmpfs (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

Убедитесь, что поддержка SCSI-дисков включена (CONFIG_BLK_DEV_SD):

ЯДРО Включение поддержки SCSI-дисков (CONFIG_SCSI, CONFIG_BLK_DEV_SD)
Device Drivers --->
  SCSI device support  ---> 
    <*> SCSI device support
    <*> SCSI disk support
ЯДРО Включение базовой поддержки SATA и PATA (CONFIG_ATA_ACPI, CONFIG_SATA_PMP, CONFIG_SATA_AHCI, CONFIG_ATA_BMDMA, CONFIG_ATA_SFF, CONFIG_ATA_PIIX)
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)

Убедитесь, что включена базовая поддержка NVMe:

ЯДРО Включение базовой поддержки NVMe для Linux 4.4.x (CONFIG_BLK_DEV_NVME)
Device Drivers  --->
  <*> NVM Express block device
ЯДРО Включение базовой поддержки NVMe для Linux 5.x.x (CONFIG_DEVTMPFS)
Device Drivers --->
  NVME Support --->
    <*> NVM Express block device

Не помешает включить следующую дополнительную поддержку NVMe:

ЯДРО Включение дополнительной поддержки NVMe (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

Теперь перейдите в раздел File Systems и выберите те файловые системы, которые планируете использовать. Файловая система, используемая в качестве корневой, должна быть включена в ядро (не модулем), иначе система не сможет подключить раздел при загрузке. Также включите Virtual memory и /proc file system. При необходимости выберите один или несколько параметров, необходимых системе:

ЯДРО Включение поддержки файловой системы (CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS, CONFIG_BTRFS_FS, CONFIG_XFS_FS, CONFIG_MSDOS_FS, CONFIG_VFAT_FS, CONFIG_PROC_FS, и 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)

Если для подключения к Интернету используется PPPoE или модемное соединение, то включите следующие параметры (CONFIG_PPP, CONFIG_PPP_ASYNC и CONFIG_PPP_SYNC_TTY):

ЯДРО Включение поддержки PPPoE (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

Два параметра сжатия не повредят, но и не являются обязательными, как и PPP over Ethernet. Фактически, последний используется в случае, если ppp сконфигурирован на использование ядерный PPPoE режим.

Не забудьте настроить поддержку сетевых карт (Ethernet или беспроводных).

Поскольку большинство современных систем являются многоядерными, важно включить Symmetric multi-processing support (CONFIG_SMP):

ЯДРО Включение поддержки SMP (CONFIG_SMP)
Processor type and features  --->
  [*] Symmetric multi-processing support
Заметка
Во многоядерных системах каждое ядро считается за один процессор.

Если используются USB-устройства ввода (например, клавиатура и мышь) или другие устройства, то не забудьте включить и эти параметры:

ЯДРО Включение поддержки USB и HID(CONFIG_HID_GENERIC, CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD, (CONFIG_HID_GENERIC, CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD, CONFIG_USB4)
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:

ЯДРО 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>

<div lang="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
Заметка
The 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.

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

[*] 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) --->  

Security options  ---> 
[*] Integrity subsystem   
  [*] Basic module for enforcing kernel lockdown                                                                       
  [*]   Enable lockdown LSM early in init                                                                       
        Kernel default lockdown mode (Integrity)  --->            

  [*]   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 --out /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 sperate 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>

<div lang="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>

<div lang="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"
Заметка
The SECUREBOOT_SIGN_KEY and SECUREBOOT_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.
Заметка
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.


Настройка ядра, специфичная для архитектуры

Также рекомендуются следующие параметры:

ЯДРО Рекомендуемые параметры для Alpha
General setup --->
  <*> SRM environment through procfs
  <*> Configure uac policy via sysctl
  
Plug and Play configuration --->
  <*> Plug and Play support
  <M>   ISA Plug and Play support
  
SCSI support --->
  SCSI low-level drivers --->
    <*> SYM53C8XX Version 2 SCSI support (NEW)
    <*> Qlogic ISP SCSI support
  
Network device support --->
  Ethernet (10 or 100 Mbit) --->
    <M> DECchip Tulip (dc21x4x) PCI support
    <M> Generic DECchip & DIGITAL EtherWORKS PCI/EISA
    <M> EtherExpressPro/100 support (eepro100)
    <M> EtherExpressPro/100 support (e100)
  Ethernet (1000 Mbit) --->
    <M> Alteon AceNIC
      [*] Omit support for old Tigon I
    <M> Broadcom Tigon3
  [*] FDDI driver support
  <M> Digital DEFEA and DEFPA
  <*> PPP support
    <*> PPP Deflate compression
  
Character devices --->
  [*] Support for console on serial port
  [*] Direct Rendering Manager
  
File systems --->
  <*> Kernel automounter version 4 support
  Network File Systems --->
    <*> NFS
      [*] NFSv3 client
      <*> NFS server
      [*] NFSv3 server
  Partition Types --->
    [*] Advanced partition selection
    [*] Alpha OSF partition support
  Native Language Support
    <*> NLS ISO 8859-1
  
Sound --->
  <M> Sound card support
    <M> OSS sound modules
      [*] Verbose initialisation
      [*] Persistent DMA buffers
      <M> 100% Sound Blaster compatibles

Компиляция и установка

Когда настройка закончена, настало время скомпилировать и установить ядро. Выйдите из настройки и запустите процесс компиляции:

root #make && make modules_install
root #make boot
Заметка
Можно включить параллельную сборку, используя make -jX, где X — это число параллельных задач, которые может запустить процесс сборки. Это похоже на инструкции, которые были даны ранее относительно файла /etc/portage/make.conf в части переменной MAKEOPTS

По завершении компиляции, скопируйте образ ядра в каталог /boot/. Новые ядра могут создавать файл vmlinux вместо vmlinux.gz. Помните это, когда копируете ваш образ ядра.

root #cp arch/alpha/boot/vmlinux.gz /boot/



Kernel installation

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.

If unsure, follow the 'Traditional layout' subsection below.

systemd-boot

When using systemd-boot (formerly gummiboot) as the bootloader, systemd's kernel-install must be used. Therefore ensure the systemd and the systemd-boot USE flags are enabled on sys-kernel/installkernel, and then install the relevant package for systemd-boot.

On OpenRC systems:

ФАЙЛ /etc/portage/package.use/systemd-boot
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #emerge --ask sys-apps/systemd-utils

On systemd systems:

ФАЙЛ /etc/portage/package.use/systemd
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
# Needed for <systemd-254
sys-apps/systemd gnuefi
root #emerge --ask sys-apps/systemd

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/installkernel
sys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel

When systemd's kernel-install is used, it should be configured to use the grub layout, this is the default if the grub USE flag is enabled:

ФАЙЛ /etc/kernel/install.conf
layout=grub

Traditional layout, other bootloaders (e.g. lilo, etc.)

The traditional /boot layout (for e.g. LILO, etc.) is used by default if the grub, systemd-boot and uki USE flags are not enabled. No further action is required.


Building an initramfs

In certain cases it is necessary to build an initramfs - an initial ram-based file system. The most common reason is when important file system locations (like /usr/ or /var/) are on separate partitions. With an initramfs, these partitions can be mounted using the tools available inside the initramfs. The default configuration of the Project:Distribution Kernel requires an initramfs.

Without an initramfs, there is a risk that the system will not boot properly as the tools that are responsible for mounting the file systems require information that resides on unmounted file systems. An initramfs will pull in the necessary files into an archive which is used right after the kernel boots, but before the control is handed over to the init tool. Scripts on the initramfs will then make sure that the partitions are properly mounted before the system continues booting.

Важно
If using genkernel, it should be used for both building the kernel and the initramfs. When using genkernel only for generating an initramfs, it is crucial to pass --kernel-config=/path/to/kernel.config to genkernel or the generated initramfs may not work with a manually built kernel. Note that manually built kernels go beyond the scope of support for the handbook. See the kernel configuration article for more information.

Installkernel can automatically generate an initramfs when installing the kernel if the dracut USE flag is enabled:

ФАЙЛ /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut

Alternatively, dracut may be called manually to generate an initramfs. Install sys-kernel/dracut first, then have it generate an initramfs:

root #emerge --ask sys-kernel/dracut
root #dracut --kver=3.16.5-gentoo

The initramfs will be stored in /boot/. The resulting file can be found by simply listing the files starting with initramfs:

root #ls /boot/initramfs*

Optional: Building an Unified Kernel Image

An Unified Kernel Image (UKI) combines, among other things, the kernel, the initramfs and the kernel command line into a single executable. Since the kernel command line is embedded into the unified kernel image it should be specified before generating the unified kernel image (see below). Note that any kernel command line arguments supplied by the bootloader or firmware at boot are ignored when booting with secure boot enabled.

An unified kernel image requires a stub loader, currently the only one available is systemd-stub. To enable it:

For systemd systems:

ФАЙЛ /etc/portage/package.use/systemd
sys-apps/systemd boot

For OpenRC systems:

ФАЙЛ /etc/portage/package.use/systemd-utils
sys-apps/systemd-utils boot

Installkernel can automatically generate an unified kernel image using either dracut or ukify, by enabling the respective flag. The uki USE flag should be enabled as well to install the generated unified kernel image to the $ESP/EFI/Linux directory on the EFI system partition (ESP).

For dracut:

ФАЙЛ /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut uki
ФАЙЛ /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"

For ukify:

ФАЙЛ /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut ukify uki
ФАЙЛ /etc/kernel/cmdline
some-kernel-command-line-arguments

Note that while dracut can generate both an initramfs and an unified kernel image, ukify can only generate the latter and therefore the initramfs must be generated separately with dracut.

Generic Unified Kernel Image

The prebuilt sys-kernel/gentoo-kernel-bin can optionally install a prebuilt generic unified kernel image containing a generic initramfs that is able to boot most systemd based systems. It can be installed by enabling the generic-uki USE flag, and configuring installkernel to not generate a custom initramfs or unified kernel image:

ФАЙЛ /etc/portage/package.use/generic-uki
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki

Secure Boot

The generic Unified Kernel Image optionally distributed by sys-kernel/gentoo-kernel-bin is already pre-signed. How to sign a locally generated unified kernel image depends on whether dracut or ukify is used. Note that the location of the key and certificate should be the same as the SECUREBOOT_SIGN_KEY and SECUREBOOT_SIGN_CERT as specified in /etc/portage/make.conf.

For dracut:

ФАЙЛ /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"

For ukify:

ФАЙЛ /etc/kernel/uki.conf
[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem

Rebuilding external kernel modules

External kernel modules installed by other packages via linux-mod-r1.eclass must be rebuilt for each new kernel version. When the distribution kernels are used this may be automated by enabling the dist-kernel flag globally.

ФАЙЛ /etc/portage/package.use/module-rebuild
*/* dist-kernel

External kernel modules may also be rebuilt manually with:

root #emerge --ask @module-rebuild

Модули ядра

Список доступных модулей ядра

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

Модули, которые должны загружаться при каждой загрузке, могут быть добавлены в файлы /etc/modules-load.d/*.conf, по одному модулю в строке. Если для модулей необходимы дополнительные параметры, их следует указывать в файлах /etc/modprobe.d/*.conf.

Чтобы просмотреть все модули, доступные для определённой версии ядра, выполните следующую команду find. Не забудьте заменить "<kernel version>" на соответствующую версию ядра для поиска:

root #find /lib/modules/<kernel version>/ -type f -iname '*.o' -or -iname '*.ko' | less

Принудительная загрузка отдельных модулей ядра

Чтобы принудительно загрузить в систему модуль 3c59x.ko (драйвер для определённого семейства сетевых карт от 3Com), отредактируйте файл /etc/modules-load.d/network.conf и добавьте туда имя модуля.

root #mkdir -p /etc/modules-load.d
root #nano -w /etc/modules-load.d/network.conf

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

ФАЙЛ /etc/modules-load.d/network.confПринудительная загрузка модуля 3c59x
3c59x

Продолжите установку с раздела Настройка системы.