젠투 리눅스 amd64 핸드북: 젠투 설치

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

도입부

환영합니다

우선, 젠투의 세계에 잘 오셨습니다! 선택과 성능의 세계로 들어오셨습니다. 젠투는 선택 그 자체입니다. 젠투를 설치할 때, 사용자 자신이 얼마나 스스로 컴파일 하고 싶어하는지, 어떤 시스템 로거를 사용하는지 등에 대해 여러번 명확히 밝혀두었습니다.

Openness

Gentoo's premier tools are built from simple programming languages. Portage, Gentoo's package maintenance system, is written in Python. Ebuilds, which provide package definitions for Portage are written in bash. Our users are encouraged to review, modify, and enhance the source code for all parts of Gentoo.

By default, packages are only patched when necessary to fix bugs or provide interoperability within Gentoo. They are installed to the system by compiling source code provided by upstream projects into binary format (although support for precompiled binary packages is included too). Configuring Gentoo happens through text files.

For the above reasons and others: openness is built-in as a design principle.

Choice

젠투는 빠르며, 깔끔하며 유연한 설계를 갖춘 최신 메타 배포판입니다. 젠투는 자유 소프트웨어 환경을 빌드하며 사용자의 눈 밖으로 그 어떠한 요소도 숨겨두지 않았습니다. 젠투에서 사용하는 꾸러미 관리 시스템 포티지를 파이썬으로 작성했다는건, 사용자가 쉽게 코드를 살펴보고 수정할 수 있음을 의미합니다. 젠투 꾸러미 시스템은 (비록 미리 컴파일한 꾸러미도 들어있지만) 소스 코드를 활용하며 일반 텍스트 파일을 통해 젠투를 설정합니다. 다시 말해, 모든 부분이 열려있습니다.

When installing Gentoo, choice is made clear throughout the Handbook. System administrators can choose two fully supported init systems (Gentoo's own OpenRC and Freedesktop.org's systemd), partition structure for storage disk(s), what file systems to use on the disk(s), a target system profile, remove or add features on a global (system-wide) or package specific level via USE flags, bootloader, network management utility, and much, much more.

As a development philosophy, Gentoo's authors try to avoid forcing users onto a specific system profile or desktop environment. If something is offered in the GNU/Linux ecosystem, it's likely available in Gentoo. If not, then we'd love to see it so. For new package requests please file a bug report or create your own ebuild repository.

Power

Being a source-based operating system allows Gentoo to be ported onto new computer instruction set architectures and also allows all installed packages to be tuned. This strength surfaces another Gentoo design principle: power.

A system administrator who has successfully installed and customized Gentoo has compiled a tailored operating system from source code. The entire operating system can be tuned at a binary level via the mechanisms included in Portage's make.conf file. If so desired, adjustments can be made on a per-package basis, or a package group basis. In fact, entire sets of functionality can be added or removed using USE flags.

젠투를 동작하게 하는 요소의 선택에 대해 모든 사람이 이해하는 것이 중요합니다. 사용자들이 좋아하지 않는 그 어떤 것도 강요하려 들지 않습니다. 강요한다는 느낌을 받는다면 버그 보고서^en로 제출하십시오.

설치 구성 방식

젠투 설치를 다음 장의 모음에 따라 10단계로 나누어 볼 수 있습니다. 각각의 단계가 끝나면 다음과 같은 결과 상태가 됩니다:

단계	결과
1	젠투를 설치할 수 있는 환경을 준비합니다.
2	젠투를 설치할 인터넷 연결 환경을 준비합니다
3	젠투를 설치할 하드디스크를 준비합니다.
4	설치환경을 준비하고, 새 환경으로 루트 기준을 전환할 수 있습니다.
5	모든 젠투 설치 프로그램이 있는 핵심 꾸러미의 설치가 끝납니다.
6	리눅스 커널을 설치합니다.
7	대부분의 젠투 시스템 설정 파일이 만들어집니다.
8	필요한 시스템 도구를 설치합니다.
9	적당한 부트 로더를 설치하고 설정합니다.
10	새로 설치한 젠투 리눅스 환경을 탐색할 준비가 끝납니다.

각각의 선택이 주어질 때마다, 핸드북에서는 장점과 단점을 최대한 설명하려고 합니다. 비록 내용은 기본 선택으로 진행하겠지만(제목에 "기본:" 으로 표시), 마찬가지로 다른 가능성도 문서에 기록했습니다(제목에 "대안:"으로 표시). 기본 사항이 젠투에서 추천하는 선택이라고 생각하지 마십시오. 하지만 대부분 사용자가 선택할 것이라는 생각은 듭니다.

가끔 선택의 기로에 직면할 수 있습니다. 이런 단계는 "선택:" 으로 표시했으며 젠투를 설치하는데 필요하지는 않습니다. 그러나 몇가지 선택 단계는 이전 결정 요소에 따라 의존성이 있을 수 있습니다. 우리는 이런 일에 대해서 선택 단계를 설명하기 전에 알려 드리겠습니다.

젠투 설치 옵션

젠투는 오만가지 방법으로 설치할 수 있습니다. 젠투 설치 CD나 DVD 같은 공식 젠투 설치 미디어로 다운로드하고 설치할 수 있습니다. 설치 미디어는 USB 메모리에 설치하거나 네트워크 부팅 환경으로 접근할 수 있습니다. 대신 젠투는 이미 설치한 배포판과 같은 비공식 미디어에서도 설치할 수 있으며, 또는 젠투가 들어있지 않은 부팅 디스크(예: Knoppix)에서도 설치할 수 있습니다.

이 문서는 공식 젠투 설치 미디어를 활용한 설치 방법을 다루거나, 경우에 따라 네트워크 부팅을 통한 설치를 다룹니다.

참고
비 젠투 CD 를 이용한 방법을 포함한 다른 방법을 통해 설치를 시도할 경우 대안 설치 안내서를 읽으십시오.

또한 마찬가지로 약간의 도움을 줄 수 있을지도 모르는 젠투 설치 요령 문서를 제공합니다.

문제

설치(또는 설치 문서)에 문제가 있다면, 버그 추적 시스템^en을 찾아보시고 알려진 버그인지 확인하십시오. 그렇지 않으면 우리가 이를 처리할 수 있게 버그 보고서를 만들어주십시오. 버그를 할당 받을 개발자를 두려워하지 마십시오 -- (보통) 사람을 잡아먹지는 않으니까요.

참고로, 이 문서가 각각의 아키텍처와 관련된 문서이긴 하지만, 다른 아키텍처에도 참조로 포함합니다. 젠투 핸드북의 많은 부분이 (개발 자원의 고립과 역작의 중복을 막기 위해) 모든 아키텍처를 대상으로 공유하는 일반적인 내용을 활용하기 때문입니다. 우리는 혼란을 막기 위해 내용 중복을 최소한으로 유지하겠습니다.

당면한 문제가 사용자 문제(문서를 주의깊게 읽었음에도 불구하고 여러분이 발생시키는 에러)인지 소프트웨어 문제(설치, 문서를 충분히 시험했음에도 불구하고 우리가 만들어낸 문제)인지 확실치 않다면 irc.freenode.net 의 #gentoo (webchat) 채널에 자유롭게 참가하시면 됩니다. 물론 다른 이유에서라도 우리는 여러분을 반갑게 맞이하겠습니다.

만약 젠투에 대한 질문이 있다면, 자주 묻는 질문 게시글을 확인하십시오. 젠투 포럼^en에서도 자주 묻는 질문^en을 볼 수 있습니다.

← 처음 처음 올바른 매체 선택 →

하드웨어 요구 사항

시작하기 전에, 우선 amd64 장치에 젠투를 성공적으로 설치할 때 필요한 하드웨어 요구 사항을 하나하나 살펴보겠습니다.

	소형 CD	LiveDVD
CPU	AMD64 CPU 또는 EM64T^en CPU (Core 2 Duo & Quad 프로세서는 EM64T임)
메모리	256 MB	512 MB
디스크 공간	2.5 GB (스왑 공간 제외)
스왑 공간	최소 256 MB

젠투 AMD64 프로젝트 페이지^en는 젠투 amd64 지원 정보를 알아보기에 좋은 곳입니다.

젠투 리눅스 설치 미디어

요령
While it's recommended to use the official Gentoo boot media when installing, it's possible to use other installation environments. However, there is no guarantee they will contain required components. If an alternate install environment is used, skip to Preparing the disks.

소형 설치 CD

젠투 소형 설치 CD는 자체적으로 젠투 환경을 지니고 있는 부팅 이미지입니다. 이 CD또는 다른 설치 미디어를 통해 사용자가 리눅스를 부팅할 수 있습니다. 부팅 과정에서 하드웨어를 감지하고, 적절한 드라이버를 불러옵니다. 이미지는 젠투 개발자가 관리하며, 인터넷에 연결한 상태라면 누구든 젠투를 설치할 수 있습니다.

소형 설치 CD는 install-amd64-minimal-<release>.iso 파일 이름을 지니고 있습니다.

The Gentoo LiveGUI

Some users may find it easier to install Gentoo using the LiveGUI, which provides a KDE desktop environment. In addition to providing a useful graphical environment, the LiveGUI has more kernel modules and firmware, which can help with using modern Wi-Fi chipsets.

참고
The Gentoo LiveGUI USB image is built for amd64 and arm64 platforms weekly.

그러면 스테이지란 무엇인가요?

스테이지 3 타르볼은 최소한의 젠투 환경을 갖추고 있는 저장 파일이며, 이 설명서의 지시에 따라 젠투 설치를 계속하는데 안성맞춤입니다. 이전에 젠투 핸드북은 세가지 스테이지 타르볼^en을 사용한 설치 방법을 설명했습니다. 젠투에서 스테이지 1과 스테이지 2 타르볼을 여전히 제공하는 동안 공식 설치 방식은 스테이지 3 타르볼을 사용했습니다. 스테이지 1 또는 스테이지 2 타르볼을 이용한 젠투 설치 진행에 관심이 있다면 젠투에 대한 자주 묻는 질문에서 스테이지 1이나 스테이지 2 타르볼을 어떻게 설치하죠?를 읽어보십시오.

스테이지 3 타르볼은 공식 젠투 미러^en중 어디서든 releases/amd64/autobuilds/ 위치에서 다운로드 할 수 있습니다. 스테이지 파일은 자주 업데이트하며, 설치 CD에는 없습니다.

요령
For now, stage files can be ignored. They will be described in greater detail later when they are needed

참고
Historically, the handbook described installation steps for stage files with versions lower than 3. These stages contained environments unsuitable for typical installations, and are no longer covered in the handbook.

다운로드

미디어 가져오기

젠투 리눅스에서 사용하는 기본 설치 매체는 부팅이 가능하고, 매우 간단한 젠투 리눅스 환경을 갖추고 있는 소형 설치 CD 입니다. 이 환경에는 젠투 설치에 적절한 모든 도구가 들어있습니다. CD 이미지 자체는 다운로드 페이지(추천)를 방문하거나 여러 가용 미러^en중 한 곳에서 ISO 파일을 직접 찾아 다운로드할 수 있습니다.

Navigating Gentoo mirrors

미러에서 다운로드할 경우, 소형 설치 CD는 다음과 같은 절차를 통해 찾을 수 있습니다:

releases/ 디렉터리로 이동하십시오.
(amd64/와 같은) 대상 아키텍처 관련 디렉터리를 선택하십시오
autobuilds/를 선택하십시오.
amd64 및 x86 아키텍처용 파일은 각각의 경우에 대해 current-install-amd64-minimal/ 또는 current-install-x86-minimal/ 디렉터리를 찾아보십시오. 다른 모든 아키텍처용 파일을 찾아보려면 current-iso/ 디렉터리를 탐색하십시오.

참고
arm, mips, s390 같은 일부 대상 아키텍처는 소형 설치 CD가 없습니다. 이 경우, 젠투 출시 엔지니어링 프로젝트는 이 아키텍처를 대상으로 .iso 파일을 지원하지 않습니다.

이 위치 안에 있는 설치 미디어 파일은 .iso 접미사로 끝나는 파일입니다. 예를 들어 다음 목록을 보시면:

코드 releases/amd64/autobuilds/current-iso/ 의 다운로드 파일 목록 예제

[DIR] hardened/                                          05-Dec-2014 01:42    -   
[   ] install-amd64-minimal-20141204.iso                 04-Dec-2014 21:04  208M  
[   ] install-amd64-minimal-20141204.iso.CONTENTS        04-Dec-2014 21:04  3.0K  
[   ] install-amd64-minimal-20141204.iso.DIGESTS         04-Dec-2014 21:04  740   
[TXT] install-amd64-minimal-20141204.iso.DIGESTS.asc     05-Dec-2014 01:42  1.6K  
[   ] stage3-amd64-20141204.tar.bz2                      04-Dec-2014 21:04  198M  
[   ] stage3-amd64-20141204.tar.bz2.CONTENTS             04-Dec-2014 21:04  4.6M  
[   ] stage3-amd64-20141204.tar.bz2.DIGESTS              04-Dec-2014 21:04  720   
[TXT] stage3-amd64-20141204.tar.bz2.DIGESTS.asc          05-Dec-2014 01:42  1.5K

위 예제에서 install-amd64-minimal-20141204.iso 파일이 소형 설치 CD 그 자체입니다. 그러나 보시다시피, 다른 관련 파일도 있습니다:

A .CONTENTS 파일은 설치 미디어의 모든 파일 목록이 들어있는 텍스트 파일입니다. 이 파일은 펌웨어 또는 드라이버를 다운로드하기 전에 설치 미디어에 있는지 검사할 때 활용합니다.
A .DIGESTS 파일은 ISO 파일의 해시값이 들어있으며 다양한 해시 형식과 알고리즘을 동원합니다. 이 파일은 다운로드한 ISO 파일이 깨졌는지 검사할 때 사용할 수 있습니다.
A .DIGESTS.asc 파일은 ISO 파일의 해시 값만 들어있는 것이 아니라(.DIGESTS 파일과 유사), 파일의 암호화 서명도 들어있습니다. 이 파일은 다운로드한 ISO 파일이 깨졌는지 검사할때 사용할 수 있을 뿐만 아니라, 젠투 릴리즈 엔지니어링 팀이 확실히 제공했고, 변조되지 않았는지 검사할 때도 사용할 수 있습니다.

지금은 현재 위치에 존재하는 다른 파일을 무시하십시오. 이들 파일은 나중에 진행할 설치 과정에서 다시 다룹니다. .iso 파일을 다운로드하고, 다운로드 파일을 검증하려면, 해당 .iso파일에 대한 .DIGESTS.asc 파일 역시 마찬가지로 다운로드하십시오. .CONTENTS 파일은 설치 과정에서 더이상 참조하지 않으므로 다운로드할 필요가 없으며, .DIGESTS 파일은 .DIGESTS.asc과 비교하였을 때, 상단의 암호화 서명을 제외한 나머지 부분은 동일한 내용이 들어갑니다.

요령
The .DIGESTS file is only needed if the signature in the .iso.asc file is not verified.

다운로드한 파일 검증

참고
이 과정은 선택적 과정이며 젠투 리눅스를 설치하는데 굳이 필요하지 않습니다만, 다운로드한 파일이 깨졌는지 확인하고 젠투 기반 팀이 분명히 지원 했는지 확인해보시는 것이 좋습니다.

먼저, 젠투 출시 엔지니어링 팀이 제공한 설치 파일인지 암호화 서명으로 확인합니다.
암호화 서명 검증이 끝나면, 다운로드 파일이 깨졌는지 확인합니다.

마이크로소프트 윈도우 기반 검증

우선 암호화 서명을 검증하려면 GPG4Win^en과 같은 도구를 사용할 수 있습니다. 설치 후 젠투 출시 엔지니어링 팀의 공개 키를 가져와야합니다. 키 목록은 서명 페이지^en에 있습니다. 키를 가져온 후, 사용자는 .DIGESTS.asc 파일의 서명을 검증할 수 있습니다.

리눅스 기반 검증

리눅스 시스템에서 대부분의 일반적인 암호화 서명을 검증하는 방식은 app-crypt/gnupg 프로그램을 사용하는 것입니다. 이 꾸러미를 설치하면, 다음 명령을 사용하여 .DIGESTS.asc 파일의 암호화 서명을 검증할 수 있습니다.

요령
When importing Gentoo keys, verify that the fingerprint (BB572E0E2D182910) matches.

먼저 서명 페이지^en에 있는 올바른 키 모음을 다운로드하십시오:

user $gpg --keyserver hkp://keys.gnupg.net --recv-keys 0xBB572E0E2D182910

gpg: requesting key 0xBB572E0E2D182910 from hkp server pool.sks-keyservers.net
gpg: key 0xBB572E0E2D182910: "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" 1 new signature
gpg: 3 marginal(s) needed, 1 complete(s) needed, classic trust model
gpg: depth: 0  valid:   3  signed:  20  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: depth: 1  valid:  20  signed:  12  trust: 9-, 0q, 0n, 9m, 2f, 0u
gpg: next trustdb check due at 2018-09-15
gpg: Total number processed: 1
gpg:         new signatures: 1

Alternatively you can use instead the WKD to download the key:

user $gpg --auto-key-locate=clear,nodefault,wkd --locate-key releng@gentoo.org

gpg: key 9E6438C817072058: public key "Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>" imported
gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
pub   dsa1024 2004-07-20 [SC] [expires: 2025-07-01]
      D99EAC7379A850BCE47DA5F29E6438C817072058
uid           [ unknown] Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>
sub   elg2048 2004-07-20 [E] [expires: 2025-07-01]

Or if using official Gentoo release media, import the key from /usr/share/openpgp-keys/gentoo-release.asc (provided by sec-keys/openpgp-keys-gentoo-release):

user $gpg --import /usr/share/openpgp-keys/gentoo-release.asc

gpg: directory '/home/larry/.gnupg' created
gpg: keybox '/home/larry/.gnupg/pubring.kbx' created
gpg: key DB6B8C1F96D8BF6D: 2 signatures not checked due to missing keys
gpg: /home/larry/.gnupg/trustdb.gpg: trustdb created
gpg: key DB6B8C1F96D8BF6D: public key "Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org>" imported
gpg: key 9E6438C817072058: 3 signatures not checked due to missing keys
gpg: key 9E6438C817072058: public key "Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) <releng@gentoo.org>" imported
gpg: key BB572E0E2D182910: 1 signature not checked due to a missing key
gpg: key BB572E0E2D182910: public key "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" imported
gpg: key A13D0EF1914E7A72: 1 signature not checked due to a missing key
gpg: key A13D0EF1914E7A72: public key "Gentoo repository mirrors (automated git signing key) <repomirrorci@gentoo.org>" imported
gpg: Total number processed: 4
gpg:               imported: 4
gpg: no ultimately trusted keys found

다음, .DIGESTS.asc 파일의 암호화 서명을 검증하십시오:

user $gpg --verify install-amd64-minimal-20141204.iso.DIGESTS.asc

gpg: Signature made Fri 05 Dec 2014 02:42:44 AM CET
gpg:                using RSA key 0xBB572E0E2D182910
gpg: Good signature from "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD  B1BA BB57 2E0E 2D18 2910

다운로드한 모든 파일이 완전히 올바른지 확인하려면, 젠투 서명 페이지^en에 있는 지문키를 받아 검증하십시오.

참고
It's generally good practice to mark an imported key as trusted, once it's certain the key is trustworthy. When trusted keys are verified, gpg will not say unknown and warn about the signature being untrusted.

Writing the boot media

물론 ISO 파일을 다운로드한 것만으로는 젠투 리눅스 설치를 시작할 수 없습니다. ISO 파일을 부팅할 CD에 구워야 하며, 이와 같은방법으로 파일 자체를 CD에 굽는 것이 아니라 파일 안의 내용을 굽습니다. 아래 몇가지 일반적인 방식을 설명했습니다. 보다 자세한 과정은 자주 묻는 ISO 파일 굽기 질문에서 찾아볼 수 있습니다.

Writing a bootable USB

Most modern systems support booting from a USB device.

Writing with Linux

dd is typically available on most Linux distros, and can be used to write the Gentoo boot media to a USB drive.

Determining the USB device path

Before writing, the path to the desired storage device must be determined.

dmesg will display detailed information describing the storage device as it is added to the system:

root #dmesg

[268385.319745] sd 19:0:0:0: [sdd] 60628992 512-byte logical blocks: (31.0 GB/28.9 GiB)

Alternatively, lsblk can be used to display available storage devices:

root #lsblk

sdd           8:48   1  28.9G  0 disk
├─sdd1        8:49   1   246K  0 part
├─sdd2        8:50   1   2.8M  0 part
├─sdd3        8:51   1 463.5M  0 part
└─sdd4        8:52   1   300K  0 part

Once the device name has been determined, this can be added to the path prefix /dev/ to get the device path /dev/sdd.

요령
Using the base device path, ie. sdd opposed to sdd1, is recommend as the Gentoo boot media contains a full GPT partition scheme.

Writing with dd

경고
Be sure to check the target (of=target) path before executing dd, as it will be overwritten.

With the device path (/dev/sdd) and boot media install-amd64-minimal-<release timestamp>.iso ready:

root #dd if=install-amd64-minimal-<release timestamp>.iso of=/dev/sdd bs=4096 status=progress && sync

참고
if= specifies the input file, of= specifies the output file, which in this case, is a device.

요령
bs=4096 is used as it speeds up transfers in most cases, status=progress displays transfers stats.

디스크 굽기

See also
A more elaborate set of instructions can be found in CD/DVD/BD_writing#Image_writing.

마이크로소프트 윈도우에서 굽기

리눅스에서 굽기

리눅스에서는 app-cdr/cdrtools 꾸러미의 일부인 cdrecord 명령을 사용하여 CD를 구울 수 있습니다.

예를 들자면, ISO 파일을 /dev/sr0 장치의 CD에 구우려고 할 때(이 장치는 시스템의 첫번째 CD 장치입니다 - 필요한 경우 올바른 장치 파일로 바꾸십시오):

user $cdrecord dev=/dev/sr0 install-amd64-minimal-20141204.iso

이에 상응하는 그래픽 사용자 인터페이스로 kde-apps/k3b의 일부인 K3B를 사용할 수 있습니다. K3B에서, Tools로 이동후, Burn CD Image를 사용하십시오. 그 다음 K3B에서 안내하는 절차를 따르십시오.

부팅

설치 미디어 부팅

미디어를 준비하고 나면 부팅할 차례입니다. 시스템에 미디어를 장착한 후, 다시 부팅하고 마더보드 펌웨어 사용자 인터페이스로 들어가십시오. 보통 전원 인가 후 자체 시험(POST) 과정에서 DEL, F1, F10, ESC키를 누르면 들어갈 수 있습니다. '실행' 키는 시스템과 마더보드에 따라 다릅니다. 확실하지 않으면 인터넷 검색엔진을 활용하시고, 마더보드 모델 이름으로 이리저리 찾아보십시오. 결과는 금방 알아볼 수 있을겁니다. 마더보드 펌웨어 메뉴로 들어가고 나면 부팅 순서를 바꿔서 내장 디스크 장치로 들어가보기 전에 외장 부팅 미디어(CD/DVD 또는 USB 드라이브)로 부팅을 시도할 수 있게 하십시오. 이렇게 설정을 바꾸지 않으면 거의 대부분 외장 부팅 미디어를 무시하고, 내장 디스크 장치로 다시 부팅합니다.

중요
BIOS 대신에 UEFI 인터페이스를 활용할 목적으로 젠투를 설치한다면 UEFI로 바로 부팅하는 방법을 추천합니다. 그렇지 않으면 젠투 리눅스 설치를 마치기 전에 부팅용 UEFI USB 스틱(또는 다른 매체)을 만들어야 할지도 모릅니다.

과정이 끝나지 않았다면 설치 미디어를 드라이브에 넣었거나 장착했는지 확인하고, 다시 부팅하십시오. 부팅 프롬프트를 띄워야 합니다. 해당 화면에서, 기본 부팅 옵션으로 부팅 과정을 시작하려면 Enter키를 누르시면 됩니다. 개별 부팅 옵션으로 설치 미디어를 부팅하려면, 다음 커널을 부팅 옵션으로 지정하고 Enter를 치십시오.

참고
보통의 경우에 위에서 언급했듯이 별도의 인자를 특정하지 않은 기본 젠투 커널도 잘 작동합니다. 부팅 문제 해결이나 전문가 옵션을 확인하려면, 이 섹션을 계속해서 읽으시기 바랍니다. 그렇지 않으면, Enter를 누르고 추가 하드웨어 설정로 넘어가시기 바랍니다.

부팅 프롬프트에서, 존재하는 커널을 표시하는 옵션(F1)과 부팅 옵션(F2)이 있습니다. (정보 표시든 사용할 커널 이든)15초 안에 선택하지 않으면, 설치 미디어는 디스크 부팅 과정으로 넘어갑니다. 이 과정에서는 설치 매체에서 다시 부팅하거나 CD를 서랍에서 제거하지 않고 설치한 환경을 사용해볼 수 있습니다(원격 설치를 위한 목적일 수도 있습니다).

지정한 커널을 표시합니다. 최소 설치 미디어의 경우, 기 지정한 커널 부팅 옵션 두가지만 제공합니다. 기본 옵션 하나는 gentoo입니다. 다른 하나는 커널 프레임버퍼 기능을 끄는 -nofb 값입니다.

다음은 사용할 수 있는 커널 요약 정보 및 설명을 나타냅니다.

커널 선택

gentoo

K8 CPU(NUMA 지원 포함)와 EM64T CPU를 지원하는 기본 커널

gentoo-nofb

"gentoo"와 동일하나 프레임버퍼 기능 없음

memtest86

로컬 RAM 오류 검사

커널 측면을 살펴보면, 부팅 과정을 더욱 세밀하게 조절할 수 있도록 돕는 부팅 옵션이 있습니다.

하드웨어 옵션

