Kernel/Gentoo Kernel Configuration Guide/ko

This page is a translated version of the page Kernel/Gentoo Kernel Configuration Guide and the translation is 69% complete.

Outdated translations are marked like this.

Other languages:

이 문서는 직접 커널 설정 개념을 소개하며 대부분의 일반 설정 과정의 함정을 낱낱이 파헤칩니다.

도입부

젠투에서는 커널 설정, 설치, 업그레이드 방식을 두가지 제공합니다. 하나는 자동 (genkernel) 그리고 다른 하나는 수동 입니다. 비록 자동 방식이 대부분 사용자에게 쉽겠지만, 상당수의 젠투 사용자들이 커널을 직접 설정하는 방법을 선택하는지에 대해서는 수많은 이유가 있습니다:

엄청난 유연성
작은 (커널) 크기
짧은 컴파일 시간
배움의 경험
극심한 귀차니즘
커널 설정에 대한 확실한 지식 확보 또는
완벽한 설정 처리

이 안내서에서는 자동 설정 방식(genkernel)을 다루지 않습니다. 커널과 관련된 문제를 genkernel로 다루려 한다면 Genkernel 글을 참고하십시오.

이 안내서에서는 시작부터 끝날 때까지 직접 설정 과정을 문서화하지 않습니다. 설정 과정은 상식적으로 상당 범위를 다루며 시스템을 사용하는데 있어 비교적 고수준의 기술 지식을 요합니다. 대신 직접 설정의 개념 정도 소개하며 사용자 입장에서 대부분 빠지기 쉬운 함정을 자세하게 안내하겠습니다.

참고
이 안내서는 일반적으로 사용하는 컴퓨터의 아키텍처 와 최근 커널을 기준으로 작성했다고 간주합니다. 이전 커널 또는 유별난 아키텍처에 대한 일부 세부 사항은 다를 수 있습니다. 허나 그래도 대부분의 내용은 어디든 관련성이 있습니다.

여기서, 사용자 여러분께서 이미 하드디스크(보통 /usr/src 아래 어딘가에)에 리눅스 커널 소스 코드의 압축을 해제했고, ncurses 메뉴 체계 기반을 통해 어느 정도 설정을 탐색하는 지식을 갖춘 상태에서 menuconfig 설정 유틸리티에 들어가는 방법을 알고 있다고 가정하겠습니다. 만약 이 단계의 사용자가 아니라면 도움이 될 다른 문서가 있으니 찾아보십시오. 다음 게시글을 읽고, 이 안내서로 돌아오시면 됩니다:

커널 소스 코드 개요는 포티지 트리에 있는 커널 소스 코드 꾸러미 정보가 있습니다.
커널 업그레이드는 커널 업그레이드 및 커널 전환 방법을 설명합니다.
젠투 핸드북의 커널 설정 장에서는 커널 설치 방법을 다룹니다. 적당한 아키텍처를 선택하신 후 리눅스 커널 설정장을 들어가서 내용을 살펴보십시오.

설정 개념

기본

일반 과정은 실제로 꽤 단순합니다: 여러개의 옵션을, 각 메뉴와 하위 메뉴로 분류한 채로 나타나며, 원하는 하드웨어 지원 및 시스템과 관련된 커널 기능이 이미 선택한 상태입니다.

커널에는 기본 설정이 들어있는데 소스 코드 일부로 menuconfig를 처음 실행할 때 나타납니다. 기본 값은 보통 다양하고 분별성이 있는데, 대부분의 사용자가 기본 설정에서 바꾸는 설정 가지 수가 적음을 의미합니다. 이미 활성화한 커널의 기본 설정을 비활성화하기로 결정했다면 해당 옵션의 동작에 대해 정확하게 이해하고 있는지 확인하시고, 그 다음에 비활성화하십시오.

리눅스 커널 설정을 처음 진행하는 동안, 설정 목적은 보수적이어야 합니다. 너무 도전적이어서도 안되며 가능한 한 기본 설정의 수정은 최소화하십시오. 또한, 실제 시스템을 부팅할 수 있도록 개별적으로 처리할 시스템 설정 부분이 있음을 고려하십시오.

내장이냐 모듈이냐

대부분의 설정 옵션은 3가지 상태로 구분 합니다: 빌드하지 않는 (N) 옵션, 커널에 빌드하는 (Y) 옵션, 모듈로 빌드하는 (M) 옵션이 될 수 있습니다. 모듈은 파일 시스템 상 외부에 저장하며, 내장 항목은 커널 이미지 자체에 직접 빌드합니다.

