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

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:PPC64/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 principal: 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을 볼 수 있습니다.





하드웨어 요구 사항

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


CPU PowerPC64 CPU
시스템 IBM RS/6000s, Power Macintosh G5, IBM p 시리즈와 IBM i 시리즈
메모리 64 MB
디스크 공간 1.5 GB (스왑 영역 제외)
스왑 영역 최소 256 MB

지원 시스템 전체 목록은 http://penguinppc.org/about/intro.php#hardwareen로 이동하여 참고하십시오.


젠투 리눅스 설치 미디어

요령
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-ppc64-minimal-<release>.iso 파일 이름을 지니고 있습니다.

예비 젠투 LiveDVD

간혹 젠투를 설치할 때 쓸 수 있도록 젠투 10 프로젝트에서 특별한 DVD를 손수 만듭니다. 이 장 다음의 내용은 소형 설치 CD를 대상으로 하기 때문에 약간 다를 수 있습니다. 그러나, LiveDVD(또는 다른 리눅스 부팅 환경)에서는 터미널에서 sudo su -를 실행하거나 sudo -i를 실행하여 루트 프롬프트를 띄우는 기능을 지원합니다.

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

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

스테이지 3 타르볼은 공식 젠투 미러en중 어디서든 releases/ppc64/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는 다음과 같은 절차를 통해 찾을 수 있습니다:

  1. releases/ 디렉터리로 이동하십시오.
  2. (ppc64/와 같은) 대상 아키텍처 관련 디렉터리를 선택하십시오
  3. autobuilds/를 선택하십시오.
  4. amd64x86 아키텍처용 파일은 각각의 경우에 대해 current-install-amd64-minimal/ 또는 current-install-x86-minimal/ 디렉터리를 찾아보십시오. 다른 모든 아키텍처용 파일을 찾아보려면 current-iso/ 디렉터리를 탐색하십시오.
참고
arm, mips, s390 같은 일부 대상 아키텍처는 소형 설치 CD가 없습니다. 이 경우, 젠투 출시 엔지니어링 프로젝트는 이 아키텍처를 대상으로 .iso 파일을 지원하지 않습니다.

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

코드 releases/ppc64/autobuilds/current-iso/ 의 다운로드 파일 목록 예제
[DIR] hardened/                                          05-Dec-2014 01:42    -   
[   ] install-ppc64-minimal-20141204.iso                 04-Dec-2014 21:04  208M  
[   ] install-ppc64-minimal-20141204.iso.CONTENTS        04-Dec-2014 21:04  3.0K  
[   ] install-ppc64-minimal-20141204.iso.DIGESTS         04-Dec-2014 21:04  740   
[TXT] install-ppc64-minimal-20141204.iso.DIGESTS.asc     05-Dec-2014 01:42  1.6K  
[   ] stage3-ppc64-20141204.tar.bz2                      04-Dec-2014 21:04  198M  
[   ] stage3-ppc64-20141204.tar.bz2.CONTENTS             04-Dec-2014 21:04  4.6M  
[   ] stage3-ppc64-20141204.tar.bz2.DIGESTS              04-Dec-2014 21:04  720   
[TXT] stage3-ppc64-20141204.tar.bz2.DIGESTS.asc          05-Dec-2014 01:42  1.5K

위 예제에서 install-ppc64-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.

다운로드한 파일 검증

참고
이 과정은 선택적 과정이며 젠투 리눅스를 설치하는데 굳이 필요하지 않습니다만, 다운로드한 파일이 깨졌는지 확인하고 젠투 기반 팀이 분명히 지원 했는지 확인해보시는 것이 좋습니다.
  1. 먼저, 젠투 출시 엔지니어링 팀이 제공한 설치 파일인지 암호화 서명으로 확인합니다.
  2. 암호화 서명 검증이 끝나면, 다운로드 파일이 깨졌는지 확인합니다.

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

우선 암호화 서명을 검증하려면 GPG4Winen과 같은 도구를 사용할 수 있습니다. 설치 후 젠투 출시 엔지니어링 팀의 공개 키를 가져와야합니다. 키 목록은 서명 페이지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-ppc64-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-ppc64-minimal-20141204.iso

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

부팅


기본: Apple/IBM 머신에서 설치 CD 부팅

CD-ROM에 설치 CD를 넣고 시스템을 다시 부팅하십시오. 시작할 때 c 키를 누른채로 기다리십시오. 화면 바닥에 boot: 프롬프트와 친숙한 메시지가 나타납니다.