acpi=on: ACPI 지원을 불러오며 시동시 CD에서 acpid 데몬을 시작합니다. 시스템에서 ACPI를 적절하게 동작시킬 필요가 있을 경우에 필요합니다. 하이퍼스레딩 지원용도로는 필요하지 않습니다.
acpi=off: ACPI 기능을 완전히 끕니다. 일부 오래된 시스템에서 쓸만하며 APM을 사용하는 시스템에서 필요합니다. 이 옵션을 주면 여러분의 프로세서의 하이퍼스레딩 기능을 끕니다.
console=X: CD로 접근할 직렬 콘솔을 설정합니다. 첫번째 옵션은 x86에서 보통 ttyS0인 장치이며, 그 다음에는 콤마로 구분한 연결 옵션이 따라옵니다. 기본 옵션은 9600,8,n,1 입니다.
dmraid=X: 장치 매퍼 RAID 하위시스템에 옵션 값을 넘겨주도록 합니다. 옵션 값은 따옴표로 둘러싸여있어야 합니다.
doapm: APM 드라이버 지원을 불러옵니다. acpi=off 사용도 필요합니다.
dopcmcia: PCMCIA와 카드버스 하드웨어 지원을 불러오며 시동시 CD에서 pcmcia cardmgr을 시작합니다. PCMCIA/카드 버스 장치에서 부팅할 때만 필요합니다.
doscsi: 대부분의 SCSI 컨트롤러 지원을 불러옵니다. 커널의 SCSI 하위시스템을 사용하는 대부분의 USB 장치로 부팅할 때도 필요합니다.
sda=stroke: BIOS가 대용량 디스크를 제어할 수 없을때 전체 하드 디스크에 대해 구역을 잡을 수 있게 해줍니다. 이 옵션은 오래된 BIOS를 사용하는 장치에서만 사용합니다. sda를 이 옵션이 필요한 장치 이름으로 바꾸십시오.
ide=nodma: 커널에서 DMA의 비활성화를 강제하며 일부 IDE 칩셋이나 CDROM 드라이브에서 필요로 합니다. 여러분의 IDE CDROM을 읽어들이는데 문제가 있다면 이 옵션을 사용해보십시오. 이 옵션은 또한 hdparm을 실행할 때 기본 옵션을 비활성화 합니다.
noapic: 최신 마더보드에서 볼 수 있는 고급 프로그램가능 인터럽트 컨트롤러(APIC)기능을 끕니다. 오래된 하드웨어에서 일부 문제가 있는 것으로 알려져 있습니다.
nodetect: 장치 자동감지 및 DHCP 감지를 포함한 CD가 할 수 있는 모든 자동감지기능을 끕니다. CD나 드라이버의 문제를 디버깅할 때 유용합니다.
nodhcp: 감지한 네트워크 카드의 DHCP 감지를 끕니다. 정적 주소를 가진 네트워크에만 유용합니다.
nodmraid: 보드에 내장한 IDE/SATA RAID 컨트롤러와 같은 장치 매퍼 RAID 지원을 비활성화 합니다.
nofirewire: Firewire 모듈 불러오기를 비활성화 합니다. CD를 시동할때 Firewire 하드웨어가 문제를 일으킬 경우에만 유용합니다.
nogpm: gpm 콘솔 마우스 지원을 비활성화 합니다.
nohotplug: 시동시 hotplug와 coldplug 시동 스크립트 불러오기를 비활성화 합니다. CD나 드라이버의 문제를 디버깅할 때 유용합니다.
nokeymap: 비 US 키보드 배치를 선택할 때 사용하는 키배치 선택을 비활성화 합니다.
nolapic: 단일 프로세서 커널의 지역 APIC를 비활성화 합니다.
nosata: 직렬 ATA 모듈 불러오기를 비활성화 합니다. SATA 하위시스템에 문제가 있을 때 사용합니다.
nosmp: SMP 활성화 커널에서 SMP 또는 대칭형 다중처리를 비활성화 합니다. 일부 드라이버나 마더보드의 SMP 관련 문제를 디버깅할 때 유용합니다.
nosound: 사운드 지원과 음량 설정 기능을 비활성화 합니다. 사운드 지원에서 문제가 발생할때 유용합니다.
nousb: USB 모듈의 자동 불러오기를 비활성화 합니다. USB 문제를 디버깅할 때 유용합니다.
slowusb: IBM 블레이드센터와 같은 느린 USB CDROM에서의 부팅 과정중에 별도의 일시정지 시간을 추가합니다.

논리 볼륨/장치 관리자

dolvm: 리눅스 논리 볼륨 관리자 기능을 활성화합니다.

기타 옵션

debug: 코드 디버깅을 활성화합니다. 엄청나게 많은 내용이 화면에 나타나기 때문에 지저분해보일 수 있습니다.
docache: CD에서 실행하는 동안에 활용할 내용을 모두 RAM에 캐싱하여 사용자가 /mnt/cdrom 마운트를 해제하고 다른 CDROM을 마운트할 수 있게 합니다. 이 옵션을 활용하려면 최소한 CD 용량 두 배의 RAM 용량이 필요합니다.
doload=X: 언급한 목록을 초기 램 디스크로 의존 요소와 함께 불러오게 합니다. X 대신 모듈 이름을 넣으시면 됩니다. 여러 모듈 이름을 쉼표로 구분하여 지정할 수 있습니다.
dosshd: 부팅할 때 sshd를 시작합니다. 담당자가 직접 붙지 않고 설치할 때 쓸만한 옵션입니다.
passwd=foo: 루트 암호 초기 값은 없는 상태이기 때문에 "dosshd" 옵션을 활용할 경우 루트 암호를 설정할 때 필요하며, foo 부분에 지정한 암호대로 루트 암호를 설정합니다.
noload=X: 불러오는 모듈 중에 문제를 일으키는 모듈을 초기 램 디스크에서 불러오지 않고 건너뛰게합니다. 표기 방식은 doload와 비슷합니다.
nonfs: 부팅할 때 portmap/nfsmount 시작을 비활성화합니다.
nox: X를 활성화 한 라이브CD 에서 자동으로 X를 시작하지 않는 대신 명령행으로 들어가게 합니다.
scandelay: 활용할 수 있게 준비하는데 오래걸리는 장치를 기다릴 수 있게 부팅 과정중에 10초간 CD 동작을 멈추게합니다.
scandelay=X: 활용할 수 있게 준비하는데 오래걸리는 장치를 기다릴 수 있게 사용자가 지정한 초 단위 시간동안 기다릴 수 있게 합니다. X 대신 초 단위 대기 시간을 넣으시면 됩니다.

참고
부팅 미디어에서 do* 옵션을 확인하기 전에 no*옵션을 먼저 확인하여 지정한 순서대로 정확하게 우선 처리합니다.

이제 CD를 부팅하고, (gentoo 커널이 충분하지 않다면)커널과 부팅 옵션을 선택하십시오. 예제에서는 dopcmcia 커널 매개 변수로 gentoo 커널을 부팅합니다:

boot:gentoo dopcmcia

그 다음 과정에서 사용자는 부팅 화면과 진행 표시줄을 만납니다. 시스템에 설치시 US 키보드 배치가 아닌 상태에서 끝냈다면, 자세한 출력 화면으로 전환하려 즉시 Alt+F1을 눌렀는지 확인하고 지시에 따르십시오. 10초 동안 아무런 선택을 하지 않으면 기본값(US 키보드)를 선택하고 부팅 과정을 계속 진행합니다. 부팅 과정이 끝나면, 사용자는 "Live" 젠투 리눅스 환경에 슈퍼유저 root 사용자로 자동으로 로그인합니다. 루트 프롬프트가 현재 콘솔에 나타나며, Alt+F2, Alt+F3, Alt+F4로 다른 콘솔로 전환할 수 있습니다. Alt+F1을 누르면 시작 콘솔로 돌아갑니다.

추가 하드웨어 설정

설치 미디어로 부팅하면 모든 하드웨어 장치를 감지하려 하고, 하드웨어를 지원하는 적절한 커널 모듈을 불러옵니다. 대부분의 주된 경우에는, 매우 잘 동작합니다. 그러나 어떤 경우에는 시스템에서 필요로 하는 커널 모듈을 자동으로 불러오지 않는 경우가 있습니다. 어떤 시스템의 하드웨어에서 PCI 자동 감지가 빠졌다면, 적당한 커널 모듈을 직접 불러와야합니다.

다음 예제에서는 8139too 모듈(네트워크 인터페이스 종류를 지원)을 불러옵니다:

root #modprobe 8139too

선택: 사용자 계정

다른 사람이 설치 환경에 접근하려 하거나 비 루트 사용자가 설치 미디어에서 명령을 실행하려 한다면(예를 들어 보안상의 이유로 루트 권한 없이 irssi를 사용하여 대화를 하려한다면), 추가 사용자 계정을 만들어야 하며, 루트 암호를 강한 암호로 설정해야 합니다.

루트 암호를 바꾸려면, passwd 유틸리티를 사용하십시오:

root #passwd

New password: (Enter your new password)
Re-enter password: (Re-enter your password)

사용자 계정을 만들려면, 신원 정보를 입력해야 하며, 계정 암호도 입력해야 합니다. 이 과정에서는 useradd와 passwd 명령을 사용합니다.

다음 예제에서, "john" 사용자를 만듭니다:

root #

useradd -m -G users john

root #passwd john