빌드에 포함 및 모듈화^en 개념간에는 중요한 차이점이 있습니다. 몇가지 예외를 들자면, 커널 자체에서는 시스템이 필요로 하는 외부 모듈을 불러오려 하지 않습니다. 모듈을 언제 불러올 지 말지는 사용자가 결정하도록 내버려둡니다. 시스템의 다른 나머지 부분이 요청시 불러오는 구조로 되어 있고 모듈을 자동으로 불러오는 유틸리티가 있지만 하드웨어 지원과 커널 기능을 커널에 포함하여 빌드하는 것이 좋습니다. 그러면 커널에서 언제 필요하든지간에 커널 기능과 하드웨어 지원 기능을 포함하고 있기 때문에 이 점을 인지할 수 있습니다. 이는 커널 기능에 (Y)로 설정하여 처리할 수 있습니다. 이렇게 관계되도록 설정하려면 커널에 펌웨어 지원을 포함하도록 해야합니다. .config에서 FW_LOADER=y 옵션과 CONFIG_FIRMWARE_IN_KERNEL=y 옵션을 설정하거나 다음처럼 설정하시면 됩니다:

나머지 설정 부분에 대해서는, 커널에 포함하여 빌드하는 옵션이 정말 필요합니다. 예를 들어 루트 분할 공간이 btrfs 파일 시스템일 경우 btrfs 파일 시스템 기능을 모듈로 빌드하면 부팅할 수 없습니다. 시스템에서는 루트 분할 공간에서 btrfs 모듈을 찾겠지만(루트 분할 공간에 모듈이 들어가 있음), btrfs 파일 시스템 기능 지원을 불러오기 전에는 루트 분할 공간을 탐색할 루 없습니다! btrfs를 포함하여 빌드하지 않으면 초기화 과정에서 루트 장치를 찾는데 실패합니다.

See the article on kernel Modules for more information, and the instructions on using menuconfig to configure the kernel.

하드웨어 지원

시스템의 아키텍처 형식을 발견하기 전에, 설정 유틸리티는 시스템에 실제로 나타나는 하드웨어가 무엇인지 발견하려 들지도 않습니다. 일부 하드웨어 지원에 대한 기본 값만 있으므로 사용자는 각 시스템의 하드웨어 설정과 관련된 설정 옵션을 찾아 분명하게 설정해야합니다.

적당한 설정 옵션을 선택하려면 컴퓨터 안에 붙어있거나 연결한 구성품에 대한 지식이 필요합니다. 대부분의 경우 이러한 구성품은 시스템의 뚜껑을 열지 않고도 알아볼 수 있습니다. 대부분의 내부 구성품에 대해서는 사용자가 판매 제품 이름이나 모델보다는 각 장치에 붙어있는 칩셋을 식별해야합니다. 대부분의 확장 카드는 자체 브랜드 이름을 달고 판매하지만, 다른 제조사의 칩셋을 사용합니다.

어떤 커널 설정 옵션을 사용할 지 사용자가 결정하도록 도와주는 유틸리티가 있습니다. lspci (sys-apps/pciutils 꾸러미 구성 바이너리)는 PCI 기반, AGP 기반 하드웨어를 식별하는데, 이 정보에는 마더보드 자체에 붙인 구성품 정보도 들어있습니다. lsusb (sys-apps/usbutils 꾸러미 구성 바이너리)는 시스템의 USB 포트에 연결한 다양한 장치를 식별합니다.

하드웨어 세계의 다양한 표준화 양상 때문에 혼동되는 상황입니다. 사용자가 상당히 다른 기본 설정을 선택하기 전에는 IDE 하드 디스크는 PS/2 또는 USB 키보드 및 마우스처럼 그냥 동작해야 합니다. 기본 VGA 디스플레이 기능 지원도 역시 포함되어 있습니다. 그러나 이더넷 어댑터 같은 장치는 거의 표준화되어 있지 않습니다. 이런 장치 사용자들은 이더넷 칩셋을 확인해야 하며, 카드별로 적당한 하드웨어 지원 드라이버를 선택하여 네트워크에 접근할 수 있도록 해야 합니다.

