Handbook:Parts/Installation/Stage/ko

날짜 및 시간 설정
젠투를 설치하기 전 날짜와 시간을 올바르게 설정했는지 확인하십시오. 잘못 설정한 시간은 나중에 이상한 결과를 초기할지도 모릅니다!

현재 날짜 및 시간을 확인하려면 date를 실행하십시오:

날짜 시간 표시가 잘못됐다면,  문법(월, 일, 시간, 분, 연도)으로 업데이트하십시오. 이 단계에서는 UTC 시간을 사용합니다. 나중의 설치 단계에서 시간대를 지정하겠습니다.

2014년 3월 29일 16시 21분을 설정하려면:

스테이지 타르볼 다운로드
루트 파일 시스템을 마운트한 젠투 마운트 지점으로 이동하십시오(대부분 ):

설치 매체에 따라, 스테이지를 다운로드할 도구 몇가지가 준비되어 있습니다. 비-그래픽 방식의 메뉴 기반 브라우저 가 그 중 하나입니다. 스테이지를 다운로드하려면 다음과 같이 젠투 미러를 탐색하십시오:

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

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

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

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

최소 설치 CD 처럼, 추가로 다운로드할 파일이 있습니다:
 * 스테이지 타르볼 파일 목록이 있는 파일
 * 각각의 알고리즘으로 만든 스테이지 파일의 체크섬이 있는 파일
 * 파일과 마찬가지로 각각의 알고리즘으로 만든 스테이지 파일의 체크섬이 있지만, 젠투 프로젝트에서 제공했음을 확인할때 쓰는 암호화 서명도 들어있는

과정이 끝나면, 를 눌러 브라우저를 빠져나가십시오.

스테이지 파일 다운로드가 끝나면, 다운로드한 스테이지 타르볼의 무결성을 검증할 수 있습니다. 을 사용하여 또는  파일에서 제공하는 체크섬 출력을 비교하십시오.

SHA512 체크섬을 검증한다면:

Another way is to use the  command:

To validate the Whirlpool checksum:

Compare the output of these commands with the value registered in the files. The values need to match, otherwise the downloaded file might be corrupt (or the digests file is).

Just like with the ISO file, it is also possible to verify the cryptographic signature of the file using   to make sure the checksums have not been tampered with:

스테이지 다르볼 압축 해제
Now unpack the downloaded stage onto the system. We use  to proceed:

Make sure that the same options (xvjpf) are used. The x stands for Extract, the v for Verbose to see what happens during the extraction process (optional), the j for Decompress with bzip2, the p for Preserve permissions and the f to denote that we want to extract a File, not standard input.

Now that the stage is installed, continue with Configuring the compile options.

도입부
To optimize Gentoo, it is possible to set a couple of variables which impact Portage behavior. All those variables can be set as environment variables (using ) but that isn't permanent. To keep the settings, Portage reads in the file, a configuration file for Portage.

Fire up an editor (in this guide we use ) to alter the optimization variables we will discuss hereafter.

From the file it is obvious how the file should be structured: commented lines start with "#", other lines define variables using the VARIABLE="content" syntax. Several of those variables are discussed next.

CFLAGS and CXXFLAGS
The CFLAGS and CXXFLAGS variables define the optimization flags for the gcc C and C++ compiler respectively. Although those are defined generally here, for maximum performance one would need to optimize these flags for each program separately. The reason for this is because every program is different. However, this is not manageable, hence the definition of these flags in the file.

In one should define the optimization flags that will make the system the most responsive generally. Don't place experimental settings in this variable; too much optimization can make programs behave bad (crash, or even worse, malfunction).

We will not explain all possible optimization options. To understand them all, read the GNU Online Manual(s) or the gcc info page ( -- only works on a working Linux system). The file itself also contains lots of examples and information; don't forget to read it too.

A first setting is the  or   flag, which specifies the name of the target architecture. Possible options are described in the file (as comments). A commonly used value is native as that tells the compiler to select the target architecture of the current system (the one users are installing Gentoo on).

A second one is the  flag (that is a capital O, not a zero), which specifies the gcc optimization class flag. Possible classes are s (for size-optimized), 0 (zero - for no optimizations), 1, 2 or even 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). is the recommended default. is known to cause problems when used system-wide, so we recommend to stick to.

Another popular optimization flag is  (use pipes rather than temporary files for communication between the various stages of compilation). It has no impact on the generated code, but uses more memory. On systems with low memory, gcc might get killed. In that case, do not use this flag.

Using  (which doesn't keep the frame pointer in a register for functions that don't need one) might have serious repercussions on the debugging of applications.

When the CFLAGS and CXXFLAGS variables are defined, combine the several optimization flags in one string. The default values contained in the stage3 archive that is unpacked should be good enough. The following one is just an example:

MAKEOPTS
The  variable defines how many parallel compilations should occur when installing a package. A good choice is the number of CPUs (or CPU cores) in the system plus one, but this guideline isn't always perfect.

준비, 시, 작!
Update the file to match personal preference and save (nano users would hit ).

Then continue with Installing the Gentoo base system.