New password: (Enter john's password)
Re-enter password: (Re-enter john's password)

(현재) root 사용자에서 새로 만든 사용자 계정으로 전환하려면 su 명령을 사용하십시오:

root #su - john

선택: 설치 과정에 문서 보기

TTY

설치 과정에 젠투 핸드북을 보려면, 우선 위에서 설명한 대로 사용자 계정을 만드십시오 그 다음 Alt + F2를 눌러 새 터미널로 이동하십시오.

설치 과정에서는, 젠투 핸드북을 살펴볼 때 links 명령을사용할 수 있습니다. 물론 인터넷 연결이 동작중일때만 가능합니다.

user $links https://wiki.gentoo.org/wiki/Handbook:AMD64/ko

초기 터미널로 돌아가려면 Alt+F1을 누르십시오.

요령
When booted to the Gentoo minimal or Gentoo admin environments, seven TTYs will be available. They can be switched by pressing Alt then a function key between F1-F7. It can be useful to switch to a new terminal when waiting for job to complete, to open documentation, etc.

GNU Screen

GNU Screen 유틸리티는 공식 젠투 설치 미디어에 기본으로 들어있습니다. 위에서 언급한 다중 TTY 접속 방식 보다는 다른 창에서 설치 과정을 보려고 screen을 사용하는 노련한 리눅스 덕후에게 효율적일 수 있습니다.

선택: SSH 데몬 시작

설치 과정에 다른 사용자에게 시스템 접근을 허락하려면(아마도 설치 과정에 지원을 한다거나 원격으로 무언가를 진행하려 할 경우?), 사용자 계정을 만들어야 하며(이전에 문서에 기록한 대로) SSH 데몬을 시작해야 합니다.

SSH 데몬을 실행하려면, 다음 명령을 실행하십시오:

root #service sshd start

참고
사용자가 시스템에 로그온하면 (지문키라고 하는)이 시스템의 호스트 키를 확인해야 한다는 메시지를 봅니다. 이 동작은 보통 SSH 서버에 처음 접속했을 때 나타납니다. 그러나 시스템을 설정하고 누군가가 새로 만든 시스템에 로그온하면, SSH 클라이언트에서 호스트 키가 바뀌었다는 경고를 봅니다. 이는 달라진 SSH 서버에 사용자가 로그온했기 때문입니다(현재 사용중인 라이브 환경이 아니라 명백하게 완전히 새로 설치한 젠투 시스템이기 때문). 화면에 나타난 다음 과정을 따라 클라이언트 시스템의 호스트 키를 바꾸십시오.

sshd를 사용할 수 있게 하려면, 네트워크가 올바르게 동작해야 합니다. 네트워크 설정 장으로 계속 진행하십시오.

← 젠투 리눅스 설치 정보 처음 네트워크 설정 →

자동 네트워크 감지

아마도 바로 동작하겠죠?

시스템을 DHCP 서버가 붙은 이더넷에 연결했다면, 네트워크 설정은 거의 자동으로 이루어집니다. ssh, scp, ping, irssi, wget, links 등, 설치 CD에 들어있는 대부분의 네트워크 관련 명령 역시 바로 동작합니다.

DHCP 사용

DHCP(동적 호스트 설정 프로토콜)은 네트워크 정보(IP주소, 네트워크 마스크, 브로드캐스트 주소, 게이트웨이, 네임서버 등)를 자동으로 받을 수 있게 합니다. DHCP 서버가 네트워크에 있을 때(또는 ISP 서비스 업체에서 DHCP 서비스를 제공할 때)만 동작합니다. 네트워크 인터페이스가 이 정보를 자동으로 받게 하려면, dhcpcd를 사용하십시오:

DHCP requires that a server be running on the same Layer 2 (Ethernet) segment as the client requesting a lease. DHCP is often used on RFC1918 (private) networks, but is also used to acquire public IP information from ISPs.

요령
Official Gentoo boot media runs dhcpcd automatically at startup. This behavior can be disabled by adding the nodhcp argument to the boot media kernel commandline.

If it is not already running, dhcpcd can be started on enp1s0 with:

root #dhcpcd eth0

일부 네트워크 관리자는 시스템에서 사용할 호스트 이름과 도메인 이름을 요구합니다. 이 경우 다음 명령을 사용하십시오:

root #dhcpcd -HD eth0

To stop dhcpcd, -x can be used:

root #dhcpcd -x

sending signal Term to pid 10831
waiting for pid 10831 to exit

See also
Dhcpcd usage

네트워크 시험

A properly configured default route is a critical component of Internet connectivity, route configuration can be checked with:

root #ip route

default via 192.168.0.1 dev enp1s0

If no default route is defined, Internet connectivity is unavailable, and additional configuration is required.

Basic internet connectivity can be confirmed with a ping:

root #ping -c 3 1.1.1.1

요령
It's helpful to start by pinging a known IP address instead of a hostname. This can isolate DNS issues from basic Internet connectivity issues.

Outbound HTTPS access and DNS resolution can be confirmed with:

root #curl --location gentoo.org --output /dev/null

모든 기능이 제대로, 이 장의 나머지를 건너뛰고 바로 다음 단계 설치 과정 (디스크 준비)으로 진행할 수 있습니다.

If curl reports an error, but Internet-bound pings work, DNS may need configuration.

If Internet connectivity has not been established, first interface information should be verified, then:

net-setup can be used to assist in network configuration.
Application specific configuration may be required.
Manual network configuration can be attempted.

인터페이스 이름 결정

If networking doesn't work out of the box, additional steps must be taken to enable Internet connectivity. Generally, the first step is to enumerate host network interfaces.

ifconfig의 대안 수단으로 ip 명령을 인터페이스 이름으로 결정하요 사용할 수 있습니다. 다음 예제에서는 ip addr 출력 내용(은 다른 시스템의 내용이며 이전 내용과 조금 다름)을 보여줍니다:

The link argument can be used to display network interface links:

root #ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff

The address argument can be used to query device address information:

root #ip addr

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e8:40:f2:ac:25:7a brd ff:ff:ff:ff:ff:ff
    inet 10.0.20.77/22 brd 10.0.23.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::ea40:f2ff:feac:257a/64 scope link 
       valid_lft forever preferred_lft forever

The output of this command contains information for each network interface on the system. Entries begin with the device index, followed by the device name: enp1s0.

요령
ifconfig 명령을 사용했을 때 인터페이스가 나타나지 않으면, 동일한 명령에 -a 옵션을 사용해보십시오. 이 옵션은 유틸리티에 시스템에서 발견한 모든 인터페이스의 가동 여부를 표시하도록 강제합니다. ifconfig -a 출력에 내용이 나타나지 않으면 하드웨어에 문제가 있거나 인터페이스 드라이버를 커널에 불러오지 않았음음을 의미합니다. 두 경우는 이 핸드북의 주제 범위를 벗어납니다. #gentoo (webchat)에 지원을 문의하십시오.

이 문서 나머지 과정에서, 핸드북은 동작하는 네트워크 인터페이스를 eth0라 하겠습니다.

유추 가능 인터페이스 이름으로 추세가 이동함에 따라, 시스템에 있는 인터페이스 이름은 이전에 사용하던 eth0 이름 부여 방식과 약간 다를 수 있습니다. 최근 설치 미디어에서는 eno0, ens1, enp5s0와 같은 규칙적인 네트워크 인터페이스 이름을 표시합니다. ifconfig 출력에서 로컬 네트워크와 관련된 IP 주소와 함께 네트워크 인터페이스를 찾아 나타냄을 살펴보십시오.

Optional: Application specific configuration

The following methods are not generally required, but may be helpful in situations where additional configuration is required for Internet connectivity.

선택: 프록시 설정

인터넷을 프록시로 연결했다면 설치 과정에 프록시를 설정해야 합니다. 프록시 설정은 정말 쉽습니다. 프록시 서버 정보를 넣을 변수를 설정하기만 하면 됩니다.

Certain text-mode web browsers such as links can also make use of environment variables that define web proxy settings; in particular for the HTTPS access it also will require the https_proxy environment variable to be defined. While Portage will be influenced without passing extra run time parameters during invocation, links will require proxy settings to be set.

대부분의 경우, 서버의 호스트 이름을 사용하여 변수를 정의하는 것으로 충분합니다. 예제에서는 proxy.gentoo.org라는 프록시 서버와 8080포트를 사용한다고 가정하겠습니다.

참고
The # symbol in the following commands is a comment. It has been added for clarity only and does not need to be typed when entering the commands.

HTTP 프록시(HTTP와 HTTPS 트래픽용)를 설정하려면:

root #export http_proxy="http://proxy.gentoo.org:8080"

프록시에 사용자 이름과 암호가 필요하다면, 변수에 다음 문법을 사용하십시오:

코드 프록시 변수에 사용자 이름/암호 추가

http://username:password@proxy.gentoo.org:8080

Start links using the following parameters for proxy support:

user $links -http-proxy ${http_proxy} -https-proxy ${https_proxy}

FTP 프록시를 설정하려면:

root #export ftp_proxy="ftp://proxy.gentoo.org:8080"

Start links using the following parameter for a FTP proxy:

user $links -ftp-proxy ${ftp_proxy}

RSYNC 프록시를 설정하려면:

root #export RSYNC_PROXY="proxy.gentoo.org:8080"

대안: PPP 사용

If PPPoE is required for Internet access, the Gentoo boot media includes the pppoe-setup script to simplify ppp configuration.

During setup, pppoe-setup will ask for:

The name of the Ethernet interface connected to the ADSL modem.
The PPPoE username and password.
DNS server IPs.
Whether or not a firewall is needed.

root #

pppoe-setup

root #pppoe-start

In the event of failure, credentials in /etc/ppp/pap-secrets or /etc/ppp/chap-secrets should be verified. If credentials are correct, PPPoE Ethernet interface selection should be checked.

대안: PPTP 사용

PPTP 지원이 필요하다면, 설치 CD에서 제공하는 pptpclient를 사용하십시오. 그러나 우선은 설정이 올바른지부터 확인하십시오. /etc/ppp/pap-secrets 또는 /etc/ppp/chap-secrets 파일을 편집하여 올바른 사용자 이름과 암호 조합이 들어가도록 하십시오:

Edit /etc/ppp/pap-secrets or /etc/ppp/chap-secrets so it contains the correct username/password combination:

root #nano -w /etc/ppp/chap-secrets

다음, 필요한 경우 /etc/ppp/options.pptp를 편집하십시오:

root #nano -w /etc/ppp/options.pptp

모든 조치가 완료되었다면, (options.pptp에 설정할 수 없던 옵션으로) pptp를 실행하여 서버에 연걸하십시오:

root #pptp <server ip>

무선 네트워크 접근 준비

경고
Do not use WEP unless it is the only option. WEP provides essentially no security over an open network.

참고
iw 명령 지원은 아키텍처별로 다릅니다. 명령을 사용할 수 없다면, 현재 아키텍처에서 net-wireless/iw 꾸러미를 사용할 수 있는지 참고하십시오. iw 명령은 net-wireless/iw 꾸러미를 설치하지 않으면 활용할 수 없습니다.

무선 네트워크(802.11)카드를 사용한다면, 무엇보다도 먼저 무선 설정을 해야 합니다. 현제 무선 네트워크 카드의 무선 설정을 보려면 iw 명령을 사용하시면 됩니다. iw를 실행하면 결과는 다음과 비슷합니다:

root #iw dev wlp9s0 info

Interface wlp9s0
	ifindex 3
	wdev 0x1
	addr 00:00:00:00:00:00
	type managed
	wiphy 0
	channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
	txpower 30.00 dBm

현재 연결 상태를 확인하려면:

root #iw dev wlp9s0 link

Not connected.

또는

root #iw dev wlp9s0 link

Connected to 00:00:00:00:00:00 (on wlp9s0)
	SSID: GentooNode
	freq: 2462
	RX: 3279 bytes (25 packets)
	TX: 1049 bytes (7 packets)
	signal: -23 dBm
	tx bitrate: 1.0 MBit/s

참고
일부 무선 네트워크 카드는 wlp9s0 대신 wlan0또는 ra0 장치 이름을 갖습니다. 정확한 장치 이름을 알아보려면 iplink를 실행하십시오.

대부분 사용자에게 바꾸어야 할 중요한 두가지 항목이 있는데, ESSID(무선 네트워크 이름으로 알려짐)와 경우에 따라 바꿀 WEP 키입니다.

우선 인터페이스 활성화 여부를 확인합니다:

root #ip link set dev wlp9s0 up

GentooNode 공개 네트워크로 연결하려면:

root #iw dev wlp9s0 connect -w GentooNode

16진수 WEP 키를 사용하여 연결하려면, 키 값 앞에 d:를 앞에 붙이십시오:

root #iw dev wlp9s0 connect -w GentooNode key 0:d:1234123412341234abcd

ASCII WEP 키로 연결하려면:

root #iw dev wlp9s0 connect -w GentooNode key 0:some-password

참고
무선 네트워크를 WPA또는 WPA2로 설정한다면 wpa_supplicant를 사용해야합니다. 젠투 리눅스에서 무선 네트워크를 설정하는 내용을 더 많이 알아보려면 젠투 핸드북의 무선 네트워크 절을 읽어보십시오.

iw dev wlp9s0 명령으로 무선 네트워크 설정을 확인하십시오. 무선 네트워크가 동작한다면, 다음 절(네트워크 용어 이해) 에서 설명하는 IP 수준 네트워크 옵션을 설정하거나 이전에 설명한 net-setup 도구를 사용하십시오.

자동 네트워크 설정

In cases where automatic network configuration is unsuccessful, the Gentoo boot media provides scripts to aid in network configuration. net-setup can be used to configure wireless network information and static IPs.

root #net-setup eth0

net-setup에서는 네트워크 환경에 대한 일부 사항을 질문합니다. 모든 과정이 끝나면 네트워크 연결은 동작해야 합니다. 네트워크 연결 시험 방법은 앞서 언급했습니다. 시험 결과가 긍정적이라면 축하드립니다! 이 절의 나머지 부분을 건너뛰고 디스크 준비로 계속 진행하십시오.

중요
Network status should be tested after any configuration steps are taken. In the event that configuration scripts do not work, manual network configuration is required.

네트워크 용어 이해

If all of the above fails, the network must be configured manually. This is not particularly difficult, but should be done with consideration. This section serves to clarify terminology and introduce users to basic networking concepts pertaining to manually configuring an Internet connection.

요령
Some CPE (Carrier Provided Equipment) combines the functions of a router, access point, modem, DHCP server, and DNS server into one unit. It's important to differentiate the functions of a device from the physical appliance.

Interfaces and addresses

Network interfaces are logical representations of network devices. An interface needs an address to communicate with other devices on the network. While only a single address is required, multiple addresses can be assigned to a single interface. This is especially useful for dual stack (IPv4 + IPv6) configurations.

For consistency, this primer will assume the interface enp1s0 will be using the address 192.168.0.2.

중요
IP addresses can be set arbitrarily. As a result, it's possible for multiple devices to use the same IP address, resulting in an address conflict. Address conflicts should be avoided by using DHCP or SLAAC.

요령
IPv6 typically uses StateLess Address AutoConfiguration (SLAAC) for address configuration. In most cases, manually setting IPv6 addresses is a bad practice. If a specific address suffix is preferred, interface identification tokens can be used.

Networks and CIDR

Once an address is chosen, how does a device know how to talk to other devices?

IP addresses are associated with networks. IP networks are contiguous logical ranges of addresses.

Classless Inter-Domain Routing or CIDR notation is used to distinguish network sizes.

The CIDR value, often notated starting with a /, represents the size of the network.
- The formula 2 ^ (32 - CIDR) can be used to calculate network size.
- Once network size is calculated, usable node count must be reduced by 2.
  - The first IP in a network is the Network address, and the last is typically the Broadcast address. These addresses are special and cannot be used by normal hosts.

요령
The most common CIDR values are /24, and /32, representing 254 nodes and a single node respectively.

A CIDR of /24 is the de-facto default network size. This corresponds to a subnet mask of 255.255.255.0, where the last 8 bits are reserved for IP addresses for nodes on a network.

The notation: 192.168.0.2/24 can be interpreted as:

The address 192.168.0.2
On the network 192.168.0.0
With a size of 254 (2 ^ (32 - 24) - 2)
- Usable IPs are in the range 192.168.0.1 - 192.168.0.254
With a broadcast address of 192.168.0.255
- In most cases, the last address on a network is used as the broadcast address, but this can be changed.

Using this configuration, a device should be able to communicate with any host on the same network (192.168.0.0).

The Internet

Once a device is on a network, how does it know how to talk to devices on the Internet?

To communicate with devices outside of local networks, routing must be used. A router is simply a network device that forwards traffic for other devices. The term default route or gateway typically refers to whatever device on the current network is used for external network access.

요령
It's a standard practice to make the gateway the first or last IP on a network.

If an Internet-connected router is available at 192.168.0.1, it can be used as the default route, granting Internet access.

To summarize:

Interfaces must be configured with an address and network information, such as the CIDR value.
Local network access is used to access a router on the same network.
The default route is configured, so traffic destined for external networks is forwarded to the gateway, providing Internet access.

The Domain Name System

Remembering IPs is hard. The Domain Name System was created to allow mapping between Domain Names and IP addresses.

Linux systems use /etc/resolv.conf to define nameservers to be used for DNS resolution.

요령
Many routers can also function as a DNS server, and using a local DNS server can augment privacy and speed up queries through caching.

Many ISPs run a DNS server that is generally advertised to the gateway over DHCP. Using a local DNS server tends to improve query latency, but most public DNS servers will return the same results, so server usage is largely based on preference.

직접 네트워크 설정

Interface address configuration

중요
When manually configuring IP addresses, the local network topology must be considered. IP addresses can be set arbitrarily; conflicts may cause network disruption.

To configure enp1s0 with the address 192.168.0.2 and CIDR /24:

root #ip address add 192.168.0.2/24 dev enp1s0

요령
The start of this command can be shortened to ip a.

Default route configuration

Configuring address and network information for an interface will configure link routes, allowing communication with that network segment:

root #ip route

192.168.0.0/24 dev enp1s0 proto kernel scope link src 192.168.0.2

요령
This command can be shortened to ip r.

The default route can be set to 192.168.0.1 with:

root #ip route add default via 192.168.0.1

DNS configuration

Nameserver info is typically acquired using DHCP, but can be set manually by adding nameserver entries to /etc/resolv.conf.

경고
If dhcpcd is running, changes to /etc/resolv.conf will not persist. Status can be checked with ps x | grep dhcpcd.

nano is included in Gentoo boot media and can be used to edit /etc/resolv.conf with:

root #nano -w /etc/resolv.conf

Lines containing the keyword nameserver followed by a DNS server IP address are queried in order of definition:

파일 /etc/resolv.confUse Quad9 DNS.

nameserver 9.9.9.9
nameserver 149.112.112.112

파일 /etc/resolv.confUse Cloudflare DNS.

nameserver 1.1.1.1
nameserver 1.0.0.1

DNS status can be checked by pinging a domain name:

root #ping -c 3 gentoo.org

Once connectivity has been verified, continue with Preparing the disks.

← 올바른 매체 선택 처음 디스크 준비 →

블록 장치 소개

블록 장치

리눅스 파일 시스템, 분할 영역, 블록 장치 등 젠투 리눅스 및 일반적인 리눅스 운영체제의 바람직한 디스크 측면의 양상을 살펴보도록 하겠습니다. 디스크와 파일 시스템의 입출력을 이해하고 나서, 젠투 리눅스 설치에 필요한 분할 영역과 파일 시스템을 설정하겠습니다.

시작에 앞서 블록 장치를 살펴보도록 하죠. 아마~도 리눅스 시스템에서 첫번째 드라이브로 표시하는 대부분 잘 알려진 블록 장치는 /dev/sda겠죠. SCSI와 직렬 ATA 드라이브 둘 다 /dev/sd*와 같은 식으로 표시합니다. 게다가 커널의 libata 프레임워크에서는 IDE 드라이브도 마찬가지로 /dev/sd*로 표시합니다. 이전 장치 프레임워크에서 첫번째 IDE 드라이브는 /dev/hda입니다.

The following table will help readers determine where to find a certain type of block device on the system:

Type of device	Default device handle	Editorial notes and considerations
IDE, SATA, SAS, SCSI, or USB flash	/dev/sda	Found on hardware from roughly 2007 until the present, this device handle is perhaps the most commonly used in Linux. These types of devices can be connected via the SATA bus, SCSI, USB bus as block storage. As example, the first partition on the first SATA device is called /dev/sda1.
NVM Express (NVMe)	/dev/nvme0n1	The latest in solid state technology, NVMe drives are connected to the PCI Express bus and have the fastest transfer block speeds on the market. Systems from around 2014 and newer may have support for NVMe hardware. The first partition on the first NVMe device is called /dev/nvme0n1p1.
MMC, eMMC, and SD	/dev/mmcblk0	embedded MMC devices, SD cards, and other types of memory cards can be useful for data storage. That said, many systems may not permit booting from these types of devices. It is suggested to not use these devices for active Linux installations; rather consider using them to transfer files, which is their typical design intention. Alternatively this storage type could be useful for short-term file backups or snapshots.

위에 나타낸 블록 장치는 디스크의 추상 인터페이스를 표현합니다. 사용자 프로그램은 블록 장치가 IDE가 됐든 SCSI가 됐든 뭐가 됐든지간에 신경쓰지 않고 디스크와 소통을 수행할 때 이 블록 장치를 사용할 수 있습니다. 프로그램에서는 디스크의 저장 공간에 대해, 연속적이며, 임의로 접근하는 512 바이트 블록의 모음으로 다룰 수 있습니다.

분할 영역 테이블

비록 (예를 들어서 btrfs RAID를 만든다 치면) 이론적으로 리눅스 시스템을 저장할 디스크 전체를 분할하지 않고도 사용할 수 있다고는 하지만, 실제로는 거의 불가능합니다. 대신, 전체 디스크 블록 장치를 더 작게 나누고, 더 관리하기 쉬운 블록 장치로 만들 수 있습니다. amd64 시스템에서는, 분할 영역(파티션)이라고 합니다. 현재 MBR과 GPT 두가지 분할 표준 기술이 있습니다.

GPT

GPT (GUID 분할 영역 테이블) 설정에선 분할 영역에 64비트 식별자를 사용합니다. 분할 영역 정보를 저장하는 위치는 512 바이트의 MBR보다 훨씬 크며, GPT 디스크 분할 영역의 수는 실제로 제한이 없습니다. 또한 분할 영역 크기도 훨씬 큰 제한 용량 값 범위에 들어갑니다(거의 8 ZiB - 예, 제타바이트입니다).

운영 체제와 펌웨어의 시스템 프로그램 인터페이스가 (BIOS 대신) UEFI일 때, GPT는 MBR로 인한 호환성 문제가 일어나는 현 상황에서 단연 필수라 할 수 있습니다.

GPT는 또한 검사합과 중복을 활용하는 이점이 있습니다. CRC32 검사합 값을 활용하여 헤더와 분할 영역 테이블의 오류를 찾으며 디스크의 마지막 부분에 GPT 정보를 백업합니다. 백업 데이블은 디스크 시작 부분의 주 GPT가 손상됐을 경우 복원할 때 사용할 수 있습니다.

중요
There are a few caveats regarding GPT:

Using GPT on a BIOS-based computer works, but then one cannot dual-boot with a Microsoft Windows operating system. The reason is that Microsoft Windows will boot in UEFI mode if it detects a GPT partition label.
Some buggy (old) motherboard firmware configured to boot in BIOS/CSM/legacy mode might also have problems with booting from GPT labeled disks.

MBR

MBR(주 부트 레코드) 설정은 시작 섹터 및 분할 영역의 길이, 그리고 다음의 분할 영역 형식을 지원하는 32비트 식별자를 사용합니다: 주, 확장, 논리. 주 분할 영역은 마스터 부트 레코드 자체에 저장한 정보를 지니고 있습니다. 주 부트 레코드는 매우 작으며(보통 512 바이트) 디스크의 맨 처음에 위치합니다. 공간이 작기 때문에 오직 네 개의 주 분할 영역만을 지원합니다(예를 들자면, /dev/sda1부터 /dev/sda4까지).

더 많은 분할 영역을 지원하려면 주 분할 영역 중 하나를 확장 분할 영역으로 표시할 수 있습니다. 이 분할 영역은 논리 분할 영역(분할 영역 안의 분할 영역)을 보유할 수 있습니다.

중요
대부분 마더보드 제조사에서 지원하지만 분할 테이블을 오래된 기술로 간주합니다. 2010년 이전 생산 하드웨어에서 동작하지 않는다면, GUID 분할 테이블 방식으로 디스크를 분할하시는 방법이 최선입니다. MBR 방식으로 진행하려는 독자 여러분은 다음 내용을 참고바랍니다:

대부분의 2010년 이후 생산 마더보드에서는 MBR 분할 방식을 오래된 (지원하지만 이상적은 아님) 부팅 설정으로 간주합니다.
32비트 식별자는 2TiB 이상의 디스크를 MBR 방식으로 분할 처리하지 못합니다.
확장 분할 영역을 사용하지 않는 한, MBR 방식은 4개의 최대 분할 영역을 지원합니다.
MBR 설정은 MBR 설정을 대체하는 어떤 기술도 지원하지 않습니다. 따라서 어떤 프로그램이나 사용자가 MBR을 덮어쓸 경우 모든 분할 영역 정보를 분실합니다.

핸드북 저자는 젠투를 설치할 경우라면 GPT 사용을 추천합니다.

고급 저장장치

amd64 설치 CD에서는 논리 볼륨 관리자(LVM)을 지원합니다. LVM에서는 분할 영역 설정을 통해 유연성을 제공합니다. 아래 설치 과정은 일반 분할 영역을 중점적으로 다루지만, 이런 방식을 원할 경우를 대비하여 LVM을 지원한다는 사실을 알아두시는 게 유익합니다. 자세한 내용은 LVM 게시글을 살펴보십시오. 초보자 여러분은 LVM의 완전한 설명은 이 안내서의 내용 범위에 벗어난다는 사실을 알아두셨으면 합니다.

기본 분할 형태

Throughout the remainder of the handbook, we will discuss and explain two cases:

UEFI firmware with GUID Partition Table (GPT) disk.
MBR DOS/legacy BIOS firmware with a MBR partition table disk.

While it is possible to mix and match boot types with certain motherboard firmware, mixing goes beyond the intention of the handbook. As previously stated, it is strongly recommended for installations on modern hardware to use UEFI boot with a GPT disklabel disk.

이 핸드북의 나머지 부분에서는 다음 공간 분할 형태를 간단한 배치 예제로 활용합니다:

중요
The first row of the following table contains exclusive information for either a GPT disklabel or a MBR DOS/legacy BIOS disklabel. When in doubt, proceed with GPT, since amd64 machines manufactured after the year 2010 generally support UEFI firmware and GPT boot sector.

분할 영역	파일 시스템	크기	설명
/dev/sda1	(부트로더)	2M	BIOS 부트 분할 영역
/dev/sda1	ext2 (UEFI를 사용하는 경우 fat32)	128M	부트/EFI 시스템 분할 영역
/dev/sda3	(스왑)	512M 이상	스왑 분할 영역
/dev/sda4	ext4	디스크 나머지 부분	루트 분할 영역

이 내용으로 충분하고 독자 여러분이 GPT 방식으로 진행하겠다면 기본: 디스크 분할시 parted 사용편으로 넘어갈 수 있습니다. 여전히 MBR 방식(이보쇼?!)을 선호하고 예제 배치를 따라가겠다면 대안: 디스크 분할시 fdisk 사용편으로 넘어갈 수 있습니다.

fdisk와 parted는 디스크 공간 분할 유틸리티입니다. fdisk는 잘 알려진, 안정적인 프로그램이며 MBR 공간 분할 방식에 추천하지만 parted는 GPT 공간 분할 방식을 지원하는 리눅스용 첫 블록 장치 관리 유틸리티 중 하나입니다. fdisk 인터페이스 방식을 선호하는 사용자라면 parted 대신 gdisk(GPT fdisk)를 사용할 수 있습니다.

만들기 절차를 진행하기 전에 해당 절의 첫번째 부분에서는 분할 영역 형태를 어떻게 만드는지와 일반적인 문제를 언급하는 내용을 다루겠습니다.

분할 배치 설계

분할 영역을 얼마나 많이, 크게 할까요?

분할 영역의 수는 환경에 따라 다릅니다. 예를 들어, 사용자가 많을 경우 보안성을 개선하고 백업을 쉽게 하기 위해 /home/을 나누는 것이 좋습니다. 젠투를 메일 서버로 설치한다면, /var/에 모든 메일을 저장하므로 /var/를 나누어야 합니다. 파일 시스템의 탁월한 선택은 성능을 극대화합니다. 게임 서버는 게임 서버를 설치할 /opt/를 따로 나눕니다. 이유는 /home/과 비슷합니다: 보안과 백업이죠. 대부분의 상황에서 /usr/는 거대한 상태고 남아있습니다. 주요 프로그램을 저장할 뿐만 아니라, (보통 /usr/portage에 기본으로 들어가는) 젠투 이빌드 저장소는 거의 650MB를 차지합니다. 이 디스크 공간은 보통 이빌드 저장소내에 저장하는 packages/와 distfiles/ 디렉터리는 제외하고 추산합니다.

In most situations on Gentoo, /usr and /var should be kept relatively large in size. /usr hosts the majority of applications available on the system and the Linux kernel sources (under /usr/src). By default, /var hosts the Gentoo ebuild repository (located at /var/db/repos/gentoo) which, depending on the file system, generally consumes around 650 MiB of disk space. This space estimate excludes the /var/cache/distfiles and /var/cache/binpkgs directories, which will gradually fill with source files and (optionally) binary packages respectively as they are added to the system.

관리자 취향에 달려있습니다. 분할 영역 또는 볼륨을 나누면 다음과 같은 장점이 있습니다:

각 분할 영역 또는 볼륨에 대해 최상의 동작을 수행하는 파일 시스템을 선택합니다.
제 기능을 상실한 도구가 분할 영역 또는 볼륨에 계속 파일을 기록할 경우, 남아 있는 공간이 없어져 전체 시스템이 동작하지 않습니다.
필요한 경우, (이 장점은 여러 개의 분할 영역보다는 여러 대의 디스크에서 더 돋보이지만) 동시에 여러 분할 영역을 검사할 수 있어, 파일 시스템 검사 시간을 줄일 수 있습니다.
일부 분할 영역 또는 볼륨을 읽기 전용, nosuid(setuid 무시), noexec(실행 비트 무시) 등으로 마운트하여 보안성을 개선할 수 있습니다.

그러나, 마찬가지로 다중 분할 영역에는 단점도 존재합니다. 제대로 설정하지 않으면 어떤 분할 영역에는 공간이 상당히 남지만, 다른 분할 영역은 그렇지 않을 수 있습니다. 다른 골칫거리는 분할 영역이 나뉘어져 있는 상황입니다. /usr/ 또는 /var/와 같은 중요한 마운트 지점은 특히 그렇습니다. 다른 부팅 스크립트를 시작하기 전에 분할 영역을 마운트하려면 관리자가 종종 initramfs로 부팅해야합니다. 항상 있는 경우는 아니기 때문에 결과가 다양하게 나타납니다.

디스크에서 GPT 레이블을 사용하지 않으면 SCSI와 SATA에서는 분할 영역 갯수가 15개로 제한되어있습니다.

참고
Installations that intend to use systemd as the service and init system must have the /usr directory available at boot, either as part of the root filesystem or mounted via an initramfs.

스왑 공간이 무엇인가요?

Recommendations for swap space size
RAM size	Suspend support?	Hibernation support?
2 GB or less	2 * RAM	3 * RAM
2 to 8 GB	RAM amount	2 * RAM
8 to 64 GB	8 GB minimum, 16 maximum	1.5 * RAM
64 GB or greater	8 GB minimum	Hibernation not recommended! Hibernation is not recommended for systems with very large amounts of memory. While possible, the entire contents of memory must be written to disk in order to successfully hibernate. Writing tens of gigabytes (or worse!) out to disk can can take a considerable amount of time, especially when rotational disks are used. It is best to suspend in this scenario.

완벽한 스왑 분할 영역 값은 없습니다. 스왑 영역의 존재 목적은 내부 메모리(RAM)가 용량 고갈에 처해있을 때 커널에서 디스크 공간을 제공하려는 것입니다. 스왑 영역은 커널에서 곧 접근하지 않을 메모리 페이지를 디스크(스왑 또는 페이지-아웃)에 옮기고 메모리를 확보할 수 있도록 합니다. 물론 메모리가 갑자기 필요할 때도 이 페이지를 메모리에 되돌려놓습니다만(페이지-인), 시간이 오래걸립니다(내부 메모리에 비해 디스크는 비교적 매우 느립니다).

시스템이 메모리를 집중적으로 사용하는 프로그램을 실행하려 하지 않거나 시스템에 충분한 메모리가 있을 경우 많은 스왑 영역이 필요하지 않을지도 모릅니다. 그러나 스왑 영역은 최대 절전모드 기능을 사용할 경우 전체 메모리 공간을 사용하기도 합니다. 시스템을 최대 절전모드로 진입하려 한다면, 더 큰 스왑 영역이 필요하며, 최소한, 종종 시스템에 대용량의 메모리를 설치합니다.

UEFI 사용

운영체제를 부팅할 때 (BIOS 대신) UEFI를 사용하는 시스템에 젠투를 설치할 경우, EFI 시스템 분할 영역(ESP)을 만드는 과정이 중요합니다. 아래에 설명할 parted의 절차에는 이 동작을 올바르게 처리하는데 필요한 포인터가 있습니다.

ESP는 (때로는 리눅스 시스템에서 vfat으로 나타나는) FAT 종류 중 하나여야 합니다. 공식 UEFI 명세^en에서는 UEFI 펌웨어에서, ESP를 활용할 때 FAT32를 추천하지만, FAT 12, 16, 32 파일 시스템을 인식한다고 명시되어 있습니다. ESP를 FAT32로 포맷하기로 합니다:

root #mkfs.fat -F 32 /dev/sda1

중요
FAT 변종을 ESP에 사용하지 않으면 시스템의 UEFI 펌웨어를 부트로더(또는 리눅스 커널)에서 찾을 수 있음을 장담할 수 없으며 대부분의 경우 시스템 부팅이 불가능합니다!

BIOS 부트 분할 영역이란?

BIOS 부팅 분할 영역은 매우 작(1~2MB)으며 GRUB2와 같은 부트로더가 할당 저장 공간(MBR의 경우 몇 백 메가바이트정도 저장함)에 맞지 않는 추가 데이터를 저장할 수 있으며, 어떤 위치에든 둘 수 있는건 아닙니다.

대안: 디스크 분할시 fdisk 사용

다음 부분에서는 fdisk를 사용하여 예제 분할 영역 배치를 만드는 방법을 설명합니다. 예제 분할 영역 배치는 앞서 언급했습니다:

개인 취향에 따라 분할 영역 배치를 바꾸십시오.

분할 영역	설명
/dev/sda1	BIOS 부팅 분할 영역
/dev/sda1	부팅 분할 영역
/dev/sda3	스왑 분할 영역
/dev/sda4	루트 분할 영역

현재 분할 영역 배치 보기

fdisk는 디스크를 분할 영역으로 나누는 유명하고 강력한 도구입니다. fdisk를 디스크에서 다시 실행해보십시오(예제에서는 /dev/sda를 사용):

root #fdisk /dev/sda

p키를 사용하여 현재 분할 영역 설정을 표시하십시오:

Command (m for help):p

Disk /dev/sda: 240 heads, 63 sectors, 2184 cylinders
Units = cylinders of 15120 * 512 bytes
  
   Device Boot    Start       End    Blocks   Id  System
/dev/sda1   *         1        14    105808+  83  Linux
/dev/sda2            15        49    264600   82  Linux swap
/dev/sda3            50        70    158760   83  Linux
/dev/sda4            71      2184  15981840    5  Extended
/dev/sda5            71       209   1050808+  83  Linux
/dev/sda6           210       348   1050808+  83  Linux
/dev/sda7           349       626   2101648+  83  Linux
/dev/sda8           627       904   2101648+  83  Linux
/dev/sda9           905      2184   9676768+  83  Linux

Device Start End Sectors Size Type /dev/sda1 2048 2099199 2097152 1G EFI System /dev/sda2 2099200 10487807 8388608 4G Linux swap /dev/sda3 10487808 1953523711 1943035904 926.5G Linux root (x86-64)

}}

각각의 디스크에는 하나의 스왑 분할 영역과("Linux Swap"으로 나타남) 7개의 리눅스 시스템(각각의 분할 영역이 "Linux"라고 나타남)을 넣도록 설정했습니다.

fdisk에서 모든 분할 영역 제거

Pressing the g key will instantly remove all existing disk partitions and create a new GPT disklabel:

Command (m for help):g

Created a new GPT disklabel (GUID: 3E56EE74-0571-462B-A992-9872E3855D75).

디스크에서 모든 분할 영역을 제거하십시오. d를 입력하여 분할 영역을 삭제하십시오. 기존의 /dev/sda1 분할 영역을 삭제하려면:

Command (m for help):d

Partition number (1-4): 1

분할 영역을 삭제할 예정입니다. 분할 영역 목록에는 더이상 나타나지 않겠지만(p) 바뀐 내용을 저장하기 전에는 지워지지 않습니다. 사용자가 실수했을 경우 진행을 멈출 수 있습니다. 이 경우 q를 바로 입력하고 Enter를 치면 분할 영역을 삭제하지않습니다.

p를 입력하여 분할 영역 목록을 출력하고 d와 삭제할 분할 영역 번호를 입력하는 과정을 반복하십시오. 최종적으로, 분할 영역 테이블을 비웠습니다:

Command (m for help):p

Disk /dev/sda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
  
Device Boot    Start       End    Blocks   Id  System

이제 메모리에 있는 분할 영역 테이블을 비웠고, 분할 영역을 만들 준비를 끝냈습니다.

BIOS 부팅 분할 영역 만들기

참고
A smaller ESP is possible but not recommended, especially given it may be shared with other OSes.

먼저 매우 작은 BIOS 부팅 분할 영역을 만들겠습니다. 새 분할 영역을 만드는 명령 n을 입력하시고, 주 분할 영역을 선택할 p를 입력한 후, 1을 입력하여 첫번째 주 분할 영역을 선택하십시오. 첫번째 섹터를 물어보면 2048부터 시작하는지(부트로더에 필요함)확인한 후 Enter를 치십시오. 마지막 섹터를 물어보면 +2M을 입력하여 2MB 크기의 분할 영역을 만드십시오:

Command (m for help):n

Command action
  e   extended
  p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (64-10486533532, default 64): 2048
Last sector, +sectors +size{M,K,G} (4096-10486533532, default 10486533532): +2M

Do you want to remove the signature? [Y]es/[N]o: Y The signature will be removed by a write command.

}}

UEFI 용도로 분할 영역을 표시하십시오:

Command (m for help):t

Selected partition 1
Hex code (type L to list codes): 4
Changed system type of partition 1 to 4 (BIOS boot)

Optionally, to have the ESP conform to the Discoverable System Partition (DSP) specification, switch to expert mode and perform the following extra step to set the partition's UUID:

Command (m for help):x

Expert command (m for help):u

Selected partition 1
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
New UUID (in 8-4-4-4-12 format): c12a7328-f81f-11d2-ba4b-00a0c93ec93b
Partition UUID changed from 10293DC1-DF6C-4443-8ACF-C756B81B4767 to C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

Press the r key to return to the main menu:

Expert command (m for help):r

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Command (m for help):

스왑 분할 영역 만들기

마지막으로, 루트 분할 영역을 만들려면, 새 분할 영역을 만드는 명령 n을 입력하시고, p를 입력하여 fdisk에게 주 분할 영역 만들기를 지시한 후, 3을 입력하여 세번째 주 분할 영역 /dev/sda3을 만드십시오. 첫번째 섹터를 물어보면 Enter를 치십시오. 마지막 섹터를 물어보면 +512M(또는 필요한 스왑 공간만큼)을 입력하여 512MB 크기의 분할 영역을 만드십시오.

부팅 분할 영역 만들기

이 과정이 끝난 후 분할 영역 형식을 설정하는 명령 t를 입력하고, 3을 입력하여 방금 만든 분할 영역을 입력한 후, 82를 입력하여 "Linux Swap" 형식으로 바꾸십시오.

Command (m for help):t

Partition number (1,2, default 2): 2
Partition type or alias (type L to list all): 19
 
Changed type of partition 'Linux filesystem' to 'Linux swap'.

Optionally, to have the swap partition conform to the Discoverable System Partition (DSP) specification, switch to expert mode and perform the following extra step to set the partition's UUID:

Command (m for help):x

Expert command (m for help):u

Partition number (1,2, default 2): 2
Selected partition 2
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
New UUID (in 8-4-4-4-12 format): 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
Partition UUID changed from 7529CDF6-9482-4497-B021-576745648B2A to 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F..

Press the r key to return to the main menu:

Expert command (m for help):r

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Command (m for help):

루트 분할 영역 만들기

마지막으로, 루트 분할 영역을 만들려면, 새 분할 영역을 만드는 명령 n을 입력하시고, p를 입력하여 fdisk에게 주 분할 영역 만들기를 지시한 후, 4를 입력하여 네번째 주 분할 영역 /dev/sda4를 만드십시오. 첫번째 섹터를 물어보면 Enter를 치십시오. 마지막 섹터를 물어보면 Enter를 쳐서 디스크의 나머지 공간을 취하는 분할 영역을 만드십시오. 이 과정이 끝나면 p를 입력하였을 때 다음과 같은 분할 영역 테이블 모습이 나타나야합니다:

Command (m for help):n

Partition number (3-128, default 3): 3
First sector (10487808-1953525134, default 10487808):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (10487808-1953525134, default 1953523711):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Created a new partition 3 of type 'Linux filesystem' and of size 926.5 GiB..

참고
Setting the root partition's type to "Linux root (x86-64)" is not required and the system will function normally if it is set to the "Linux filesystem" type. This filesystem type is only necessary for cases where a bootloader that supports it (i.e. systemd-boot) is used and a fstab file is not wanted.

After creating the root partition, press t to set the partition type, 3 to select the partition just created, and then type in 23 to set the partition type to "Linux Root (x86-64)".

Command(m for help):t