게다가, 어떤 구성 요소가 기본 설정으로 그냥 잘 동작하기만 한다면, 시스템의 완벽한 잠재성능을 끌어 올리기 위해 더욱 특별한 옵션을 선택해야합니다. 예를 들어 적당한 IDE 칩셋을 활성화하지 않았다면 IDE 하드 디스크는 매우 느리게 동작합니다.

It is recommended for drivers that require firmware to be configured as modules to more easily load the firmware from disk. Common groups that should be included here are GPU and networking drivers (when not using an NFS, or similar networked based, rootfs).

커널 기능

또한 하드웨어 지원에 있어, 사용자 여러분은 커널에서 필요한 소프트웨어 기능을 고려해야 합니다. 이런 기능 중 중요한 한가지는 파일 시스템 지원입니다. 사용자는 하드디스크에서 사용 중인 파일 시스템 지원 기능과 외장 장치에서 사용할 파일 시스템 지원 기능을 활성화해야 합니다(예: USB 장치의 VFAT).

다른 일반 소프트웨어 기능의 예를 들자면 고급 네트워크 기능이 있습니다. 라우팅 또는 방화벽 동작을 수행한다면 관련 설정 항목을 커널 설정에 포함해야합니다.

준비됐죠?

이제 개념을 소개했으니 시스템 하드웨어를 식별하고, menuconfig 인터페이스로 탐색한 다음, 시스템에 필요한 커널 옵션을 선택하는 과정의 시작은 쉬울겝니다.

이 안내서의 나머지는 일반적으로 혼동하기 쉬운 부분이며, 사용자가 빠져들기 쉬운 일반적인 문제를 피해가는 방법에 대해 알려드립니다. 잘 되시길!

보통 문제와 혼동하는 부분

SATA 디스크는 SCSI 입니다

최신 데스크톱 시스템에는 저장장치(하드 디스크 및 CD/DVD 드라이브)를 IDE^en (리본 케이블) 방식이 아닌 직렬 ATA^en 버스에 연결합니다.

리눅스에서의 SATA 기능 지원은 SCSI 하위 시스템에 배치한 libata 참조 계층에서 구현했습니다. 이런 이유로 SATA 드라이버는 설정의 SCSI 드라이버 섹션에서 나타납니다. 게다가 시스템 저장장치는 SCSI 장치처럼 다루는데 SCSI 디스크/CD롬 장치 역시 필요하다는 이야기입니다. 첫번째 SATA 하드 디스크는 /dev/sda고 첫번째 SATA 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)  --->

참고
비표준 칩셋 목록은 하단의 커널 안내 상자의 Serial ATA and Parallel ATA drivers (libata)에 있는 SCSI low-level drivers 항목 아래에 있습니다.

USB 호스트 컨트롤러

USB는 컴퓨터 외부 주변장치를 연결하는 목적으로 널리 적용한 버스 인터페이스입니다. USB가 성공한 이유는 표준화된 프로토콜이지만 USB host controller devices (HCDs)를 적은 다양성 범위 내에서 구현했기 때문입니다. USB 형식은 주로 4가지가 있습니다:

UHCI 는 통합 호스트 컨트롤러 인터페이스입니다. USB 1.1을 지원하며 보통 VIA 또는 인텔 칩셋의 마더보드에서 찾을 수 있습니다.
OHCI 는 공개 호스트 컨트롤러 인터페이스입니다. USB 1.1을 지원하며 보통 Nvidia 또는 SiS 칩셋의 마더보드에서 찾을 수 있습니다.
EHCI 는 확장 호스트 컨트롤러 인터페이스입니다. USB 2.0을 지원하며 보통 USB 2.0을 지원하는 어떤 컴퓨터에서든 찾을 수 있습니다.
XHCI 는 확장 가능한 호스트 컨트롤러 인터페이스입니다. 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 컨트롤러와 호환되므로 더이상 XHCI와 EHCI 둘 다 선택하지 않아도 됩니다. 사용자는 EHCI를 추가 안전책으로 활성화할 수 있습니다. USB 2.0 컨트롤러를 사용할 수 없을 경우 아무 문제 없습니다.

시스템에 나타난 각 USB HCD 형식에 따른 관련 옵션을 선택하지 않으면 USB 포트가 '죽어있는' 경험을 할 지도 모릅니다. 이 경우 동작하는 USB 장치를 연결했을 때, 어떤식으로는 동작하지 않거나 응답하지 않습니다.

