Handbook:MIPS/Installation/Kernel/ko

This page is a translated version of the page Handbook:MIPS/Installation/Kernel and the translation is 100% complete.

Other languages:

MIPS 핸드북
설치
설치 정보
매체 선택
네트워크 설정
디스크 준비
스테이지 3 설치
베이스 시스템 설치
커널 설정
시스템 설정
도구 설치
부트로더 설정
마무리
젠투 활용
포티지 소개
USE 플래그
포티지 기능
초기화 스크립트 시스템
환경 변수
포티지 활용
파일 및 디렉터리
변수
소프트웨어 브랜치 함께 사용하기
추가 도구
꾸러미 저장소 개별 설정
고급 기능
네트워크 설정
시작하기
고급 설정
모듈러 네트워크
무선 네트워크
기능 추가
동적 관리

선택: 펌웨어 설치

Firmware

Linux Firmware

일부 드라이버는 동작하기 전에 시스템에 추가 펌웨어를 설치해야 합니다. 네트워크 인터페이스에 흔히 있는 경우이며 특히 무선 네트워크 인터페이스의 경우 그렇습니다. 또한 AMD, nVidia, 인텔에서 나오는 대부분의 최신 비디오 칩셋의 경우 오픈 소스 드라이버를 사용할 때 종종 외부 펌웨어 파일이 필요합니다. 대부분의 펌웨어는 sys-kernel/linux-firmware에 있습니다:

It is recommended to have the sys-kernel/linux-firmware package installed before the initial system reboot in order to have the firmware available in the event that it is necessary:

root #emerge --ask sys-kernel/linux-firmware

참고
Installing certain firmware packages often requires accepting the associated firmware licenses. If necessary, visit the license handling section of the Handbook for help on accepting licenses.

It is important to note that kernel symbols that are built as modules (M) will load their associated firmware files from the filesystem when they are loaded by the kernel. It is not necessary to include the device's firmware files into the kernel's binary image for symbols loaded as modules.

Microcode

In addition to discrete graphics hardware and network interfaces, CPUs also can require firmware updates. Typically this kind of firmware is referred to as microcode. Newer revisions of microcode are sometimes necessary to patch instability, security concerns, or other miscellaneous bugs in CPU hardware.

Microcode updates for AMD CPUs are distributed within the aforementioned sys-kernel/linux-firmware package. Microcode for Intel CPUs can be found within the sys-firmware/intel-microcode package, which will need to be installed separately. See the Microcode article for more information on how to apply microcode updates.

Kernel configuration and compilation

이제 커널 소스를 설정하고 컴파일 할 차례입니다. 두가지 방식으로 접근할 수 있습니다:

Ranked from least involved to most involved:

직접 설정하고 빌드하는 방법, 또는
genkernel 도구를 사용하여 자동으로 리눅스 커널을 빌드하고 설치하는 방법

주변에 빌드한 모든 배포판의 핵심은 리눅스 커널입니다. 이는 사용자 프로그램과 여러분의 시스템 하드웨어 사이에 있는 계층입니다. 젠투는 사용자에게 최대한 다양한 커널 소스코드를 제공합니다. 설명을 포함한 전체 목록은 커널 개요 페이지에 있습니다.

요령
Kernel installation tasks such as, copying the kernel image to /boot or the EFI System Partition, generating an initramfs and/or Unified Kernel Image, updating bootloader configuration, can be automated with installkernel. Users may wish to configure and install sys-kernel/installkernel before proceeding. See the Kernel installation section below for more more information.

소스 코드 설치

참고
This section is only relevant when using the following genkernel (hybrid) or manual kernel management approach.

The use of sys-kernel/installkernel is not strictly required, but highly recommended. When this package is installed, the kernel installation process will be delegated to installkernel. This allows for installing several different kernel versions side-by-side as well as managing and automating several tasks relating to kernel installation described later in the handbook. Install it now with:

root #emerge --ask sys-kernel/installkernel

When installing and compiling the kernel for mips-based systems, Gentoo recommends the sys-kernel/mips-sources package.

Choose an appropriate kernel source and install it using emerge:

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

/usr/src를 들여다보면 설치한 커널 소스를 가리키는 linux 심볼릭 링크를 볼 수 있습니다:

It is conventional for a /usr/src/linux symlink to be maintained, such that it refers to whichever sources correspond with the currently running kernel. However, this symbolic link will not be created by default. An easy way to create the symbolic link is to utilize eselect's kernel module.

For further information regarding the purpose of the symlink, and how to manage it, please refer to Kernel/Upgrade.

First, list all installed kernels:

root #eselect kernel list

Available kernel symlink targets:
  [1]   linux-6.6.21-gentoo

In order to create a symbolic link called linux, use:

root #eselect kernel set 1

root #ls -l /usr/src/linux

lrwxrwxrwx    1 root   root    12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo

기본: 직접 설정

도입부

참고
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.

커널을 직접 설정하는 방법은 리눅스 사용자가 해본 일중에 가장 어려운 과정으로 보입니다. 아니라고 하는것도 조금은 맞습니다 - 커널을 여러번 설정해본 사람중에는 이게 어려웠는지 기억하는 사람이 없습니다.

그러나 맞는 이야기이기도 합니다. 커널을 직접 설정했을 때 시스템을 알아둘 필요가 있습니다. 대부분의 정보는 lspci 명령이 들어있는 sys-apps/pciutils를 이머지하여 수집할 수 있습니다:

root #emerge --ask sys-apps/pciutils

참고
chroot를 하고 나면, lspci가 출력하는 (pcilib: cannot open /sys/bus/pci/devices와 같은) pcilib 경고를 무시하는게 안전합니다.

시스템 정보를 알아볼 수 있는 또 다른 부분은 설치 CD에서 사용하는 커널 모듈이 무엇인지 보여주는 lsmod를 실행했을 때 나타나는 활성화 할 모듈에 대한 바람직한 실마리입니다.

이제 커널 소스 디렉터리로 이동하여 make menuconfig를 실행하십시오. 메뉴 기반 설정 화면을 실행합니다.

root #

cd /usr/src/linux

root #make menuconfig

리눅스 커널 설정에는 굉장히 많은 섹션이 있습니다. 반드시 활성화해야 할 몇가지 옵션 목록을 먼저 보도록 하겠습니다(그렇지 않으면 젠투가 제 기능을 못하거나, 추가 설정 없이 제대로 동작하지 않을지도 모릅니다). 또한 더 많은 도움을 줄 젠투 커널 설정 안내서도 젠투 위키에 있습니다.

필수 옵션 활성화

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 --->
  Generic Driver Options --->
    [*] Gentoo Linux support
    [*]   Linux dynamic and persistent device naming (userspace devfs) support
    [*]   Select options required by Portage features
        Support for init systems, system and service managers  --->
          [*] OpenRC, runit and other script based systems and managers
          [*] systemd

Naturally the choice in the last two lines depends on the selected init system (OpenRC vs. systemd). It does not hurt to have support for both init systems enabled.

When using sys-kernel/vanilla-sources, the additional selections for init systems will be unavailable. Enabling support is possible, but goes beyond the scope of the handbook.

Enabling support for typical system components

시스템을 부팅할 때 살아있는 모든 드라이버(SCSI 컨트롤러 등)가 모듈로 남아있지 않고 커널에 들어갔는지 확인하십시오. 아니면 부팅을 제대로 진행할 수 없습니다.

정확한 프로세서 형식을 선택하십시오. 사용자가 하드웨어 문제 알림을 받을 수 있도록 MCE 기능 활성화(가능할 경우)를 추천합니다. 일부 아키텍처(x86_64)에서는 dmesg로 나타나지 않지만 /dev/mcelog에 나타납니다. app-admin/mcelog 꾸러미가 필요한 부분입니다.

또한 Maintain a devtmpfs file system to mount at /dev(CONFIG_DEVTMPFS 와 CONFIG_DEVTMPFS_MOUNT)를 선택하여 부팅 과정에 중요한 장치 파일을 미리 준비할 수 있게 하십시오.

커널 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 디스크 지원 활성화

Device Drivers --->
   SCSI device support  --->
      <*> SCSI disk support

커널 Enabling basic SATA and PATA support (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)

Verify basic NVMe support has been enabled:

커널 Enable basic NVMe support for Linux 4.4.x (CONFIG_BLK_DEV_NVME)

Device Drivers  --->
  <*> NVM Express block device

커널 Enable basic NVMe support for Linux 5.x.x (CONFIG_DEVTMPFS)

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

이제 File Systems로 가서 사용할 파일 시스템 지원을 선택하십시오. 루트 파일 시스템에서 사용할 파일 시스템을 모듈로 컴파일하지 마십시오. 그렇지 않으면 젠투 시스템에서 파티션을 마운트할 수 없습니다. 또한 Virtual memory와 /proc file system도 선택하십시오. 시스템에서 필요한 옵션(CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_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
  <*> Reiserfs support
  <*> JFS filesystem support
  <*> XFS filesystem support
  <*> Btrfs filesystem support
  DOS/FAT/NT Filesystems  --->
    <*> MSDOS fs support
    <*> VFAT (Windows-95) fs support
 
Pseudo Filesystems --->
    [*] /proc file system support
    [*] Tmpfs virtual memory file system support (former shm fs)

인터넷에 연결할 때 PPPoE를 사용하거나 전화걸기 모뎀을 사용한다면 다음 옵션 (CONFIG_PPP, CONFIG_PPP_ASYNC, CONFIG_PPP_SYNC_TTY)을 활성화하십시오:

커널 PPPoE 필수 드라이버 선택

Device Drivers --->
  Network device support --->
    <*> PPP (point-to-point protocol) support
    <*>   PPP support for async serial ports
    <*>   PPP support for sync tty ports

두 압축 옵션은 문제를 일으키진 않겠지만 꼭 필요하진 않으며, 커널 모드 PPPoE를 사용하도록 설정했을 때 PPP에서 사용하는PPP over Ethernet 옵션도 마찬가지입니다.

네트워크(유무선) 카드의 커널 지원 포함도 잊지 마십시오.

대부분의 시스템에는 구성에 따라 다중 코어를 지니고 있기도 하므로, Symmetric multi-processing support(CONFIG_SMP) 활성화도 중요합니다:

커널 SMP 지원 활성화

Processor type and features  --->
  [*] Symmetric multi-processing support

참고
멀티코어 시스템에서는 각 코어 갯수를 하나의 프로세서로 취급합니다.

USB 입력 장치(키보드, 마우스)또는 다른 USB 장치(CONFIG_HID_GENERIC, CONFIG_USB_HID, CONFIG_USB_SUPPORT, CONFIG_USB_XHCI_HCD, CONFIG_USB_EHCI_HCD, CONFIG_USB_OHCI_HCD)를 사용한다면 마찬가지로 활성화를 잊지 마십시오:

커널 입력 장치용 USB 지원 활성화

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

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>  

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

설정 준비

중요
Origin 200/2000, Indigo2 Impact (R10000), Octane/Octane2, O2 에서 시스템을 부팅하려면 64비트 커널이 필요합니다. 이 머신에서 64비트 커널을 빌드할 크로스컴파일러를 만들려면 sys-devel/kgcc64를 이머지하십시오.

대부분의 시스템에서는 커널 소스에 .configs 예제를 지원합니다. 모든 시스템에서 이런 방식으로 설정을 지원하진 않습니다. 이 설정은 아래 표에 언급한 명령으로 처리할 수 있습니다.

시스템	설정 명령
Cobalt Servers	make cobalt_defconfig
Indy, Indigo2 (R4k), Challenge S	make ip22_defconfig
Origin 200/2000	make ip27_defconfig
Indigo2 Impact (R10k)	make ip28_defconfig
O2	make ip32_defconfig

모든 젠투 설치 이미지에서는 이미지 자체의 일부로 /proc/config.gz와 같이 접근할 수 있는 커널 설정 옵션을 제공합니다. 이 파일은 대부분의 경우 사용합니다. 커널 소스 코드가 현재 동작중인 커널과 거의 비슷하다면 최선의 선택일 수 있습니다. 이 파일을 추출하려면, 간단하게 아래와 같이 zcat 명령을 실행하십시오.

root #zcat /proc/config.gz > .config

중요
이 커널 설정은 netboot 이미지로 설정한 상태입니다. initramfs의 디렉터리 또는 initrd의 루프백 장치가 있는 곳에서 루트 파일시스템 이미지를 찾을 수 있습니다. make menuconfig를 실행할 때 General Setup으로 이동 후 initramfs 옵션 비활성화를 꼭 처리해주십시오.

개별 설정

설정을 찾았다면 커널 소스 디렉터리로 다운로드 후 .config로 이름을 바꾸십시오. 그 다음 위에서 언급한 대로 업데이트할 내용을 모두 가져오기 위해 make oldconfig를 실행하시고 컴파일하기 전에 설정을 개별적으로 바꾸십시오.

root #

cd /usr/src/linux

root #

cp /path/to/example-config .config

root #make oldconfig

현재의 기본값으로 처리하려면, 그냥 각 프롬프트에서 Enter(또는 Return)를 누르십시오...

root #make menuconfig

중요
Kernel Hacking 섹션에서 "Are You Using A Cross Compiler?"라는 옵션이 있습니다. 이 옵션은 커널을 컴파일 할 때 gcc에게 커널 Makefile을 "mips-linux-"(또는 mipsel-linux ... 등)과 명령으로 간주하라고 알려줍니다. 크로스 컴파일을 진행한다면 특히 이 옵션을 꺼야합니다. 크로스 컴파일러를 호출해야 한다면, 다음 절에서 보여드리는 바와 같이 CROSS_COMPILE 변수를 사용하여 접두사를 정의하십시오.

중요
Octane systems 중 ALSA가 동작하지 않는 곳에서 JFS와 ALSA를 같이 넣었을때 발생하는 문제가 있습니다. MIPS용 JFS 실험 환경을 시험삼아 활용하려 한다면, 이와 같은 경우에는 JFS 사용을 피하시는게 좋습니다.

컴파일 및 설치

이제 커널을 설정했고 컴파일 하고 설치할 차례입니다. 설정을 빠져나간 후 컴파일 과정을 시작하십시오:

참고
64비트 머신에서 64비트 컴파일러를 사용하려면 CROSS_COMPILE=mips64-unknown-linux-gnu-(리틀 엔디언 시스템에서는 mips64el-...)를 지정하십시오.

자체적으로 컴파일하려면:

root #make vmlinux modules modules_install

대상 머신에 컴파일 하려면 mips64-unknown-linux-gnu- 를 적절하게 적어넣으십시오:

root #make vmlinux modules modules_install CROSS_COMPILE=mips64-unknown-linux-gnu-

x86같은 다른 머신에서 컴파일할 때는 커널을 컴파일하고 특정 디렉터리로 모듈을 설치하여 대상 머신에 보낼 때 다음 명령을 사용하십시오.

root #

make vmlinux modules CROSS_COMPILE=mips64-unknown-linux-gnu-

root #make modules_install INSTALL_MOD_PATH=/somewhere

중요
Indy, Indigo2 (R4k), Challenge S, O2에서 64비트 커널을 컴파일하면 vmlinux 대신 vmlinux.32 타겟을 사용하십시오. 그렇지 않으면 머신을 부팅할 수 없습니다. ELF64 형식을 해석할 수 없는 PROM에서 처리할 일입니다.

root #make vmlinux.32

참고
make -jX 명령을 사용하고 X에 실행 가능토록 허용할 빌드 프로세스 갯수를 넣어 병렬 빌드를 활성화 할 수 있습니다. 이는 앞서 언급한 /etc/portage/make.conf의 MAKEOPTS 변수와 비슷합니다.

위 과정을 통해 최종 커널 vmlinux.32를 만듭니다.

커널 컴파일이 끝나면 /boot에 커널 이미지를 복사하십시오:

참고
Cobalt servers에서 부트로더는 압축 커널 이미지 형태로 나타납니다. gzip -9 할 파일은 /boot/에 있음을 기억해두십시오.

root #cp vmlinux /boot/kernel-6.6.21-gentoo

Cobalt servers 에서는 커널 이미지를 압축하십시오:

root #gzip -9v /boot/kernel-6.6.21-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 should only be considered by users that have a required need that only Genkernel can meet, otherwise it is recommended to use the Distribution kernel or manually compile your own as it will make maintaining a Gentoo system a lot more simple. An example of why genkernel is more difficult to manage is the lack of integration with sys-kernel/installkernel. This means a user will not get the same level of automation as provided by the other methods, such as Unified Kernel Images will need to be created manually when using Genkernel.

Genkernel provides a generic kernel configuration file and will compile the kernel and initramfs, then install the resulting binaries to the appropriate locations. This results in minimal and generic hardware support for the system's first boot, and allows for additional update control and customization of the kernel's configuration in the future.

Be informed: while using genkernel to maintain the kernel provides system administrators with more update control over the system's kernel, initramfs, and other options, it will require a time and effort commitment to perform future kernel updates as new sources are released. Those looking for a hands-off approach to kernel maintenance should use a distribution kernel.

For additional clarity, it is a misconception to believe genkernel automatically generates a custom kernel configuration for the hardware on which it is run; it uses a predetermined kernel configuration that supports most generic hardware and automatically handles the make commands necessary to assemble and install the kernel, the associate modules, and the initramfs file.

Binary redistributable software license group

If the linux-firmware package has been previously installed, then skip onward to the to the installation section.

As a prerequisite, due to the firwmare USE flag being enabled by default for the sys-kernel/genkernel package, the package manager will also attempt to pull in the sys-kernel/linux-firmware package. The binary redistributable software licenses are required to be accepted before the linux-firmware will install.

This license group can be accepted system-wide for any package by adding the @BINARY-REDISTRIBUTABLE as an ACCEPT_LICENSE value in the /etc/portage/make.conf file. It can be exclusively accepted for the linux-firmware package by adding a specific inclusion via a /etc/portage/package.license/linux-firmware file.

If necessary, review the methods of accepting software licenses available in the Installing the base system chapter of the handbook, then make some changes for acceptable software licenses.

If in analysis paralysis, the following will do the trick:

root #mkdir /etc/portage/package.license

파일 /etc/portage/package.license/linux-firmwareAccept binary redistributable licenses for the linux-firmware package

sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE

Installation

이제 genkernel을 사용하는 방법을 보겠습니다. 먼저 sys-kernel/genkernel 이빌드를 이머지하십시오:

root #emerge --ask sys-kernel/genkernel

Generation

이제 genkernel all를 실행하여 커널 소스 코드를 컴파일하십시오. genkernel은 대부분의 하드웨어를 지원하는 커널을 컴파일 하므로 컴파일이 끝나기까지 상당한 시간이 걸린다는 사실을 알아두십시오!

참고
부트 파티션에서 ext2 또는 ext3 파일 시스템을 쓰지 않는다면 genkernel --menuconfig all 명령으로 커널을 직접 설정하고 커널에 각각의 지원 파일 시스템을 추가해야 합니다(예: 모듈 아님). LVM2 사용자는 마찬가지로 매개변수 --lvm을 넣어야겠습니다.

참고
Users of LVM2 should add --lvm as an argument to the genkernel command below.

root #genkernel all

genkernel 동작이 끝나면, 모듈 전체 모음과 초기화 램 디스크(initramfs)를 만듭니다. 이 문서에서 나중에 부트로더를 설정할 때 이 커널과 initrd를 사용합니다. 부트로더 설정 파일을 편집할 때 정보로 사용하겠으니 커널과 initrd의 이름을 적어두십시오. "실제" 시스템을 시작하기 전에 하드웨어 자동 감지(설치 CD와 유사) 동작을 수행하는 즉시 initrd를 시작합니다.

root #ls /boot/kernel* /boot/initramfs*

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

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

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=6.6.21-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 kernel-install

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-apps/systemd ukify          # For systemd systems
sys-apps/systemd-utils ukify    # For OpenRC systems
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

Force loading particular kernel modules

예를 들어 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

Note that the module's .ko file suffix is insignificant to the loading mechanism and left out of the configuration file:

파일 /etc/modules-load.d/network.confForce loading 3c59x module

3c59x

시스템 설정으로 설치 과정을 계속 진행하십시오.

← 젠투 베이스 시스템 설치 처음 시스템 설정 →