Partition number (1-3, default 3): 3
Partition type or alias (type L to list all): 23
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Changed type of partition 'Linux filesystem' to 'Linux root (x86-64)'

Optionally, to have the root partition conform to the Discoverable System Partition (DSP) specification, switch to expert mode and perform the following extra step to set the partition's UUID:

Command (m for help):x

Expert command (m for help):u

Partition number (1-3, default 3): 3
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
New UUID (in 8-4-4-4-12 format): 4f68bce3-e8cd-4db1-96e7-fbcaf984b709
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Partition UUID changed from 40465382-FA2A-4846-9827-640821CC001F to 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709.

Press the r key to return to the main menu:

Expert command (m for help):r

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Command (m for help):

After completing these steps, pressing p should display a partition table that looks similar to the following:

Command (m for help):p

Disk /dev/sda: 30.0 GB, 30005821440 bytes
240 heads, 63 sectors/track, 3876 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
  
   Device Boot    Start       End    Blocks   Id  System
/dev/sda1             1         3      5198+  ef  EFI (FAT-12/16/32)
/dev/sda2   *         3        14    105808+  83  Linux
/dev/sda3            15        81    506520   82  Linux swap
/dev/sda4            82      3876  28690200   83  Linux

Device Start End Sectors Size Type /dev/sda1 2048 2099199 2097152 1G Linux filesystem /dev/sda2 2099200 10487807 8388608 4G Linux swap /dev/sda3 10487808 1953523711 1943035904 926.5G Linux root (x86-64)

Filesystem/RAID signature on partition 1 will be wiped.

}}

분할 영역 배치 저장하기

분할 영역 배치를 저장하고 fdisk를 빠져나가려면 w를 입력하십시오.

Command (m for help):w

분할 영역을 만들었다면 이제 파일 시스템을 올려놓을 차례입니다.

Partitioning the disk with MBR for BIOS / legacy boot

The following table provides a recommended partition layout for a trivial MBR DOS / legacy BIOS boot installation. Additional partitions can be added according to personal preference or system design goals.

Device path (sysfs)	Mount point	File system	DPS UUID (`PARTUUID`)	Description
/dev/sda1	/boot	xfs	N/A	MBR DOS / legacy BIOS boot partition details.
/dev/sda2	N/A. Swap is not mounted to the filesystem like a device file.	swap	0657fd6d-a4ab-43c4-84e5-0933c84b4f4f	Swap partition details.
/dev/sda3	/	xfs	4f68bce3-e8cd-4db1-96e7-fbcaf984b709	Root partition details.

Change the partition layout according to personal preference.

Viewing the current partition layout

Fire up fdisk against the disk (in our example, we use /dev/sda):

root #fdisk /dev/sda

Use the p key to display the disk's current partition configuration:

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf163b576
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048    2099199    2097152     1G 83 Linux
/dev/sda2        2099200   10487807    8388608     4G 82 Linux swap / Solaris
/dev/sda3       10487808 1953525167 1943037360 926.5G 83 Linux

This particular disk was until now configured to house two Linux filesystems (each with a corresponding partition listed as "Linux") as well as a swap partition (listed as "Linux swap"), using a GPT table.

Creating a new disklabel / removing all partitions

Pressing o will instantly remove all existing disk partitions and create a new MBR disklabel (also named DOS disklabel):

Command (m for help):o

Created a new DOS disklabel with disk identifier 0xf163b576.
The device contains 'gpt' signature and it will be removed by a write command. See fdisk(8) man page and --wipe option for more details.

Alternatively, to keep an existing DOS disklabel (see the output of p above), consider removing the existing partitions one by one from the disk. Press d to delete a partition. For instance, to delete an existing /dev/sda1:

Command (m for help):d

Partition number (1-4): 1

The partition has now been scheduled for deletion. It will no longer show up when printing the list of partitions (p, but it will not be erased until the changes have been saved. This allows users to abort the operation if a mistake was made - in that case, type q immediately and hit Enter and the partition will not be deleted.

Repeatedly press p to print out a partition listing and then press d and the number of the partition to delete it. Eventually, the partition table will be empty:

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf163b576

The disk is now ready to create new partitions.

Creating the boot partition

First, create a small partition which will be mounted as /boot. Press n to create a new partition, followed by p for a primary partition and 1 to select the first primary partition. When prompted for the first sector, make sure it starts from 2048 (which may be needed for the boot loader) and press Enter. When prompted for the last sector, type +1G to create a partition 1 GB in size:

Command (m for help):n

Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-1953525167, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-1953525167, default 1953525167): +1G
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Created a new partition 1 of type 'Linux' and of size 1 GiB.

Mark the partition as bootable by pressing the a key and pressing Enter:

Command (m for help):a

Selected partition 1
The bootable flag on partition 1 is enabled now.

Note: if more than one partition is available on the disk, then the partition to be flagged as bootable will have to be selected.

Creating the swap partition

Next, to create the swap partition, press n to create a new partition, then p, then type 2 to create the second primary partition, /dev/sda2. When prompted for the first sector, press Enter. When prompted for the last sector, type +4G (or any other size needed for the swap space) to create a partition 4GB in size.

Command (m for help):n

Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (2099200-1953525167, default 2099200):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2099200-1953525167, default 1953525167): +4G
 
Created a new partition 2 of type 'Linux' and of size 4 GiB.

After all this is done, press t to set the partition type, 2 to select the partition just created and then type in 82 to set the partition type to "Linux Swap".

Command (m for help):t

Partition number (1,2, default 2): 2
Hex code (type L to list all codes): 82
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Changed type of partition 'Linux' to 'Linux swap / Solaris'.

Creating the root partition

Finally, to create the root partition, press n to create a new partition. Then press p and 3 to create the third primary partition, /dev/sda3. When prompted for the first sector, hit Enter. When prompted for the last sector, hit Enter to create a partition that takes up the rest of the remaining space on the disk:

Command (m for help):n

Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (3,4, default 3): 3
First sector (10487808-1953525167, default 10487808):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (10487808-1953525167, default 1953525167):
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Created a new partition 3 of type 'Linux' and of size 926.5 GiB.

After completing these steps, pressing p should display a partition table that looks similar to this:

Command (m for help):p

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: HGST HTS721010A9
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xf163b576
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Device     Boot    Start        End    Sectors   Size Id Type
/dev/sda1  *        2048    2099199    2097152     1G 83 Linux
/dev/sda2        2099200   10487807    8388608     4G 82 Linux swap / Solaris
/dev/sda3       10487808 1953525167 1943037360 926.5G 83 Linux

Saving the partition layout

Press w to write the partition layout and exit fdisk:

Command (m for help):w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Now it is time to put filesystems on the partitions.

파일 시스템 만들기

경고
When using SSD or NVMe drive, it is wise to check for firmware upgrades. Some Intel SSDs in particular (600p and 6000p) require a firmware upgrade for possible data corruption induced by XFS I/O usage patterns. The problem is at the firmware level and not any fault of the XFS filesystem. The smartctl utility can help check the device model and firmware version.

도입부

이제 분할 영역을 만들었고, 파일 시스템을 제 위치에 얹어놓을 차례입니다. 다음 절에서는 리눅스에서 지원하는 다양한 파일 시스템을 설명합니다. 어떤 파일 시스템을 사용할 지 이미 알고 있는 독자라면 파티션에 파일 시스템 반영하기로 계속 진행할 수 있습니다. 그렇지 않으면 계속 읽어 내려가면서 쓸 수 있는 파일시스템이 어떤 종류가 있는지 알아보십시오.

파일 시스템

다양한 파일 시스템이 있습니다. 일부는 amd64 아키텍처에서 안정적입니다 - 중요한 분할 영역을 위해서라면 좀 더 시험적인 분할 영역을 선택하기 전에 파일 시스템과 지원 상태에 대한 내용을 좀 더 읽어보시는 것이 좋겠습니다.

btrfs: 스냅샷, 검사합을 통한 자체복구, 투명 압축, 하위 볼륨, 통합 RAID 같은 고급 기능을 제공하는 차세대 파일 시스템입니다. 일부 배포판은 이미 특별한 옵션으로 탑재했지만 실무에서 쓰기엔 준비가 미흡합니다. 파일 시스템이 깨지는 경우가 다반사입니다. 개발자들은 이전 버전에 문제가 있기 때문에 안전을 위해 최신 커널 버전을 사용하라고 합니다. 몇년 동안 이래왔고 무엇인가 바뀐다고 하면 너무 일찍 언급합니다. 깨지는 문제를 고친다고 하면 가끔 이전 커널에 있던 대로 돌아갑니다. 파일 시스템을 쓰려 한다면 위험을 감수하십시오!
ext2: 검증된 리눅스 파일시스템이지만 메타데이터 저널링기능이 없습니다. 이는 시작시간의 파일시스템 검사루틴에서 조금 더 많은 시간소모를 할 수 있다는 의미입니다. 이제 일관성 검사를 더욱 빠르게 할 수 있고 비 저널링의 대체 수단으로써 일반적으로 더욱 선호하는 차세대 저널링 파일시스템의 상당한 선택요소가 있습니다. 저널링 파일시스템은 시스템을 시동하고 파일시스템에 비일관 상태가 발생했을 때 긴 지연시간을 줄입니다.
ext3: 빠른 복구 기능을 제공하는 메타데이터 저널링을 제공하며, 게다가 전체 데이터와 정렬된 데이터 저널링과 같은 강화 저널링 모드도 지원하는 ext2 파일시스템의 저널링 버전입니다. 대부분의 모든 상황에서 고성능 동작이 가능한 HTree 색인을 사용합니다. 간단히 말해 ext3는 아주 좋은 믿을 수 있는 파일시스템입니다. ext3을 모든 목적의 모든 플랫폼 파일시스템으로 추천합니다.
ext4: ext3으로부터 갈라져 나와 성능을 향상시키고 디스크상 형식에 대해 적절한 수정을 가하여 용량 제한을 없애는 새로운 기능을 포함하여 만든 파일시스템입니다. 볼륨 하나의 크기를 1EB까지 늘릴 수 있고, 파일 최대 크기는 16TB가 될 수 있습니다. 기존의 ext2/3 비트맵 블록 할당 대신에 ext4는 대용량 파일 성능을 끌어올리고 단편화를 줄인 extents를 사용합니다. ext4는 디스크의 데이터 배치에 대해 최적화 할 더 많은 방법을 파일시스템 드라이버에 제공하는 좀 더 세련된 블록 할당 알고리즘(지연할당 및 다중블록 할당)을 제공합니다. ext4는 모든 목적의 모든 플랫폼의 파일 시스템에 추천합니다.
f2fs: 플래시 지향 파일 시스템은 처음에 낸드 플래시 메모리에서 활용할 목적으로 삼성에서 만들었습니다. 2016년 2/4분기 시점에, 이 파일 시스템은 여전히 미완의 상태지만 젠투를 마이크로SD 카드, USB 드라이브, 기타 플래시 기반 저장 장치에 설치할 경우 괜찮은 선택입니다.
JFS: IBM의 고성능 저널링 파일시스템입니다. JFS는 다양한 상황속에서도 좋은 성능을 내는, 가볍고 빠르며 믿을 수 있는 B+트리 기반 파일시스템입니다.
ReiserFS: 전반적으로 좋은 성능을 내며 특히 용량이 작은 수많은 파일들을 다룰 때 더 많은 CPU 사이클을 소비하는 경우 좋은 성능이 나는 B+트리 기반 저널링 파일시스템입니다. ReiserFS는 다른 파일시스템보다 덜 관리중인 것으로 보입니다.
XFS: 견고한 기능 모음을 지니고 있으며 확장성에 있어 최적화 된 메타데이터 저널링 파일시스템입니다. XFS는 다양한 하드웨어 문제에 대해 그다지 관대하진 않은 것 같습니다.
vfat: FAT32로 알려진 vfat은 리눅스에서 지원하지만 권한 설정은 지원하지 않습니다. 여러 운영 체제간 상호 운용성을 목적으로(주로 마이크로소프트 윈도우) 활용하지만 일부 시스템 펌웨어(UEFI)용으로도 필요합니다.
NTFS: "New Technology" 파일 시스템은 마이크로 소프트의 대표 파일 시스템입니다. 위의 vfat과 비슷하게 BSD 또는 리눅스에서 필요한 권한 설정 또는 확장 속성을 저장하지 않기에 루트 파일 시스템으로 활용할 수 없습니다. 오직 마이크로소프트 윈도우와 상호 연동할 때만 활용해야합니다(오직 이 경우에만 역점을 둠을 참고하십시오).

More extensive information on filesystems can be found in the community maintained Filesystem article.

분할 영역에 파일 시스템 반영하기

참고
Please make sure to emerge the relevant user space utilities package for the chosen filesystem before rebooting. There will be a reminder to do so near the end of the installation process.

분할 영역 또는 볼륨에 파일 시스템을 만들 때, 각 파일 시스템에서 사용할 수 있는 도구가 있습니다. 각 파일 시스템의 추가 정보를 살펴보려면 하단 표의 파일 시스템 이름을 누르십시오:

파일시스템	구성 명령	최소 CD 포함?	꾸러미
btrfs	mkfs.btrfs	Yes	sys-fs/btrfs-progs
ext2	mkfs.ext2	Yes	sys-fs/e2fsprogs
ext3	mkfs.ext3	Yes	sys-fs/e2fsprogs
ext4	mkfs.ext4	Yes	sys-fs/e2fsprogs
f2fs	mkfs.f2fs	Yes	sys-fs/f2fs-tools
jfs	mkfs.jfs	Yes	sys-fs/jfsutils
reiserfs	mkfs.reiserfs	Yes	sys-fs/reiserfsprogs
xfs	mkfs.xfs	Yes	sys-fs/xfsprogs
vfat	mkfs.vfat	Yes	sys-fs/dosfstools
NTFS	mkfs.ntfs	Yes	sys-fs/ntfs3g

중요
The handbook recommends new partitions as part of the installation process, but it is important to note running any mkfs command will erase any data contained within the partition. When necessary, ensure any data that exists within is appropriately backed up before creating a few filesystem.

예를 들어, 예제 분할 영역 구조와 같이 ext2 형식의 부팅 분할 영역 (/dev/sda1) 과 ext4 형식의 루트 분할 영역 (/dev/sda3)을 취하려면, 다음 명령을 사용할 수 있습니다:

root #mkfs.ext4 /dev/sda3

EFI system partition filesystem

The EFI system partition (/dev/sda1) must be formatted as FAT32:

root #mkfs.ext2 /dev/sda1

Legacy BIOS boot partition filesystem

Systems booting via legacy BIOS with a MBR/DOS disklabel can use any filesystem format supported by the bootloader.

For example, to format with XFS:

root #mkfs.xfs /dev/sda1

Small ext4 partitions

(8GB 이하의) 작은 분할 영역에서 ext2, ext3, ext4 를 사용한다면, 충분한 inode 갯수를 예약할 적당한 옵션으로 파일 시스템을 만들어야합니다. mke2fs(mkfs.ext2)에서는 "아이노드 당 바이트" 설정을 사용하여 파일 시스템에서 보유할 아이노드 갯수를 계산합니다. 작은 분할 영역일수록 아이노드 갯수를 늘리는 것이 좋습니다.

root #mkfs.ext2 -T small /dev/<device>

각 16kB 영역을 하나의 4kB 영역으로 줄이는 "아이노드 당 바이트"로 주어진 파일 시스템의 아이노드 갯수를 네 배로 뻥튀기(?)합니다. 비율값을 부여하여 속성을 조절할 수 있습니다:

스왑 분할 영역 활성화

mkswap은 스왑 분할 영역을 초기화하는 명령입니다:

root #mkswap /dev/sda2

스왑 분할 영역을 활성화하려면, swapon 명령을 사용하십시오:

root #swapon /dev/sda2

This 'activation' step is only necessary because the swap partition is newly created within the live environment. Once the system has been rebooted, as long as the swap partition is properly defined within fstab or other mount mechanism, swap space will activate automatically.

루트 분할 영역 마운트

참고
Installations which were previously started, but did not finish the installation process can resume the installation from this point in the handbook. Use this link as the permalink: Resumed installations start here.

Certain live environments may be missing the suggested mount point for Gentoo's root partition (/mnt/gentoo), or mount points for additional partitions created in the partitioning section:

root #mkdir --parents /mnt/gentoo

For EFI installs only, the ESP should be mounted under the root partition location:

root #mkdir --parents /mnt/gentoo/efi

Continue creating additional mount points necessary for any additional (custom) partition(s) created during previous steps by using the mkdir command.

이제 분할 영역을 초기화했고 파일 시스템을 넣었으므로 분할 영역을 마운트할 차례입니다. mount 명령을 사용하지만 만들어놓은 모든 분할 영역에 대해 마운트 디렉터리를 만들 필요는 없다는 사실을 잊지 마십시오. 예제를 통해 우리는 루트 분할 영역을 마운트하겠습니다:

Mount the root partition:

root #mount /dev/sda3 /mnt/gentoo

Continue mounting additional (custom) partitions as necessary using the mount command.

참고
/tmp/를 따로 나눈 분할 영역에 두어야 한다면, 마운트하기 전에 퍼미션을 바꾸었는지 확인하십시오:

root #chmod 1777 /mnt/gentoo/tmp

이 설정은 /var/tmp에도 적용 유지합니다.

지침을 따르고 나면 proc 파일 시스템(커널 가상 인터페이스)와 다른 커널 의사 파일 시스템을 마운트합니다. 그러나 우선 젠투 설치 파일을 설치하겠습니다.

← 네트워크 설정 처음 젠투 설치 파일 설치 →

스테이지 타르볼 선택

요령
On supported architectures, it is recommended for users targeting a desktop (graphical) operating system environment to use a stage file with the term desktop within the name. These files include packages such as sys-devel/llvm and dev-lang/rust-bin and USE flag tuning which will greatly improve install time.

The stage file acts as the seed of a Gentoo install. Stage files are generated with Catalyst by the Release Engineering Team. Stage files are based on specific profiles, and contain an almost-complete system.

When choosing a stage file, it's important to pick one with profile targets corresponding to the desired system type.

중요
While it's possible to make major profile changes after an installation has been established, switching requires substantial effort and consideration, and is outside the scope of this installation manual. Switching init systems is difficult, but switching from no-multilib to multilib requires extensive Gentoo and low-level toolchain knowledge.

대부분 사용자는 '고급' 타르볼 선택 항목을 활용하면 안됩니다. 이 항목은 특정 프로그램 또는 하드웨어 설정용으로 만들었습니다.

OpenRC

OpenRC is a dependency-based init system (responsible for starting up system services once the kernel has booted) that maintains compatibility with the system provided init program, normally located in /sbin/init. It is Gentoo's native and original init system, but is also deployed by a few other Linux distributions and BSD systems.

OpenRC does not function as a replacement for the /sbin/init file by default and is 100% compatible with Gentoo init scripts. This means a solution can be found to run the dozens of daemons in the Gentoo ebuild repository.

systemd

systemd is a modern SysV-style init and rc replacement for Linux systems. It is used as the primary init system by a majority of Linux distributions. systemd is fully supported in Gentoo and works for its intended purpose. If something seems lacking in the Handbook for a systemd install path, review the systemd article before asking for support.

Multilib (32비트 및 64비트)

참고
Not every architecture has a multilib option. Many only run with native code. Multilib is most commonly applied to amd64.

시스텝 기본 타르볼을 선택하면, 특히 시스템 프로파일 선택을 진행할 때, 설치 과정의 나머지 시간을 절약할 수 있습니다. 스테이지 타르볼 선택은 앞으로의 시스템 설정에 직접적인 영향을 주며 이후에 발생할 두통을 예방할 수 있습니다. multilib 타르볼은 가능하면 64비트 라이브러리를 사용하며 호환성이 필요하면 32비트 버전을 대신 사용합니다. 주요 설치 과정에 있어 최상의 옵션이며, 앞으로 다양한 개별 설정을 유연하게 처리할 수 있기 때문입니다. 프로파일을 쉽게 바꿀 수 있는 시스템을 원한다면 프로세서 아키텍처에 해당하는 multilib 타르볼 옵션을 다운로드해야합니다.

요령
Using multilib targets makes it easier to switch profiles later, compared to no-multilib

no-multilib(순수 64비트)

경고
no-multilib 시스템에서 multilib 시스템으로 이전할 경우 젠투 동작과 하부 단계 툴체인에 대한 해박한 지식이 필요합니다(게다가 이 문제는 툴체인 개발자들 마저도 이를 갈게 만듭니다). 비굴해서 그런게 아니며 이 안내서에서 다룰 내용의 범위를 벗어납니다.

no-multilib 타르볼 시스템 베이스로 선택하면 완벽한 64비트 처리 시스템 환경을 갖춥니다. 이 환경은 multilib 프로파일로 전환하는 희한하지만 가능한 기능을 갖추고 있습니다. 정말 필요한 경우가 아닌 이상 처음 젠투를 사용하는 사람이라면 no-multilib 타르볼을 젠투에서 사용하지 않는게 좋습니다.

스테이지 타르볼 다운로드

Before downloading the stage file, the current directory should be set to the location of the mount used for the install:

root #cd /mnt/gentoo

날짜 및 시간 설정

Stage archives are generally obtained using HTTPS which requires relatively accurate system time. Clock skew can prevent downloads from working, and can cause unpredictable errors if the system time is adjusted by any considerable amount after installation.

date 명령으로 현재 날짜와 시각을 확인하십시오:

root #date

Mon Oct  3 13:16:22 PDT 2016

날짜 시각이 잘못 나타났다면 아래 방식으로 고치십시오.

자동

Using NTP to correct clock skew is typically easier and more reliable than manually setting the system clock.

chronyd, part of net-misc/chrony can be used to update the system clock to UTC with:

root #ntpd -q -g

중요
Systems without a functioning Real-Time Clock (RTC) must sync the system clock at every system start, and on regular intervals thereafter. This is also beneficial for systems with a RTC, as the battery could fail, and clock skew can accumulate.

경고
Standard NTP traffic not authenticated, it is important to verify time data obtained from the network.

수동

When NTP access is unavailable, date can be used to manually set the system clock.

모든 리눅스 시스템에 UTC 시계 설정을 추천합니다. 시간대는 설치 과정 후반에 설정합니다. 시간대를 설정하면 시계를 지역 시간으로 나타냅니다.

date 명령으로 시스템 시계를 직접 설정할 수도 있습니다. MMDDhhmmYYYY 형식으로 설정합니다(월,일,시,분,연도).

예를 들어 2016년 10월 03일 13시 16분을 설정하려면:

root #date 100313162016

그래픽 브라우저

완벽한 그래픽 여건을 갖춘 웹 브라우저에서 주 웹사이트 다운로드 페이지에서 스테이지 파일 URL을 그대로 복사해서 쓰는데 아무런 문제가 없습니다. 간단히 적절한 탭을 선택한 다음, 스테이지 파일 링크 위에 마우스 커서를 가져간 후, 마우스 오른쪽 단추를 누르고 링크 주소 복사 (Firefox) 또는 링크 위치 복사 (Chromium)를 선택하여 클립보드에 링크를 복사합니다. 그 후 명령행에서 wget 유틸리티 매개변수 자리에 붙여넣어 스테이지 타르볼을 내려받으십시오:

root #wget <PASTED_STAGE_URL>

명령행 브라우저

좀 더 예전부터 사용해온 독자 또는 젠투 사용자라면, 그래픽 방식이 아닌 메뉴기반 브라우저 links를 대신 선호할 지도 모르겠습니다. 스테이지 파일을 다운로드하려면 다음 명령으로 젠투 미러를 찾아보십시오:

root #links https://www.gentoo.org/downloads/mirrors/

links에서 HTTP 프록시를 사용하려면, -http-proxy 옵션으로 URL을 전달하십시오:

root #links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/

links 다음에는 lynx 브라우저도 있습니다. links와 유사하게 비-그래픽 브라우저지만, 메뉴 기반 브라우저도 아닙니다.

root #lynx https://www.gentoo.org/downloads/mirrors/

프록시를 지정해야 한다면, http_proxy 또는 ftp_proxy 변수 값을 export로 처리하십시오:

root #

export http_proxy="http://proxy.server.com:port"

root #export ftp_proxy="http://proxy.server.com:port"

미러 목록에서 가까운 미러를 선택하십시오. HTTP 미러를 사용하는 걸로 충분합니다만, 다른 프로토콜로도 쓸 수 있습니다. releases/amd64/autobuilds/ 디렉터리로 이동하십시오. 존재하는 모든 스테이지 파일이 나타납니다(아마도 각각의 하위 아키텍처에 있는 하위 디렉터리에 있을지도 모릅니다). 그 중 하나를 선택하고 d를 눌러 다운로드하십시오.

스테이지 파일 다운로드가 끝나면 스테이지 타르볼 내용의 무결성을 검증하고 유효화할 수 있습니다. 이 부분은 다음 장에서 진행합니다.

스테이지 파일 검증 및 유효화에 관심 없는 분들은 q키를 눌러 명령행 브라우저를 닫고 바로 스테이지 타르볼 압축 해제 부분으로 넘어갈 수 있습니다.

검증 및 유효화

참고
Most stages are now explicitly suffixed with the init system type (openrc or systemd), although some architectures may still be missing these for now.

최소 설치 CD 처럼, 추가로 검증하고 유효화할 다운로드 파일이 있습니다. 이 단계는 건너뛸 수 있지만 그냥 다운로드한 파일의 무결성에 신경 쓰는 사용자를 위해 제공합니다.

root #wget https://distfiles.gentoo.org/releases/

스테이지 타르볼 파일 목록이 있는 .CONTENTS 파일.
각각의 알고리즘으로 만든 스테이지 파일의 체크섬이 있는 .DIGESTS 파일.
.DIGESTS 파일과 마찬가지로 각각의 알고리즘으로 만든 스테이지 파일의 체크섬이 있지만, 젠투 프로젝트에서 제공했음을 확인할때 쓰는 암호화 서명도 들어있는 .DIGESTS.asc.