깔끔하게 (sys-apps/pciutils 꾸러미에 있는)lspci 꼼수를 쓰면 시스템에 어떤 HCD 장치가 있는지 비교적 쉽게 찾을 수 있습니다. 일치하는 SATA 컨트롤러는 무시하고, 이 시스템에서 ECHI와 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를 선택하십시오. 보통 나타나는 모든 세가지 옵션이 최대 지원입니다만, 올바른 옵션인지 확실하지 않다면:

커널 USB HCDs 설정^en

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

리눅스 커널 3.12.13 이후, USB 컨트롤러가 OHCI이고 USB 키보드 및 마우스를 사용하는 경우 OHCI support for PCI-bus USB controllers (USB_OHCI_HCD_PCI<)를 활성화합니다.

다중 프로세서, Hyper-Threading 및 다중 코어 시스템

대부분 컴퓨터 시스템은 다중 프로세서 기반이지만, 항상 직접적으로 명백하게 다중 프로세서 방식으로 동작하는건 아닙니다.

대부분의 인텔 CPU가 hyper-threading 기술을 지원합니다. 이 기술은 단일 CPU가 두개의 논리 프로세서(코어)처럼 보이도록합니다.
대부분의 인텔/AMD CPU는 실제로 하나의 칩 패키지에 여러 물리 프로세서를 넣어, 이 프로세서를 다중 코어^en 프로세서라고 합니다.
일부 고성능(high-end) 컴퓨터 시스템은 실제로 특별한 마더보드에 여러 물리 프로세서를 장착하여 단일 프로세서 시스템의 성능을 훨씬 뛰어넘는 성능을 발휘합니다. 시스템 사용자는 아마도 이런 시스템을 지니고 있다면 결코 싼 시스템이 아니라는걸 알 지도 모릅니다.

이 모든 경우, 적당한 커널 옵션을 선택하여 이 설정으로부터 최상의 성능을 끌어내야 합니다:

커널 다중 처리 지원 기능 설정

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

다음 옵션은 전원 관리 기능을 활성화 할 뿐만 아니라 시스템에 붙는 모든 CPU의 요구사항이기도 합니다:

커널 다중 프로세서 시스템의 전원 관리

Power management and ACPI options  --->
 [*] ACPI (Advanced Configuration and Power Interface) Support

x86 상위 메모리 영역 지원

x86 아키텍처의 32비트 주소 공간 제한 때문에 기본 설정을 지닌 커널은 램 용량을 896MB 까지만 지원할 수 있습니다. 시스템에 더 많은 용량의 메모리가 있다면, 상위 메모리 지원을 활성화하기 전에는 처음 896MB 부분만 보입니다.

참고
이 제한 사항은 x86(IA32) 아키텍처에 한합니다. 다른 아키텍처에서는 설정 조절 없이 큰 용량의 메모리를 자체적으로 지원합니다.

상위 메모리 영역 지원은 이제 기본적으로 비활성화 상태인데, 소규모 시스템의 과부하를 유발하기 때문입니다. 이 문제에 신경 쓰시지 마십시오. 더 많은 가용 메모리로 인한 성능 증가에 비하면 과부하는 별로 중요하지 않습니다.

4GB를 넘는 RAM을 보유하고 있지 않다면 4GB 옵션을 선택하십시오:

커널 x86 상위 메모리 지원 활성화

Processor type and features  --->
 High Memory Support  --->
  (X) 4GB
  ( ) 64GB

압축 커널 모듈

커널 버전 3.18.x(이상) 부터 커널 모듈 압축이 가능합니다. gzip과 xz 압축 방식을 활용할 수 있습니다. 압축 모듈로 커널을 컴파일 하기 전에 적당한 USE 플래그를 붙여 sys-apps/kmod를 이머지하는 것이 중요합니다.

파일 /etc/portage/package.use/kmodEnabling compression support for kmod

sys-apps/kmod lzma zlib

sys-apps/kmod를 다시 이머지하십시오:

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

모듈 압축을 활성화하고 알맞은 압축 방식을 선택하십시오:

커널 모듈 압축 활성화

Enable loadable module support --->
  [*]   Compress modules on installation
  Compression algorithm ()  --->
    <X> GZIP
        XZ

커널 Enable module compression

[*] Enable loadable module support --->
  Module compression mode () --->
    ( ) None
    (X) GZIP
    ( ) XZ
    ( ) ZSTD