요령
CD/DVD 드라이브 서랍을 열려면 부팅 중에 왼쪽 마우스 단추를 누른채로 기다리십시오.

이 프롬프트에서는 설치 CD에서 부팅할 기본 리눅스 커널(gentoo)을 부팅할 수 있습니다.

몇가지 커널 옵션을 이 프롬프트에서 조절할 수 있습니다. 다음 표에 추가할 수 있는 부팅 옵션을 넣어보았습니다:

부팅 옵션 설명
video= 이 옵션은 제조사별 태그 radeonfb, rivafb, atyfb, aty128, nvidiafb, ofonly중 하나를 취합니다. 이 태그 뒤에 따라오는 해상도와 재생주파수는 필요한대로 붙입니다. 예를 들자면 video=radeonfb:1280x1024@75 와 같습니다. 어떤 태그를 선택해야 할지 확실히 모르겠다면, 대부분의 경우 ofonly로 동작합니다.
nol3 일부 파워북의 레벨 3 캐시를 비활성화합니다(최소한 17"가 필요)
debug 메시지를 많이 쏟아내는 verbose 부팅을 활성화하며 설치 CD를 디버깅할 때 활용할 initrd 쉘을 실행합니다
sleep=N 계속하기 전 N(양의 정수)초 동안 기다립니다. 충분히 빨리 동작할 수 없는 매우 오래된 SCSI CD-ROM에서 필요합니다.
bootfrom=X X 대신 지정한 다른 장치에서 부팅합니다
dosshd sshd를 시작합니다. 무감독 설치에 쓸만합니다
passwd=foo = 다음에 따라오는 값을 루트 암호로 설정합니다. 원격 설치시 dosshd와 함께 사용합니다.

이 프롬프트에서 Enter 키를 치고 젠투 리눅스 환경을 CD에서 완전히 불러오십시오.

IBM p 시리즈

IBM p 시리즈에서는 CD를 자동으로 부팅해야 합니다. 가끔은 그렇지 않습니다. 이런 경우 다중 부팅 메뉴에서 CD-ROM을 부팅 장치로 설정하십시오. 모니터와 키보드가 붙었다면, 시작할 때 F1 키를 눌러 멀티 부팅 메뉴에 도달할 수 있습니다. 그러나 시스템이 직렬 콘솔로 들어간다면 1키를 누르십시오. 직렬 콘솔의 다음 줄의 시작 부분이 보일 때 키를 누르십시오:

코드 '1' 을 눌러야 하는 줄
memory      keyboard     network      scsi      speaker

다른 방법은, 오픈 펌웨어로 건너뛰고 다음 절차를 수행하는 방법입니다:

  1. 오픈 펌웨어로 부팅: 멀티 부팅 과정으로 들어가는 절차와 동일하나 F11 대신, F88을 사용하십시오.
  2. 0> boot cdrom:1,yaboot 명령을 실행합니다
  3. 등판에 등을 기대고 즐기세요!
참고
다음 출력이 나타나면 오픈 펌웨어 설정이 제대로 된 상태가 아닙니다. 위에서 설명한대로 다중 부팅 옵션을 사용하십시오:
코드 오픈 펌웨어를 제대로 설정하지 않았을 경우의 출력
0 > boot cdrom:1,yaboot
 ok
0 >

키보드 배치 설정

콘솔에서 루트 프롬프트("#")가 뜹니다. Alt+fn+F2, Alt+fn+F3, Alt+fn+F4키를 눌러 다른 콘솔로 전환할 수 있습니다. Alt+fn+F1키를 눌러 처음 콘솔로 돌아오십시오.

비 US 키보드로 시스템에서 젠투를 설치할 때, 키보드의 키 배치를 불러오려면 loadkeys 명령을 활용하십시오. 사용할 수 있는 키 배치를 보려면 /usr/share/keymaps/i386 경로에서 ls명령을 실행하십시오.

root #ls /usr/share/keymaps/i386/

이제 loadkeys 명령으로 선택한 키 배치를 불러오십시오:

root #loadkeys be-latin1

다른 일반 설정은 아마도 쿼티 PC110 키보드 설정일지도 모르겠습니다:

root #loadkeys pc110


추가 하드웨어 설정

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

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

root #modprobe 8139too

선택: 사용자 계정

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

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

root #passwd
New password: (Enter your new password)
Re-enter password: (Re-enter your password)

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

다음 예제에서, "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:PPC64/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:

인터페이스 이름 결정

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 een 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 바이트 블록의 모음으로 다룰 수 있습니다.


파티션과 슬라이스

비록 이론적으로 리눅스 시스템을 저장할 디스크 전체를 사용할 수 있다고는 하지만, 실제로는 거의 불가능합니다. 대신, 전체 디스크 블록 장치를 더 작게 나누고, 더 관리하기 쉬운 블록 장치로 만들 수 있습니다. 대부분의 시스템에서는 파티션이라고 합니다. 다른 아키텍처에서는 슬라이스라고 하는 비슷한 기술이 있습니다.

분할 배치 설계

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

분할 영역의 수는 환경에 따라 다릅니다. 예를 들어, 사용자가 많을 경우 보안성을 개선하고 백업을 쉽게 하기 위해 /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.

스왑 공간이 무엇인가요?

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

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


기본: mac-fdisk 사용

중요
이 절차는 애플 G5 시스템용입니다.
Partition Description
/dev/sda1 Apple partition map, automatically created when the disk is formatted with a "mac" partition table.
/dev/sda2 New World boot block
/dev/sda3 Swap partition
/dev/sda4 Root partition

mac-fdisk를 시작하십시오:

root #mac-fdisk /dev/sda

리눅스 파티션을 만들려면 우선 앞서 지운 파티션을 삭제하십시오. 이 파티션을 삭제하려면 mac-fdisk에서 d키를 사용하십시오. 삭제할 파티션 번호를 물어봅니다.

그 다음, b키를 사용하여 Apple_Bootstrap 파티션을 만드십시오. 시작 블록 위치를 물어봅니다. 처음 남은 파티션의 번호를 입력하고 p를 입력하십시오. 이 경우, "2p"입니다.

참고
이 파티션은 "boot" 파티션이 아닙니다. 모든 파티션이 리눅스가 쓰진 않습니다. 이 파티션에 어떤 파일 시스템도 올라갈 필요가 없으며 마운트조차도 해서는 안됩니다. PPC 사용자는 /boot에 대한 추가 파티션이 필요없습니다.

이제 c를 눌러 스왑 파티션을 만드십시오. 다시 말해, mac-fdisk에서는 몇번째 블록에서 시작하는지 물어봅니다. Apple_Bootstrap 파티션을 만들때 2번을 입력했던바와 같이, "3p"를 입력하십시오 크기를 물어보면 512M(또는 필요한 용량만큼)을 입력하십시오. 이름을 물어보면 "swap"(필수)이라고 입력하십시오.

루트 파티션을 만들려면 c를 입력하십시오. 그 다음 루트 파티션의 블록 시작 위치를 선택할 때 "4p"라고 입력하십시오. 크기를 물어보면 "4p"를 다시 입력하십시오. mac-fdisk에서는 이 입력을 "존재하는 전체 공간 사용"이란 뜻으로 해석합니다. 이름을 물어보면 "root"(필수)라고 입력하십시오.

끝내려면 w로 파티션 정보를 디스크에 기록하고 q로 mac-fdisk를 끝내십시오.

참고
모든 부분이 문제없는지 확인하려면, mac-fdisk를 한번 이상 실행하고 모든 파티션이 제자리에 위치했는지 검사하십시오. 만들어놓은 모든 파티션이 나타나지 않거나, 바뀐 내용 일부가 보이지 않는다면 mac-fdisk에서 i를 눌러 파티션을 다시 초기화하십시오. 참고로 이 명령은 파티션 맵을 다시 만들기 때문에 모든 파티션을 제거합니다.

대안: fdisk 사용

중요
이 절차는 IBM p 시리즈, i 시리즈, 오픈파워 시스템에 해당합니다.
참고
POWER5 기반 하드웨어에서 젠투 설치 과정에 RAID 디스크 어레이를 사용하려 한다면, 고급 기능 포맷 방식으로 iprconfig를 실행하여 디스크 어레이를 만드십시오. 설치가 끝나면 sys-fs/iprutils를 이머지하십시오.

ipr 기반의 SCSI 어댑터를 사용한다면 ipr 유틸리티를 시작하십시오.

root #/etc/init.d/iprinit start

다음 내용에서는 이전에 설명한 파티션 배치를 만드는 방법의 예제를 분명하게 설명합니다:

파티션 설명
/dev/sda1 PPC PReP 부트 파티션
/dev/sda2 스왑 파티션
/dev/sda3 루트 파티션

개인 취향에 따라 파티션 배치를 바꾸십시오.

현재 파티션 배치 보기

fdisk는 디스크를 파티션으로 나누는 저명하고 강력한 도구입니다. fdisk를 현재 디스크에서 실행해보십시오(예제에서는 /dev/sda를 사용):

root #fdisk /dev/sda
Command (m for help)

시스템에 AIX 파티션이 남아있다면 다음 오류 메시지가 나타납니다:

root #fdisk /dev/sda
  There is a valid AIX label on this disk.
  Unfortunately Linux cannot handle these
  disks at the moment.  Nevertheless some
  advice:
  1. fdisk will destroy its contents on write.
  2. Be sure that this disk is NOT a still vital
     part of a volume group. (Otherwise you may
     erase the other disks as well, if unmirrored.)
  3. Before deleting this physical volume be sure
     to remove the disk logically from your AIX
     machine.  (Otherwise you become an AIXpert).

걱정 마시고 o를 누르면 비어있는 새 DOS 파티션 테이블을 만들 수 있습니다.

경고
이 과정은 설치한 AIX를 망가뜨립니다!

p를 입력하여 현재 파티션 설정을 표시하십시오:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          12       53266+  83  Linux
/dev/sda2              13         233      981571+  82  Linux swap
/dev/sda3             234         674     1958701+  83  Linux
/dev/sda4             675        6761    27035410+   5  Extended
/dev/sda5             675        2874     9771268+  83  Linux
/dev/sda6            2875        2919      199836   83  Linux
/dev/sda7            2920        3008      395262   83  Linux
/dev/sda8            3009        6761    16668918   83  Linux

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

모든 파티션 제거

디스크에서 모든 파티션을 제거하십시오. 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.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
Device Boot    Start       End    Blocks   Id  System

이제 파티션 테이블을 비웠으니 파티션을 만들어보겠습니다. 앞에서 이야기한 대로 기본 파티션 형태를 사용하겠습니다. 물론, 문자 그대로 따라오시지 말고 개인 취향에 따라 적절히 조절하세요.

PPC PReP 부트 파티션 만들기

우선 작은 PReP 부트 파티션을 만들겠습니다. n 을 입력하여 새 파티션을 만들고, p 입력하여 주 파티션을 선택한 다음, 1을 입력하여 첫번째 주 파티션을 선택하십시오. 첫번째 실린더를 물어보면 Enter를 치십시오. 마지막 실린더를 물어보면 +7M을 입력하여 7MB 크기의 파티션을 만드십시오. 여기가지 과정이 끝나면 t를 입력하여 파티션 형식을 바꾸시고, 방금 만든 파티션 1번을 선택하신 후, 41을 입력하여 "PPC PReP Boot"를 선택하십시오. 마지막으로, PReP 파티션을 부팅 가능하도록 표시하십시오.

참고
PReP 파티션 크기는 8MB 미만이어야 합니다!
Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
Command (m for help):n
Command action
      e   extended
      p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-6761, default 1): 
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-6761, default
6761): +8M
Command (m for help):t
Selected partition 1
Hex code (type L to list codes): 41
Changed system type of partition 1 to 41 (PPC PReP Boot)
Command (m for help):a
Partition number (1-4): 1
Command (m for help):