openssl을 사용하여 .DIGESTS 또는 .DIGESTS.asc 파일에서 제공하는 체크섬 출력을 비교하십시오.

SHA512 체크섬을 검증한다면:

root #openssl dgst -r -sha512 stage3-amd64-<release>.tar.bz2

dgst instructs the openssl command to use the Message Digest sub-command, -r prints the digest output in coreutils format, and -sha512 selects the SHA512 digest.

월풀 체크섬을 검증하려면:

root #openssl dgst -r -whirlpool stage3-amd64-<release>.tar.bz2

.DIGESTS(.asc) 파일에 등록한 값을 이 명령의 출력과 비교하십시오. 값이 일치해야 하며, 그렇지 않으면 다운로드한 파일(또는 digests 파일)이 깨진 상태입니다.

sha512sum 명령을 사용하는 다른 방법도 있습니다:

root #sha512sum stage3-amd64-<release>.tar.bz2

The --check option instructs sha256sum to read a list of expected files and associated hashes, and then print an associated "OK" for each file that calculates correctly or a "FAILED" for files that do not.

ISO 파일과 마찬가지로, gpg를 활용하여 .DIGESTS.asc 파일의 암호화 서명을 검증하여 누군가가 체크섬에 손을 댔는지 여부를 확인할 수 있습니다:

For official Gentoo live images, the sec-keys/openpgp-keys-gentoo-release package provides PGP signing keys for automated releases. The keys must first be imported into the user's session in order to be used for verification:

root #gpg --import /usr/share/openpgp-keys/gentoo-release.asc

For all non-official live images which offer gpg and wget in the live environment, a bundle containing Gentoo keys can be fetched and imported:

root #wget -O - https://qa-reports.gentoo.org/output/service-keys.gpg | gpg --import

Verify the signature of the tarball and, optionally, associated checksum files:

root #gpg --verify stage3-amd64-<release>.tar.bz2,.DIGESTS.asc

If verification succeeds, "Good signature from" will be in the output of the previous command(s).

The fingerprints of the OpenPGP keys used for signing release media can be found on the release media signatures page.

스테이지 타르볼 설치하기

이제 다운로드한 스테이지를 시스템에 압축해제하십시오. tar를 사용하여 진행하겠습니다:

root #tar xpvf stage3-*.tar.bz2 --xattrs-include='*.*' --numeric-owner

동일한 옵션(xpf와 --xattrs-include='*.*')을 사용했는지 확인하십시오. x는 추출, p는 권한 플래그 유지, f는 표준 출력이 아닌 파일로 추출함을 나타냅니다. --xattrs-include='*.*'는 압축 파일에 저장한 이름 영역 전체의 확장 속성을 포함합니다. 마지막으로 --numeric-owner 옵션은 얼리어답터가 공식 젠투 설치 미디어를 활용하지 않는다 할 지라도, 젠투 릴리즈 엔지니어링 팀이 의도한 대로 타르볼에서 풀려나온 파일의 사용자 ID와 그룹 ID가 동일하게 나왔는지 확인합니다.

x extract, instructs tar to extract the contents of the archive.
p preserve permissions.
v verbose output.
f file, provides tar with the name of the input archive.
--xattrs-include='*.*' Preserves extended attributes in all namespaces stored in the archive.
--numeric-owner Ensure that the user and group IDs of files being extracted from the tarball remain the same as Gentoo's release engineering team intended (even if adventurous users are not using official Gentoo live environments for the installation process).

이제 스테이지 파일의 압축을 해제했으니, 컴파일 옵션 설정으로 진행하십시오.

컴파일 옵션 설정

도입부

젠투를 최적화 하려는 목적으로 젠투에서 공식적으로 지원하는 꾸러미 관리자 포티지 동작에 영향을 줄 여러가지 변수를 설정할 수 있습니다. 이들 변수는 (export로) 환경 변수처럼 설정할 수 있습니다만 언제든 값이 유지되는 것은 아닙니다. 설정값을 유지하려, 포티지의 설정 파일 /etc/portage/make.conf 파일을 포티지에서 읽습니다.

참고
Technically variables can be exported via the shell's profile or rc files, however that is not best practice for basic system administration.

Portage reads in the make.conf file when it runs, which will change runtime behavior depending on the values saved in the file. make.conf can be considered the primary configuration file for Portage, so treat its content carefully.

참고
쓸 수 있도록 주석 처리하여 준비한 모든 변수 목록은 /mnt/gentoo/usr/share/portage/config/make.conf.example에 있습니다. 젠투 설치를 제대로 하기위해 설정이 필요한 변수만을 아래에 언급했습니다.

For a successful Gentoo installation only the variables that are mentioned below need to be set.}}

편집기를 실행(이 안내서에서는 nano를 사용합니다)하여 이 다음에 언급할 최적화 변수값을 바꾸어보겠습니다.

root #nano -w /mnt/gentoo/etc/portage/make.conf

make.conf.example 파일에서 파일을 어떤 식으로 구성해야 하는지 분명히 나타납니다: "#"(으)로 시작하는 줄은 주석이며, 다른 줄은 VARIABLE="content" 문법으로 작성한 변수 설정 부분입니다. 다양한 이들 변수에 대해서는 다음에 이야기하겠습니다.

CFLAGS와 CXXFLAGS

CFLAGS와 CXXFLAGS 변수는 gcc C/C++ 컴파일러의 최적화 플래그를 각각 지정합니다. 보통 여기에 지정하지만, 최적의 성능을 위해서는 각각의 프로그램에 플래그를 최적화해야합니다. 각각의 프로그램이 다르기 때문입니다. 그러나 그리 관리하기 쉬운게 아니므로 이 플래그 정의를 make.conf 파일에 다룹니다.

make.conf 에서는 보통 시스템에 가장 많이 영향을 줄 최적화 플래그를 지정해야합니다. 이 변수에 시험적인 설정은 넣지 마십시오. 최적화를 과도하게 하면 프로그램 동작이 잘못되는 수가 있습니다(깨지거나, 잘못되거나, 기능이 망가지거나).

가능한 모든 최적화 옵션을 설명하지는 않겠습니다. 이들을 전부 이해하려면 GNU 온라인 문서^en 또는 gcc 정보 페이지(info gcc - 리눅스 시스템에서만 동작)를 참고하십시오. make.conf.example 파일 자체에 상당한 양의 예제와 정보를 담고 있습니다. 이것 또한 잊지 말고 살펴보십시오.

첫번째 설정은 대상 아키텍처 이름을 지정하는 -march= 또는 -mtune= 플래그입니다. 사용할 수 있는 옵션은 make.conf.example 파일에 (주석으로) 들어있습니다. 보통 사용하는 값은 컴파일러가 대상 아키텍처를 (사용자가 젠투를 설치하려는) 현재 시스템으로 설정하도록 하는 native 값입니다.

두번째는 gcc 최적화 수준 플래그를 지정하는 -O 플래그(숫자 영이 아닌 대문자 O임) 입니다. 가능한 클래스는 s(크기 최적화), 0(영. 최적화 안함), 1, 2, 또는 속도 최적화 를 위한 3 플래그(모든 클래스는 이전 클래스와 비슷하지만, 몇가지 특징을 추가함)입니다. 기본적으로 -O2를 추천합니다. 시스템 전반적인 영역에 있어 -O3이 문제를 일으키는것으로 알려져 있어 -O2에 집착하기를 추천합니다.

다른 최적화 플래그는 -pipe(다중 스테이지 컴파일간 통신에 임시 파일을 쓰는 대신 파이프를 활용)입니다. 생성 코드에 영향을 주지는 않지만 더 많은 메모리를 사용합니다. 메모리가 부족해지면, gcc를 강제로 끝냅니다. 이 경우 이 플래그를 사용하지 마십시오.

-fomit-frame-pointer(필요하지 않은 함수에 대한 프레임 포인터를 레지스터에서 계속 가지고 있지 않도록 하는 옵션)를 사용하면 프로그램을 디버깅하는동안 심각한 문제가 생길지도 모릅니다.

CFLAGS와 CXXFLAGS 변수를 지정하면, 각각의 최적화 플래그를 하나의 문자열로 합칩니다. 스테이지 3 아카이브에 들어있는 기본값은 풀려나온 값 자체로도 충분합니다. 다음 플래그는 예제일뿐입니다:

코드 CFLAGS와 CXXFLAGS 변수 예제

CFLAGS="-march=native -O2 -pipe"
# Use the same settings for both variables
CXXFLAGS="${CFLAGS}"

요령
GCC 최적화 안내서에 다양한 컴파일 옵션이 시스템에 어떻게 영향을 주는지 많은 설명을 넣었지만, 시스템 최적화를 시작하려는 초보자에게는 Safe CFLAGS(en)가 더 도움이 될 수도 있습니다.

MAKEOPTS

MAKEOPTS 변수는 꾸러미를 설치하는 동안 컴파일을 동시에 몇개를 진행하는지 지정합니다. 최적의 값은 시스템에 붙은 CPU(또는 CPU 코어)의 갯수에 1을 더한 값이지만 이 안내서가 언제나 완벽하진 않습니다.

Further, as of Portage 3.0.53^[1], if left undefined, Portage's default behavior is to set the MAKEOPTS load-average value to the same number of threads returned by nproc.

A good choice is the smaller of: the number of threads the CPU has, or the total amount of system RAM divided by 2 GiB.

경고
Using a large number of jobs can significantly impact memory consumption. A good recommendation is to have at least 2 GiB of RAM for every job specified (so, e.g. -j6 requires at least 12 GiB). To avoid running out of memory, lower the number of jobs to fit the available memory.

요령
When using parallel emerges (--jobs), the effective number of jobs run can grow exponentially (up to make jobs multiplied by emerge jobs). This can be worked around by running a localhost-only distcc configuration that will limit the number of compiler instances per host.

코드 make.conf의 MAKEOPTS 선언 예제

MAKEOPTS="-j2"

Search for MAKEOPTS in man 5 make.conf for more details.

준비, 시, 작!

개인 취향에 맞춰 /mnt/gentoo/etc/portage/make.conf를 업데이트한 후 저장하십시오(나노 사용자는 Ctrl+X를 치십시오).

References

↑ https://gitweb.gentoo.org/proj/portage.git/commit/?id=de7be7f45ee54e3f789def46542919550687d15e

← 디스크 준비 처음 젠투 베이스 시스템 설치 →

루트 변경

DNS 정보 복사

새 환경에 들어가기 전 아직 남은 하나는 /etc/resolv.conf의 DNS 정보를 복사하는 일입니다. 새 환경에 들어가고 나서 네트워크가 그대로 동작할 수 있게 하려면 꼭 필요합니다. /etc/resolv.conf 파일에는 네트워크를 사용할 때 활용하는 네임 서버 주소가 들어있습니다.

이 정보를 복사하려면 cp 명령에 --dereference 옵션을 전달하는게 좋습니다. /etc/resolv.conf 파일이 심볼릭 링크라면 심볼릭 링크가 아니라 링크의 대상 파일 그 자체를 찾아서 복사합니다. 그렇지 않으면 새 환경에서 심볼릭 링크로 남아있으며(링크 대상은 새 환경에 존재하지 않습니다), 실제 존재하지 않는 파일을 참조합니다.

root #cp --dereference /etc/resolv.conf /mnt/gentoo/etc/

필요한 파일 시스템 마운트

잠시 동안, 리눅스 루트는 새 위치로 바뀝니다. 새 환경이 제대로 동작하는지 보려면 각각의 파일 시스템을 활성화해야 합니다.

활성화해야 할 파일 시스템은 다음과 같습니다:

리눅스 커널에서 환경에 공개하려는 정보가 만든 의사 파일 시스템(일반 파일 같지만, 실제로는 동적으로 생성하는 파일 시스템) /proc/
/proc/보다 구조가 잘 갖춰져있어 대체 용도로 쓸 수 있는 의사 파일 시스템 /sys/
리눅스 장치 관리자(보통 udev)가 일부 관리하는 일반 파일 시스템이며, 모든 장치 파일이 들어있는 /dev/

다른 두개의 파일 시스템은 바인드 마운트를 하는데 반해 /proc/ 위치는 /mnt/gentoo/proc/에 마운트합니다. 후자의 경우, /mnt/gentoo/proc/는 (말 그대로) 파일 시스템에 대한 새 마운트지만, /mnt/gentoo/sys/는 실제로 /sys/(동일한 파일 시스템에 대한 두번째 마운트 지점)이 된다는 의미입니다.

요령
If using Gentoo's install media, this step can be replaced with simply: arch-chroot /mnt/gentoo.

root #

mount --types proc /proc /mnt/gentoo/proc

root #

mount --rbind /sys /mnt/gentoo/sys

root #

mount --make-rslave /mnt/gentoo/sys

root #

mount --rbind /dev /mnt/gentoo/dev

root #

mount --make-rslave /mnt/gentoo/dev

참고
--make-rslave 동작은 설치 과정에서 나중에 systemd 지원 기능에 필요합니다.

경고
비 젠투 설치 매체를 사용할 경우 이 과정이 충분하지 않을 수도 있습니다. 일부 배포판은 /dev/shm 심볼릭 링크를 /run/shm/으로 만들지만 루트를 바꾸고 난 후에는 무효처리됩니다. /dev/shm/을 적당한 tmpfs로 마운트 하려면 다음 명령으로 문제를 처리할 수 있습니다:

root #

test -L /dev/shm && rm /dev/shm && mkdir /dev/shm

root #

mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm

또한 파일 모드를 1777로 설정했는지 확인하십시오:

root # chmod 1777 /dev/shm

새 환경으로 진입

모든 파티션을 초기화 하고 기반 환경을 설치했으니, 새 설치 환경에 chroot로 들어갈 차례입니다. 현재 설치 환경의 세션의 루트(접근할 수 있는 최상위 환경)를 설치 시스템의 루트(초기화한 파티션)로 바꾼다는 의미입니다. 그래서 이름이 change root 또는 chroot라고 합니다.

루트 위치 전환은 세 단계로 처리합니다:

chroot를 사용하여 루트 위치를 (설치 매체의)/에서 (파티션의) /mnt/gentoo/로 바꿉니다
몇가지 설정(/etc/profile에 있음)을 source 명령으로 메모리에 다시 불러옵니다
chroot로 바꾼 환경임을 인지하기 위해 초기 프롬프트를 바꿉니다.

root #

chroot /mnt/gentoo /bin/bash

root #

source /etc/profile

root #export PS1="(chroot) ${PS1}"

이 때, 모든 동작을 새 젠투 리눅스 환경에서 바로 처리할 수 있습니다. 물론 끝나려면 한참 멀었지만, 설치 절이 여전히 아직도 남아있는 이유입니다!

요령
젠투 설치가 여기 어디에선가 멈췄다면 이 단계에서 설치를 '재개'할 수 있"어야"합니다. 디스크 영역을 다시 분할할 필요가 없습니다! 간단하게 루트 분할 영역 마운트 를 진행하고, 작업 환경에 다시 들어오기 전 #DNS 정보 복사로 위 단계 진행을 시작하십시오. 이 방법은 부트로더 문제를 해결할 때도 쓸만합니다. 더 많은 내용은 chroot 게시글에서 찾아보실 수 있습니다.

Preparing for a bootloader

Now that the new environment has been entered, it is necessary to prepare the new environment for the bootloader. It will be important to have the correct partition mounted when it is time to install the bootloader.

UEFI systems

For UEFI systems, /dev/sda1 was formatted with the FAT32 filesystem and will be used as the EFI System Partition (ESP). Create a new /efi directory (if not yet created), and then mount ESP there:

root #

mkdir /efi

root #

mount /dev/sda1 /efi

DOS/Legacy BIOS systems

For DOS/Legacy BIOS systems, the bootloader will be installed into the /boot directory, therefore mount as follows:

root #mount /dev/sda1 /boot

포티지 설정

웹에서 이빌드 저장소 스냅샷 가져와서 설치하기

다음은 이빌드 저장소 스냅샷을 설치할 차례입니다. 이 스냅샷에는 사용할 수 있는 프로그램 (설치) 이름, 시스템 관리자가 선택할 수 있는 프로파일, 꾸러미, 프로파일별 소식 항목 등이 들어있습니다.

제한적인 방화벽 환경에 있어 네트워크 대역폭 활용을 아낄 분들은 (스냅샷을 다운로드할 때 HTTP/FTP를 활용하므로) emerge-webrsync 사용을 권장합니다. 네트워크 또는 대역폭 제한이 없는 독자분들은 다음으로 신나게(!) 건너 뛸 수 있습니다.

이 과정을 통해 젠투 미러 중 한 곳에서 (매일 최신 내용으로 바뀌는) 최신 스냅샷을 가져와서 시스템에 설치합니다:

root #emerge-webrsync

참고
설치 과정 중 emerge-webrsync에서 /var/db/repos/gentoo/ 위치가 없는 문제를 보고합니다. 당연한 결과이며 걱정할 필요가 없습니다. 도구에서 해당 위치를 만듭니다.

이 시점부터는 포티지에서 각각의 추천 업데이트를 실행하라고 알려줍니다. 스테이지 파일을 통해 설치한 시스템 꾸러미는 새 버전이 존재하며, 저장소 스냅샷을 새로 설치하여 포티지가 새 꾸러미를 인식하기 때문입니다. 지금은 꾸러미 업데이트를 안전하게 무시할 수 있으며, 젠투 설치가 끝나기 전이라도 업데이트를 미룰 수 있습니다.

선택: 미러 선택

소스코드를 빨리 다운로드 하려면 빠른 미러를 선택하시는 것이 좋습니다. 포티지는 make.conf 파일의 GENTOO_MIRRORS 변수에서 미러를 찾아보며 해당 변수에 들어간 미러를 활용합니다 젠투 미러 목록 및 시스템에서 물리적으로 가까운(대부분 이런 미러가 빠름) 미러(또는 복수의 미러) 를 검색할 수 있습니다. 그러나 우리에겐 필요한 미러를 선택할 때 멋진 인터페이스를 제공해 주는 mirrorselect 도구가 있습니다. 선택할 미러를 찾아보고 하나 이상의 미러를 Spacebar 키로 선택하면 됩니다.

A tool called mirrorselect provides a pretty text interface to more quickly query and select suitable mirrors. Just navigate to the mirrors of choice and press Spacebar to select one or more mirrors.

root #mirrorselect -i -o >> /mnt/gentoo/etc/portage/make.conf

Alternatively, a list of active mirrors are available online.

선택: 젠투 이빌드 저장소 업데이트

젠투 이빌드 저장소를 최신 버전으로 업데이트할 수 있습니다. 이전에 emerge-webrsync 명령은 상당히 최근의 포티지 스냅샷(보통 최근 24시간 까지)을 설치하기 때문에 분명히 말하자면 선택적인 동작입니다.

최근 꾸러미 업데이트(최대 한시간 동안)가 필요하다면, emerge --sync 명령을 사용하십시오. 이 명령은 젠투 이빌드 저장소(이전에 emerge-webrsync 명령으로 가져옴)를 최신 상태로 업데이트하는데 rsync 프로토콜을 사용합니다.

root #emerge --sync

몇가지 프레임 버퍼와 직렬 콘솔 같은 느린 터미널에서는, 처리 과정의 속도를 높이기 위해 --quiet 옵션을 사용하시는 것이 좋습니다:

root #emerge --sync --quiet

뉴스 항목 보기

젠투 이빌드 저장소를 시스템과 동기화 하면, 포티지에서 다음과 같은 메시지로 사용자에게 경고합니다:

 * IMPORTANT: 2 news items need reading for repository 'gentoo'.

 * Use eselect news to read news items.

뉴스 항목은 rsync 트리로 사용자에게 중요한 메시지를 강제로 전달하는 통신 매체를 제공하려 만들었습니다. 뉴스 항목을 관리하려면 eselect news를 사용하십시오. eselect 프로그램은 시스템에서 바뀐 항목 또는 시스템 전반 설정을 처리하는 일반 관리 인터페이스입니다. 이 경우 eselect는 news 모듈 사용을 요청합니다.

news 모듈에서 다음 동작을 주로 사용합니다:

list 명령으로 표시할 뉴스 목록의 개요를 표시합니다
read 명령으로 읽을 수 있는 뉴스 항목을 표시합니다
purge 명령으로 이미 읽어서 더 이상 읽을 일이 없는 뉴스 항목을 제거할 수 있습니다

root #

eselect news list

root #eselect news read

뉴스 리더에서 사용할 수 있는 기능이 무엇인지 더 살펴보려면 설명서 페이지를 참고하십시오:

root #man news.eselect

적절한 프로파일 선택

요령
Desktop profiles are not exclusively for desktop environments. They are also suitable for minimal window managers like i3 or sway.

프로파일이란 젠투 시스템의 구성요소입니다. USE, CFLAGS 등 중요한 변수 값의 기본값만을 지정하는 것이 아니라 꾸러미 버전 범위를 시스템에 고정합니다. 이 설정 데이터는 젠투 포티지 개발자가 관리합니다.

현재 시스템에서 활용하는 프로파일을 eselect로 볼 수 있으며, 이제 profile 모듈을 사용해보면:

root #eselect profile list

Available profile symlink targets:
  [1]   default/linux/amd64/23.0 *
  [2]   default/linux/amd64/23.0/desktop
  [3]   default/linux/amd64/23.0/desktop/gnome
  [4]   default/linux/amd64/23.0/desktop/kde

참고
명령 출력 결과는 예제일 뿐이며, 언제든 바뀝니다.

보신 바와 같이, 몇가지 데스크톱에 대한 데스크톱 하위 프로파일이 있습니다.

경고
프로파일 업그레이드를 가벼이 여기면 안됩니다. 초기 프로파일을 선택할 때, 스테이지3에서 처음 사용하는 동일한 버전(이를테면 17.0)에 해당하는 프로파일을 활용하는지 확인하십시오. 각 새 프로파일 버전은 이전 절차 내용을 담은 뉴스 항목으로 공지합니다. 새 프로파일로 전환하기 전에 해당 내용을 반드시 확인하고 따르십시오.

amd64 아키텍처에서 존재하는 프로파일을 확인한 후 사용자는 시스템의 다른 프로파일을 선택할 수 있습니다:

root #eselect profile set 2

No-multilib

32비트 프로그램 또는 라이브러리를 뺀 순수한 64비트 환경을 선택하려면, no-multilib 프로파일을 활용하십시오:

root #eselect profile list

Available profile symlink targets:
  [1]   default/linux/amd64/13.0 *
  [2]   default/linux/amd64/13.0/desktop
  [3]   default/linux/amd64/13.0/desktop/gnome
  [4]   default/linux/amd64/13.0/desktop/kde
  [5]   default/linux/amd64/13.0/no-multilib

다음 no-multilib 프로파일을 선택하십시오:

root #

eselect profile set 5

root #eselect profile list

Available profile symlink targets:
  [1]   default/linux/amd64/13.0
  [2]   default/linux/amd64/13.0/desktop
  [3]   default/linux/amd64/13.0/desktop/gnome
  [4]   default/linux/amd64/13.0/desktop/kde
  [5]   default/linux/amd64/13.0/no-multilib *

참고
developer 하위 프로파일은 젠투 리눅스 개발 용도로 사용하며, 일반 사용자가 사용한다는 의미가 아닙니다.

Optional: Adding a binary package host

Since December 2023, Gentoo's Release Engineering team has offered an official binary package host (colloquially shorted to just "binhost") for use by the general community to retrieve and install binary packages (binpkgs).^[1]

Adding a binary package host allows Portage to install cryptographically signed, compiled packages. In many cases, adding a binary package host will greatly decrease the mean time to package installation and adds much benefit when running Gentoo on older, slower, or low power systems.

Repository configuration

The repository configuration for a binhost is found in Portage's /etc/portage/binrepos.conf/ directory, which functions similarly to the configuration mentioned in the Gentoo ebuild repository section.

When defining a binary host, there are two important aspects to consider:

The architecture and profile targets within the sync-uri value do matter and should align to the respective computer architecture (amd64 in this case) and system profile selected in the Choosing the right profile section.
Selecting a fast, geographically close mirror will generally shorten retrieval time. Review the mirrorselect tool mentioned in the Optional: Selecting mirrors section or review the online list of mirrors where URL values can be discovered.

파일 /etc/portage/binrepos.conf/gentoobinhost.confCDN-based binary package host example