보통 make modules_install에서 depmod를 실행합니다. sys-apps/kmod 에 적당한 USE 플래그를 설정하지 않았을 때(위 단계에서 package.use 참고) 처음 실행하면, 의존성 목록이 비어있을 것입니다. 때문에, 시스템에서는 압축한 상태로 빌드한 어떤 모듈이든 불러올 수 없습니다.

kmod를 다시 컴파일 하고 나면, 이 문제를 해결하기 위해 depmod를 다시 실행하십시오:

root #

depmod -a

root #

modprobe <module_name>

커널 설정 간편 표기

도입부

커널 설정 방법을 읽을 때, 종종 설정 항목은 CONFIG_<거시기>로 나타납니다. 이 간편 표기 방식은 내부적으로 활용하는 커널 설정이며, 커널 설정 파일(/usr/src/linux/.config 또는 자동으로 만든 /proc/config.gz)에서 찾아볼 수 있습니다. 물론, 간편 표기 방식이 커널 설정에 있어 실제 위치로 변환하는데 있어 썩 좋은 방식은 아닙니다. make menuconfig 도구는 이 문제를 풀어냅니다.

CONFIG_FOO를 실제 설정 위치로 변환하기

CONFIG_TMPFS_XATTR 기능을 활성화해야 한다 합시다. 커널 설정 메뉴를 실행(make menuconfig)하고 / 키를 누르십시오. 검색 상자를 엽니다. 이 검색 상자에 CONFIG_TMPFS_XATTR를 입력하십시오.

다음은 이 검색 결과의 출력 내용입니다:

커널 menuconfig에서의 "CONFIG_TMPFS_XATTR" 검색 결과

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]

이 출력 결과는 수많은 정보를 보여줍니다.

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

이 정보를 통해 어떤 CONFIG_* 요구사항이든 해석이 쉬울 수 있습니다. 간단히 말해, 사용자는:

Depends on 항목에 설명한 설정을 활성화해야 하고
Location: 위치를 탐색하며
Prompt: 항목에서 참고하는 값을 바꿔야합니다

요령
괄호 안 숫자를 살펴보십시오. 사용하즌 해당 옵션을 건너뛰거나, 숫자를 눌러 활성화한 메뉴에 최대한 가깝게 찾아보며 접근할 수 있습니다. 위 예제에서 키보드의 1을 누르면 해당 옵션 또는 유사 옵션으로 건너뜁니다.

기타 커널 설정 문서

지금까지는 일반적인 개념과 커널 설정에 대한 개별적인 문제에 대해서만 다루었습니다. 더 자세한 내용은 사용자의 이야기거리로 남겨둡니다. 그러나 젠투 문서 모음의 나머지 부분에서는 다루기 쉬운 주제에 대해 특별히 세부적인 내용을 제공합니다.

어떤 문서는 커널의 개별 설정 영역에 도움이 될 수도 있습니다. 이 경고는 앞서 언급했지만 기억해두십시오: 커널 설정을 처음 진행하는 사용자는 커널을 설정하려할 때 성급해서는 안됩니다. 기본적인 시스템을 띄워 시작하고, 동작하며 오디오, 인쇄 등의 기능 지원은 언제든 나중에 추가할 수 있습니다.

커널 동작의 기본 지식 습득은 나중의 설정 단계에서 사용자에게 도움이 되는데 사용자는 무엇이 시스템을 동작하지 못하게 하고 무엇이 그렇지 않은지 알게 되기 때문입니다. 새 기능 또는 하드웨어 추가를 시도하기 전, 항상 (동작하는) 커널 설정을 커널 소스코드 폴더가 아닌 다른 폴더에 저장하는 것이 현명합니다.

AlSA 게시글^en에서는 사운드 카드 지우너 들아비어ㅔ 필요한 설정 옵션을 자세하게 다룹니다. ALSA는 모듈로 빌드하지 않는 형식으로 제안하는 예외 항목입니다. ALSA는 실제로 구성 요소를 모듈화 했을 경우 상당히 설정하기 쉽습니다.

블루투스 게시글^en에는 블루투스 장치를 사용할 때 필요한 옵션을 자세히 다룹니다.

IPv6 라우터 안내서^en에는 차세대 네트워크 주소 형식을 활용하는 라우팅 기능을 갖추기 위한 커널 설정 방법을 자세히 다룹니다.

3D 그래픽 성능을 개선하기 위해 폐쇄 소스코드 기반 nVidia 그래픽 드라이버를 사용한다면 nVidia 안내서를 통해 시스템에서 어떤 옵션을 선택할 지 말아야 할 지 보여줍니다.