이제 (p 명령으로) 파티션 테이블을 다시 살펴봤을 때, 다음 파티션 정보가 나타나야합니다:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1  *            1           3       13293   41  PPC PReP Boot

스왑 파티션 만들기

다음 스왑 파티션을 만들도록 하겠습니다. 스왑 파티션을 만들려면 n키를 입력하여 새 파티션을 만들고, 우리 같은 경우는 /dev/sda2를 만들겠으니 2를 입력하여 두번째 파티션을 만듭니다. 첫 실린더를 물어보면 그냥 Enter키를 칩니다. 마지막 실린더를 물어보면 +512M을 입력하여 512MB 크기의 파티션을 만듭니다. 그 다음 파티션 형식을 설정하려면 t를 입력하고, 방금 만든 파티션 2를 선택한 후, 파티션 형식을 Linux Swap으로 바꾸기 위해 82를 입력합니다. 이 단계가 끝나면 p를 입력하여 다음과 같은 파티션 표를 출력해야합니다:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           3       13293   41  PPC PReP Boot
/dev/sda2               4         117      506331   82  Linux swap

루트 파티션 만들기

마지막으로, 루트 파티션을 만들겠습니다. 과정을 진행하려면, 새 파티션을 만드는 명령 n을 입력하시고, 주 파티션을 만들겠다고 fdisk에게 알리기 위해 p를 입력한 후, 세번째 주 파티션 /dev/sda3를 만들기 위해 3을 입력하십시오. 첫번째 섹터를 물어보면 Enter를 치십시오. 마지막 섹터를 물어보면 Enter를 쳐서 디스크의 나머지 공간을 취하는 파티션을 만드십시오. 이 과정이 끝나면 p를 입력하였을 때 다음과 같은 파티션 테이블 모습이 나타나야합니다:

Command (m for help):p
Disk /dev/sda: 30.7 GB, 30750031872 bytes
141 heads, 63 sectors/track, 6761 cylinders
Units = cylinders of 8883 * 512 = 4548096 bytes
  
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1           3       13293   41  PPC PReP Boot
/dev/sda2               4         117      506331   82  Linux swap
/dev/sda3             118        6761    29509326   83  Linux

파티션 배치 저장하기

파티션 배치를 저장하고 fdisk를 빠져나가려면 w를 입력하십시오.

Command (m for help):w


파일 시스템 만들기

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

도입부

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

파일 시스템

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

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 (), or mount points for additional partitions created in the partitioning section:

root #mkdir --parents

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

root #mkdir --parents

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 타르볼을 젠투에서 사용하지 않는게 좋습니다.

스테이지 타르볼 다운로드

날짜 및 시간 설정

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

루트 파일 시스템을 마운트한 젠투 마운트 지점으로 이동하십시오(대부분 /mnt/gentoo):

root #cd /mnt/gentoo

그래픽 브라우저

완벽한 그래픽 여건을 갖춘 웹 브라우저에서 주 웹사이트 다운로드 페이지에서 스테이지 파일 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/ppc64/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-ppc64-<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-ppc64-<release>.tar.bz2

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

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