[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/

Installing binary packages

Portage will compile packages from code source by default. It can be instructed to use binary packages in the following ways:

The --getbinpkg option can be passed when invoking the emerge command. This method of for binary package installation is useful to install only a particular binary package.
Changing the system's default via Portage's FEATURES variable, which is exposed through the /etc/portage/make.conf file. Applying this configuration change will cause Portage to query the binary package host for the package(s) to be requested and fall back to compiling locally when no results are found.

For example, to have Portage always install available binary packages:

파일 /etc/portage/make.confConfigure Portage to use binary packages by default

# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"

Please also run getuto for Portage to set up the necessary keyring for verification:

root #getuto

Additional Portage features will be discussed in the the next chapter of the handbook.

USE 변수 설정

USE는 젠투가 사용자에게 제공하는 가장 강력한 변수중 하나입니다. 여러 프로그램 각 항목을 추가로 지원하든 안하든 컴파일할 수 있습니다. 예를 들어 어떤 프로그램은 GTK+ 지원 또는 Qt 지원을 넣고 컴파일할 수 있습니다. 다른 프로그램은 SSL 지원을 빼고 컴파일할 수 있습니다. 어떤 프로그램은 X11 지원(X-서버) 대신 프레임버퍼 지원(svgalib)을 빼고도 컴파일할 수 있습니다.

대부분의 배포판에서는 가능한한 최대한의 지원을 포함하여 꾸러미를 컴파일합니다. 상당한 양의 의존성에 상관 없이 프로그램의 크기와 시작 시간이 늘어납니다. 젠투 사용자는 컴파일할 때 어떤 옵션을 넣을지 지정할 수 있습니다. 이것이 바로 USE 변수가 동작하는 위치입니다.

USE 변수에는 컴파일 옵션에 매핑할 키워드가 들어있습니다. 예를 들어 ssl은 SSL 지원을 프로그램에 넣어 프로그램에서 SSL 기능이 동작하도록 컴파일합니다. -X는 X 서버 지원을 제거합닏(앞에 음수부호가 들어감에 주목). gnome gtk -kde -qt4 -qt5는 시스템을 GNOME(아키텍처에서 지원한다면)에 완전히 맞추려 그놈(및 GTK+) 지원을 넣고 KDE(및 Qt) 지원을 뺍니다.

기본 USE 설정은 시스템에서 사용하는 젠투 프로파일의 make.defaults 파일에 있습니다. 젠투에서는 프로파일의 (복잡한) 계층 시스템을 사용하는데, 이 단계로는 깊이 들어가지 않겠습니다. 현재 활성화한 USE 설정을 확인하는 가장 쉬운 방법은 emerge --info를 실행하고 "USE"로 시작하는 줄을 선택해서 확인하는 방법입니다:

root #emerge --info | grep ^USE

USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."

참고
위 예제는 잘렸으며, 실제 USE 값 설정 목록은 엄청 큽니다.

시스템에서 사용할 수 있는 USE 플래그의 전체 설명은 /var/db/repos/gentoo/profiles/use.desc에 있습니다.

root #less /var/db/repos/gentoo/profiles/use.desc

less 명령에서는 ↑, ↓키로 스크롤할 수 있고, q를 눌러 빠져나갈 수 있습니다.

예제를 통해 DVD, ALSA, CD 기록 기능을 지원하는 KDE 기반 시스템의 USE 플래그 설정을 보여드리겠습니다:

root #nano -w /etc/portage/make.conf

파일 /etc/portage/make.confKDE 기반 시스템에서 DVD, ALSA, CD 기록 기능을 포함하는 USE 플래그 활성화

USE="-gtk -gnome qt4 qt5 kde dvd alsa cdr"

/etc/portage/make.conf에서 USE를 정의할 때, 기본 목록에서 추가 (또는 USE 플래그가 - 부호로 시작하는경우 삭제)됩니다. 기본 USE 설정을 무시하고 자체적으로 관리하려는 사용자는 make.conf의 USE 정의 앞부분에 -*를 넣으십시오:

파일 /etc/portage/make.conf기본 USE 플래그 무시

USE="-* X acl alsa"

경고
(위 설정과 마찬가지로) -* 설정이 가능하다 하더라도, 기본 USE 플래그는 일부 이빌드의 설정 충돌을 막고 다른 오류가 일어나지 않게 심혈을 기울여 설정했으므로 권장하지 않습니다.

CPU_FLAGS_*

Some architectures (including AMD64/X86, ARM, PPC) have a USE_EXPAND variable called CPU_FLAGS_<ARCH>, where <ARCH> is replaced with the relevant system architecture name.

중요
Do not be confused! AMD64 and X86 systems share some common architecture, so the proper variable name for AMD64 systems is CPU_FLAGS_X86.

This is used to configure the build to compile in specific assembly code or other intrinsics, usually hand-written or otherwise extra, and is not the same as asking the compiler to output optimized code for a certain CPU feature (e.g. -march=).

Users should set this variable in addition to configuring their COMMON_FLAGS as desired.

A few steps are needed to set this up:

root #emerge --ask --oneshot app-portage/cpuid2cpuflags

Inspect the output manually if curious:

root #cpuid2cpuflags

Then copy the output into package.use:

root #echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags

VIDEO_CARDS

The VIDEO_CARDS USE_EXPAND variable should be configured appropriately depending on the available GPU(s). Setting VIDEO_CARDS is not required for a console only install.

Below is an example of a properly set VIDEO_CARDS variable. Substitute the name of the driver(s) to be used.

파일 /etc/portage/make.conf

VIDEO_CARDS="amdgpu radeonsi"

Details for various GPU(s) can be found at the AMDGPU, Intel, Nouveau (Open Source), or NVIDIA (Proprietary) articles.

선택: ACCEPT_LICENSE 변수 설정

Starting with Gentoo Linux Enhancement Proposal 23 (GLEP 23), a mechanism was created to allow system administrators the ability to "regulate the software they install with regards to licenses... Some want a system free of any software that is not OSI-approved; others are simply curious as to what licenses they are implicitly accepting."^[2] With a motivation to have more granular control over the type of software running on a Gentoo system, the ACCEPT_LICENSE variable was born.

젠투는 다음과 같이 프로파일에 기 지정 초기값을 보유하고 있습니다:

user $portageq envvar ACCEPT_LICENSE

@FREE

라이선스 그룹은 젠투 라이선스 프로젝트가 젠투 저장소를 관리하며 지정합니다:

그룹 이름	설명
@GPL-COMPATIBLE	자유 소프트웨어 재단에서 인가한 GPL 호환 라이선스 ^{[a_license 1]}
@FSF-APPROVED	자유 소프트웨어 재단에서 인가한 라이선스 (@GPL-COMPATIBLE도 해당)
@OSI-APPROVED	오픈 소스 이니셔티브(OSI)에서 인가한 라이선스 ^{[a_license 2]}
@MISC-FREE	아마도 자유 소프트웨어 일지도 모르는 기타 라이선스, 예: 자유 소프트웨어 정의를 따름 ^{[a_license 3]} 그러나 FSF 또는 OSI에서 인가하지 않음
@FREE-SOFTWARE	@FSF-APPROVED, @OSI-APPROVED, @MISC-FREE를 합침
@FSF-APPROVED-OTHER	"자유 문서"와 "프로그램 및 문서에서 활용하는 저작물"에 해당하는(글꼴 포함) 자유 소프트웨어 재단 인가 라이선스
@MISC-FREE-DOCS	'자유' 정의를 따르는 자유 문서와 기타 저작물 (글꼴 포함) ^{[a_license 4]} 에 대해 @FSF-APPROVED-OTHER 에 없는 라이선스
@FREE-DOCUMENTS	@FSF-APPROVED-OTHER, @MISC-FREE-DOCS 를 합침
@FREE	사용, 공유, 수정, 공유 수정물에 대한 모든 라이선스 모음. @FREE-SOFTWARE, @FREE-DOCUMENTS 를 합침
@BINARY-REDISTRIBUTABLE	바이너리 형식 소프트웨어의 자유 재배포를 최소한 허용하는 라이선스. @FREE도 해당.
@EULA	권리를 제한하는 라이선스 동의서. "all-rights-reserved" 보다 제한적이거나 분명한 허용이 필요함

Some common license groups include:

A list of software licenses grouped according to their kinds.
Name	Description
`@GPL-COMPATIBLE`	GPL compatible licenses approved by the Free Software Foundation ^{[a_license 5]}
`@FSF-APPROVED`	Free software licenses approved by the FSF (includes `@GPL-COMPATIBLE`)
`@OSI-APPROVED`	Licenses approved by the Open Source Initiative ^{[a_license 6]}
`@MISC-FREE`	Misc licenses that are probably free software, i.e. follow the Free Software Definition ^{[a_license 7]} but are not approved by either FSF or OSI
`@FREE-SOFTWARE`	Combines `@FSF-APPROVED`, `@OSI-APPROVED`, and `@MISC-FREE`.
`@FSF-APPROVED-OTHER`	FSF-approved licenses for "free documentation" and "works of practical use besides software and documentation" (including fonts)
`@MISC-FREE-DOCS`	Misc licenses for free documents and other works (including fonts) that follow the free definition ^{[a_license 8]} but are NOT listed in `@FSF-APPROVED-OTHER`.
`@FREE-DOCUMENTS`	Combines `@FSF-APPROVED-OTHER` and `@MISC-FREE-DOCS`.
`@FREE`	Metaset of all licenses with the freedom to use, share, modify and share modifications. Combines `@FREE-SOFTWARE` and `@FREE-DOCUMENTS`.
`@BINARY-REDISTRIBUTABLE`	Licenses that at least permit free redistribution of the software in binary form. Includes `@FREE`.
`@EULA`	License agreements that try to take away your rights. These are more restrictive than "all-rights-reserved" or require explicit approval

Currently set system wide acceptable license values can be viewed via:

user $portageq envvar ACCEPT_LICENSE

@FREE

As visible in the output, the default value is to only allow software which has been grouped into the @FREE category to be installed.

Specific licenses or licenses groups for a system can be defined in the following locations:

System wide within the selected profile - this sets the default value.
System wide within the /etc/portage/make.conf file. System administrators override the profile's default value within this file.
Per-package within a /etc/portage/package.license file.
Per-package within a /etc/portage/package.license/ directory of files.

/etc/portage/make.conf 파일을 수정하여 시스템 전체 영역 값을 조정할 수 있습니다. 기본 값은 자유 소프트웨어 재단, 오픈소스 이니셔티브에서 분명하게 인가했거나, 자유 소프트웨어 정의를 따르는 라이선스만을 따릅니다.:

파일 /etc/portage/make.confACCEPT_LICENSE 개별 설정

ACCEPT_LICENSE="-* @FREE"

필요한 경우 다음과 같이 꾸러미 별로 설정할 수 있습니다:

파일 /etc/portage/package.license/kernel라이선스 허용 예제

app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode

root #mkdir /etc/portage/package.license

Software license details for an individual Gentoo package are stored within the LICENSE variable of the associated ebuild. One package may have one or many software licenses, therefore it be necessary to specify multiple acceptable licenses for a single package.

파일 /etc/portage/package.license/kernelAccepting licenses on a per-package basis

app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode

중요
ebuild의 LICENSE변수는 젠투 개발자와 사용자에게 필요한 지침일 뿐입니다. 법적 조항이 아니며, 실제로 어떻게 반영이 되는지는 보증하지 않습니다. 따라서 이 변수에 신경쓰실 일이 없으며, 여러분이 사용하려믄 모든 파일이 들어간 꾸러미 자체를 유심히 살펴보십시오.

@world 세트 업데이트

이 다음 단계는 stage3를 빌드한 후 어떤 프로파일을 선택하든지간에 시스템에서 최신 내용을 반영하도록 "필요한" 과정입니다:

A profile target different from the stage file has been selected.
Additional USE flags have been set for installed packages.

Readers who are performing an 'install Gentoo speed run' may safely skip @world set updates until after their system has rebooted into the new Gentoo environment.

Readers who are performing a slow run can have Portage perform updates for package, profile, and/or USE flag changes at the present time:

root #emerge --ask --verbose --update --deep --newuse @world

Removing obsolete packages

It is important to always depclean after system upgrades to remove obsolete packages. Review the output carefully with emerge --depclean --pretend to see if any of the to-be-cleaned packages should be kept if personally using them. To keep a package which would otherwise be depcleaned, use emerge --noreplace foo.

root #emerge --ask --pretend --depclean

If happy, then proceed with a real depclean:

root #emerge --ask --depclean

요령
완전한 구성을 갖춘 데스크톱 환경 프로파일을 선택하면 설치 과정에 필요한 시간은 상당히 늘어날 수 있습니다. 진행 과정의 일은 '과정상 경험' 으로 처리할 수 있습니다. 짧은 프로파일 이름을 지닌, 드문 경우의 시스템 @world 세트가 있는데 이 프로파일은 시스템에 필요한 꾸러미 수가 적습니다. 다시 말해서:

default/linux/amd64/13.0을 선택하면 상당히 적은 꾸러미를 최신으로 유지합니다만,
default/linux/amd64/13.0/desktop/gnome/systemd는 OpenRC에서 Systemd로, 그놈 데스크톱 환경 프레임워크를 설치한 만큼 상당한 꾸러미를 설치해야합니다.

시간대

참고
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.

기대한 대로의 시간대 영역을 나타내지 않는 /usr/share/zoneinfo/Etc/GMT* 시간대 이름 사용을 피하십시오. GMT-8의 경우 실제로 GMT+8입니다.

시스템 시간대를 선택하십시오. 존재하는 시간대를 /usr/share/zoneinfo/에서 찾아보시고 /etc/timezone 파일에 작성하십시오.

root #ls /usr/share/zoneinfo

root #ls -l /usr/share/zoneinfo/Europe/

total 256
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Amsterdam
-rw-r--r-- 1 root root 1742 Dec  3 17:19 Andorra
-rw-r--r-- 1 root root 1151 Dec  3 17:19 Astrakhan
-rw-r--r-- 1 root root 2262 Dec  3 17:19 Athens
-rw-r--r-- 1 root root 3664 Dec  3 17:19 Belfast
-rw-r--r-- 1 root root 1920 Dec  3 17:19 Belgrade
-rw-r--r-- 1 root root 2298 Dec  3 17:19 Berlin
-rw-r--r-- 1 root root 2301 Dec  3 17:19 Bratislava
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Brussels
...

Suppose the timezone of choice is Europe/Brussels.

OpenRC

The desired timezone name can be written to /etc/timezone:

root #echo "Europe/Brussels" > /etc/timezone

그 다음 /etc/timezone 항목을 기반으로 /etc/localtime 파일을 업데이트하는 sys-libs/timezone-data 꾸러미를 다시 설정하겠습니다. /etc/localtime 파일은 시스템이 어떤 시간대 영역에 있는지 알고자 시스템 C 라이브러리에서 사용합니다.

root #emerge --config sys-libs/timezone-data

참고
The /etc/localtime file is used by the system C library to know the timezone the system is in.

systemd

A slightly different approach is employed when using systemd. A symbolic link is generated:

root #ln -sf ../usr/share/zoneinfo/Europe/Brussels /etc/localtime

Later, when systemd is running, the timezone and related settings can be configured with the timedatectl command.

로캘 설정

참고
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.

Locale generation

대부분의 사용자는 시스템에 하나 내지는 두개의 로캘을 사용하려고 합니다.

로캘은 시스템과 대화할 때 사용자가 사용할 언어에 한정하지 않으며 정렬 문자열의 규칙, 날짜 및 시간의 표시 등의 항목도 포함합니다.

시스템에서 지원할 로캘은 /etc/locale.gen에 있습니다.

root #nano -w /etc/locale.gen

다음 로캘은 (UTF-8과 같은)문자 형식에 따라 영문(미국)과 독일어(독일)를 설정하는 예제입니다.

파일 /etc/locale.gen적절한 문자 형식으로 US 및 DE 로캘 활성화

en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE.UTF-8 UTF-8

경고
일부 프로그램에서 UTF-8이 필요하므로, 되도록이면 UTF-8로 설정하십시오.

다음 단계는 locale-gen을 실행할 차례입니다. /etc/locale.gen파일에 지정한 모든 로캘을 만듭니다.

root #locale-gen

선택한 로캘을 사용할 수 있는지 확인하려면 locale -a을 실행하십시오.

On systemd installs, localectl can be used, e.g. localectl set-locale ... or localectl list-locales.

Locale selection

이 과정이 끝나면 시스템 범위 로캘을 설정할 차례입니다. 이제 eselect 명령에 locale 모듈을 사용하겠습니다.

eselect locale list 명령으로 존재 대상을 나타냈습니다:

root #eselect locale list

Available targets for the LANG variable:
  [1] C
  [2] POSIX
  [3] en_US
  [4] en_US.iso88591
  [5] en_US.utf8
  [6] de_DE
  [7] de_DE.iso88591
  [8] de_DE.iso885915
  [9] de_DE.utf8
  [ ] (free form)

eselect locale set VALUE 명령으로 올바른 로캘을 설정할 수 있습니다:

root #eselect locale set 9

직접 설정한다면 /etc/env.d/02locale 파일에서도 처리할 수 있습니다:

파일 /etc/env.d/02locale시스템 로캘 정의 직접 설정

LANG="de_DE.UTF-8"
LC_COLLATE="C"

로캘을 설정했는지 확인하십시오. 그렇지 않으면, 커널을 빌드할 때와 설치 과정에서 나중에 다른 프로그램을 배포할 때 시스템에서 경고와 오류를 출력합니다.

이제 환경을 다시 불러오십시오:

root #env-update && source /etc/profile && export PS1="(chroot) ${PS1}"

이 과정을 통해 사용자 안내를 도울 완전한 지역화 안내서를 만들었습니다. 시스템에서 UTF-8 문자 코드를 활성화 할 주제로만 작성한 UTF-8 안내서도 흥미로운 읽을거리입니다.

References

← 젠투 설치 파일 설치 처음 리눅스 커널 설정 →

선택: 펌웨어 설치

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.

SOF Firmware

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

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.

Distribution kernels

Distribution Kernels are ebuilds that cover the complete process of unpacking, configuring, compiling, and installing the kernel. The primary advantage of this method is that the kernels are updated to new versions by the package manager as part of @world upgrade. This requires no more involvement than running an emerge command. Distribution kernels default to a configuration supporting the majority of hardware, however two mechanisms are offered for customization: savedconfig and config snippets. See the project page for more details on configuration.

Optional: Signed kernel modules

The kernel modules in the prebuilt distribution kernel (sys-kernel/gentoo-kernel-bin) are already signed. To sign the modules of kernels built from source enable the modules-sign USE flag, and optionally specify which key to use for signing in /etc/portage/make.conf:

파일 /etc/portage/make.confEnable module signing

USE="modules-sign"

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

If MODULES_SIGN_KEY is not specified the kernel build system will generate a key, it will be stored in /usr/src/linux-x.y.z/certs. It is recommended to manually generate a key to ensure that it will be the same for each kernel release. A key may be generated with:

root #openssl req -new -nodes -utf8 -sha256 -x509 -outform PEM -out kernel_key.pem -keyout kernel_key.pem

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

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

Optional: Signing the kernel image (Secure Boot)

The kernel image in the prebuilt distribution kernel (sys-kernel/gentoo-kernel-bin) is already signed for use with Secure Boot. To sign the kernel image of kernels built from source enable the secureboot USE flag, and optionally specify which key to use for signing in /etc/portage/make.conf. Note that signing the kernel image for use with secureboot requires that the kernel modules are also signed, the same key may be used to sign both the kernel image and the kernel modules:

파일 /etc/portage/make.confEnable custom signing keys

USE="modules-sign secureboot"

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

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

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

See the above section for instructions on generating a new key, the steps may be repeated if a separate key should be used to sign the kernel image.

To successfully boot with Secure Boot enabled, the used bootloader must also be signed and the certificate must be accepted by the UEFI firmware or Shim. This will be explained later in the handbook.

Installing a distribution kernel

To build a kernel with Gentoo patches from source, type:

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

System administrators who want to avoid compiling the kernel sources locally can instead use precompiled kernel images:

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

중요
Distribution Kernels, such as sys-kernel/gentoo-kernel and sys-kernel/gentoo-kernel-bin, by default, expect to be installed alongside an initramfs. Before running emerge to install the kernel users should ensure that sys-kernel/installkernel has been configured to utilize an initramfs generator (for example Dracut) as described in the installkernel section.

Upgrading and cleaning up

Once the kernel is installed, the package manager will automatically update it to newer versions. The previous versions will be kept until the package manager is requested to clean up stale packages. To reclaim disk space, stale packages can be trimmed by periodically running emerge with the --depclean option:

root #emerge --depclean

Alternatively, to specifically clean up old kernel versions:

root #emerge --prune sys-kernel/gentoo-kernel sys-kernel/gentoo-kernel-bin

요령
By design, emerge only removes the kernel build directory. It does not actually remove the kernel modules, nor the installed kernel image. To completely clean-up old kernels, the app-admin/eclean-kernel tool may be used.

Post-install/upgrade tasks

An upgrade of a distribution kernel is capable of triggering an automatic rebuild for external kernel modules installed by other packages (for example: sys-fs/zfs-kmod or x11-drivers/nvidia-drivers). This automated behaviour is enabled by enabling the dist-kernel USE flag. When required, this same flag will also trigger re-generation of the initramfs.

It is highly recommended to enable this flag globally via /etc/portage/make.conf when using a distribution kernel:

파일 /etc/portage/make.confEnabling USE=dist-kernel

USE="dist-kernel"

Manually rebuilding the initramfs or Unified Kernel Image

If required, manually trigger such rebuilds by, after a kernel upgrade, executing:

root #emerge --ask @module-rebuild

If any kernel modules (e.g. ZFS) are needed at early boot, rebuild the initramfs afterward via:

root #

emerge --config sys-kernel/gentoo-kernel

root #

emerge --config sys-kernel/gentoo-kernel-bin

소스 코드 설치

참고
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 amd64-based systems, Gentoo recommends the sys-kernel/gentoo-sources package.

Choose an appropriate kernel source and install it using emerge:

root #emerge --ask sys-kernel/gentoo-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.

아키텍처별 커널 설정

32비트 프로그램을 지원해야 할 경우(multilib) IA32 에뮬레이션을 선택했는지 확인하십시오. 젠투는 기본적으로 multilib 시스템을 설치(32비트/64비트 처리 혼용) 하므로 no-multilib 프로파일을 사용하지 않는 한, 이 옵션이 필요합니다.

커널 프로세서 형식 및 기능 선택

'"`UNIQ--pre-000000CD-QINU`"'

앞서 디스크 분할시 GPT 파티션 레이블을 사용했다면 지원을 활성화하십시오.

커널 GPT 지원 활성화

'"`UNIQ--pre-000000D0-QINU`"'

시스템을 부팅하려 UEFI를 사용한다면 리눅스 커널에서 EFI stub support와 EFI 변수를 활성화하십시오:

커널 UEFI 지원 활성화

'"`UNIQ--pre-000000D3-QINU`"'

커널 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

컴파일 및 설치

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

root #make && make modules_install

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

커널 컴파일이 끝나면 /boot/에 커널 이미지를 복사하십시오. make install 명령으로 처리할 수 있습니다.

root #make install

이 동작은 커널 이미지, System.map 파일, 커널 설정 파일을 /boot/에 함께 복사합니다.

대안: 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

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

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

파일 시스템 정보

파일 시스템 레이블과 UUID

MBR(BIOS)와 GPT 에는 파일 시스템 레이블과 파일 시스템 UUID가 있습니다. 이 속성은 블록 장치를 찾아 마운드할 때 mount 명령에서 대신 사용하여 /etc/fstab에 지정할 수 있습니다. 파일 시스템 레이블과 UUID는 앞에 LABEL과 UUID를 붙여 식별 명칭을 부여하며, blkid 명령으로 확인할 수 있습니다:

root #blkid

경고
분할 영역의 파일 시스템을 날렸다면, 파일 시스템 레이블과 UUID 값도 바뀌거나 제거됩니다.

고유성을 확보하기 위해, MBR 방식 분할 영역 테이블을 사용하는 독자 여러분의 경우 /etc/fstab의 마운트 가능한 볼륨을 지정할 때는 레이블에 UUID를 사용하는 방식을 추천합니다.

중요
UUIDs of the filesystem on a LVM volume and its LVM snapshots are identical, therefore using UUIDs to mount LVM volumes should be avoided.

분할 영역 레이블 및 UUID

GPT쪽으로 간 사용자는 /etc/fstab 에 분할 영역을 정의할 수 있는 '믿을 수 있는' 옵션을 더 넣습니다. 분할 영역 레이블과 분할 영역 UUID는 GPT 방식으로 포맷한 장치에 활용할 수 있는데 블록 장치의 개별 분할 영역을 분할 영역에 어떤 파일 시스템을 사용하든 상관 없이 유일하게 구별하려는 목적입니다. 분할 영역 레이블과 UUID는 PARTLABEL과 PARTUUID로 지정하며, 터미널에서 blkid 명령을 실행하면 간단하고 편리하게 깔끔한 모양새로 볼 수 있습니다:

Output for an amd64 EFI system using the Discoverable Partition Specification UUIDs may like the following:

root #blkid

분할 영역 레이블에 대해서는 항상 그렇진 않지만, fstab에서 분할 영역을 UUID로 식별할 때는 개별 볼륨을 찾을 때, 심지어는 파일 시스템이 나중에 바뀌더라도 부트로더에서 햇갈리지 않게 합니다. fstab에 이전 방식으로 기본 블록 장치 파일(/dev/sd*N)을 활용할 경우, 보통 SATA 블록 장치를 추가/제거할 경우 종종 시스템을 다시 시작하는데, 이때 위험 부담이 있습니다.

블록 장치 파일 작명은 시스템에 디스크가 어떻게 어떤 순서로 붙어있나 등의 요인에 따라 다릅니다. 또한 앞서 부팅 과정에서 커널이 어떤 장치를 먼저 찾았냐에 따라 다른 순서로 보여줄 수 있습니다. 디스크 장착 순서를 계속 다루지 않는 이상, 기존 상태로는 기본 블록 장치 파일을 활용하는게 간단하고 직관적인 접근 방식입니다.

fstab 정보

리눅스 시스템에서 사용하는 모든 분할 영역 정보는 /etc/fstab 에 있습니다. 이 파일에는 분할 영역의 마운트 지점(파일 시스템 구조를 볼 수 있는 곳), 마운트해야 할 방법, 특수 옵션(자동인지 아닌지, 사용자가 마운트를 할 수 있는지 없는지 등)이 들어있습니다

fstab 파일 만들기

참고
If the init system being used is systemd, the partition UUIDs conform to the Discoverable Partition Specification as given in Preparing the disks, and the system uses UEFI, then creating an fstab can be skipped, since systemd auto-mounts partitions that follow the spec.

/etc/fstab 파일은 표와 비슷한 문법을 사용합니다. 각 줄은 6개의 내용으로 채워져있으며 공백(단일 공백, 탭 또는 혼합)문자로 나눕니다. 각각의 필드는 자체적인 의미를 지니고 있습니다:

첫번째 내용은 마운트할 블록 특수 장치 또는 원격 파일 시스템을 나타냅니다. 대부분의 장치 식별자는 장치 파일 경로, 파일 시스템 레이블과 UUID, 분할 영역 레이블과 UUID와 같은 식으로 블록 특수 장치 노드에서 사용할 수 있습니다.
두번째 내용은 분할 영역을 마운트할 마운트 지점을 나타냅니다
세번째 내용은 분할 영역에서 사용하는 파일 시스템을 나타냅니다
네번째 내용은 분할 영역을 마운트할 때 mount에서 사용하는 마운트 옵션을 나타냅니다. 모든 분할 영역에는 자체 마운트 옵션이 있기에 옵션 전체 목록을 알아보려면 mount 맨 페이지(man mount)를 읽어보시는게 좋겠습니다. 여러가지 마운트 옵션은 콤마로 구분합니다.
다섯번째 내용은 분할 영역 덤프를 남겨둔지 여부를 나타냅니다. 보통 0(영)으로 남겨둡니다.
여섯번째 내용은 시스템을 제대로 된 과정을 거쳐 끄지 못했을 때 fsck에서 파일 시스템을 점검할 순서를 나타냅니다. 루트 파일 시스템은 1이어야 하며 나머지는 2가 되어야 합니다(점검이 필요하지 않다면 0으로 남겨둡니다).

중요
젠투에서 제공하는 기본 /etc/fstab 파일은 올바른 fstab 파일이 아니지만, 양식 내용이 좀 더 자세하게 들어있습니다.

root #nano -w /etc/fstab

DOS/Legacy BIOS systems

/boot/ 분할 영역에 대한 옵션을 적어가는 방법을 살펴보도록 하겠습니다. 단지 예제일 뿐이며 설치 과정에서 결정한 공간 분할 형태에 따라 바꾸어야합니다.

amd64 분할 영역 예제에서, /boot/는 보통 ext2 파일 시스템을 쓰는 /dev/sda1 분할 영역입니다. 부팅 과정에 검사해야 하기 때문에 다음의 대용으로 적어내려가겠습니다:

파일 /etc/fstab/etc/fstab의 /boot 줄 예제

/dev/sda1 /boot ext2 defaults 0 2

어떤 사용자는 시스템의 보안을 개선하려는 이유로 /boot/ 분할 영역을 자동으로 마운트하려 하지 않습니다. 이러한 사용자는 defaults를 noauto로 바꾸어야합니다. 이 옵션은 해당 분할 영역을 사용하려고 할 때마다 직접 마운트해야 함을 의미합니다.

이전에 결정한 분할 영역 모양새에 따라 규칙을 추가하시고, CD-ROM 드라이브라든지, 물론, 다른 분할 영역과 드라이브도 사용한다면 해당 장치도 추가하십시오.

좀 더 내용을 추가한 /etc/fstab 파일 예제는 다음과 같습니다:

파일 /etc/fstab/etc/fstab 전체 예제

/dev/sda1   /boot        ext2    defaults,noatime     0 2
/dev/sda2   none         swap    sw                   0 0
/dev/sda3   /            ext4    noatime              0 1
  
/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

/dev/cdrom /mnt/cdrom auto noauto,user 0 0 }}