그 밖에, 전원 관리 안내서에서는 CPU 주파수 스케일링, 대기, 최대 절전 기능을 활용하기 위한 커널 설정 방법을 설명합니다.

PowerPC 시스템을 사용중이라면 PPC FAQ에서 PPC 커널 설정을 다루는 일부 장을 살펴보십시오.

인쇄 안내^en에는 리눅스 인쇄 지원에 필요한 커널 옵션이 있습니다.

USB 안내서^en에는 키보드, 마우스, 저장장치, USB 프린터와 같은 일반 USB 장치를 사용하는데 필요한 설정을 자세하게 다룹니다.

문제 해결

바뀐 설정 적용 안됨

설정을 바꿀 때 사용자에게 일어나는 흔한 일이지만, 새로 설정한 커널을 실제로 부팅하는 과정에서 벌인 사소한 실수일 뿐입니다. 다시 설정한 커널이 아닌 커널 이미지로 다시 부팅했고 어떤 문제이든지 간에 풀려던 문제가 아직도 나타나고 있음을 찾고 있으며, 때문에 바꾸어놓은 설정이 문제를 해결하지 않았다고 볼 수 있습니다.

커널 컴파일 및 설치 과정은 이 문서의 범위를 벗어납니다. 일반적인 안내 내용을 보시려면 커널 업그레이드 안내서를 보십시오. 간단하게 말씀드리자면, 수정한 커널은 1) 설정, 2) 컴파일, 3) (마운트 하지 않았다면)/boot 마운트, 4) /boot에 새 커널 이미지 복사, 5) 새 커널을 참조하도록 부트로더 확인, 6) 재부팅, 순서를 따릅니다. 중간에 빠진 절차가 있다면, 바뀐 결과대로 동작하지 않습니다.

configure
compile
mount /boot (if not already mounted)
copy new kernel image to /boot
make sure the bootloader will reference the new kernel
reboot

If one of those final stages has been missed, then the changes will not properly take effect.

하드디스크에서 새로 컴파일한 커널과 일치하는지 확인할 수 있습니다. 커널 컴파일한 날짜와 시각을 확인하면 됩니다. 시스템 아키텍처를 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분 이상 차이나면 커널 설치에 문제가 있어 새로 수정한 커널 이미지로 부팅하지 않았음을 나타냅니다.

모듈을 자동으로 불러오지 않음

이 문서 앞에서 언급했듯이 커널 설정 시스템에서는 커널 구성 요소를 빌드시 포함(Y)이 아닌 모듈(M)로 설정했을 때, 상당한 양의 동작상 변화를 숨깁니다. 이 문제에 수많은 사용자들이 낚일 수 있기 때문에 다시 말씀드리는게 좋을거라 보고 있습니다.

커널에 포함하여 빌드하도록 구성 요소를 선택하면, 소스 코드를 커널 이미지(bzImage)에 넣어 빌드합니다. 커널에서 해당 구성 요소를 필요로 한다면, 사용자의 개입 과정 없이 자동으로 초기화한 후 불러옵니다.

구성 요소를 모듈로 선택하면, 코드는 커널 모듈 파일로 빌드하며, 파일 시스템에 설치합니다. 보통, 커널이 해당 구성 요소를 사용해야 한다면 찾을 수 없습니다. 일부 예외적으로는, 실제 모듈을 불러오려고도 하지 않습니다. 이 작업은 사용자가 처리해야합니다.

만약 네트워크 카드를 모듈로 빌드하였고, 네트워크에 접근할 수 없는 문제를 발견했다면 아마도 모듈을 불러오지 않았기 때문일지도 모릅니다. 직접 모듈을 불러오거나 시스템에서 부팅 시간에 자동으로 모듈을 불러오도록 설정해야합니다.

사용자가 다른 방식을 취해야 할 이유가 있지 않는 한, 해당 구성 요소를 커널에 넣어 빌드하여 커널에서 자체적으로 일부 설정을 알아서 설정할 수 있게 하면 해결할 수 있습니다.

추가 참조

genkernel - 커널 및 initramfs 빌드 과정을 자동화할 때 쓰는 도구입니다.
proc 파일 시스템(보안 핸드북) - 커널 동작 중 매개 변수 값과 변수 값을 동적으로 바꿉니다.

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Daniel Drake, Curtis Napier, Justin Robinson, Lukasz Damentko, Jonathan Smith, nightmorph
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.