root #sha512sum stage3-ppc64-<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-ppc64-<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

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

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

코드 CFLAGSCXXFLAGS 변수 예제
CFLAGS="-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를 치십시오).




루트 변경

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라고 합니다.

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

  1. chroot를 사용하여 루트 위치를 (설치 매체의)/에서 (파티션의) /mnt/gentoo/로 바꿉니다
  2. 몇가지 설정(/etc/profile에 있음)을 source 명령으로 메모리에 다시 불러옵니다
  3. 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, was formatted with the FAT32 filesystem and will be used as the EFI System Partition (ESP). Create a new directory (if not yet created), and then mount ESP there:

root #mkdir # May have been created in a previous step
root #mount

DOS/Legacy BIOS systems

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

root #mount /dev/sda1

포티지 설정

젠투 이빌드 저장소

미러를 선택하는데 있어 두번째로 중요한 단계는 /etc/portage/repos.conf/gentoo.conf 파일의 젠투 이빌드 저장소 설정입니다. 이 파일에는 꾸러미 저장소(포티지에서 프로그램 꾸러미를 다운로드하고 설치할 때 필요한 모든 정보가 들어있는 관련 파일 및 이빌드 모음)를 업데이트 하는데 필요한 동기화 정보가 들어있습니다.

저장소 설정은 몇 가지 단순한 과정을 거칩니다. 우선 repos.conf 디렉터리가 없다면 만드십시오:

root #mkdir --parents /mnt/gentoo/etc/portage/repos.conf

다음, 포티지에서 제공하는 젠투 저장소 설정 파일을 (새로 만든) repos.conf 디렉터리에 복사하십시오:

root #cp /mnt/gentoo/usr/share/portage/config/repos.conf /mnt/gentoo/etc/portage/repos.conf/gentoo.conf

텍스트 편집기를 골라 쓰든지 cat 명령을 사용하십시오. 해당 파일은 다음과 같이 .ini 파일 형식으로 되어 있습니다.

파일 /mnt/gentoo/etc/portage/repos.conf/gentoo.conf
[DEFAULT]
main-repo = gentoo
 