UEFI systems

Below is an example of an /etc/fstab file for a system that will boot via UEFI firmware:

파일 /etc/fstabA full /etc/fstab example for an UEFI system

# Adjust for any formatting differences and/or additional partitions created from the "Preparing the disks" step
/dev/sda1   /efi        vfat    umask=0077     0 2
/dev/sda2   none         swap    sw                   0 0
/dev/sda3   /            xfs    defaults,noatime              0 1
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
/dev/cdrom  /mnt/cdrom   auto    noauto,user          0 0

DPS UEFI PARTUUID

Below is an example of an /etc/fstab file for a disk formatted with a GPT disklabel and Discoverable Partition Specification (DPS) UUIDs set for UEFI firmware:

파일 /etc/fstabDPS PARTUUID fstab example

# Adjust any formatting difference and additional partitions created from the "Preparing the disks" step.
# This example shows a GPT disklabel with Discoverable Partition Specification (DSP) UUID set:
PARTUUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b   /efi        vfat    umask=0077                   0 2
PARTUUID=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f   none        swap    sw                           0 0
PARTUUID=4f68bce3-e8cd-4db1-96e7-fbcaf984b709   /           xfs     defaults,noatime             0 1

세번째 내용에 auto를 사용하면 mount 명령에서 파일시스템에 처리해야 할 방식을 짐작하여 처리합니다. 여러 파일 시스템을 만들 수 있는 이동식 미디어에 추천합니다. 네번째에 user를 넣으면 비-루트 사용자도 CD에 마운트할 수 있습니다.

To improve performance, most users would want to add the noatime mount option, which results in a faster system since access times are not registered (those are not needed generally anyway). This is also recommended for systems with solid state drives (SSDs). Users may wish to consider lazytime instead.

요령
Due to degradation in performance, defining the discard mount option in /etc/fstab is not recommended. It is generally better to schedule block discards on a periodic basis using a job scheduler such as cron or a timer (systemd). See Periodic fstrim jobs for more information.

/etc/fstab 파일을 다시 확인하시고, 저장하고 빠져나가서 다음 단계를 계속 진행하십시오.

네트워크 정보

It is important to note the following sections are provided to help the reader quickly setup their system to partake in a local area network.

For systems running OpenRC, a more detailed reference for network setup is available in the advanced network configuration section, which is covered near the end of the handbook. Systems with more specific network needs may need to skip ahead, then return here to continue with the rest of the installation.

For more specific systemd network setup, please review see the networking portion of the systemd article.

호스트, 도메인 정보

사용자가 처리할 수 있는 선택중 하나는 PC의 이름을 부여하는 것입니다. 조금 쉬워보이긴 합니다만 리눅스 PC에 적당한 이름을 찾기란 대부분의 사용자에겐 어렵습니다. 빨리 넘어가기 위해 이 결정이 끝이 아님을 알아두십시오. 나중에 바꿀 수 있습니다. 아래 예제에서는 "homenetwork" 도메인에서 "tux" 호스트이름을 사용함을 보여줍니다.

Set the hostname (OpenRC or systemd)

root #echo tux > /etc/hostname

systemd

To set the system hostname for a system currently running systemd, the hostnamectl utility may be used. During the installation process however, systemd-firstboot command must be used instead (see later on in handbook).

For setting the hostname to "tux", one would run:

root #hostnamectl hostname tux

View help by running hostnamectl --help or man 1 hostnamectl.

Network

There are many options available for configuring network interfaces. This section covers a only a few methods. Choose the one which seems best suited to the setup needed.

DHCP via dhcpcd (any init system)

Most LAN networks operate a DHCP server. If this is the case, then using the dhcpcd program to obtain an IP address is recommended.

To install:

root #emerge --ask net-misc/dhcpcd

To enable and then start the service on OpenRC systems:

root #

rc-update add dhcpcd default

root #

rc-service dhcpcd start

To enable the service on systemd systems:

root #systemctl enable dhcpcd

With these steps completed, next time the system boots, dhcpcd should obtain an IP address from the DHCP server. See the Dhcpcd article for more details.

netifrc (OpenRC)

요령
This is one particular way of setting up the network using Netifrc on OpenRC. Other methods exist for simpler setups like Dhcpcd.

네트워크 설정

젠투 리눅스 설치 과정에서 네트워크를 거의 설정했습니다만 설치 CD 자체에서의 설정이었으며 설치한 환경에 대한 설정은 아니었습니다. 이제 네트워크 설정을 설치한 젠투 리눅스 시스템에 만들겠습니다.

참고
본딩, 브릿징, 802.1Q VLAN, 무선 네트워크를 다루는 네트워크에 대한 자세한 내용은 젠투 네트워크 설정 절에서 다룹니다.

모든 네트워크 정보를 /etc/conf.d/net에서 가져왔습니다. 별로 직관적이지 않은것 같은 간단한 문법을 사용합니다. 그러나 두려워 하실 일이 없습니다. 모든 내용은 아래에 설명해드립니다. 여러가지 설정을 다루는 자세한 설명 예제는 /usr/share/doc/netifrc-*/net.example.bz2에 있습니다.

먼저 net-misc/netifrc를 설치하십시오:

root #emerge --ask --noreplace net-misc/netifrc

기본적으로 DHCP를 사용합니다. DHCP를 동작하게 하려면 DHCP 클라이언트를 설치해야합니다. 필요한 시스템 도구 설치 편에서 설명하겠습니다.

DHCP 별개 옵션 때문이거나, DHCP를 모든 컴퓨터에서 쓸 수 있는게 아니어서 네트워크 연결을 설정해야한다면 /etc/conf.d/net 파일을 여십시오:

root #nano -w /etc/conf.d/net

config_eth0 와 routes_eth0 변수에 IP 주소 정보와 라우팅 정보를 입력하여 설정하십시오:

참고
여기서는 eth0 네트워크 인터페이스로 가정합니다. 그러나 이 이름이 시스템에 따라 다릅니다. 설치 매체가 최근의 것이라면 설치 매체로 부팅했을 때 나타나는 인터페이스 이름과 동일하다고 가정함을 추천합니다.

파일 /etc/conf.d/net고정 IP 정의

config_eth0="192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255"
routes_eth0="default via 192.168.0.1"

DHCP를 사용하려면, config_eth0를 정의하십시오:

파일 /etc/conf.d/netDHCP 정의

config_eth0="dhcp"

존재하는 모든 옵션을 보려면 /usr/share/doc/netifrc-*/net.example.bz2를 읽어보십시오. DHCP 옵션을 설정해야 한다면 DHCP 클라이언트 맨 페이지도 읽어보십시오.

시스템에 여러가지 네트워크 인터페이스를 달고 있다면, config_eth1, config_eth2 등에 대해 위 과정을 반복하십시오.

이제 설정을 저장하고 빠져나간 후 다음 과정으로 계속 진행하십시오.

부팅 과정에서 네트워크 자동으로 시작하기

부팅 과정에서 네트워크 인터페이스를 활성화하려면, 기본 실행 레벨에 추가해야합니다.

root #

cd /etc/init.d

root #

ln -s net.lo net.eth0

root #rc-update add net.eth0 default

시스템에 여러가지 네트워크 인터페이스가 있다면 net.eth0 처럼 적당한 net.* 파일을 만들어야합니다.

다음에 시스템을 부팅하면 네트워크 인터페이스 이름(현재 문서에 남긴 이름은 eth0)의 가정이 틀렸음을 알아챌 것입니다. 이 문제를 바로잡으려면 다음 단계를 따라 처리하십시오:

(eth0 대신 enp3s0같이) 올바른 인터페이스 이름으로 /etc/conf.d/net 파일을 업데이트하십시오
새 심볼릭 링크를 만드십시오(/etc/init.d/net.enp3s0)
이전 심볼릭 링크를 제거하십시오(rm /etc/init.d/net.eth0)
새로 만든 심볼릭 링크를 기본 실행 레벨에 추가하십시오
이전 심볼릭 링크를 rc-update del net.eth0 default 명령으로 제거하십시오

hosts 파일

다음은 네트워크 환경을 리눅스에 알려야 합니다. /etc/hosts 에서 정의하며, 이름 서버에서 해석할 수 없는 호스트에서 호스트의 이름을 IP 주소로 바꾸는 과정을 돕습니다.

root #nano -w /etc/hosts

파일 /etc/hosts네트워크 정보 채우기

# This defines the current system and must be set
127.0.0.1     tux.homenetwork tux localhost
  
# Optional definition of extra systems on the network
192.168.0.5   jenny.homenetwork jenny
192.168.0.6   benny.homenetwork benny

편집기에서 저장하고 빠져나가서 다음 과정을 계속 진행하십시오.

시스템 정보

루트 암호

passwd 명령으로 루트 암호를 설정하십시오.

root #passwd

루트 리눅스 계정은 가장 강력한 계정이므로 강력한 암호를 선택해야 합니다. 나중에 매일 사용할 일반 사용자 계정을 추가로 만듭니다.

Init와 부팅 설정

OpenRC

(최소한 OpenRC를 쓸 때)젠투에서 서비스와 시스템의 시작과 마침 과정을 설정할 때 /etc/rc.conf 파일을 활용합니다. /etc/rc.conf 파일을 열고 파일의 모든 주석을 맘대로 제거하십시오. 필요한 부분의 설정을 다시 살펴보고 바꾸십시오.

root #nano -w /etc/rc.conf

그 다음 /etc/conf.d/keymaps 파일을 열어 키보드 설정을 처리하십시오. 해당 파일을 편집하여 올바른 키보드를 선택하고 설정하십시오.

root #nano -w /etc/conf.d/keymaps

keymap 변수는 특히 조심스럽게 다루십시오. 잘못된 키맵을 선택하면 키보드로 입력할 때, 이상한 결과가 나타납니다.

마지막으로 시계 옵션을 설정하려 /etc/conf.d/hwclock 파일을 편집하겠습니다. 개인 취향에 맞춰 편집하십시오.

root #nano -w /etc/conf.d/hwclock

하드웨어 클록에서 UTC 방식을 사용하지 않는다면, 파일에 clock="local"를 설정해야 합니다. 그렇지 않으면 시스템의 시계 동작이 꼬이는 일이 생깁니다.

systemd

First, it is recommended to run systemd-machine-id-setup and then systemd-firstboot which will prepare various components of the system are set correctly for the first boot into the new systemd environment. The passing the following options will include a prompt for the user to set a locale, timezone, hostname, root password, and root shell values. It will also assign a random machine ID to the installation:

root #systemd-machine-id-setup

root #systemd-firstboot --prompt

Next users should run systemctl to reset all installed unit files to the preset policy values:

root #systemctl preset-all --preset-mode=enable-only

It's possible to run the full preset changes but this may reset any services which were already configured during the process:

root #systemctl preset-all

These two steps will help ensure a smooth transition from the live environment to the installation's first boot.

← 리눅스 커널 설정 처음 시스템 도구 설치 →

시스템 로거

OpenRC

스테이지 3 아카이브에서 몇가지 도구가 빠졌는데 대부분 꾸러미가 동일한 기능을 지니고 있기 때문입니다. 이제 설치할 도구를 선택하는건 사용자의 몫입니다.

첫번째로 결정해야 할 도구는 시스템 로깅 수단을 제공합니다. 유닉스 및 리눅스는 로깅 능력에 있어 멋진 역사를 지니고 있습니다 - 필요하다면, 로그 파일에 시스템에 일어나는 모든 일을 기록할 수 있습니다. 이 일은 시스템 로거가 처리합니다.

젠투는 선택할 다양한 시스템 로거를 제공합니다. 그 중 몇가지가 있다면:

app-admin/sysklogd - 시스템 로깅 데몬의 기존 모음입니다. 초보자를 배려하여 기본 로깅 설정으로도 그 자체로 특별하게 잘 동작합니다.
app-admin/syslog-ng - 최근의 시스템 로거입니다. 하나의 큰 파일이 아닌 다른 방식으로 로깅하려면 추가 설정이 필요합니다. 좀 더 능력있는 사용자라면 로깅 잠재 기능때문에 이 꾸러미를 사용합니다. 지능 로깅 동작은 추가 설정이 필요합니다.
app-admin/metalog - 매우 설정하기 쉬운 시스템 로거

마찬가지로 포티지에 다른 다양한 로거가 존재합니다. 수많은 꾸러미는 매일 늘어납니다.

요령
sysklogd 또는 syslog-ng를 사용하려 한다면, 시스템 로거가 로그 파일에 대한 순환 매커니즘을 제공하지 않으므로, 이들 꾸러미를 설치한 후 logrotate를 설치 및 설정하는 것이 좋습니다.

선택한 시스템 로거를 설치하려면, emerge후, rc-update를 사용하여 기본 런레벨에 추가해야합니다. 다음 예제에서는 app-admin/sysklogd를 설치합니다:

root #emerge --ask app-admin/sysklogd

root #rc-update add sysklogd default

systemd

While a selection of logging mechanisms are presented for OpenRC-based systems, systemd includes a built-in logger called the systemd-journald service. The systemd-journald service is capable of handling most of the logging functionality outlined in the previous system logger section. That is to say, the majority of installations that will run systemd as the system and service manager can safely skip adding a additional syslog utilities.

See man journalctl for more details on using journalctl to query and review the systems logs.

For a number of reasons, such as the case of forwarding logs to a central host, it may be important to include redundant system logging mechanisms on a systemd-based system. This is a irregular occurrence for the handbook's typical audience and considered an advanced use case. It is therefore not covered by the handbook.

선택: 크론 데몬

OpenRC

다음은 크론 데몬입니다. 설치를 해도 안해도 그만이며, 모든 시스템에서 설치할 필요는 없지만, 설치하는게 현명합니다.

크론 데몬은 일정별로 계획한 명령을 실행합니다. 규칙적으로(예를 들어 매일, 주별, 월별) 실행할 필요가 있는 명령에 대해 매우 간편합니다.

All cron daemons support high levels of granularity for scheduled tasks, and generally include the ability to send an email or other form of notification if a scheduled task does not complete as expected.

젠투는 sys-process/bcron, sys-process/dcron, sys-process/fcron, sys-process/cronie 등의 다양한 크론 데몬을 제공합니다. 이들 중 하나를 설치하는 건 시스템 로거를 설치할 때와 마찬가지입니다. 다음 예제에서는 sys-process/cronie를 설치합니다:

sys-process/cronie - cronie is based on the original cron and has security and configuration enhancements like the ability to use PAM and SELinux.
sys-process/dcron - This lightweight cron daemon aims to be simple and secure, with just enough features to stay useful.
sys-process/fcron - A command scheduler with extended capabilities over cron and anacron.
sys-process/bcron - A younger cron system designed with secure operations in mind. To do this, the system is divided into several separate programs, each responsible for a separate task, with strictly controlled communications between parts.

cronie

The following example uses sys-process/cronie:

root #emerge --ask sys-process/cronie

root #rc-update add cronie default

Alternative: dcron

root #emerge --ask sys-process/dcron

dcron또는 fcron을 사용한다면, 추가 초기화 명령을 실행해야합니다:

root #crontab /etc/crontab

Alternative: fcron

root #emerge --ask sys-process/fcron

If fcron is the selected scheduled task handler, an additional emerge step is required:

root #emerge --config sys-process/fcron

Alternative: bcron

bcron is a younger cron agent with built-in privilege separation.

root #emerge --ask sys-process/bcron

systemd

Similar to system logging, systemd-based systems include support for scheduled tasks out-of-the-box in the form of timers. systemd timers can run at a system-level or a user-level and include the same functionality that a traditional cron daemon would provide. Unless redundant capabilities are necessary, installing an additional task scheduler such as a cron daemon is generally unnecessary and can be safely skipped.

선택: 파일 색인

파일 시스템을 색인 처리하여 파일 탐색을 더 빠르게 하려면 sys-apps/mlocate를 설치하십시오.

root #emerge --ask sys-apps/mlocate

선택: 원격 접근

요령
opensshd's default configuration does not allow root to login as a remote user. Please create a non-root user and configure it appropriately to allow access post-installation if required, or adjust /etc/ssh/sshd_config to allow root.

설치 후 시스템을 원격으로 접근하려면, 기본 런레벨에 sshd 초기화 스크립트를 추가하십시오:

OpenRC

root #rc-update add sshd default

직렬 콘솔 접근이 필요하다면 (원격 서버의 경우 가능) /etc/inittab에서 직렬 콘솔 섹션의 주석 표시를 빼십시오:

Uncomment the serial console section in /etc/inittab:

root #nano -w /etc/inittab

# SERIAL CONSOLES
s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100
s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100

systemd

To enable the SSH server, run:

root #systemctl enable sshd

To enable serial console support, run:

root #systemctl enable getty@tty1.service

Optional: Shell completion

Bash

Bash is the default shell for Gentoo systems, and therefore installing completion extensions can aid in efficiency and convenience to managing the system. The app-shells/bash-completion package will install completions available for Gentoo specific commands, as well as many other common commands and utilities:

root #emerge --ask app-shells/bash-completion

Post installation, bash completion for specific commands can managed through eselect. See the Shell completion integrations section of the bash article for more details.

Time synchronization

It is important to use some method of synchronizing the system clock. This is usually done via the NTP protocol and software. Other implementations using the NTP protocol exist, like Chrony.

To set up Chrony, for example:

root #emerge --ask net-misc/chrony

OpenRC

On OpenRC, run:

root #rc-update add chronyd default

systemd

On systemd, run:

root #systemctl enable chronyd.service

Alternatively, systemd users may wish to use the simpler systemd-timesyncd SNTP client which is installed by default.

root #systemctl enable systemd-timesyncd.service

파일 시스템 도구

사용하는 파일 시스템에 따라 필요한 파일 시스템 유틸리티를 설치해야 합니다(파일 시스템 무결성 검사, 추가 파일 시스템 만들기 등). ext2, ext3, ext4 파일 시스템(sys-fs/e2fsprogs)을 관리하는 도구는 이미 @system 세트의 일부로 설치했음을 참고하십시오.

다음 테이블 목록에서는 각각의 파일 시스템을 사용할 경우 설치할 도구를 보여줍니다:

파일 시스템	꾸러미
Ext2, 3, and 4	sys-fs/e2fsprogs
XFS	sys-fs/xfsprogs
ReiserFS	sys-fs/reiserfsprogs
JFS	sys-fs/jfsutils
VFAT (FAT32, ...)	sys-fs/dosfstools
Btrfs	sys-fs/btrfs-progs

It's recommended that sys-block/io-scheduler-udev-rules is installed for the correct scheduler behavior with e.g. nvme devices:

root #emerge --ask sys-block/io-scheduler-udev-rules

요령
자세한 젠투 파일 시스템 정보를 보려면 파일 시스템 게시글을 살펴보십시오.

네트워크 도구

추가 네트워크 도구가 필요하지 않으면 부트로더 설정으로 바로 계속 진행하십시오.

DHCP 클라이언트 설치

중요
여러분의 선택에 달려있긴 하지만, 네트워크에 접속하는 대부분의 사용자는 DHCP 서버에 연결하는 DHCP 클라이언트가 필요합니다. DHCP 클라이언트를 설치하십시오. 이 단계를 잊고 넘어간다면, 시스템이 네트워크에 참여할 수 없어, 나중에 DHCP 클라이언트를 다운로드하고 설치할 수 없습니다.

netifrc 스크립트로 시스템에 있는 하나 이상의 네트워크 인터페이스에서 IP 주소를 자동으로 가져오도록 하려면 DHCP 클라이언트를 설치해야합니다. 젠투 저장소상에 다른 DHCP 클라이언트도 있지만, net-misc/dhcpcd 클라이언트를 추천합니다:

root #emerge --ask net-misc/dhcpcd

선택: PPPoE 클라이언트 설치

인터넷에 연결할 때 PPP를 사용한다면 net-dialup/ppp 꾸러미를 설치하십시오:

root #emerge --ask net-dialup/ppp

추가: 무선 네트워킹 도구 설치

시스템을 무선 네트워크에 연결하려면, 공개/WEP 네트워크에 연결할 net-wireless/iw 꾸러미를 설치하거나, WPA/WPA2 네트워크에 연결할 net-wireless/wpa_supplicant 꾸러미를 설치하십시오. iw 명령은 무선 네트워크를 검색하는 기본 진단 도구로서 쓸만합니다.

root #emerge --ask net-wireless/iw net-wireless/wpa_supplicant

이제 부트로더 설정으로 계속 진행하십시오.

← 시스템 설정 처음 부트로더 설정 →

부트로더 선택

리눅스 커널을 설정하고, 시스템 도구를 설치하고, 설정 파일을 편집하고 나면, 리눅스 설치의 일부로서 마지막으로 중요한 부분, 부트로더를 설치할 차례입니다.

부트로더는 부팅 과정에서 리눅스 커널의 실행을 담당합니다. 부트로더가 없으면 시스템에서는 전원 단추를 누른 후 그 다음 과정을 어떻게 처리해야 할지 모릅니다.

amd64에서는 BIOS 기반 시스템에서 GRUB2 또는 LILO를 설정하는 방법, UEFI 시스템에서 GRUB2 또는 efibootmgr을 사용하는 방법을 문서에 남겨두었습니다.

여기서는 부트로더 꾸러미를 이머징하고 시스템 디스크에 부트로더를 설치하는 방법을 설명합니다. 이머징은 시스템에서 활용할 수 있는 프로그램 꾸러미를 Portage에 만들려고 요청할 때 활용합니다. 설치는 다음에 전원을 다시 켰을 때 부트로더를 활성화한 후 동작 대기 상태로 두도록 시스템 디스크 드라이브의 적당한 부분에 파일을 복사하거나 물리적으로 수정함을 의미합니다.

기본: GRUB2

기본적으로, 젠투 시스템에서는 기존 GRUB을 그대로 이어가는 GRUB2(sys-boot/grub)로 의존 대세가 바뀌었습니다. 설정을 추가로 하지 않아도 이전 BIOS("pc") 시스템을 기꺼이 지원합니다. 빌드 이전에 필요한 일부 설정으로 여러 추가 플랫폼을 지원할 수 있습니다. 자세히 알아보시려면 GRUB 게시글의 선행 과정 부분을 참고하십시오.

Emerge

MBR 분할 영역 테이블만 지원하는 이전 BIOS 시스템을 활용한다면 GRUB을 이머징할 때 추가로 설정할 필요가 없습니다:

root #emerge --ask --verbose sys-boot/grub:2

UEFI 사용자 참고사항: 위 명령을 실행하면 이머징을 시작하기 전 GRUB_PLATFORMS 활성 변수 값을 나타냅니다. UEFI 기능이 동작하는 시스템을 활용한다면, 해당 사용자는 GRUB_PLATFORMS="efi-64"(기본적인 고려 사항)값을 넣었는지 확인해야합니다. 설치 과정에 이 값이 나타나지 않은 경우라면 GRUB2를 이머징하기 전 /etc/portage/make.conf 파일에 GRUB_PLATFORMS="efi-64" 값을 추가하여, GRUB2에 EFI 기능을 넣어 빌드할 수 있게 해야합니다.

root #echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.conf

root #emerge --ask sys-boot/grub:2