[gentoo]
location = /var/db/repos/gentoo
sync-type = rsync
sync-uri = rsync://rsync.gentoo.org/gentoo-portage
auto-sync = yes
sync-rsync-verify-jobs = 1
sync-rsync-verify-metamanifest = yes
sync-rsync-verify-max-age = 24
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
sync-openpgp-key-refresh-retry-count = 40
sync-openpgp-key-refresh-retry-overall-timeout = 1200
sync-openpgp-key-refresh-retry-delay-exp-base = 2
sync-openpgp-key-refresh-retry-delay-max = 60
sync-openpgp-key-refresh-retry-delay-mult = 4

sync-uri 변수 기본값은 위에 언급한 바와 같이 전환 기반 미러 위치를 결정합니다. 젠투의 운영기반 시스템의 과부하를 완화하는데 도움을 주며 특정 미러가 깨졌을 경우 우회하는 수단을 제공합니다. 자체 로컬 포티지 미러를 사용하기

전에는 기본 URI 설정을 그대로 두는 것이 좋습니다.
요령
이 부분에 관심있다면 포티지 플러그인 동기화 API에 대한 공식 사양을 동기화 문서en에서 찾을 수 있습니다.

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

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

제한적인 방화벽 환경에 있어 네트워크 대역폭 활용을 아낄 분들은 (스냅샷을 다운로드할 때 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 프로그램은 시스템에서 바뀐 항목 또는 시스템 전반 설정을 처리하는 일반 관리 인터페이스입니다. 이 경우 eselectnews 모듈 사용을 요청합니다.

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/ppc64/ *
  [2]   default/linux/ppc64//desktop
  [3]   default/linux/ppc64//desktop/gnome
  [4]   default/linux/ppc64//desktop/kde
참고
명령 출력 결과는 예제일 뿐이며, 언제든 바뀝니다.

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

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

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

root #eselect profile set 2



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

  1. The architecture and profile targets within the sync-uri value do matter and should align to the respective computer architecture (ppc64 in this case) and system profile selected in the Choosing the right profile section.
  2. 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/gentoo.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:

  1. 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.
  2. 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"

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.confUSE 정의 앞부분에 -*를 넣으십시오:

파일 /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 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를 빌드한 후 어떤 프로파일을 선택하든지간에 시스템에서 최신 내용을 반영하도록 "필요한" 과정입니다:

  1. A profile target different from the stage file has been selected.
  2. 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 안내서도 흥미로운 읽을거리입니다.





선택: 펌웨어 설치

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

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

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

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

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:

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

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

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.

Installing a distribution kernel

Before installing the kernel package the dracut USE flag needs to be added for the package sys-kernel/installkernel in /etc/portage/package.use:

파일 /etc/portage/package.use/installkernelEnable dracut support
sys-kernel/installkernel dracut

Users may also wish to enable additional sys-kernel/installkernel USE flags at this stage. See the Installation/Kernel#Installkernel section for details.

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

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

Post-install/upgrade tasks

Distribution kernels are capable of rebuilding kernel modules installed by other packages. linux-mod-r1.eclass provides the dist-kernel USE flag which controls a subslot dependency on virtual/dist-kernel.

Enabling this USE flag on packages like sys-fs/zfs and sys-fs/zfs-kmod allows them to automatically be rebuilt against a newly updated kernel and, if applicable, will re-generate the initramfs accordingly.

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.

When installing and compiling the kernel for ppc64-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-3.16.5-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-3.16.5-gentoo

대안: genkernel 사용

참고
In case it was missed, this section requires the kernel sources to be installed. Be sure to obtain the relevant kernel sources, then return here for the rest of section.

직접 설정이 상당히 벅차다면, genkernel을 추천합니다. 커널을 설정하고 빌드하는 과정을 자동으로 처리합니다.

Genkernel 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*

기본: 직접 설정

도입부

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


컴파일 및 설치

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

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

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

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


Kernel installation

Installkernel

Installkernel may be used to automate, the kernel installation, initramfs generation, unified kernel image generation and/or bootloader configuration among other things. sys-kernel/installkernel implements two paths of achieving this: the traditional installkernel originating from Debian and systemd's kernel-install. Which one to choose depends, among other things, on the system's bootloader. By default systemd's kernel-install is used on systemd profiles, while the traditional installkernel is the default for other profiles.

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

systemd-boot

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

On OpenRC systems:

파일 /etc/portage/package.use/systemd-boot
sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot
root #emerge --ask sys-apps/systemd-utils

On systemd systems:

파일 /etc/portage/package.use/systemd
sys-apps/systemd boot
sys-kernel/installkernel systemd-boot
# Needed for <systemd-254
sys-apps/systemd gnuefi
root #emerge --ask sys-apps/systemd

GRUB

Users of GRUB can use either systemd's kernel-install or the traditional Debian installkernel. The systemd USE flag switches between these implementations. To automatically run grub-mkconfig when installing the kernel, enable the grub USE flag.

파일 /etc/portage/package.use/installkernel
sys-kernel/installkernel grub
root #emerge --ask sys-kernel/installkernel

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

파일 /etc/kernel/install.conf
layout=grub

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

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


Building an initramfs

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

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

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

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

파일 /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut

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

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

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

root #ls /boot/initramfs*

Optional: Building an Unified Kernel Image

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

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

For systemd systems:

파일 /etc/portage/package.use/systemd
sys-apps/systemd boot

For OpenRC systems:

파일 /etc/portage/package.use/systemd-utils
sys-apps/systemd-utils boot

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

For dracut:

파일 /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut uki
파일 /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"

For ukify:

파일 /etc/portage/package.use/installkernel
sys-kernel/installkernel dracut ukify uki
파일 /etc/kernel/cmdline
some-kernel-command-line-arguments

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

Generic Unified Kernel Image

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

파일 /etc/portage/package.use/generic-uki
sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify uki

Secure Boot

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

For dracut:

파일 /etc/dracut.conf
uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"

For ukify:

파일 /etc/kernel/uki.conf
[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem

Rebuilding external kernel modules

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

파일 /etc/portage/package.use/module-rebuild
*/* dist-kernel

External kernel modules may also be rebuilt manually with:

root #emerge --ask @module-rebuild

커널 모듈

모듈 설정

참고
하드웨어 모듈은 직접 나열해야합니다. udev 명령은 대부분 연결한 장치를 직접 찾습니다. 그러나, 대부분의 경우는 자동 감지 모듈을 찾아내는게 위험하지 않습니다만, 일부 특이한 하드웨어의 경우 자체 드라이버를 불러오도록 해야 할 때도 있습니다.

/etc/modules-load.d/*.conf에 자동으로 불러올 모듈을 한 줄에 하나씩 넣으십시오. 모듈의 추가 옵션은 필요할 경우 /etc/modprobe.d/*.conf 파일에 넣으시면 됩니다.

존재하는 모든 모듈을 보려면 다음과 같이 find 명령을 실행하십시오. 잊지 말고 "<kernel version>" 부분을 컴파일한 커널의 버전으로 바꾸십시오.

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

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는 앞에 LABELUUID를 붙여 식별 명칭을 부여하며, 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는 PARTLABELPARTUUID로 지정하며, 터미널에서 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 파일 만들기

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

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

DOS/Legacy BIOS systems

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

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

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

이전에 결정한 분할 영역 모양새에 따라 규칙을 추가하시고, 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
                    0 2
/dev/sda2   none             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/fstabGPT disklabel DPS 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                                  0 2
PARTUUID=0657fd6d-a4ab-43c4-84e5-0933c84b4f4f   none            sw                           0 0
PARTUUID=   /           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_eth0routes_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)의 가정이 틀렸음을 알아챌 것입니다. 이 문제를 바로잡으려면 다음 단계를 따라 처리하십시오:

  1. (eth0 대신 enp3s0같이) 올바른 인터페이스 이름으로 /etc/conf.d/net 파일을 업데이트하십시오
  2. 새 심볼릭 링크를 만드십시오(/etc/init.d/net.enp3s0)
  3. 이전 심볼릭 링크를 제거하십시오(rm /etc/init.d/net.eth0)
  4. 새로 만든 심볼릭 링크를 기본 실행 레벨에 추가하십시오
  5. 이전 심볼릭 링크를 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
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

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






커널을 설정했고 컴파일했으며 필요한 시스템 설정 파일의 내용을 올바르게 채워넣었으니, 시스템을 부팅할 때 커널을 실행할 프로그램을 설치할 차례입니다. 이 프로그램을 부트로더라고합니다.

Linux/PPC64에서는 yaBoot 를 부트로더로 사용합니다.

Using GRUB

Installation

root #emerge --ask sys-boot/grub

Setup bootstrap partition

First, prepare the bootstrap partition that was created created during the preparing the disk step. Following the example, this partition should be /dev/sda2. Optionally, confirm this by using parted:

Replace /dev/sda with the correct device if required.

root #parted /dev/sda print
Model: ATA Patriot Burst El (scsi)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Disk /dev/sda: 120GB
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Sector size (logical/physical): 512B/512B
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Partition Table: mac
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Disk Flags:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Number  Start   End     Size    File system  Name       Flags
 1      512B    32.8kB  32.3kB               Apple
 2      32.8kB  852kB   819kB   hfs          bootstrap  boot
 3      852kB   538MB   537MB   ext4         Boot
 4      538MB   54.2GB  53.7GB  ext4         Gentoo

In this output, partition 2 has the bootstrap information so /dev/sda2 is the correct path to use.

Format this partition as HFS using the hformat command which is part of the sys-fs/hfsutils package:

root #dd if=/dev/zero of=/dev/sda2 bs=512
root #hformat -l bootstrap /dev/sda2

Create a directory to mount the bootstrap partition and then mount it:

root #mkdir /boot/NWBB
root #mount --types hfs /dev/sda2 /boot/NWBB

Setup GRUB

root #grub-install --macppc-directory=/boot/NWBB /dev/sda2

If it installs without errors, unmount the bootstrap:

root #umount /boot/NWBB

Next, bless the partition so it will boot:

root #hmount /dev/sda2
root #hattrib -t tbxi -c UNIX :System:Library:CoreServices:BootX
root #hattrib -b :System:Library:CoreServices
root #humount

Finally, build the grub.cfg file:

root #grub-mkconfig -o /boot/grub/grub.cfg


IBM 하드웨어에 yaboot 사용

IBM 하드웨어에서는 yabootconfig 또는 ybin을 실행할 수 없습니다. 다음 단계를 따르십시오.

  • yaboot-static을 설치합니다
  • dd if=/usr/lib/yaboot/yaboot.chrp of=/dev/sdXX를 실행합니다(XX는 PReP 파티션의 디스크와 파티션입니다. 예제에서는 /dev/sda1 였습니다)
  • 다음 yaboot.conf 파일을 만들어 /etc/에 넣습니다.(위 설정, yaboot.conf 의 맨 페이지, 아래의 yaboot.conf 예제 중 하나를 살펴보십시오)
  • OF의 부팅 장치가 PReP 부트 파티션을 활성화 한 하드 드라이브를 가리킨다면 동작하는 상태입니다. 그렇지 않으면 IPL 타임에 다중 부팅 메뉴로 들어가서 PReP 부트 파티션으로 부팅 장치를 설정하십시오

다 됐습니다!

파일 yaboot.confIBM hardware의 yaboot.conf 예제
device=disk:
partition=2
root=/dev/sda3
default=linux
timeout=50
  
image=/boot/kernel-3.16.5-gentoo
    label=linux
    append="console=ttyS0,9600"
    read-only

POWER4, POWER5, PReP 디스크 파티션이 있고 동일한 위치에 커널에 있는 블레이드 기반 하드웨어에서는 yaboot.conf를 단순하게 만들어 쓸 수 있습니다. 다음 설정 정도면 충분합니다:

파일 yaboot.confPReP 하드웨어용 yaboot.conf
default = linux
timeout = 100
image=/boot/kernel-3.16.5-gentoo
        label=linux
        read-only
        root = /dev/sda3
        append="root=/dev/sda2"

yaboot을 PReP 파티션에 복사했는지 확인하려면:

root #dd if=/dev/sda1 count=10 | grep ELF
Binary file (standard input) matches
10+0 records in
10+0 records out

내용이 일치함은 yaboot을 제대로 설치했다는 뜻입니다.


시스템 다시 부팅

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)

사용자가 루트 권한으로 몇가지 작업을 수행할 필요가 있다면, 임시로 루트 권한을 받기 위해 su - 명령을 사용할 수 있습니다. 다른 방법은 sudo 꾸러미를 사용하는 방법인데, 올바르게 설정했다면 매우 안전합니다.

디스크 정리

타르볼 제거

젠투 설치가 끝나고 시스템을 다시 부팅한 후 모든 부분이 잘 끝났다면 이제 다운로드한 스테이지 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 "젠투 리눅스 ppc64 핸드북: 젠투 설치" overrides earlier display title "Handbook:PPC64/Full/Installation/ko".