(위에서와 같이) make.conf에 GRUB_PLATFORMS="efi-64"를 활성화하지 않고 GRUB2를 이머지했다 하더라도 나중에 해당 줄을 추가할 수 있고, emerge에 --update --newuse 옵션을 전달하여 전체 꾸러미 모음^en의 의존성을 다시 처리할 수 있습니다.

root #emerge --ask --update --newuse --verbose sys-boot/grub:2

이제 GRUB2 프로그램을 이머징했지만, 설치한 상태는 아닙니다.

설치

다음, /boot/grub/에 필요한 GRUB2 파일을 grub-install 명령으로 설치할 차례입니다. 첫번째 디스크(부팅할 디스크)를 /dev/sda라고 가정하고, 다음 명령중 하나로 GRUB2 파일을 설치합니다:

BIOS를 사용하면:

root #grub-install /dev/sda

For DOS/Legacy BIOS systems:

root #grub-install /dev/sda

UEFI를 사용하면:

중요
grub-install을 실행하기 전 EFI 시스템 공간을 마운트 했는지 확인하십시오. grub-install 프로그램이 잘못된 디렉터리를 사용한 "어떤" 설정 내지는 표시 없이 잘못된 디렉터리의 GRUB EFI 파일(grubx64.efi)로 설치할 수 있습니다.

For UEFI systems:

root #grub-install --target=x86_64-efi --efi-directory=/boot

Upon successful installation, the output should match the output of the previous command. If the output does not match exactly, then proceed to Debugging GRUB, otherwise jump to the Configure step.

Optional: Secure Boot

The sys-boot/grub package does not recognize the secureboot USE flag, this is because the GRUB EFI executable is not installed by the package but is instead built and installed by the grub-install command. GRUB must therefore be manually signed after installation to the boot partition. Additionally, GRUB is a modular bootloader but loading modules is prohibited when Secure Boot is enabled. Therefore all necessary modules must be compiled into the GRUB EFI executable, below an example is shown including some basic modules, this may have to be adjusted for more advanced configurations:

root #emerge --noreplace sbsigntools

root #

export GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label sleep smbios squash4 test true video xfs zfs zfscrypt zfsinfo"

root #grub-install --target=x86_64-efi --efi-directory=/efi --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv

root #

sbsign /efi/EFI/GRUB/grubx64.efi --key /path/to/kernel_key.pem --cert /path/to/kernel_key.pem --out /efi/EFI/GRUB/grubx64.efi

To successfully boot with secure boot enabled the used certificate must either be accepted by the UEFI firmware, or shim must be used as a pre-loader. Shim is pre-signed with the third-party Microsoft Certificate, accepted by default by most UEFI motherboards.

How to configure the UEFI firmware to accept custom keys depends on the firmware vendor, which is beyond the scope of the handbook. Below is shown how to setup shim instead:

root #emerge sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/GRUB/shimx64.efi

root #cp /usr/share/shim/mmx64.efi /efi/EFI/GRUB/mmx64.efi

Shims MOKlist requires keys in the DER format, since the OpenSSL key generated in the example here is in the PEM format, the key must be converted first:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

참고
The path used here must be the path to the pem file containing the certificate belonging to the generated key. In this example both key and certificate are in the same pem file.

Then the converted certificate can be imported into Shims MOKlist:

root #mokutil --import /path/to/kernel_key.der

And finally we register Shim with the UEFI firmware. In the following command, boot-disk and boot-partition-id must be replaced with the disk and partition identifier of the EFI system partition:

root #

efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\GRUB\shimx64.efi' --label 'shim' --unicode

Debugging GRUB

When debugging GRUB, there are a couple of quick fixes that may result in a bootable installation without having to reboot to a new live image environment.

In the event that "EFI variables are not supported on this system" is displayed somewhere in the output, it is likely the live image was not booted in EFI mode and is presently in Legacy BIOS boot mode. The solution is to try the removable GRUB step mentioned below. This will overwrite the executable EFI file located at /EFI/BOOT/BOOTX64.EFI. Upon rebooting in EFI mode, the motherboard firmware may execute this default boot entry and execute GRUB.

중요
grub-install 에서 Could not prepare Boot variable: Read-only file system와 같은 오류가 나타났을 경우, 과정을 제대로 넘어가기 위해 efivars 특수 마운트 지점을 다시 마운트 해야합니다:

root #mount -o remount,rw /sys/firmware/efi/efivars

root #mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivars

This is caused by certain non-official Gentoo environments not mounting the special EFI filesystem by default. If the previous command does not run, then reboot using an official Gentoo live image environment in EFI mode.

일부 마더보드 제조사에서는 .EFI 파일을 저장할 EFI 시스템 파티션(ESP)의 디렉터리 위치 경로를 /efi/boot/ 디렉터리만 지원하는 것 같습니다. GRUB 설치 관리자에서는 --removable 옵션을 주어 자동으로 처리할 수 있습니다. 다음 명령을 실행하기 전에 ESP를 마운트했는지 확인하십시오. (앞서 말한대로) /boot에 ESP를 마운트했다고 생각한다면, 다음 명령을 실행하십시오:

root #grub-install --target=x86_64-efi --efi-directory=/boot --removable

이 명령은 UEFI 명세로 정의한 기본 디렉터리를 만들고 grubx64.efi 파일을 동일한 명세로 정의한 '기본' EFI 파일 위치에 복사합니다.

설정

다음, /etc/default/grub 파일과 /etc/grub.d 스크립트를 기반으로 정의한 사용자 설정을 기반으로 하여 GRUB2 설정을 만드십시오. GRUB2에서 어떤 커널로 부팅할지 (/boot/에 존재하는 가장 최신의 버전), 루트 파일 시스템이 어디인지 자동으로 찾기 때문에 사용자가 직접 설정할 필요가 없습니다. /etc/default/grub 의 GRUB_CMDLINE_LINUX 변수에 커널 매개 변수를 넣을 수도 있습니다.

최종 GRUB2 설정을 만들려면 grub-mkconfig 명령을 실행하십시오:

root #grub-mkconfig -o /boot/grub/grub.cfg

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-6.6.21-gentoo
Found initrd image: /boot/initramfs-genkernel-amd64-6.6.21-gentoo
done

명령 출력은 최소한 시스템 부팅에 필요한 하나의 리눅스 이미지를 찾았다는 알림이 나와야 합니다. initramfs를 사용했거나, 커널 빌드시 genkernel를 사용했다면, 마찬가지로 올바른 initrd 이미지를 찾아야 합니다. 이런 경우가 아니라면 /boot/로 이동해서 ls 명령으로 내용을 확인해보십시오. 여전히 파일이 빠졌다면, 커널 설정으로 되돌아가서 설치 절차를 따르십시오.

요령
os-prober 유틸리티로 붙어있는 드라이브에서 다른 우영체제를 찾아 붙일 수 있습니다. 윈도우 7, 8.1, 10, 그리고 다른 리눅스 배포판을 찾을 수 있습니다. 듀얼 부팅 시스템을 원한다면 sys-boot/os-prober 꾸러미를 설치하고 grub-mkconfig 명령을 (위에서 보신 것처럼) 다시 실행하십시오. 운영체제를 찾는 과정에 문제가 있다면, 젠투 커뮤니티에 지원을 요청하기 전 GRUB 게시글을 다시 확인하십시오.

대안 1: LILO

Emerge

LInuxLOader LILO는 검증되고 본 기능에 충실한 리눅스 부트로더입니다. 그러나 GRUB에 비하면 부족한 측면도 있습니다. LILO를 그래도 사용하는 이유는, 일부 시스템에서 GRUB이 처리할 수 없는 동작을 LILO에서 처리할 수 있기 때문입니다. 물론, 일부 사용자가 여전히 LILO에 집착하기 때문이기도 합니다. 어쨌든간에 젠투는 두 부트로더를 다 지원합니다.

LILO 설치는 순식간입니다. 그냥 emerge 명령을 사용하십시오.

root #emerge --ask sys-boot/lilo

설정

LILO를 설정하려면, 먼저 /etc/lilo.conf 파일을 만드십시오:

root #nano -w /etc/lilo.conf

설정 파일에서 부팅 커널을 참조할 섹션을 사용합니다. 이 설정 파일에서 참조하려는 커널 파일(및 커널 버전)과 initramfs 파일을 알아내십시오.

참고
루트 파일 시스템이 JFS라면, 각각의 부팅 항목 다음에 append="ro"를 추가하여 읽기 쓰기 마운팅이 가능하기 전에 JFS에서 로그 작성을 제고하도록 하십시오

파일 /etc/lilo.confLILO 설정 예제

'"`UNIQ--pre-0000013E-QINU`"'

참고
다른 분할 배치 형식을 사용하거나 다른 커널 이미지를 사용한다면, 그에 맞게 조절하십시오.

initramfs가 필요하다면, 이 initramfs 파일을 참고하여 설정을 바꾸고 initramfs에게 실제 루트 장치가 어디있는지 알려주십시오:

파일 /etc/lilo.conf부팅 항목에 initramfs 정보 추가

'"`UNIQ--pre-00000141-QINU`"'

추가 옵션을 커널에 전달해야 한다면 append 구문을 사용하십시오. 예를 들어 프레임버퍼를 활성화할 video 구문을 추가하려면:

파일 /etc/lilo.conf부팅 옵션에 비디오 매개 변수 추가

'"`UNIQ--pre-00000144-QINU`"'

genkernel을 사용한 사용자는 설치 CD에서 사용한 부팅 옵션과 동일한 옵션을 커널에 사용함을 알아야합니다. 예를 들어 SCSI 장치 활성화가 필요하다면 doscsi를 커널 옵션으로 추가합니다.

이제 파일을 저장하고 빠져나가십시오.

설치

과정을 마무리하려면, /sbin/lilo를 실행하여 LILO가 /etc/lilo.conf 설정을 시스템에 반영(디스크 자체에 설치)할 수 있게 하십시오. 커널 파일 이름을 바꾸고 시스템을 부팅하려면 커널을 새로 설치하거나 lilo.conf 파일을 바꿀 때마다 /sbin/lilo를 실행해야 함을 숙지하십시오.

root #/sbin/lilo

대안 2: efibootmgr

UEFI 기반 시스템에서는, 시스템의 UEFI 펌웨어(기본 부트 로더)에서 UEFI 부팅 항목을 직접 다룰 수 있습니다. 일부 시스템에서는 부팅할 때 GRUB2와 같은 추가(또는 차선) 부트로더가 필요하지 않습니다. 이 말은 결국, GRUB2 같은 EFI 기반 부트로더의 존재 이유가 바로 부팅 과정에서 UEFI 시스템 기능을 "확장"하는데 있습니다. efibootmgr를 사용하는 것이야말로(융통성이 없긴 하지만) 시스템 부팅 관점 접근 상 간소화를 원하는 이들에게 안성맞춤입니다. GRUB2(상부 참고)를 사용하는게 주로 사용자에게 더 쉬운 방법인데 UEFI 시스템을 부팅할 때 유연한 접근 방식을 취하기 때문입니다.

System administrators who desire to take a minimalist, although more rigid, approach to booting the system can avoid secondary bootloaders and boot the Linux kernel as an EFI stub.

sys-boot/efibootmgr 프로그램은 부트로더가 아님을 기억해두십시오. efibootmgr은 UEFI 펌웨어와 소통하고 UEFI 펌웨어 설정을 업데이트할 때 사용하는 도구이기 때문에 이전에 설치한 리눅스 커널을 (필요한 경우)추가 옵션을 통해 부팅할 수 있으며, 또는 다중 부팅 항목을 넣을 수 있습니다. 이러한 동작간 작용은 EFI 변수로 처리할 수 있습니다(따라서 이를 처리하기 전에 커널의 EFI 변수 지원이 필요합니다).

계속하기 전, EFI stub kernel 게시글을 우선 읽어두십시오. 시스템의 UEFI 펌웨어로 바로 부팅할 수 있게 커널의 몇가지 지정 옵션을 활성화해야합니다. 커널을 다시 컴파일 해야 할 수도 있습니다. efibootmgr 게시물을 살펴보시는 것도 좋습니다.

It is also a good idea to take a look at the efibootmgr article for additional information.

참고
다시 반복하지만, efibootmgr은 UEFI 시스템에서 부팅하는데 필수 요건이 아닙니다. 리눅스 커널 자체에서 즉시 부팅할 수 있으며, 추가 커널 명령행 옵션은 리눅스 커널 자체의 일부로 내장할 수 있습니다(사용자가 명령행에서 처럼 부팅 매개 변수를 지원하도록 호출할 수 있는 커널 설정 옵션이 있습니다). 심지어 initramfs도 커널 '그 자체'로 빌드할 수 있습니다.

이런 방식으로 진행하기로 마음먹었다면 프로그램을 설치해야합니다:

root #emerge --ask sys-boot/efibootmgr

그 다음 /boot/efi/boot/ 디렉터리를 만들고, 커널을 bzImage.efi 위치에 복사하십시오:

root #

mkdir -p /boot/efi/boot

root #

cp /boot/vmlinuz-* /boot/efi/boot/bzImage.efi

참고
UEFI 정의를 활용한다면 디렉터리 구분자로서 \ 사용은 필수입니다.

다음, 새로 컴파일한 EFI 커널로 부팅하는 "Gentoo" 항목을 UEFI 펌웨어에 적어주십시오:

root #efibootmgr --create --disk /dev/sda --part 2 --label "Gentoo" --loader "\efi\boot\bzImage.efi"

초기 램 파일 시스템(initramfs)를 사용한다면, 적당한 부팅 옵션을 추가하십시오:

root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l "\efi\boot\bzImage.efi" initrd='\initramfs-genkernel-amd64-6.6.21-gentoo'

Note that the above command presumes an initramfs file was copied into the ESP inside the same directory as the bzImage.efi file.

설정을 다 바꿨다면, 시스템을 다시 부팅할 때, 부팅 항목에 "Gentoo"가 뜹니다.

Unified Kernel Image

If installkernel was configured to build and install unified kernel images. The unified kernel image should already be installed to the EFI/Linux directory on the EFI system partition, if this is not the case ensure the directory exists and then run the kernel installation again as described earlier in the handbook.

To add a direct boot entry for the installed unified kernel image:

root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader /efi/EFI/Linux/gentoo-x.y.z.efi

대안 3: Syslinux

Syslinux는 amd64 아키텍처의 또 다른 대안 부트로더입니다. MBR을 지원하며 6.00부터는 EFI 부팅을 지원합니다. PXE(네트워크) 부팅과 잘 알려지지 않은 부팅 옵션도 지원합니다. Syslinux는 핸드북에서 지원하지 않는 다른 여러가지 아키텍처도 지원하는 유명한 부트로더이긴 합니다. 독자 여러분은 Syslinux 게시글을 따라 이 부트로더를 이머징하고 설치하여 정보를 찾아보실 수 있습니다.

Alternative 4: systemd-boot

Another option is systemd-boot, which works on both OpenRC and systemd machines. It is a thin chainloader and works well with secure boot.

To install systemd-boot:

root #bootctl install

중요
Make sure the EFI system partition has been mounted before running bootctl install.

When using this bootloader, before rebooting, verify that a new bootable entry exists using:

root #bootctl list

If no new entry exists, ensure the sys-kernel/installkernel package has been installed with the systemd-boot USE flag enabled, and re-run the kernel installation.

For the distribution kernels:

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

For a manually configured and compiled kernel:

root #make install

중요
When installing kernels for systemd-boot, no root= kernel command line argument is added by default. On systemd systems that are using an initramfs users may rely instead on systemd-gpt-auto-generator to automatically find the root partition at boot. Otherwise users should manually specify the location of the root partition by setting root= in /etc/kernel/cmdline as well as any other kernel command line arguments that should be used. And then reinstalling the kernel as described above.

Optional: Secure Boot

When the secureboot USE flag is enabled, the systemd-boot EFI executable will be signed automatically. bootctl install will automatically install the signed version.

To successfully boot with secure boot enabled the used certificate must either be accepted by the UEFI firmware, or shim must be used as a pre-loader. Shim is pre-signed with the third-party Microsoft Certificate, accepted by default by most UEFI motherboards.

How to configure the UEFI firmware to accept custom keys depends on the firmware vendor, which is beyond the scope of the handbook. A postinst hook to automatically update systemd-boot and set it up with shim instead is provided on the systemd-boot wiki page. However the first time this should be done manually by following the steps below:

root #emerge --ask sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/BOOT/BOOTX64.EFI

root #cp /usr/share/shim/mmx64.efi /efi/EFI/BOOT/mmx64.efi

root #cp /efi/EFI/systemd/systemd-bootx64.efi /efi/EFI/BOOT/grubx64.efi

참고
Shim is hardcoded to load grubx64.efi. As such the systemd-boot bootloader must be named as if it were GRUB.

Shims MOKlist requires keys in the DER format, since the OpenSSL key generated in the example here is in the PEM format, the key must be converted first:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

참고
The path used here must be the path to the pem file containing the certificate belonging to the generated key. In this example both key and certificate are in the same pem file.

Then the converted certificate can be imported into Shims MOKlist:

root #mokutil --import /path/to/kernel_key.der

And finally we register Shim with the UEFI firmware. In the following command, boot-disk and boot-partition-id must be replaced with the disk and partition identifier of the EFI system partition:

root #

efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\BOOT\BOOTX64.EFI' --label 'shim' --unicode

시스템 다시 부팅

chroot로 진입한 환경을 빠져나가고 모든 파티션의 마운트를 해제하십시오. 그 다음 대미를 장식할 마법의 명령을 입력하여, 실제로 시험해보십시오: reboot.

root #exit

cdimage ~#

cd

cdimage ~#

umount -l /mnt/gentoo/dev{/shm,/pts,}

cdimage ~#

umount -R /mnt/gentoo

cdimage ~#reboot

물론 부팅 CD를 제거하는걸 잊지 않으면 새 젠투 시스템 대신 CD로 부팅합니다.

새로 설치한 젠투 환경으로 다시 부팅하고 나면, 젠투 설치 마무리로 끝내십시오.

← 시스템 도구 설치 처음 마무리 →

사용자 관리

매일 사용할 사용자 추가

유닉스/리눅스 시스템에서의 루트 계정 취급은 위험하며, 가능한한 피해야 합니다. 따라서 매일 사용할 사용자의 추가를 강력히 권합니다.

그룹은 사용자가 구성원으로서 실행할 수 있는 활동을 정합니다. 다음 표 목록은 몇가지 중요한 그룹을 나타냅니다:

그룹	설명
audio	오디오 장치에 접근할 수 있습니다
cdrom	광 장치에 접근할 수 있습니다
floppy	플로피 장치에 접근할 수 있습니다
games	게임을 할 수 있습니다
portage	포티지 제한 자료에 접근할 수 있습니다
usb	USB 장치에 접근할 수 있습니다
video	비디오 캡처 하드웨어에 접근할 수 있으며 하드웨어 가속을 사용할 수 있습니다
wheel	su 명령을 사용할 수 있습니다

wheel, users, audio그룹의 구성원 larry를 만들려면 root로 우선 로그인한 후(루트 사용자만 사용자 계정을 만들 수 있음) useradd 명령을 실행하십시오.

Login:root

Password: (Enter the root password)

When setting passwords for standard user accounts, it is good security practice to avoid using the same or a similar password as set for the root user.

Handbook authors recommended to use a password at least 16 characters in length, with a value fully unique from every other user on the system.

root #

useradd -m -G users,wheel,audio -s /bin/bash larry

root #passwd larry

Password: (Enter the password for larry)
Re-enter password: (Re-enter the password to verify)

Temporarily elevating privileges

사용자가 루트 권한으로 몇가지 작업을 수행할 필요가 있다면, 임시로 루트 권한을 받기 위해 su - 명령을 사용할 수 있습니다. 다른 방법은 sudo 꾸러미를 사용하는 방법인데, 올바르게 설정했다면 매우 안전합니다.

Disabling root login

To prevent possible threat actors from logging in as root, deleting the root password and/or disabling root login can help improve security.

To disable root login:

root #passwd -l root

To delete the root password and disable login:

root #passwd -dl root

디스크 정리

타르볼 제거

젠투 설치가 끝나고 시스템을 다시 부팅한 후 모든 부분이 잘 끝났다면 이제 다운로드한 스테이지 3 타르볼을 하드 디스크에서 제거할 수 있습니다. / 디렉터리에 다운로드했음을 기억하십시오.

The files are located in the / directory and can be removed with the following command:

root #rm /stage3-*.tar.*

이제 어디로 갈까요

그 다음 어떻게 해야 할 지 모르겠다고요? 둘러볼 방향은 굉장히 다양합니다... 젠투에서는 사용자에게 무한한 가능성을 안겨주므로, 위키에는 문서로 만들 다양한 기능과 하위 주제가 있습니다(그리고 내용은 별로 없습니다) (하단 Gentoo online 섹션 참고).

문서

It is important to note that, due to the number of choices available in Gentoo, the documentation provided by the handbook is limited in scope - it mainly focuses on the basics of getting a Gentoo system up and running and basic system management activities. The handbook intentionally excludes instructions on graphical environments, details on hardening, and other important administrative tasks. That being stated, there are more sections of the handbook to assist readers with more basic functions.

독자 여러분은 프로그램을 최신으로 유지하고, 추가 프로그램 꾸러미를 설치하며, USE 플래그 사용 상세 내용, OpenRC 초기화 시스템, 그리고 젠투 시스템 설치 후 관리에 해당하는 다양하고 유익한 주제를 담은 젠투 핸드북의 다음 부분 젠투 다루기를 살펴보시는게 좋겠습니다.

이 핸드북 이외에도 젠투 커뮤니티 구성원이 주축이 되어 작성한 다양한 내용을 구석구석 찾아보시기 바랍니다. 젠투 위키 팀은 분류 별로 위키 게시글을 나열한문서 주제 개요를 제공합니다. 예를 들어 이 페이지에서는 사용할 시스템을 좀 더 내 집처럼 안락함을 느끼도록 만드는 지역화 안내서를 제공합니다.

The majority of users with desktop use cases will setup graphical environments in which to work natively. There are many community maintained 'meta' articles for supported desktop environments (DEs) and window managers (WMs). Readers should be aware that each DE will require slightly different setup steps, which will lengthen add complexity to bootstrapping.

Many other Meta articles exist to provide our readers with high level overviews of available software within Gentoo.

젠투 온라인

중요
독자 여러분은 온라인의 모든 젠투 사이트는 젠투 활동 지침을 따른다는 사실을 참고하십시오. 젠투 커뮤니티에서의 "왕성한 활동"은 당연한 권리가 아닌 특권이며, 사용자 여러분은 이런 이유로 활동 지침이 있음을 인지하셔야 합니다.

Freenode 에서 제공하는 인터넷 릴레이 대화(IRC) 네트워크와 메일링 리스트를 제외하고 젠투 웹사이트에서는 질문, 토론, 버그 제출에 계정이 필요합니다.

포럼 및 IRC

물론 젠투 포럼^en 또는 젠투 IRC 채널^en 어디든지 언제든 여러분을 환영합니다. 과거에 젠투를 새로 설치하다 누군가가 경험한 문제이며, 답변이 달린 게시글에 대해 포럼을 검색해보는 방법이 쉬운 방법 중 하나입니다. 젠투를 처음 설치하는 동안 마주친 문제를 다른 사용자도 경험했다는 사실은 그저 놀라울 수 있습니다. 젠투 지원 채널에서 도움을 요청하기 전 포럼을 검색하시는걸 추천합니다.

메일링 리스트

포럼 또는 IRC에 계정을 만들기보다 전자메일로 도움을 요청하는 방식을 선호하시는 분들을 위해 다양한 메일링 리스트^en 가 있습니다. 사용자 여러분께서 특정 메일링 리스트에 가입하시려면 다음 방법을 따라야합니다.

버그

위키를 검토하고나서 때때로는 문제에 대해 알려지지 않은 해결책에 대해 포럼을 검색하고, IRC 채널 또는 메일링 리스트에 지원을 구할 수 있습니다. 보통 이런 경우 젠투 버그질라 사이트를 찾아보시면 됩니다.

개발 지침

젠투를 개발하는 방법을 배워보려는 독자 여러분은 개발 안내서를 살펴보실 수 있습니다. 이 안내서에서는 ebuild, eclass를 다루는 방법을 설명하며, 젠투 개발 이전 여러가지 일반 개념을 다룹니다.

맺음말

젠투는 견고하고 유연하며, 관리가 상당히 잘 되는 배포판입니다. 개발자 커뮤니티는 젠투를 "더 나은" 배포판으로 만들어 나가기 위한 의견을 듣고 싶어합니다.

다시금 말씀드리지만, 지침을 따라야 하는 이 핸드북에 대한 피드백은 핸드북 처음의 어떻게 이 핸드북의 내용을 개선할 수 있을까요? 섹션에 있습니다.

우리는 젠투를 만들어가는 방향을 사용자가 어떻게 선택할 지를 내다보고 있습니다!

← 부트로더 설정 처음 포티지 소개 →

Warning: Display title "젠투 리눅스 amd64 핸드북: 젠투 설치" overrides earlier display title "Handbook:AMD64/Full/Installation/ko".

[1] ttps://gitweb.gentoo.org/proj/portage.git/commit/?id=de7be7f45ee54e3f789def46542919550687d15e

[4] ttps://www.gnu.org/licenses/license-list.html

[5] ttps://www.opensource.org/licenses

[6] ttps://www.gnu.org/philosophy/free-sw.html

[7] ttps://freedomdefined.org/

[8] ttps://www.gnu.org/licenses/license-list.html

[9] ttps://www.opensource.org/licenses

[10] ttps://www.gnu.org/philosophy/free-sw.html

[11] ttps://freedomdefined.org/

[2] ttps://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

[3] ttps://www.gentoo.org/glep/glep-0023.html#id7

[1]

[1]

[2]

[a_license 1]

[a_license 2]

[a_license 3]

[a_license 4]

[a_license 5]

[a_license 6]

[a_license 7]

[a_license 8]