· KLDP.org · KLDP.net · KLDP Wiki · KLDP BBS ·
Gentoo Handbook/x86

1. 젠투 설치

1.1. 젠투 설치에 관하여


1.1.1. 소개

환영합니다!

모든 내용의 처음으로, 젠투에 오신 것을 환영합니다. 여러분은 선택과 성능의 세계로 들어서는 중입니다. 젠투는 선택에 관한 모든 것입니다. 젠투를 설치할 때, 몇 회에 걸쳐 여러분에게 명백한 선택을 하도록 합니다. 얼마나 컴파일 하길 원하는지 정할 수 있고, 얼마나 설치할지도 정할 수 있고, 어떤 시스템 로그 데몬을 사용할지도, 그 외의 여러가지들을 선택할 수 있습니다.

젠투는 빠릅니다. 깔끔하고 유연한 디자인을 갖는 최신의 정보기반 배포판입니다. 젠투는 자유소프트웨어로서 만들었으며, 젠투 사용자들에게 덮개 밑의 모든 것을 숨기려 하지 않습니다. 젠투에서 사용하는 패키지 관리 시스템인 Portage(이하 포티지)는 Python(이하 파이썬)으로 작성되었습니다. 즉 (파이썬으로 제작되었기 때문에) 소스코드를 쉽게 보고 변경할 수 있습니다. (비록 미리 컴파일된 패키지들이 포함되어 있기는 하지만) 젠투의 패키지 시스템은 소스코드를 사용하며 정규 텍스트 파일을 통해 설정을 합니다. 다른 말로 모든 곳이 개방되어 있습니다.

젠투를 실행하도록 하는 것이 선택이라는 점을 이해하는 것은 아주 중요합니다. 우리는 여러분들이 원하지 않는 것을 강요하지 않습니다. 만약 우리가 그렇게 한다고 느껴진다면, 그 부분을 버그리포트 해주십시오.

구성된 설치(과정)는 얼마나 됩니까?

젠투 설치는 2장에서 11장까지, 10 단계의 진행과정으로 보여질 수 있습니다. 모든 단계는 일정한 상태로 끝납니다.
  • 1단계 이후에는, 젠투를 설치하기 위한 작업 환경 준비 상태에 있습니다.
  • 2단계 이후에는, 젠투를 설치하기 위해 인터넷 연결이 준비됩니다.
  • 3단계 이후에는, 젠투 설치 파일을 저장하기 위해 하드디스크가 초기화 되어 있습니다.
  • 4단계 이후에는, 여러분의 설치 환경이 준비되고, 새로운 환경으로 시스템 루트 변경(chroot)을 할 준비가 되어있습니다.
  • 5단계 이후에는, 모든 젠투 설치 파일과 같은 핵심 패키지들이 설치됩니다.
  • 6단계 이후에는, 리눅스 커널을 컴파일이 완료됩니다.
  • 7단계 이후에는, 대부분의 젠투 시스템 설정 파일 기록을 완료합니다.
  • 8단계 이후에는, (여러분이 선택할 수 있는) 필요한 시스템 도구들이 설치됩니다.
  • 9단계 이후에는, 여러분이 선택한 부트로더가 설치되고 설정되며, 새로 설치한 젠투 리눅스에 로그인 되어 있습니다.
  • 10단계 이후에는, 여러분의 젠투 리눅스 환경을 모험할 준비가 되어 있습니다.

확실한 선택이 주어졌을 때, 찬반 양론(the pros and the cons)을 최대한 설명하도록 노력합니다. 먼저 기본 선택으로 계속 설명할 것이며, 이 부분은 제목에 "기본:"으로 구분되어 있습니다. 다른 가능한 선택은 "대안:" 으로 표시될 것입니다. 기본 선택이 추천하는 것이라고 생각하지 마십시오. 그저 대부분의 사람들이 사용할 것이라고 생각하시면 됩니다.

때때로 추가적인 단계를 따라갈 수 있습니다. 그러한 단계는 "추가:" 로 표시됩니다. 젠투 설치에 꼭 필요한 단계는 아닙니다. 하지만, 몇몇 단계는 여러분이 선택한 결정에 따라 필수적인 선택이 될 수도 있습니다. 이러한 선택을 할 때에나, 추가 단계 이전에 알려드릴 것입니다.

나의 옵션은 무엇입니까?

여러분은 여러가지 방법으로 젠투를 설치할 수 있습니다. 설치 CD 나 이미 설치된 리눅스 배포판 이나 부팅이 가능한 Knoppix(이하 크노픽스) 리눅스, 네트워크 부트 환경, 복원 디스크 등을 사용하여 다운로드하고 설치할 수 있습니다.

이 문서는 확인된 방법인 젠투 설치 CD 를 사용하여 네트워크를 통한 설치 방법을 다룰것입니다. 이 설치 방법은 여러분들이 각 패키지의 최신 버전을 사용하길 원한다고 전제하고 진행합니다. 만약 네트워크 연결을 하지 않고 설치하길 원하신다면, 네트워크가 없는 환경에 대한 설치 설명서를 포함한 젠투 2005.1 핸드북들을 읽어야만 합니다.

또한 GRP(the Gentoo Reference Platform, 젠투 설치와 함께 바로 사용할 수 있는 미리 컴파일된 패키지의 집합)을 사용한다면, 젠투 2005.1 핸드북에 있는 설명을 꼭 따라야 합니다.

다른 설치 방법에 대한 도움말은 대안 설치 가이드를 읽어주십시오. 또한 읽어두면 도움이 될만한 젠투 설치 팁 & 트릭 문서를 제공합니다. 만약 현재 설치 설명서가 과다하게 길다고 생각된다면, 여러분의 컴퓨터 아키텍쳐에 맞게 제작된 빠른 설치 가이드를 사용하도록 하십시오.

또한 몇몇 가능성들을 갖을 수 있습니다. 전체 시스템을 소스로 받아서 컴파일 한다거나 시간이 없을 때 젠투 환경을 갖고 실행하기 위해 미리 컴파일된 환경을 사용할 수도 있습니다. 그리고 물론 모든 것을 컴파일 하지는 않지만 어느정도 준비가 되어 있는 시스템을 즉시 사용할 수 있는 솔루션으로 사용할 수 있습니다.

문제점들?

설치 단계에서 (혹은 설치 문서에서) 문제점이 발견되었다면, bugtracking(이하 버그트래킹) 시스템에 방문하여 알려진 버그인지 확인해 주십시오. 알려져 있지 않은 경우에는 버그를 처리할 수 있도록 버그리포트를 생성하여 주십시오. 버그를 수정하도록 지정할 개발자들을 무서워하지 마십시오. 그들은 보통 사람들을 잡아먹지 않습니다. :) (역자 주:원문에도 이렇게 써있었습니다.)

비록 지금 읽는 문서가 아키텍쳐를 지정한 것이라 해도, 이것이 다른 아키텍쳐에서도 참조되어 있다는 점을 주의하십시오. 이것은 젠투 핸드북의 대부분이 모든 아키텍쳐에서 공통적인 소스 코드를 사용하기 때문에 (중복된 노력을 피하고 개발 자원의 고갈을 피하기 위해서) 그렇습니다. 혼란을 피하기 위해 최소한으로 핸드북을 유지하도록 노력할 것입니다.

만약 사용자 문제(문서를 꼼꼼하게 읽어봤음에도 불구하고 생기는 몇몇 에러)인지 소프트웨어 문제(설치/문서를 주의깊게 테스트 해봤음에도 생기는 몇몇 에러)인지 확인이 안된다면 irc.freenode.net 에 #gentoo 체널에 접속하십시오. 물론 다른 경우에도 환영합니다. :) (역자 주: 국내에서는 irc.hanirc.org 에 #gentoo 방이 있으며 국어로 대화하고 문제를 해결할 수 있습니다. 좋은 메너는 필수입니다.)

만약 젠투를 사용하다가 질문이 있다면, 젠투 문서에 있는 FAQ 를 확인해 보십시오. 포럼에서도 FAQ 를 볼 수 있습니다. 만약 문제를 해결하기 위해 IRC 에 접속하신다면, 대부분의 사람들이 IRC 에서 체제중인 것을 발견하시게 될 것입니다. (역자 주: 국내 irc 체널에도 역자를 포함한 다른 사용자 분들이 죽돌이로 체제하고 있습니다.)

1.2. 적합한 설치 미디어 선택하기


1.2.1. 하드웨어 요구사항

소개

시작하기 전에, 여러분의 시스템에 성공적으로 젠투를 설치하기 위해서 필요한 하드웨어 요구사항을 나열해보았다.

하드웨어 요구사항

CPU i486 혹은 그 이후의 CPU
메모리 64 MB
디스크 공간 1.5 GB (스왑 공간을 제외한 공간)
스왑 공간 최소 256 MB

1.2.2. 젠투 설치 CD 들

소개

젠투 설치 CD들은 스스로 운영 가능한(self-sustained) 젠투 환경을 포함하는 부팅 가능한 CD 입니다. 이것들은 CD로부터 리눅스를 부팅할 수 있습니다. 부팅하는 동안 여러분의 하드웨어를 검색하며, 적절한 드라이버들을 불러들입니다. CD의 내용은 젠투 개발자들에 의해 관리됩니다.

모든 설치 CD 는 부팅이 가능하며, 네트워크를 설정할 수 있고, 파티션을 설정하 수 있으며, 인터넷으로부터 젠투 설치를 시작할 수 있습니다. 최신의 사용 가능한 패키지를 사용하는 인터넷 기반 설치를 수행하는 계획을 하는 긴 시간만큼 현재는 설치에 적합한 2개의 설치 CD 를 제공합니다.

만약 인터넷 연결 작업 없이 젠투 설치하기를 원한다면, 젠투 2005.1 핸드북에 기술된 설치 설명서를 사용하여 주십시오.

우리가 현재 제공하는 2개의 설치 CD 는 다음과 같습니다.
  • 젠투 최소 설치 CD, 작고, 공통적인 부분만 있는, 부팅 가능한 시스템을 부팅고, 네트워크를 설정하며, 젠투 설치를 계속 진행하기 위한 한가지 목적의 CD 입니다.
  • 젠투 유니버스 설치 CD, 최소 설치 CD 와 동일한 기능을 갖는 부팅 CD 입니다. 추가적으로 몇몇 (각각의 하위 아키텍쳐에 최적화된) stage3 타볼 파일들을 포함합니다.

어떤 설치 CD 를 필요로 하는지 결정하는데 도움이 되기 위해 각각의 설치 CD 의 장단점에 대해 기술했습니다.

젠투 최소 설치 CD

최소 설치 CD는 install-x86-minimal-2005.1-r1.iso 으로 불리며 58 MB 의 (CD) 디스크 공간만을 차지합니다. 여러분은 젠투 설치를 위해 이 설치 CD를 사용할 수 있지만, 인터넷 연결이 가능한 곳에서만 작동합니다.

최소 설치 CD 찬반 양론
+ 다운로드의 최소화
- stage3 타볼을 포함하지 않음, 포티지 스냅샷이 없음, 미리 컴파일 된 패키지가 없음. 그러므로 네트워크 없이 설치하기에는 적합하지 않음

젠투 유니버스 설치 CD 유니버스 설치 CD는 install-x86-universal-2005.1-r1.iso 로 불리며 398 MB 의 (CD) 디스크 공간을 차지합니다. 여러분은 이 설치 CD를 젠투 설치에 사용할 수 있으며, 심지어 인터넷 연결이 안되는 곳에서도 젠투 설치가 가능합니다.
유니버스 설치 CD 찬반 양론
+ 필요한 모든 것을 포함. 네트워크 연결 없이 설치 가능
- 대용량의 다운로드

다른 CD 들

미러 사이트에서 Package CD 를 찾을 수 있을 것입니다. 이 CD 는 설치 CD가 아니지만 네트워크가 없는 상태의 설치과정 동안 이용할 수 있는 추가적인 자원입니다. CD 는 네트워크가 없는 상태의 젠투 설치과정 후에도 쉽고 빠르게 추가 응용프로그램들(이를테면 오픈오피스, KDE, Gnome 등)을 설치할 수 있도록 (GRP 세트로 알려진) 미리 컴파일된 패키지들을 포함합니다.

만약 추가적인 소프트웨어를 빨리 설치하기 위해 패키지 CD를 사용하기로 했다면, stage3 타볼이 사용하는 하위 아키텍쳐와 같은 아키텍쳐를 사용하는지 확인하십시오.

Stage3 타볼

stage3 타볼(이하 스테이지3 타볼)은 최소 젠투 환경을 포함하는 압축 파일입니다. 이 메뉴얼을 사용하여 젠투 설치를 하기에 적합합니다. 이전 버전의 핸드북은 스테이지 1부터 3까지의 타볼을 사용한 설치 과정을 기술했었습니다. 지금도 스테이지 1부터 3까지의 타볼을 제공하는 반면에 공식적인 설치 방법은 stage3 타볼을 사용하는 방법입니다. 만약 스테이지 1이나 2 타볼을 사용한 젠투 설치 과정 수행에 관심이 있다면, 젠투 FAQ에서 "어떻게 스테이지1 과 스테이지 2 타볼을 사용하여 젠투를 설치할 수 있습니까?" 를 읽어보십시오.

1.2.3. 다운로드, 젠투 설치 CD 기록, 부팅


설치에 사용할 설치 CD 를 선택하셨습니다. 이제 설치 CD 를 다운로드하고 공 CD 미디어에 기록하는 것으로 설치를 시작할 것입니다. 앞에서 말했다시피 몇몇 사용가능한 설치 CD에 대해 토론하였는데, 어디에서 CD들을 다운로드 할 수 있을까요?

설치 CD 들을 미러 서버들 중 한곳에서 받으실 수 있고 원한다면 패키지 CD 까지 다운로드 할 수 있습니다. 설치 CD들은 releases/x86/2005.1-r1/installcd 디렉터리에 있습니다.

디렉터리를 보시면 iso 확장자 파일들을 찾으실 수 있습니다. 이 파일들은 CD 미디어에 기록할 수 있는, 전체 CD 내용을 담고 있는 이미지 파일입니다.

다운로드 받은 파일에 문제가 없는지 궁금한 경우에는 파일에 대한 MD5 체크섬과 저희가 제공하는 (install-x86-minimal-2005.1-r1.iso.md5 과 같은 형식의 이름을 갖는) 체크섬 파일을 비교할 수 있습니다. Linux/Unix 환경에서 쓸 수 있는 md5sum 프로그램이나 Windows에서 쓸 수 있는 md5sum 프로그램으로 MD5 checksum을 확인할 수 있습니다.

다운로드 한 파일이 사용 가능한지 여부를 확인하기 위한 다른 방법으로 .asc 확장자로 끝나는 제공된 암호화 인증을 검증하기 위한 GnuPG 를 사용하는 방법이 있습니다. 인증 파일을 다운로드하고 공개키를 획득하십시오.

코드1: 공개키 받아오기
$ gpg --keyserver subkeys.pgp.net --recv-keys 17072058


코드2: 서명확인하기
$ gpg --verify <서명 화일> <다운받은 iso 파일>


다운받은 ISO 이미지를 이미지 버닝 프로그램으로 공CD 미디어에 기록합니다. 공CD에 기록할 때는 RAW 모드로 기록하십시오. 프로그램에 따라 방법은 다릅니다. 이곳에선 cdrecord 나 K3B 로 기록하는 방법에 대해서 설명합니다. 더 자세한 내용은 젠투 FAQ 에서 찾으실 수 있습니다.
  • cdrecord 를 사용할 경우, cdrecord dev=/dev/hdc <다운로드한 ISO 파일명> 라고 입력하십시오. (/dev/hdc 는 CD-RW 드라이브의 장치 경로로 대체하십시오.)
  • K3B 를 사용할 경우, 도구 > CD > 이미지 기록 을 선택하십시오. '''기록할 이미지' 영역에 ISO 파일을 위치할 수 있습니다. 마지막으로 시작 버튼을 클릭하십시오.

1.2.4. 설치 CD로 부팅하기


중요: 설치를 진행 하기에 앞서 먼저 이 문서를 끝까지 읽어보십시오. 설치를 시작하게되면 이 문서를 읽을 기회가 없을 것입니다.

설치 CD를 기록한 후, 부팅을 합니다. CD-ROM 드라이브에 있는 모든 CD를 제거하고, 시스템을 재시작 한 후, BIOS로 들어갑니다. BIOS에 들어가는 방법은 BIOS에 따라 DEL, F1 혹은 ESC 키를 누르는 것입니다. BIOS 내에서, 부팅순서를 변경하여 CD-ROM 이 하드디스크보다 우선하여 부팅을 시도하도록 합니다. 부팅순서 변경은 주로 "CMOS Setup"에서 찾을 수 있습니다. 만약 이렇게 하지 않는다면, CD-ROM을 무시하고, 하드디스크로 부팅할 것입니다.

다음으로 CD-ROM 에 설치 CD 를 삽입하고 재부팅하십시오. 여러분은 boot 프롬프트를 보게 될 것입니다. 부트 프롬프트가 표시된 화면에서 엔터키를 눌러서 기본 부트 옵션으로 부팅하거나, 부트 프롬프트 뒤에 지정한 커널을 입력하고 엔터를 눌러서 사용자 정의 부트 옵션으로 설치 CD 를 부팅할 수 있습니다.

지정한 커널들이요? 네, 저희는 설치 CD 에서 몇몇 커널들을 제공합니다. 기본 커널은 gentoo 입니다. 다른 커널 옵션은 필요로 하는 하드웨어를 지정하거나 프레임버퍼를 사용하지 않도록 하는 -nofb 변수들 입니다.

아래에 사용 가능한 커널들에 대해 짧게 소개했습니다.

사용가능한 커널옵션들
커널 설명
gentoo 다중 CPU 에 대한 지원을 하는 기본 2.6 커널
gentoo-nofb 프레임버퍼 지원을 제외하고는 gentoo 커널과 같습니다.
memtest86 에러에 대해 메모리를 테스트 합니다.

추가적인 커널 옵션도 지정할 수 있습니다. 추가적인 커널 옵션들은 여러분들이 직접 사용 가능하게 하거나 사용하지 않도록 설정할 수 있습니다. 다음의 목록은 부팅 화면에서 F2 키를 눌렀을 때 얻을 수 있는 메시지와 같습니다.

코드3: 커널에 설정할 수 있는 옵션들
- agpgart       agpgart 를 사용합니다.(그래픽관련 문제가 생기면 한번 해본다.)
- acpi=on       ACPI 지원을 설정합니다.
- ide=nodma     IDE 장치에서 강제로 DMA를 사용하지 않습니다.
- doscsi        SCSI 장치를 검색합니다. (특정 이더넷 카드에서 오류를 일으킬 수 있습니다.)
- dopcmcia      PCMCIA CD-ROM을 사용하려면 이 옵션을 사용합니다.
- nofirewire    Firewire 모듈을 사용하지 않습니다.
- nokeymap      비 영문권 키보드 레이아웃 사용자들은 이 옵션을 사용합니다.
- docache       다른 CD 를 CD-ROM 에 마운트 하기 위해 실행에 필요한 CD의 모든 내용을 메모리에 캐쉬합니다.
- nodetect      hwsetup/kudzu 와 hotplug 를 실행하지 않습니다.
- nousb         USB 관련 모듈을 사용하지 않습니다.
- nodhcp        네트워크 카드가 검색되어도 dhcp를 사용하여 네트워크를 설정하지 않습니다.
- nohotplug     hotplug 서비스를 사용하지 않습니다.
- noapic        APIC 를 해제합니다. (네트워크 카드나 SCSI 등의 하드웨어 장치에 문제가 발생한다면 사용하십시오.)
- noevms        EVMS2 모듈을 로딩하지 않습니다.
- nolvm2        LVM2 모듈을 로딩하지 않습니다.
- hdx=stroke    BIOS가 대용량 하드디스크를 지원하지 않는 경우에도 전체 하드디스크를 파티션 작업 할 수 있도록 허용합니다.
- noload=module1,[module2,[...]]
                module1, module2.. 자리에 쓴 모듈을 불러들이지 않습니다.


이제 여러분의 CD로 부팅하고, (기본 gentoo 커널로 부팅하는 것이 달갑지 않다면) 커널과 부팅 옵션을 선택합니다. (역주: 아마 대부분 신경쓰지 않아도 엔터만 누르면 부팅이 진행됩니다.) 예를 들어, 커널 파라메터로 dopcmcia 를 추가한 gentoo 커널 부트를 어떻게 하는지 보여드립니다.

코드 4: 커널과 부트옵션을 설정한 예
boot: gentoo dopcmcia


다음으로 부트 스크린 화면과 진행막대가 여러분들을 반길 것입니다. 만약 비 US 키보드를 시스템에서 사용한다면 즉시 Alt+F1 키를 눌러서 verbose 모드로 변경한 후, 다음 프롬프트를 확인하십시오. 만약 10초 안에 선택하지 않을 경우 기본 (US 키보드) 레이아웃으로 받아들이고 부트 과정을 진행할 것입니다. 부트 과정이 완료되면, 자동으로 관리자 계정인 "root" 로 "Live" 젠투 리눅스에 로그인 됩니다. 현재 콘솔에서 관리자 프롬프트("#")를 볼 수 있을 것입니다. 또한 Alt-F2, Alt-F3 그리고 Alt-F4 를 눌러서 다른 콘솔로 전환할 수도 있습니다. Alt-F1 을 눌르서 시작할 때의 콘솔로 되돌아 오십시오.

이어서 추가 하드웨어를 설정합니다.

1.2.5. 추가 하드웨어 설정


설치 CD 로 부팅할 때, 설치 CD 는 시스템의 모든 하드웨어를 검색하도록 시도하며 하드웨어를 지원하는 적절한 커널 모듈을 불러옵니다. 대부분의 경우, 이 시도는 잘 동작합니다. 하지만 몇몇 경우에는 여러분이 필요로 하는 커널이 자동으로 적재되지 않을 수 있습니다. 만약 PCI 자동 검색이 여러분들의 몇몇 시스템 하드웨어를 찾지 못했다면, 여러분들은 적절한 커널 모듈을 수동으로 적재해주셔야 할 것입니다.

다음 예제는 (리얼텍 8139 카드를 지원하는) 8139too 모듈을 올리도록 시도합니다.

코드 5: 커널 모듈 올리기
# modprobe 8139too


PCMCIA 지원이 필요하다면, pcmcia init 스크립트를 시작하십시오.

코드 6: PCMCIA 스크립트 시작하기
# /etc/init.d/pcmcia start


참고: 하드 디스크 성능 살짝 올려보기

고급 사용자라면 hdparm 을 이용해서 IDE 하드 디스크의 성능을 미세 조정하길 원할 것입니다. -tT 옵션으로 하드디스크 성능을 테스트 할 수 있습니다. (정확한 결과를 위해 여러번 시도해보십시오.)

코드 7: 디스크 성능 테스트
# hdparm -tT /dev/hda


하드디스크 성능을 미세조정하기 위해, 다음의 코드 중 한가지를 선택하여 실행하십시오. /dev/hda 대신 여러분의 디스크 드라이브를 사용하십시오. (혹은 직접 실험하여 보십시오.)

코드 8: 하드디스크 성능 미세 조정
DMA 모드 활성화:    # hdparm -d 1 /dev/hda
안전 성능 옵션 활성화:  # hdparm -d 1 -A 1 -m 16 -u 1 -a 64 /dev/hda


추가: 사용자 계정

지금 설치하고 있는 컴퓨터에 다른 사용자가 접속가능하게 하거나, 보안상의 이유등으로 일반계정으로 접속해야 할 필요가 있을때, 새로운 사용자를 만들고 root 계정의 비밀번호를 변경해야 합니다.

root 계정의 비밀번호를 바꿀 때는 passwd 유틸리티를 이용합니다.

코드 9: root 비밀번호 바꾸기
# passwd
New password: (비밀번호를 입력하세요.)
Re-enter password: (한번 더 입력합니다.)


사용자 계정을 생성하기 위해 먼저 아이디를 발급하고, 비밀번호를 부여할 것입니다. 이 작업을 하기 위해 useradd 와 passwd 명령을 사용합니다. 다음 예제에서 "john"이라는 사용자를 생성합니다.

코드 10: 새로운 사용자 만들기
# useradd -m -G users john
# passwd john
New password: (john 사용자의 비밀번호를 입력합니다.)
Re-enter password: (한번 더 입력합니다.)


root 계정에서 새로 만든 사용자 계정으로 전환하려면 su 명령어를 사용하면 됩니다.

코드 11: 사용자 변환
# su - john


추가: 인스톨 하면서 문서 보기

설치 과정동안 (CD나 온라인으로) 젠투 핸드북을 보기 원한다면, 사용자 계정을 생성했는지 확인하십시오. (추가: 사용자 계정을 보십시오). 그 다음 Alt-F2 를 눌러서 새로운 터미널로 이동하여 로그인 하십시오.

만약 CD 에 있는 문서를 보기 원한다면 문서를 보기 위해 바로 links2 를 실행할 수 있습니다.

코드 12: CD 에 있는 문서 보기
# links2 /mnt/cdrom/docs/html/index.html


그러나 온라인 상의 젠투 핸드북 문서가 CD 안에 들어 있는 문서보다 최신 버전이기 때문에, 온라인으로 문서를 보는 것이 더 좋습니다. 네트워크 설정 부분을 완료한 다음에만 links2를 사용하여 네트워크로 문서를 볼 수 있습니다. (그렇지 않으면 문서를 보기 위해 인터넷을 사용할 수 없습니다.)

코드 13: 온라인 문서 보기
# links2 http://www.gentoo.org/doc/en/handbook/handbook-x86.xml


Alt+F1을 눌러서 원래 사용하던 터미널로 돌아갈 수 있습니다.

추가: SSH 데몬 시작하기 Optional: Starting the SSH Daemon

인스톨을 진행하고 있는 시스템에 다른 사용자가 온라인으로 접속하길 원할때도 있을 겁니다. (인스톨을 도와주기 위해서라던가 하는 이유로 말이죠.) 그래서 그 사람이 접속하기 위한 별도의 사용자 계정을 미리 만들어 두던가, 뭐 믿을 만한 사람이라면 root 패스워드를 직접 가르쳐 줄 수도 있을겁니다.

일단 그러려면 SSH 데몬을 띄워야 합니다.

코드 14: SSH 데몬 실행하기
# /etc/init.d/sshd start

ssh 를 사용하기 위해서는 일단 먼저 네트웍이 설정되어야 합니다. 다음 챕터에서 네트웍 설정을 살펴 봅시다.

1.3. 3. 네트웍 설정


1.3.1. 3.a 자동으로 네트웍 잡기


정말 이거만 하면 돼?

네트웍 이더넷 카드가 DHCP 로 연결 된다면, 자동으로 네트웍 설정에 대한 거의 모든걸 다 해줍니다. 네트웍 설정이 끝나면, 인스톨CD 안에 있는 ssh, scp, ping, irssi, wget, links 등 네트웍 관련 명령들을 사용할 수 있습니다.

네트웍 설정이 다 끝났으면 /sbin/ifconfig 명령으로 설정 상태를 볼 수 있습니다. ifconfig 를 실행하면 lo 등의 다른 네트웍 장치와 함께 설정된 이더넷 네트웍 카드의 상태가 나옵니다. 보통 이더넷 카드가 한장이라면 특별한 경우가 아닌 한 eth0 로 설정됩니다.

코드 1: /sbin/ifconfig 를 실행했을때
# /sbin/ifconfig
(...)
eth0      Link encap:Ethernet  HWaddr 00:50:BA:8F:61:7A
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::50:ba8f:617a/10 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1498792 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1284980 errors:0 dropped:0 overruns:0 carrier:0
          collisions:1984 txqueuelen:100
          RX bytes:485691215 (463.1 Mb)  TX bytes:123951388 (118.2 Mb)
          Interrupt:11 Base address:0xe800 

참고: 프록시 설정

프록시를 통해서 인터넷에 접속한다면, 인스톨과정에서 프록시를 설정해 주어야 합니다. (역주: 젠투는 인스톨과정이 네트웍과 깊이 연관되어 있기때문에 어찌 되었던 네트웍은 설정해야 합니다.) 프록시 서버를 설정하는건 매우 쉽습니다. 그냥 프록시 서버 설정에 관련된 몇가지 변수 값만 세팅해주면 되니까요.

왠만한 경우에는 단순히 프록시 서버의 호스트네임만 설정해 주면 세팅이 끝납니다. 즉, proxy.gentoo.org 에 포트 번호 8080 써주면 끝이라는 거지요.

코드 2: 프록시 서버 설정
(HTTP 프록시 서버의 경우)
# export http_proxy="http://proxy.gentoo.org:8080"
(FTP 프록시 서버의 경우)
# export ftp_proxy="ftp://proxy.gentoo.org:8080"
(RSYNC 프록시 서버의 경우)
# export RSYNC_PROXY="proxy.gentoo.org:8080"

프록시 서버가 유저이름과 패스워드를 요구한다면 다음과 같이 설정하면 됩니다.

코드 3: proxy 변수에 유저와 패스워드 추가하기
http://username:password@proxy.gentoo.org:8080

네트웍 테스트 하기

네트웍 설정이 다 되었다고 생각이 들면 ISP의 DNS 서버나 (/etc/resolv.conf 에서 찾으 실수 있습니다.) 마음에 드는 웹사이트에 ping 을 날려 테스트 해볼 수 있습니다. 제대로 응답이 돌아온다면 DNS 네임이나 네트웍 설정등이 제대로 된것입니다.

코드 4: 네트웍테스트
# ping -c 3 www.yahoo.com

지금 네트웍이 동작한다면 이후 섹션은 안보셔도 상관없습니다. 바로 디스크 파티셔닝 섹션으로 넘어가세요. 네트웍이 동작하지 않는 다면 이후 섹션을 계속 읽어 보십시오.

1.3.2. 3.b 자동으로 네트웍 설정하기


네트웍이 바로 동작하지 않는 다면 net-setup(일반적인 랜 설정이나 무선랜설정), adsl-setup(ADSL 사용자일경우), pptp(PPTP 사용자일경우 - x86 시스템에서만 사용할 수 있습니다.) 중 하나를 이용해 네트웍을 설정해야 합니다.

만약 네트웍이 어디에도 해당되지 않을 때에는 수동으로 네트웍 설정하기로 가야 합니다.

 * 일반적인 네트웍 세팅일 경우 : net-setup
 * ADSL 유저 : RP-PPPoE
 * PPTP 유저 : PPTP

일반적인 경우: net-setup을 이용해 네트웍 설정

net-setup 스크립트를 이용하면 쉽고 간단하게 네트웍을 설정할 수 있습니다.

코드 5: net-setup 스크립트 실행
# net-setup eth0

net-setup 스크립트가 물어보는 대로 설정을 해주면 네트웍 설정이 됩니다. 설정이 다 끝나고 나면 아마 네트웍에 연결되어 있을 겁니다. 위에 나온 네트웍 테스트를 실행해보고 제대로 결과가 나온다면 성공한것입니다. 계속해서 젠투를 인스톨하면 됩니다. 당연히 이후 섹션은 안읽어 봐도 되고 (역주: 그냥 궁금하다면 읽어봐도 누가 때리지 않습니다.^^) 디스크 파티션 섹션으로 넘어가십시오.

여전히 네트웍이 동작하지 않는다면 네트웍을 수동으로 설정하는 방법 밖에 없습니다.

선택사항: RP-PPPoE를 이용한 네트웍설정

PPPoE를 이용해 인터넷에 접속해야 하는 환경이라면, 인스톨 시디에 포함된 rp-pppoe 패키지로 쉽고 간단하게 접속할 수 있습니다. adsl-setup 으로 네트웍연결에 대한 사항을 설정합니다. adsl모뎀에 연결할 이더넷의 장치명과(역주: 랜카드가 한장일 경우 특별한 경우가 아닌한 eth0입니다.) 이어서 유저네임과 패스워드를 입력하고, DNS 서버의 IP를 적어 줍니다. 그리고 방화벽을 사용할지 않할지 설정하면 됩니다.

코드 6: rp-pppoe 사용
# adsl-setup
# adsl-start

문제가 생긴다면, /etc/ppp/pap-secrets 와 /etc/ppp/chap-secrets 에 유저네임과 패스워드를 제대로 입력했는지 확인해 보십시오. 그리고 이더넷 디바이스 명을 제대로 입력했는지도 확인해 보십시오. 이더넷 디바이스가 존재하지 않는다면(역주:ifconfig로 확인해보면 됩니다.) 자신의 랜카드에 맞는 모듈을 올려주시면 됩니다. 수동으로 네트웍 설정하는 섹션에서 네트웍모듈을 어떻게 올려야 하는지 설명하겠습니다.

모든게 다 제대로 동작한다면 역시 디스크 파티셔닝 섹션으로 넘어가십시오.

선택사항: PPTP 를 이용한 네트웍 설정

주의: PPTP 는 x86 시스템에서만 지원됩니다.

PPTP를 이용하는 시스템 사용자라면 인스톨레이션 시디에 들어 있는 pptpclient 패키지를 이용해 네트웍을 설정할 수 있습니다. /etc/ppp/pap-secrets 와 /etc/ppp/chap-secrets를 설정해서 기본적인 설정을 정확하게 해 주십시오. 유저네임과 패스워드정도만 제대로 넣으시면 됩니다.

코드 7: /etc/ppp/chap-secrets 수정
# nano -w /etc/ppp/chap-secrets

그리고 /etc/ppp/options.pptp 도 수정합니다.

코드 8: /etc/ppp/options.pptp 수정
# nano -w /etc/ppp/options.pptp

다 설정했으면 그냥 pptp 만 실행하면 됩니다.

코드 9: dial-in 서버에 연결
# pptp <server ip>

네트웍이 된다면 디스크파티션으로 넘어갑니다.

1.3.3. 3.c 수동으로 네트웍 설정하기


네트웍 모듈올리기

인스톨 시디가 부팅될때, 하드웨어 장치를 자동으로 찾아서 모듈을 올리게끔 작동하긴 하지만 몇몇 하드웨일 경우에는 자동으로 찾지 못하는 경우가 발생합니다. 시스템의 하드웨어들을 전부다 찾아서 모듈을 알아서 올려준다면 참 고마운 일이겠지만 그렇지 못할 경우에는 우리가 직접 모듈을 찾아서 올려주어야 겠죠?

net-setup 이나 adsl-setup 이 실패했다면 네트웍카드가 존재하지 않을 가능성이 높습니다. 그렇다면 모듈을 찾아서 올려주야 합니다.

네트웍 관련 모듈들이 어떤게 있는지 알아볼땐 쉽게 ls 를 이용하세요.

코드 10: 모듈들 찾아보기
# ls /lib/modules/`uname -r`/kernel/drivers/net

네트웍카드에 해당하는 드라이버를 찾았다면 modprobe 명령으로 모듈을 올리세요.

코드 11: modeprobe를 이용해 커널모듈올리기
(사용자의 랜카드가 pcnet32일경우라면,)
# modprobe pcnet32

네트웍카드가 제대로 인식됐는지 확인하기 위해서는 ifconfig를 이용합니다. 네트웍카드가 인식되었다면 다음과 비슷한 메시지가 출력됩니다.

코드 12: 네트웍카드가 제대로 인식되었는지 테스트해보기
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr FE:FD:00:00:00:00  
          BROADCAST NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

에러메시지가 나온다면 네트웍카드를 인식하지 못한것입니다.

코드 13: 네트웍카드가 인식되지 않았을때
# ifconfig eth0
eth0: error fetching interface information: Device not found

네트웍카드가 여러장일때는 eth0, eth1.. 이런식으로 숫자가 올라갑니다. 사용하는 네트웍카드의 이름을 잘 기억해 두십시오. 특별한 경우가 아닌한 이 문서에서는 eth0을 기본적인 네트웍카드 이름으로 사용합니다.

네트웍카드가 인식되었다면 net-setup 이나 adsl-setup 을 다시 실행해서 네트웍을 설정합니다. 물론 자신있는 사람은 수동 편집해도 됩니다.

네트웍 설정에 기반하여 아래의 선택 사항을 고르세요.

  • DHCP 사용은 IP를 자동으로 받는 경우에 선택합니다.
  • 무선 랜 접속은 무선 랜 카드를 사용할 때 사용합니다.
  • 네트웍 용어 이해는 네트워크에 대한 정보를 설명합니다.
  • ifconfig와 route 사용은 수동으로 설정하는 방법을 설명합니다.

DHCP 사용

DHCP (Dynamic Host Configuration Protocol, 동적 호스트 설정 규약) 는 자동으로 네트워크 정보 (IP 주소, 넷마스크, 브로드캐스트 주소, 게이트웨이, 네임서버 등) 를 받을 수 있게 합니다. DHCP는 네트웍에 DHCP 서버가 있는 경우에 (또는 인터넷 업체가 DHCP 서비스를 제공해야) 적용됩니다. 네트워크 인터페이스가 정보를 자동으로 받기 위해서 dhcpcd를 사용합니다.

코드 14: dhcpcd 사용
# dhcpcd eth0
어떤 네트워크 관리자는 DHCP 서버가 제공하는
호스트네임과 도메인네임을 사용하기를 요구하는 경우도 있습니다.
이 경우에 아래의 명령을 입력하세요.
# dhcpcd -HD eth0

만약 (구글과 같은 인터넷 서버로의 핑을 시도하는) 이것이 동작한다면, 모든 설정이 완료되고 계속할 준비가 된 것입니다. 이 섹션의 나머지 부분을 건너뛰고 디스크 설정 부분으로 넘어가세요!

1.3.4. 3.d 무선 연결 준비하기


중요: iwconfig 명령은 x86, amd64, ppc 설치 시디에서만 사용할 수 있습니다. 다음에 제시된 linux-wlan-ng 프로젝트의 설명서에 의한 다른 방식으로 작업하는 확장기능을 가져올 수도 있습니다.

만약 무선 카드 (802.11) 를 사용하고 있다면, 아마 무엇을 하기전에 먼저 무선 연결을 설정해야 할 필요가 있을 것입니다. 현재 무선 카드에 대한 무선 연결 설정을 보기 위해 iwconfig명령을 사용할 수 있습니다. ifconfig실행 화면은 아마 다음처럼 보일 것입니다:

코드 15: 현재의 무선연결 설정
# iwconfig eth0
eth0      IEEE 802.11-DS  ESSID:"GentooNode"                                   
          Mode:Managed  Frequency:2.442GHz  Access Point: 00:09:5B:11:CC:F2    
          Bit Rate:11Mb/s   Tx-Power=20 dBm   Sensitivity=0/65535               
          Retry limit:16   RTS thr:off   Fragment thr:off                       
          Power Management:off                                                  
          Link Quality:25/10  Signal level:-51 dBm  Noise level:-102 dBm        
          Rx invalid nwid:5901 Rx invalid crypt:0 Rx invalid frag:0 Tx          
          excessive retries:237 Invalid misc:350282 Missed beacon:84            

중요: 어떤 무선카드는 장치 이름으로 eth0 대신 wlan0 이나 ra0 을 가질 것입니다. 정확한 장치 이름을 결정하기 위해서 어떤 명령행 변수 없이 iwconfig를 실행하세요.

대부분의 사용자를 위해서라면,변경해야 할 두가지 중요한 설정사항이 있는데, ESSID (무선 네트워크 이름) 또는 WEP키값이 그것입니다. 만약 ESSID 와 조회된 엑세스 포인트 주소가 사용중인 엑세스 포인트 이고 WEP을 사용하지 않는다면, 무선망이 동작중인 것입니다. 만약 ESSID를 변경해야 한다거나 WEP키를 추가해야 한다면, you can issue the following commands:

코드 16: ESSID 혹은 WEP 키 값을 추가하는 방법
(This sets the network name to "GentooNode")
# iwconfig eth0 essid GentooNode

(This sets a hex WEP key)
# iwconfig eth0 key 1234123412341234abcd

(This sets an ASCII key - prefix it with "s:")
# iwconfig eth0 key s:some-password

이렇게 하고 나서 무선연결 설정을 iwconfig를 이용해서 다시 확인할 수 있습니다. 한번이라도 무선 연결이 동작한다면, 다음 섹션(네트워크 용어의 이해)에서 기술된바와 같은 IP수준의 네트워크 옵션 설정을 계속하거나 이전에 설명된 net-setup을 사용하여 설정을 계속할 수 있습니다.

1.3.5. 3.e 네트워크 용어의 이해


중요: IP주소, 브로트캐스트 주소, 넷마스크, 네임서버에 대해 안다면 여기의 하위섹션을 건너뛰고 ifconfig와 route사용부분으로 넘어가실 수 있습니다.

이 위의 모든 것들에 대해 실패했다면, 네트워크 설정을 수작업으로 해야 할 것입니다. 이게 다 어려운 건 아닙니다. 하지만 만족할만한 네트워크 설정을 하기 위해서 몇몇 네트워크 용어에 친숙해야 할 필요가 있습니다. 이걸 읽은 다음에는 게이트 웨이가 무엇인지, 넷마스크는 무엇을 위해 전달 되는 것인지, 브로드캐스트 주소는 어떻게 구성되는지 네임서버는 왜 필요한지에 대해서 알게 될 것입니다.

네트워크 상에서 호스트는 IP주소(인터넷 프로토콜 주소)를 통해 인증됩니다. 이러한 주소는 0부터 255까지의 네개의 숫자조합으로 구성됩니다. 음, 이것이 최소한 우리가 인식할 수 있는 것입니다. 사실 IP 주소는 32비트의 이진수로 구성됩니다. 아래 예제를 보도록 하지요 =) :

코드 17: IP 주소 예제
IP Address (numbers):   192.168.0.2
IP Address (bits):      11000000 10101000 00000000 00000010
                        -------- -------- -------- --------
                           192      168       0        2

이러한 IP 주소는 관계된 모든 접근가능한 네트워크 상에서 멀리 떨어진 호스트에 대해 유일함을 지니고 있습니다 (예를 들자면 모든 접근가능한 호스트는 반드시 고유의 IP주소를 가지고 있어야 합니다). 내 외부 네트워크 상에서 호스트를 구별하기 위해서 IP주소는 네트워크와 호스트 두 부분으로 나뉩니다.

(네트워크의) 분리는 넷마스크로 기술되는데, 0의 모임과 1의 모임이 함께 합니다. IP에 사상될 수 있는 어떤 한 부분은 네트워크 파트, 다른 부분은 호스트 파트입니다. 보통 넷마스크는 IP어드레스와 같이 기술됩니다.

코드 18: 네트워크와 호스트의 분리 예제
IP-address:    192      168      0         2
            11000000 10101000 00000000 00000010
Netmask:    11111111 11111111 11111111 00000000
               255      255     255        0
           +--------------------------+--------+
                    Network              Host

달리 말하자면 192.168.0.14 또한 예제로 제시된 네트워크의 한 부분이지만 192.168.1.2는 아니라고 볼 수 있습니다.

브로드캐스트 주소는 같은 네트워크 영역이지만 그중 한부분은 호스트파트로서 존재합니다. 네트워크 상의 모든 호스트가 이 IP주소를 따릅니다. 이는 사실 패킷의 브로드캐스팅을 의미합니다.

코드 19: 브로드캐스트 주소
IP-address:    192      168      0         2
            11000000 10101000 00000000 00000010
Broadcast:  11000000 10101000 00000000 11111111
               192      168      0        255
           +--------------------------+--------+
                     Network             Host

인터넷 탐색을 가능케 하기 위해 반드시 인터넷 연결을 공유하는 것이 어떤 것인지를 알아야 합니다. 이러한 포스트를 게이트웨이라 부릅니다. 이것은 일반적 호스트이기 때문에 일반 IP주소를 갖습니다(for instance 192.168.0.1).

우리는 이미 모든 호스트가 각각에 대한 IP를 가지도록 지정하였습니다. 각각의 호스트를 (IP 대신)이름으로서 접근이 가능하려면 이름(dev.gentoo.org 같은것)을 (64.5.62.82 와 같은)IP주소로 변환하는 서비스가 필요합니다. 이러한 서비스를 네임 서비스라고 합니다. 이러한 서비스를 사용하기 위해서는 /etc/resolv.conf에 네임서버를 명시해주어야 합니다.

어떤 경우에는 게이트웨이가 네임서버를 잡아내기도 합니다. 그렇지 않다면 ISP 서비스를 통해 네임서버를 이용할 것입니다.

요약하자면 계속하기 전에 다음과 같은 정보를 필요로 할 것입니다 : Network Item Example Your IP address 192.168.0.2 Netmask 255.255.255.0 Broadcast 192.168.0.255 Gateway 192.168.0.1 Nameserver(s) 195.130.130.5, 195.130.130.133

1.3.6. 3.f ifconfig 와 route 의 사용


네트워크 설정은 3단계로 구성됩니다. 먼저 ifconfig를 사용하여 자신의 호스트에 할당할 IP주소를 할당합니다. 그러고 나면 route를 통해 게이트로의 라우팅을 설정합니다. 마지막으로 /etc/resolv.conf에 네임서버 주소를 위치하여 마무리합니다.

IP주소를 할당하기 위해서 나름 할당할 IP주소, 브로드캐스트 주소, 넷마스크 주소가 필요합니다. 일단 그것들을 입수하고나면 다음 명령을 실행하는데 ${IP_ADDR}은 IP주소를, ${BROADCAST}는 브로드캐스트 주소를, ${NETMASK}는 넷마스크를 대신하여 표기하였습니다.

코드 20: ifconfig 사용
# ifconfig eth0 ${IP_ADDR} broadcast ${BROADCAST} netmask ${NETMASK} up

이제 route를 통해 라우팅을 설정합니다. ${GATEWAY}는 게이트웨이 IP 주소를 의미합니다 : 코드 21: route 사용
# route add default gw ${GATEWAY}

이제 편집기 상에서 /etc/resolv.conf 를 열어보시기 바랍니다 (예를 들자면 우리는 nano를 사용합니다):

코드 22: /etc/resolv.conf 생성
# nano -w /etc/resolv.conf

이제 다음과 같은 형태로 하나 이상의 네임서버를 기입합니다. ${NAMESERVER1} 와 ${NAMESERVER2}는 할당할 네임서버 주소들입니다.

코드 23: /etc/resolv.conf 형태
nameserver ${NAMESERVER1}
nameserver ${NAMESERVER2}

다 되었습니다. 이제 (Google과 같은... 구글만세 (/-_-)/) 인터넷 서버에 핑을 시도하여 네트워크를 테스트 해보기 바랍니다. 만약 이게 된다면 축하할만한(=3) 일입니다. 이제 젠투를 설치할 준비가 된 것입니다. 디스크 준비로 넘어가십시오.

1.4. 디스크 준비

1.4.1. 4.a 블록 디바이스 소개

1.4.1.1. Block Devices


이제 우리는 디스크 지향 측면으로서의 젠투리눅스와 파일 시스템과 파티션 블록디바이스 개념이 포함된 일반적인 시각으로서의 리눅스에 대해 알아보겠습니다. 그러면 적어도 한번은 파일 시스템과 디스크 착탈(ins and outs of disks)에 익숙하다면, 젠투 리눅스 설치를 위해 파일 시스템과 파티션을 설정하는 과정으로 안내될 것입니다.

모든 과정에 앞서 블록 디바이스에 대해 소개하도록 하겠습니다. 대개 잘 알려진 블록 디바이스는 아마 /dev/hda와 같이 리눅스 시스템에서 표시되는 첫번째 IDE드라이브가 그 중 하나일 것입니다. 만약 시스템에셔 SCSI 나 SATA를 사용한다면 첫번째 하드드라이브는 /dev/sda가 될 것입니다.

블록 디바이스는 디스크에게 있어 그 상위의 추상인터페이스로 표현됩니다. 사용자 프로그램들은 이들 블록디바이스를 IDE냐 SCSI냐 아니면 그 이외의 다른 것이냐에 관계없이 응용프로그램과 디스크간 상호작용하는데 사용할 수 있습니다. 프로그램은 간단하게 디스크상의 저장공간에 대해 주소 매김을 할 수 있는데 이 저장공간은 연속된 다발형태로 존재하며 임의로 접근가능한 512바이트 크기의 블록으로 구성됩니다.

1.4.1.2. 파티션


Although it is theoretically possible to use a full disk to house your Linux system, this is almost never done in practice. Instead, full disk block devices are split up in smaller, more manageable block devices. On x86 systems, these are called partitions.

Partitions are divided in three types: primary, extended and logical.

A primary partition is a partition which has its information stored in the MBR (master boot record). As an MBR is very small (512 bytes) only four primary partitions can be defined (for instance, /dev/hda1 to /dev/hda4).

An extended partition is a special primary partition (meaning the extended partition must be one of the four possible primary partitions) which contains more partitions. Such a partition didn't exist originally, but as four partitions were too few, it was brought to life to extend the formatting scheme without losing backward compatibility.

A logical partition is a partition inside the extended partition. Their definitions aren't placed inside the MBR, but are declared inside the extended partition.

Advanced Storage

The x86 Installation CDs provide support for EVMS and LVM2. EVMS and LVM2 increase the flexibility offered by your partitioning setup. During the installation instructions, we will focus on "regular" partitions, but it is still good to know EVMS and LVM2 are supported as well.

4.b. Designing a Partitioning Scheme

Default Partitioning Scheme

If you are not interested in drawing up a partitioning scheme for your system, you can use the partitioning scheme we use throughout this book: Partition Filesystem Size Description /dev/hda1 ext2 32M Boot partition /dev/hda2 (swap) 512M Swap partition /dev/hda3 ext3 Rest of the disk Root partition

If you are interested in knowing how big a partition should be, or even how many partitions you need, read on. Otherwise continue now with partitioning your disk by reading Using fdisk to Partition your Disk.

How Many and How Big?

The number of partitions is highly dependent on your environment. For instance, if you have lots of users, you will most likely want to have your /home separate as it increases security and makes backups easier. If you are installing Gentoo to perform as a mailserver, your /var should be separate as all mails are stored inside /var. A good choice of filesystem will then maximise your performance. Gameservers will have a separate /opt as most gaming servers are installed there. The reason is similar for /home: security and backups. You will definitely want to keep /usr big: not only will it contain the majority of applications, the Portage tree alone takes around 500 Mbyte excluding the various sources that are stored in it.

As you can see, it very much depends on what you want to achieve. Separate partitions or volumes have the following advantages:

  • You can choose the best performing filesystem for each partition or volume
  • Your entire system cannot run out of free space if one defunct tool is continuously writing files to a partition or volume
  • If necessary, file system checks are reduced in time, as multiple checks can be done in parallel (although this advantage is more with multiple disks than it is with multiple partitions)
  • Security can be enhanced by mounting some partitions or volumes read-only, nosuid (setuid bits are ignored), noexec (executable bits are ignored) etc.

However, multiple partitions have one big disadvantage: if not configured properly, you might result in having a system with lots of free space on one partition and none on another. There is also a 15-partition limit for SCSI and SATA.

As an example partitioning, we show you one for a 20GB disk, used as a demonstration laptop (containing webserver, mailserver, gnome, ...):

Code Listing 1: Filesystem usage example

$ df -h Filesystem Type Size Used Avail Use% Mounted on /dev/hda5 ext3 509M 132M 351M 28% / /dev/hda2 ext3 5.0G 3.0G 1.8G 63% /home /dev/hda7 ext3 7.9G 6.2G 1.3G 83% /usr /dev/hda8 ext3 1011M 483M 477M 51% /opt /dev/hda9 ext3 2.0G 607M 1.3G 32% /var /dev/hda1 ext2 51M 17M 31M 36% /boot /dev/hda6 swap 516M 12M 504M 2% <not mounted> (Unpartitioned space for future usage: 2 GB)

/usr is rather full (83% used) here, but once all software is installed, /usr doesn't tend to grow that much. Although allocating a few gigabytes of disk space for /var may seem excessive, remember that Portage uses this partition by default for compiling packages. If you want to keep /var at a more reasonable size, such as 1GB, you will need to alter your PORTAGE_TMPDIR variable in /etc/make.conf to point to the partition with enough free space for compiling extremely large packages such as OpenOffice.

4.c. Using fdisk to Partition your Disk

The following parts explain how to create the example partition layout described previously, namely: Partition Description /dev/hda1 Boot partition /dev/hda2 Swap partition /dev/hda3 Root partition

Change your partition layout according to your own preference.

Viewing the Current Partition Layout

fdisk is a popular and powerful tool to split your disk into partitions. Fire up fdisk on your disk (in our example, we use /dev/hda):

Code Listing 2: Starting fdisk

# fdisk /dev/hda

Once in fdisk, you'll be greeted with a prompt that looks like this:

Code Listing 3: fdisk prompt

Command (m for help):

Type p to display your disk's current partition configuration:

Code Listing 4: An example partition configuration

Command (m for help): p

Disk /dev/hda: 240 heads, 63 sectors, 2184 cylinders Units = cylinders of 15120 * 512 bytes

Device Boot Start End Blocks Id System /dev/hda1 1 14 105808+ 83 Linux /dev/hda2 15 49 264600 82 Linux swap /dev/hda3 50 70 158760 83 Linux /dev/hda4 71 2184 15981840 5 Extended /dev/hda5 71 209 1050808+ 83 Linux /dev/hda6 210 348 1050808+ 83 Linux /dev/hda7 349 626 2101648+ 83 Linux /dev/hda8 627 904 2101648+ 83 Linux /dev/hda9 905 2184 9676768+ 83 Linux

Command (m for help):

This particular disk is configured to house seven Linux filesystems (each with a corresponding partition listed as "Linux") as well as a swap partition (listed as "Linux swap").

Removing all Partitions

We will first remove all existing partitions from the disk. Type d to delete a partition. For instance, to delete an existing /dev/hda1:

Code Listing 5: Deleting a partition

Command (m for help): d Partition number (1-4): 1

The partition has been scheduled for deletion. It will no longer show up if you type p, but it will not be erased until your changes have been saved. If you made a mistake and want to abort without saving your changes, type q immediately and hit enter and your partition will not be deleted.

Now, assuming that you do indeed want to wipe out all the partitions on your system, repeatedly type p to print out a partition listing and then type d and the number of the partition to delete it. Eventually, you'll end up with a partition table with nothing in it:

Code Listing 6: An empty partition table

Disk /dev/hda: 30.0 GB, 30005821440 bytes 240 heads, 63 sectors/track, 3876 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System

Command (m for help):

Now that the in-memory partition table is empty, we're ready to create the partitions. We will use a default partitioning scheme as discussed previously. Of course, don't follow these instructions to the letter if you don't want the same partitioning scheme!

Creating the Boot Partition

We first create a small boot partition. Type n to create a new partition, then p to select a primary partition, followed by 1 to select the first primary partition. When prompted for the first cylinder, hit enter. When prompted for the last cylinder, type +32M to create a partition 32 Mbyte in size:

Code Listing 7: Creating the boot partition

Command (m for help): n Command action
e extended p primary partition (1-4)
p Partition number (1-4): 1 First cylinder (1-3876, default 1): (Hit Enter) Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-3876, default 3876): +32M

Now, when you type p, you should see the following partition printout:

Code Listing 8: Created boot partition

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes 240 heads, 63 sectors/track, 3876 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System /dev/hda1 1 14 105808+ 83 Linux

We need to make this partition bootable. Type a to toggle the bootable flag on a partition and select 1. If you press p again, you will notice that an * is placed in the "Boot" column.

Creating the Swap Partition

Let's now create the swap partition. To do this, type n to create a new partition, then p to tell fdisk that you want a primary partition. Then type 2 to create the second primary partition, /dev/hda2 in our case. When prompted for the first cylinder, hit enter. When prompted for the last cylinder, type +512M to create a partition 512MB in size. After you've done this, type t to set the partition type, 2 to select the partition you just created and then type in 82 to set the partition type to "Linux Swap". After completing these steps, typing p should display a partition table that looks similar to this:

Code Listing 9: Partition listing after creating a swap partition

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes 240 heads, 63 sectors/track, 3876 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System /dev/hda1 * 1 14 105808+ 83 Linux /dev/hda2 15 81 506520 82 Linux swap

Creating the Root Partition

Finally, let's create the root partition. To do this, type n to create a new partition, then p to tell fdisk that you want a primary partition. Then type 3 to create the third primary partition, /dev/hda3 in our case. When prompted for the first cylinder, hit enter. When prompted for the last cylinder, hit enter to create a partition that takes up the rest of the remaining space on your disk. After completing these steps, typing p should display a partition table that looks similar to this:

Code Listing 10: Partition listing after creating the root partition

Command (m for help): p

Disk /dev/hda: 30.0 GB, 30005821440 bytes 240 heads, 63 sectors/track, 3876 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes

Device Boot Start End Blocks Id System /dev/hda1 * 1 14 105808+ 83 Linux /dev/hda2 15 81 506520 82 Linux swap /dev/hda3 82 3876 28690200 83 Linux

Saving the Partition Layout

To save the partition layout and exit fdisk, type w.

Code Listing 11: Save and exit fdisk

Command (m for help): w

Now that your partitions are created, you can now continue with Creating Filesystems.

4.d. Creating Filesystems

Introduction

Now that your partitions are created, it is time to place a filesystem on them. If you don't care about what filesystem to choose and are happy with what we use as default in this handbook, continue with Applying a Filesystem to a Partition. Otherwise read on to learn about the available filesystems...

Filesystems?

The Linux kernel supports various filesystems. We'll explain ext2, ext3, ReiserFS, XFS and JFS as these are the most commonly used filesystems on Linux systems.

ext2 is the tried and true Linux filesystem but doesn't have metadata journaling, which means that routine ext2 filesystem checks at startup time can be quite time-consuming. There is now quite a selection of newer-generation journaled filesystems that can be checked for consistency very quickly and are thus generally preferred over their non-journaled counterparts. Journaled filesystems prevent long delays when you boot your system and your filesystem happens to be in an inconsistent state.

ext3 is the journaled version of the ext2 filesystem, providing metadata journaling for fast recovery in addition to other enhanced journaling modes like full data and ordered data journaling. ext3 is a very good and reliable filesystem. It has an additional hashed b-tree indexing option that enables high performance in almost all situations. You can enable this indexing by adding -O dir_index to the mke2fs command. In short, ext3 is an excellent filesystem.

ReiserFS is a B*-tree based filesystem that has very good overall performance and greatly outperforms both ext2 and ext3 when dealing with small files (files less than 4k), often by a factor of 10x-15x. ReiserFS also scales extremely well and has metadata journaling. As of kernel 2.4.18+, ReiserFS is solid and usable as both general-purpose filesystem and for extreme cases such as the creation of large filesystems, the use of many small files, very large files and directories containing tens of thousands of files.

XFS is a filesystem with metadata journaling which comes with a robust feature-set and is optimized for scalability. We only recommend using this filesystem on Linux systems with high-end SCSI and/or fibre channel storage and an uninterruptible power supply. Because XFS aggressively caches in-transit data in RAM, improperly designed programs (those that don't take proper precautions when writing files to disk and there are quite a few of them) can lose a good deal of data if the system goes down unexpectedly.

JFS is IBM's high-performance journaling filesystem. It has recently become production-ready and there hasn't been a sufficient track record to comment positively nor negatively on its general stability at this point.

Applying a Filesystem to a Partition

To create a filesystem on a partition or volume, there are tools available for each possible filesystem: Filesystem Creation Command ext2 mke2fs ext3 mke2fs -j reiserfs mkreiserfs xfs mkfs.xfs jfs mkfs.jfs

For instance, to have the boot partition (/dev/hda1 in our example) in ext2 and the root partition (/dev/hda3 in our example) in ext3 (as in our example), you would use:

Code Listing 12: Applying a filesystem on a partition

# mke2fs /dev/hda1 # mke2fs -j /dev/hda3

Now create the filesystems on your newly created partitions (or logical volumes).

Activating the Swap Partition

mkswap is the command that is used to initialize swap partitions:

Code Listing 13: Creating a Swap signature

# mkswap /dev/hda2

To activate the swap partition, use swapon:

Code Listing 14: Activating the swap partition

# swapon /dev/hda2

Create and activate the swap with the commands mentioned above.

4.e. Mounting

Now that your partitions are initialized and are housing a filesystem, it is time to mount those partitions. Use the mount command. Don't forget to create the necessary mount directories for every partition you created. As an example we mount the root and boot partition:

Code Listing 15: Mounting partitions

# mount /dev/hda3 /mnt/gentoo # mkdir /mnt/gentoo/boot # mount /dev/hda1 /mnt/gentoo/boot

Note: If you want your /tmp to reside on a separate partition, be sure to change its permissions after mounting: chmod 1777 /mnt/gentoo/tmp. This also holds for /var/tmp.

We will also have to mount the proc filesystem (a virtual interface with the kernel) on /proc. But first we will need to place our files on the partitions.

Continue with Installing the Gentoo Installation Files. 5. Installing the Gentoo Installation Files

5.a. Installing a Stage Tarball

Setting the Date/Time Right

Before you continue you need to check your date/time and update it. A misconfigured clock may lead to strange results in the future!

To verify the current date/time, run date:

Code Listing 1: Verifying the date/time

# date Fri Mar 29 16:21:18 CEST 2005

If the date/time displayed is wrong, update it using the date MMDDhhmmYYYY syntax (Month, Day, hour, minute and Year). For instance, to set the date to March 29th, 16:21 in the year 2005:

Code Listing 2: Setting the date/time

# date 032916212005

Making your Choice

The next step you need to perform is to install the stage3 tarball onto your system. You have the option of downloading the required tarball from the Internet or, if you are booted from one of the Gentoo Universal Installation CDs, copy it over from the CD itself. If you have a Universal CD and the stage you want to use is on the CD, downloading it from the Internet is just a waste of bandwidth as the stage files are the same. In most cases, the command uname -m can be used to help you decide which stage file to download.

  • Default: Using a Stage from the Internet
  • Alternative: Using a Stage from the Installation CD

5.b. Default: Using a Stage from the Internet

Downloading the Stage Tarball

Go to the Gentoo mountpoint at which you mounted your filesystems (most likely /mnt/gentoo):

Code Listing 3: Going to the Gentoo mountpoint

# cd /mnt/gentoo

Depending on your installation medium, you have a couple of tools available to download a stage. If you have links2 available, then you can immediately surf to the Gentoo mirrorlist and choose a mirror close to you.

If you don't have links2 available you should have lynx at your disposal. If you need to go through a proxy, export the http_proxy and ftp_proxy variables:

Code Listing 4: Setting proxy information for lynx

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

We will now assume that you have links2 at your disposal.

Pick the releases/ directory, followed by your architecture (for instance x86/) and the Gentoo version (2005.1/ or 2005.1-r1/ if available) to finish up with the stages/ directory. There you should see all available stage files for your architecture (they might be stored within subdirectories named to the individual sub architectures). Select one and press D to download. When you're finished, press Q to quit the browser.

Code Listing 5: Surfing to the mirror listing with links2


(If you need proxy support with links2:) # links2 -http-proxy proxy.server.com:8080 http://www.gentoo.org/main/en/mirrors.xml

Make sure you download a stage3 tarball - installations using a stage1 or stage2 tarball are not supported anymore.

If you want to check the integrity of the downloaded stage tarball, use md5sum and compare the output with the MD5 checksum provided on the mirror. For instance, to check the validity of the x86 stage tarball:

Code Listing 6: Example checking integrity of a stage tarball

# md5sum -c stage3-x86-2005.1-r1.tar.bz2.md5 stage3-x86-2005.1-r1.tar.bz2: OK

Unpacking the Stage Tarball

Now unpack your downloaded stage onto your system. We use tar to proceed as it is the easiest method:

Code Listing 7: Unpacking the stage

# tar xvjpf stage3-*.tar.bz2

Make sure that you use the same options (xvjpf). 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.

Note: Some architectures (e.g. MIPS) Installation CDs and boot images rely upon the tar built into BusyBox which doesn't currently support the v option. Use the xjpf options instead.

Now that the stage is installed, continue with Installing Portage.

5.c. Alternative: Using a Stage from the Installation CD

Extracting the Stage Tarball

The stages on the CD reside in the /mnt/cdrom/stages directory. To see a listing of available stages, use ls:

Code Listing 8: List all available stages

# ls /mnt/cdrom/stages

If the system replies with an error, you may need to mount the CD-ROM first:

Code Listing 9: Mounting the CD-ROM

# ls /mnt/cdrom/stages ls: /mnt/cdrom/stages: No such file or directory # mount /dev/cdroms/cdrom0 /mnt/cdrom # ls /mnt/cdrom/stages

Now go into your Gentoo mountpoint (usually /mnt/gentoo):

Code Listing 10: Changing directory to /mnt/gentoo

# cd /mnt/gentoo

We will now extract the stage tarball of your choice. We will do this with tar. Make sure you use the same options (xvjpf). The v argument is optional and not supported in some tar versions. In the next example, we extract the stage tarball stage3-<subarch>-2005.1-r1.tar.bz2. Be sure to substitute the tarball filename with your stage.

Code Listing 11: Extracting the stage tarball

# tar xvjpf /mnt/cdrom/stages/stage3-<subarch>-2005.1-r1.tar.bz2

Now that the stage is installed, continue with Installing Portage.

5.d. Installing Portage

Unpacking a Portage Snapshot

You now have to install a Portage snapshot, a collection of files that inform Portage what software titles you can install, which profiles are available, etc.

Download and Install a Portage Snapshot

Go to the mountpoint where you mounted your filesystem (most likely /mnt/gentoo):

Code Listing 12: Going to the Gentoo mountpoint

# cd /mnt/gentoo

Fire up links2 (or lynx) and go to our Gentoo mirror list. Pick a mirror close to you and open the snapshots/ directory. There, download the latest Portage snapshot by selecting it and pressing D.

Code Listing 13: Browsing the Gentoo mirrorlist


Now exit your browser by pressing Q. You will now have a Portage snapshot stored in /mnt/gentoo. In the next step, we extract the Portage snapshot onto your filesystem. Make sure that you use the exact command; the last option is a capital C, not c.

Code Listing 14: Extracting the Portage snapshot

(Substitute <date> with the datestamp of the downloaded snapshot) # tar xvjf /mnt/gentoo/portage-<date>.tar.bz2 -C /mnt/gentoo/usr

5.e. Configuring the Compile Options

Introduction

To optimize Gentoo, you can set a couple of variables which impact Portage behaviour. All those variables can be set as environment variables (using export) but that isn't permanent. To keep your settings, Portage provides you with /etc/make.conf, a configuration file for Portage. It is this file we will edit now.

Note: A commented listing of all possible variables can be found in /mnt/gentoo/etc/make.conf.example. For a successful Gentoo installation you'll only need to set the variables which are mentioned beneath.

Fire up your favorite editor (in this guide we use nano) so we can alter the optimization variables we will discuss hereafter.

Code Listing 15: Opening /etc/make.conf

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

As you probably noticed, the make.conf.example file is structured in a generic way: commented lines start with "#", other lines define variables using the VARIABLE="content" syntax. The make.conf file uses the same syntax. Several of those variables are discussed next.

CHOST

The CHOST variable declares the target build host for your system. This variable should already be set to the correct value. Do not edit it as that might break your system. If the CHOST variable does not look correct to you, you might be using the wrong stage3 tarball.

CFLAGS and CXXFLAGS

The CFLAGS and CXXFLAGS variables define the optimization flags for the gcc C and C++ compiler respectively. Although we define those generally here, you will only have maximum performance if you optimize these flags for each program separately. The reason for this is because every program is different.

In make.conf you should define the optimization flags you think will make your 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. If you want to know them all, read the GNU Online Manual(s) or the gcc info page (info gcc -- only works on a working Linux system). The make.conf.example file itself also contains lots of examples and information; don't forget to read it too.

A first setting is the -march= flag, which specifies the name of the target architecture. Possible options are described in the make.conf.example file (as comments). For instance, for the x86 Athlon XP architecture:

Code Listing 16: The GCC march setting

# AMD64 users who want to use a native 64 bit system should use -march=k8 #EM64T users should use -march=nocona -march=athlon-xp

A second one is the -O 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 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). For instance, for a class-2 optimization:

Code Listing 17: The GCC O setting

-O2

Another popular optimization flag is -pipe (use pipes rather than temporary files for communication between the various stages of compilation).

Mind you that using -fomit-frame-pointer (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 you define the CFLAGS and CXXFLAGS, you should combine several optimization flags, like in the following example:

Code Listing 18: Defining the CFLAGS and CXXFLAGS variable

CFLAGS="-march=athlon-xp -pipe -O2" # AMD64 users should use march=k8
# EM64T users should use march=nocona
CXXFLAGS="${CFLAGS}" # Use the same settings for both variables

MAKEOPTS

With MAKEOPTS you define how many parallel compilations should occur when you install a package. A good choice is the number of CPUs in your system plus one, but this guideline isn't always perfect.

Code Listing 19: MAKEOPTS for a regular, 1-CPU system

MAKEOPTS="-j2"

Ready, Set, Go!

Update your /mnt/gentoo/etc/make.conf to your own preference and save (nano users would hit Ctrl-X). You are now ready to continue with Installing the Gentoo Base System. 6. Installing the Gentoo Base System

6.a. Chrooting

Optional: Selecting Mirrors

In order to download source code quickly it is recommended to select a fast mirror. Portage will look in your make.conf file for the GENTOO_MIRRORS variable and use the mirrors listed therein. You can surf to our mirror list and search for a mirror (or mirrors) close to you (as those are most frequently the fastest ones), but we provide a nice tool called mirrorselect which provides you with a nice interface to select the mirrors you want.

Code Listing 1: Using mirrorselect for the GENTOO_MIRRORS variable

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

Warning: Do not select any IPv6 mirrors. Our stages currently do not support IPv6.

A second important setting is the SYNC setting in make.conf. This variable contains the rsync server you want to use when updating your Portage tree (the collection of ebuilds, scripts containing all the information Portage needs to download and install software). Although you can manually enter a SYNC server for yourself, mirrorselect can ease that operation for you:

Code Listing 2: Selecting an rsync mirror using mirrorselect

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

After running mirrorselect it is adviseable to double-check the settings in /mnt/gentoo/etc/make.conf !

Copy DNS Info

One thing still remains to be done before we enter the new environment and that is copying over the DNS information in /etc/resolv.conf. You need to do this to ensure that networking still works even after entering the new environment. /etc/resolv.conf contains the nameservers for your network.

Code Listing 3: Copy over DNS information

(The "-L" option is needed to make sure we don't copy a symbolic link) # cp -L /etc/resolv.conf /mnt/gentoo/etc/resolv.conf

Mounting the /proc and /dev Filesystems

Mount the /proc filesystem on /mnt/gentoo/proc to allow the installation to use the kernel-provided information within the chrooted environment, and then mount-bind the /dev filesystem.

Code Listing 4: Mounting /proc and /dev

# mount -t proc none /mnt/gentoo/proc # mount -o bind /dev /mnt/gentoo/dev

Entering the new Environment

Now that all partitions are initialized and the base environment installed, it is time to enter our new installation environment by chrooting into it. This means that we change from the current installation environment (Installation CD or other installation medium) to your installation system (namely the initialized partitions).

This chrooting is done in three steps. First we will change the root from / (on the installation medium) to /mnt/gentoo (on your partitions) using chroot. Then we will create a new environment using env-update, which essentially creates environment variables. Finally, we load those variables into memory using source.

Code Listing 5: Chrooting into the new environment

# chroot /mnt/gentoo /bin/bash # env-update
  • Caching service dependencies...
# source /etc/profile # export PS1="(chroot) $PS1"

Congratulations! You are now inside your own Gentoo Linux environment. Of course it is far from finished, which is why the installation still has some sections left :-)

6.b. Configuring Portage

Updating the Portage tree

You should now update your Portage tree to the latest version. emerge --sync does this for you.

Code Listing 6: Updating the Portage tree

# emerge --sync (If you're using a slow terminal like some framebuffers or a serial console, you can add the --quiet option to speed up this process:) # emerge --sync --quiet

If you are behind a firewall that blocks rsync traffic, you can use emerge-webrsync which will download and install a portage snapshot for you.

If you are warned that a new Portage version is available and that you should update Portage, you should ignore it. Portage will be updated for you later on during the installation.

Choosing the Right Profile

First, a small definition is in place.

A profile is a building block for any Gentoo system. Not only does it specify default values for CHOST, CFLAGS and other important variables, it also locks the system to a certain range of package versions. This is all maintained by the Gentoo developers.

Previously, such a profile was barely touched by the user. However, x86, hppa and alpha users can choose between two profiles, one for a 2.4 kernel and one for a 2.6 kernel. This requirement has been imposed to improve the integration of the 2.6 kernels. The ppc and ppc64 architectures have several profiles available as well. We will talk about those later.

You can see what profile you are currently using with the following command:

Code Listing 7: Verifying system profile

# ls -FGg /etc/make.profile lrwxrwxrwx 1 48 Apr 8 18:51 /etc/make.profile -> ../usr/portage/profiles/default-linux/x86/2005.1/

If you are using one of the aforementioned three architectures, the default profile will provide you with a Linux 2.6-based system. This is the recommended default, but you have the option of choosing another profile too.

Some users may wish to install a system based on the older Linux 2.4 profile. If you have good reason to do this, then you should first check that an additional profile exists. On x86, we can do this with the following command:

Code Listing 8: Finding out if an additional profile exists

# ls -d /usr/portage/profiles/default-linux/x86/no-nptl/2.4 /usr/portage/profiles/default-linux/x86/no-nptl/2.4

The above example shows that the additional 2.4 profile exists (i.e. it didn't complain about missing file or directory). It is recommended that you stay with the default, but if you wish to switch, you can do so with as follows:

Code Listing 9: Switching to a 2.4 profile

(Make sure you use the right architecture, the example below is for x86) # ln -snf /usr/portage/profiles/default-linux/x86/no-nptl/2.4 /etc/make.profile (List the files in the 2.4 profile) # ls -FGg /etc/make.profile/ total 12 -rw-rr 1 939 Dec 10 14:06 packages -rw-rr 1 347 Dec 3 2004 parent -rw-rr 1 573 Dec 3 2004 virtuals

For ppc, there are a number of new profiles provided with 2005.1.

Code Listing 10: PPC Profiles

(Generic PPC profile, for all PPC machines) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc /etc/make.profile (G3 profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc/G3 /etc/make.profile (G3 Pegasos profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc/G3/Pegasos/ /etc/make.profile (G4 (Altivec) profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc/G4 /etc/make.profile (G4 Pegasos profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc/G4/Pegasos/ /etc/make.profile

For ppc64, there are a number of new profiles provided with 2005.1.

Code Listing 11: PPC64 Profiles

(Generic 64bit userland PPC64 profile, for all PPC64 machines) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/64bit-userland /etc/make.profile (Generic 32bit userland PPC64 profile, for all PPC64 machines) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/32bit-userland /etc/make.profile (Each type of userland has sub profiles as follows, with (userland) replaced with the chosen userland from above) (970 profile for JS20) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/(userland)/970 /etc/make.profile (G5 profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/(userland)/970/pmac /etc/make.profile (POWER3 profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/(userland)/power3 /etc/make.profile (POWER4 profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/(userland)/power4 /etc/make.profile (POWER5 profile) # ln -snf /usr/portage/profiles/default-linux/ppc/2005.1/ppc64/(userland)/power5 /etc/make.profile (The multilib profile is not stable as of this release.)

Configuring the USE variable

USE is one of the most powerful variables Gentoo provides to its users. Several programs can be compiled with or without optional support for certain items. For instance, some programs can be compiled with gtk-support, or with qt-support. Others can be compiled with or without SSL support. Some programs can even be compiled with framebuffer support (svgalib) instead of X11 support (X-server).

Most distributions compile their packages with support for as much as possible, increasing the size of the programs and startup time, not to mention an enormous amount of dependencies. With Gentoo you can define what options a package should be compiled with. This is where USE comes into play.

In the USE variable you define keywords which are mapped onto compile-options. For instance, ssl will compile ssl-support in the programs that support it. -X will remove X-server support (note the minus sign in front). gnome gtk -kde -qt will compile your programs with gnome (and gtk) support, and not with kde (and qt) support, making your system fully tweaked for GNOME.

The default USE settings are placed in the make.defaults files of your profile. You will find make.defaults files in the directory which /etc/make.profile points to and all parent directories as well. The default USE setting is the sum of all USE settings in all make.defaults files. What you place in /etc/make.conf is calculated against these defaults settings. If you add something to the USE setting, it is added to the default list. If you remove something from the USE setting (by placing a minus sign in front of it) it is removed from the default list (if it was in the default list at all). Never alter anything inside the /etc/make.profile directory; it gets overwritten when you update Portage!

A full description on USE can be found in the second part of the Gentoo Handbook, USE flags. A full description on the available USE flags can be found on your system in /usr/portage/profiles/use.desc.

Code Listing 12: Viewing available USE flags

# less /usr/portage/profiles/use.desc (You can scroll using your arrow keys, exit by pressing 'q')

As an example we show a USE setting for a KDE-based system with DVD, ALSA and CD Recording support:

Code Listing 13: Opening /etc/make.conf

# nano -w /etc/make.conf

Code Listing 14: USE setting

USE="-gtk -gnome qt kde dvd alsa cdr"

Optional: GLIBC Locales

You will probably only use one or maybe two locales on your system. Up until now after compiling glibc a full set of all available locales will be created. As of now you can activate the userlocales USE flag and specify only the locales you will need in /etc/locales.build. Only do this if you know what locales to choose.

Code Listing 15: Activate the userlocales USE flag especially for glibc

# mkdir -p /etc/portage # echo "sys-libs/glibc userlocales" >> /etc/portage/package.use

Now specify the locales you want to be able to use:

Code Listing 16: Opening /etc/locales.build

# nano -w /etc/locales.build

The following locales are an example to get both English (United States) and German (Germany) with the accompanying character formats (like UTF-8).

Code Listing 17: Specify your locales

en_US/ISO-8859-1 en_US.UTF-8/UTF-8 de_DE/ISO-8859-1 de_DE@euro/ISO-8859-15

Now continue with Configuring the Kernel. 7. Configuring the Kernel

7.a. Timezone

You first need to select your timezone so that your system knows where it is located. Look for your timezone in /usr/share/zoneinfo, then copy it to /etc/localtime. Please avoid the /usr/share/zoneinfo/Etc/GMT* timezones as their names do not indicate the expected zones. For instance, GMT-8 is in fact GMT+8.

Code Listing 1: Setting the timezone information

# ls /usr/share/zoneinfo (Suppose you want to use GMT) # cp /usr/share/zoneinfo/GMT /etc/localtime

7.b. Installing the Sources

Choosing a Kernel

The core around which all distributions are built is the Linux kernel. It is the layer between the user programs and your system hardware. Gentoo provides its users several possible kernel sources. A full listing with description is available at the Gentoo Kernel Guide.

For x86-based systems we have, amongst other kernels, vanilla-sources (the default kernel source as developed by the linux-kernel developers), gentoo-sources (kernel source patched with performance-enhancing features), ...

Choose your kernel source and install it using emerge. The USE="-doc" is necessary to avoid installing xorg-x11 or other dependencies at this point. USE="symlink" is not necessary for a new install, but ensures proper creation of the /usr/src/linux symlink.

Code Listing 2: Installing a kernel source

# USE="-doc symlink" emerge gentoo-sources

When you take a look in /usr/src you should see a symlink called linux pointing to your kernel source. In this case, the installed kernel source points to gentoo-sources-2.6.12-r10. Your version may be different, so keep this in mind.

Code Listing 3: Viewing the kernel source symlink

# ls -l /usr/src/linux lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-2.6.12-gentoo-r10

Now it is time to configure and compile your kernel source. You can use genkernel for this, which will build a generic kernel as used by the Installation CD. We explain the "manual" configuration first though, as it is the best way to optimize your environment.

If you want to manually configure your kernel, continue now with Default: Manual Configuration. If you want to use genkernel you should read Alternative: Using genkernel instead.

7.c. Default: Manual Configuration

Introduction

Manually configuring a kernel is often seen as the most difficult procedure a Linux user ever has to perform. Nothing is less true -- after configuring a couple of kernels you don't even remember that it was difficult ;)

However, one thing is true: you must know your system when you start configuring a kernel manually. Most information can be gathered by emerging pciutils (emerge pciutils) which contains lspci. You will now be able to use lspci within the chrooted environment. You may safely ignore any pcilib warnings (like pcilib: cannot open /sys/bus/pci/devices) that lspci throws out. Alternatively, you can run lspci from a non-chrooted environment. The results are the same. You can also run lsmod to see what kernel modules the Installation CD uses (it might provide you with a nice hint on what to enable).

Now go to your kernel source directory and execute make menuconfig. This will fire up an ncurses-based configuration menu.

Code Listing 4: Invoking menuconfig

# cd /usr/src/linux # make menuconfig

You will be greeted with several configuration sections. We'll first list some options you must activate (otherwise Gentoo will not function, or not function properly without additional tweaks).

Activating Required Options

First of all, activate the use of development and experimental code/drivers. You need this, otherwise some very important code/drivers won't show up:

Code Listing 5: Selecting experimental code/drivers, General setup

Code maturity level options --->
[1] Prompt for development and/or incomplete code/drivers
General setup --->
[2] Support for hot-pluggable devices

Make sure that every driver that is vital to the booting of your system (such as SCSI controller, ...) is compiled in the kernel and not as a module, otherwise your system will not be able to boot completely.

Now select the correct processor family:

Code Listing 6: Selecting correct processor family

Processor type and features --->
(Change according to your system) (Athlon/Duron/K7) Processor family

Now go to File Systems and select support for the filesystems you use. Don't compile them as modules, otherwise your Gentoo system will not be able to mount your partitions. Also select Virtual memory and /proc file system. If you are using a 2.4 kernel, you need to select /dev file system as 2.4 kernels do not support udev.

Code Listing 7: Selecting necessary file systems

(With a 2.4.x kernel) File systems --->
[3] Virtual memory file system support (former shm fs) [4] /proc file system support [5] /dev file system support (EXPERIMENTAL) [6] automatically mount /dev at boot /dev/pts file system for Unix98 PTYs

(With a 2.6.x kernel) File systems --->
Pseudo Filesystems --->
[7] /proc file system support [8] Virtual memory file system support (former shm fs)

(Select one or more of the following options as needed by your system)
<*> Reiserfs support <*> Ext3 journalling file system support <*> JFS filesystem support <*> Second extended fs support <*> XFS filesystem support

If your BIOS can't handle large harddrives and you jumpered the harddrive to report a limited size you have to enable the following option to gain access to your whole harddrive:

Code Listing 8: Selecting autogeometry resizing support

(2.4.x kernel only) ATA/IDE/MFM/RLL support --->
IDE, ATA and ATAPI Block devices --->
<*> Include IDE/ATA-2 DISK support Use multi-mode by default [9] Auto-Geometry Resizing support

Do not forget to enable DMA for your drives:

Code Listing 9: Activating DMA

Device Drivers --->
ATA/ATAPI/MFM/RLL support --->
[10] Generic PCI bus-master DMA support [11] Use PCI DMA by default when available

If you are using PPPoE to connect to the Internet or you are using a dial-up modem, you will need the following options in the kernel:

Code Listing 10: Selecting PPPoE necessary drivers

(With a 2.4.x kernel) Network device support --->
<*> PPP (point-to-point protocol) support <*> PPP support for async serial ports <*> PPP support for sync tty ports

(With a 2.6.x kernel) Device Drivers --->
Networking support --->
<*> PPP (point-to-point protocol) support <*> PPP support for async serial ports <*> PPP support for sync tty ports

The two compression options won't harm but are not definitely needed, neither does the PPP over Ethernet option, that might only be used by rp-pppoe when configured to do kernel mode PPPoE.

If you require it, don't forget to include support in the kernel for your ethernet card.

If you have an Intel CPU that supports HyperThreading (tm), or you have a multi-CPU system, you should activate "Symmetric multi-processing support":

Code Listing 11: Activating SMP support

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

If you use USB Input Devices (like Keyboard or Mouse) don't forget to enable those as well:

Code Listing 12: Activating USB Support for Input Devices

USB Support --->
<*> USB Human Interface Device (full HID) support

Laptop-users who want PCMCIA support should not use the PCMCIA drivers if they choose to use a 2.4 kernel. More recent drivers are available through the pcmcia-cs package which will be installed later on. 2.6-kernel users however should use the PCMCIA drivers from the kernel.

Besides compiling in PCMCIA support in the 2.6 kernel, don't forget to enable support for the PCMCIA card bridge present in your system:

Code Listing 13: Enabling PCMCIA support for 2.6 kernels

Bus options (PCI, PCMCIA, EISA, MCA, ISA) --->
PCCARD (PCMCIA/CardBus) support --->
<*> PCCard (PCMCIA/CardBus) support
(select 16 bit if you need support for older PCMCIA cards. Most people want this.)
<*> 16-bit PCMCIA support [13] 32-bit CardBus support
(select the relevant bridges below)
--- PC-card bridges <*> CardBus yenta-compatible bridge support (NEW) <*> Cirrus PD6729 compatible bridge support (NEW) <*> i82092 compatible bridge support (NEW) <*> i82365 compatible bridge support (NEW) <*> Databook TCIC host bridge support (NEW)

When you've finished configuring the kernel, continue with Compiling and Installing.

Compiling and Installing

Now that your kernel is configured, it is time to compile and install it. Exit the configuration and start the compilation process:

Code Listing 14: Compiling the kernel

(For 2.4 kernel) # make dep && make bzImage modules modules_install

(For 2.6 kernel) # make && make modules_install

When the kernel has finished compiling, copy the kernel image to /boot. Use whatever name you feel is appropriate for your kernel choice and remember it as you will need it later on when you configure your bootloader. Remember to replace <kernel-version> with the name and version of your kernel.

Code Listing 15: Installing the kernel

# cp arch/i386/boot/bzImage /boot/<kernel-version>

Now continue with Kernel Modules.

7.d. Alternative: Using genkernel

If you are reading this section, you have chosen to use our genkernel script to configure your kernel for you.

Now that your kernel source tree is installed, it's now time to compile your kernel by using our genkernel script to automatically build a kernel for you. genkernel works by configuring a kernel nearly identically to the way our Installation CD kernel is configured. This means that when you use genkernel to build your kernel, your system will generally detect all your hardware at boot-time, just like our Installation CD does. Because genkernel doesn't require any manual kernel configuration, it is an ideal solution for those users who may not be comfortable compiling their own kernels.

Now, let's see how to use genkernel. First, emerge the genkernel ebuild:

Code Listing 16: Emerging genkernel

# emerge genkernel

Next, if you are going to configure a 2.6 kernel, copy over the kernel configuration used by the Installation CD to the location where genkernel looks for the default kernel configuration:

Code Listing 17: Copying over the Installation CD kernel config

(Only do this if you are going to configure a 2.6 kernel) # zcat /proc/config.gz > /usr/share/genkernel/x86/kernel-config-2.6

Now, compile your kernel sources by running genkernel all. Be aware though, as genkernel compiles a kernel that supports almost all hardware, this compilation will take quite a while to finish!

Note that, if your boot partition doesn't use ext2 or ext3 as filesystem you might need to manually configure your kernel using genkernel --menuconfig all and add support for your filesystem in the kernel (i.e. not as a module). Users of EVMS2 or LVM2 will probably want to add --evms2 or --lvm2 as argument as well.

Code Listing 18: Running genkernel

# genkernel all

Once genkernel completes, a kernel, full set of modules and initial root disk (initrd) will be created. We will use the kernel and initrd when configuring a boot loader later in this document. Write down the names of the kernel and initrd as you will need it when writing the bootloader configuration file. The initrd will be started immediately after booting to perform hardware autodetection (just like on the Installation CD) before your "real" system starts up.

Code Listing 19: Checking the created kernel image name and initrd

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

Now, let's perform one more step to get our system to be more like the Installation CD -- let's emerge coldplug. While the initrd autodetects hardware that is needed to boot your system, coldplug autodetects everything else. To emerge and enable coldplug, type the following:

Code Listing 20: Emerging and enabling coldplug

# emerge coldplug # rc-update add coldplug boot

7.e. Kernel Modules

Configuring the Modules

You should list the modules you want automatically loaded in /etc/modules.autoload.d/kernel-2.4 (or kernel-2.6). You can add extra options to the modules too if you want.

To view all available modules, run the following find command. Don't forget to substitute "<kernel version>" with the version of the kernel you just compiled:

Code Listing 21: Viewing all available modules

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

For instance, to automatically load the 3c59x.o module, edit the kernel-2.4 or kernel-2.6 file and enter the module name in it.

Code Listing 22: Editing /etc/modules.autoload.d/kernel-2.4

(Example for 2.4 kernels) # nano -w /etc/modules.autoload.d/kernel-2.4

Code Listing 23: /etc/modules.autoload.d/kernel-2.4 or kernel-2.6

3c59x

Continue the installation with Configuring your System. 8. Configuring your System

8.a. Filesystem Information

What is fstab?

Under Linux, all partitions used by the system must be listed in /etc/fstab. This file contains the mountpoints of those partitions (where they are seen in the file system structure), how they should be mounted and with what special options (automatically or not, whether users can mount them or not, etc.)

Creating /etc/fstab

/etc/fstab uses a special syntax. Every line consists of six fields, separated by whitespace (space(s), tabs or a mixture). Each field has its own meaning:

  • The first field shows the partition described (the path to the device file)
  • The second field shows the mountpoint at which the partition should be mounted
  • The third field shows the filesystem used by the partition
  • The fourth field shows the mountoptions used by mount when it wants to mount the partition. As every filesystem has its own mountoptions, you are encouraged to read the mount man page (man mount) for a full listing. Multiple mountoptions are comma-separated.
  • The fifth field is used by dump to determine if the partition needs to be dumped or not. You can generally leave this as 0 (zero).
  • The sixth field is used by fsck to determine the order in which filesystems should be checked if the system wasn't shut down properly. The root filesystem should have 1 while the rest should have 2 (or 0 if a filesystem check isn't necessary).

The default /etc/fstab file provided by Gentoo is no valid fstab file, so start nano (or your favorite editor) to create your /etc/fstab:

Code Listing 1: Opening /etc/fstab

# nano -w /etc/fstab

Let us take a look at how we write down the options for the /boot partition. This is just an example, so if your architecture doesn't require a /boot partition (such as PPC), don't copy it verbatim.

In our default x86 partitioning example /boot is the /dev/hda1 partition, with ext2 as filesystem. It needs to be checked during boot, so we would write down:

Code Listing 2: An example /boot line for /etc/fstab

/dev/hda1 /boot ext2 defaults 1 2

Some users don't want their /boot partition to be mounted automatically to improve their system's security. Those people should substitute defaults with noauto. This does mean that you need to manually mount this partition every time you want to use it.

Now, to improve performance, most users would want to add the noatime option as mountoption, which results in a faster system since access times aren't registered (you don't need those generally anyway):

Code Listing 3: An improved /boot line for /etc/fstab

/dev/hda1 /boot ext2 defaults,noatime 1 2

If we continue with this, we would end up with the following three lines (for /boot, / and the swap partition):

Code Listing 4: Three /etc/fstab lines

/dev/hda1 /boot ext2 defaults,noatime 1 2 /dev/hda2 none swap sw 0 0 /dev/hda3 / ext3 noatime 0 1

To finish up, you should add a rule for /proc, tmpfs (required) and for your CD-ROM drive (and of course, if you have other partitions or drives, for those too):

Code Listing 5: A full /etc/fstab example

/dev/hda1 /boot ext2 defaults,noatime 1 2 /dev/hda2 none swap sw 0 0 /dev/hda3 / ext3 noatime 0 1

none /proc proc defaults 0 0 none /dev/shm tmpfs nodev,nosuid,noexec 0 0

/dev/cdroms/cdrom0 /mnt/cdrom auto noauto,user 0 0

auto makes mount guess for the filesystem (recommended for removable media as they can be created with one of many filesystems) and user makes it possible for non-root users to mount the CD.

Now use the above example to create your /etc/fstab. If you are a SPARC-user, you should add the following line to your /etc/fstab too:

Code Listing 6: Adding openprom filesystem to /etc/fstab

none /proc/openprom openpromfs defaults 0 0

Double-check your /etc/fstab, save and quit to continue.

8.b. Networking Information

Hostname, Domainname etc.

One of the choices the user has to make is name his/her PC. This seems to be quite easy, but lots of users are having difficulties finding the appropriate name for their Linux-pc. To speed things up, know that any name you choose can be changed afterwards. For all we care, you can just call your system tux and domain homenetwork.

We use these values in the next examples. First we set the hostname:

Code Listing 7: Setting the hostname

# nano -w /etc/conf.d/hostname

(Set the HOSTNAME variable to your hostname) HOSTNAME="tux"

Second we set the domainname:

Code Listing 8: Setting the domainname

# nano -w /etc/conf.d/domainname

(Set the DNSDOMAIN variable to your domain name) DNSDOMAIN="homenetwork"

If you have a NIS domain (if you don't know what that is, then you don't have one), you need to define that one too:

Code Listing 9: Setting the NIS domainname

# nano -w /etc/conf.d/domainname

(Set the NISDOMAIN variable to your NIS domain name) NISDOMAIN="my-nisdomain"

Now add the domainname script to the default runlevel:

Code Listing 10: Adding domainname to the default runlevel

# rc-update add domainname default

Configuring your Network

Before you get that "Hey, we've had that already"-feeling, you should remember that the networking you set up in the beginning of the Gentoo installation was just for the installation. Right now you are going to configure networking for your Gentoo system permanently.

Note: More detailed information about networking, including advanced topics like bonding, bridging, 802.1Q VLANs or wireless networking is covered in the Gentoo Network Configuration section.

All networking information is gathered in /etc/conf.d/net. It uses a straightforward yet not intuitive syntax if you don't know how to set up networking manually. But don't fear, we'll explain everything. A fully commented example that covers many different configurations is available in /etc/conf.d/net.example.

DHCP is used by default and does not require any further configuration.

If you need to configure your network connection either because you need specific DHCP options or because you do not use DHCP at all, open /etc/conf.d/net with your favorite editor (nano is used in this example):

Code Listing 11: Opening /etc/conf.d/net for editing

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

You will see the following file:

Code Listing 12: Default /etc/conf.d/net

# This blank configuration will automatically use DHCP for any net.* # scripts in /etc/init.d. To create a more complete configuration, # please review /etc/conf.d/net.example and save your configuration # in /etc/conf.d/net (this file :]!).

To enter your own IP address, netmask and gateway, you need to set both config_eth0 and routes_eth0:

Code Listing 13: Manually setting IP information for eth0

config_eth0=( "192.168.0.2 netmask 255.255.255.0 brd 192.168.0.255" ) routes_eth0=( "default gw 192.168.0.1" )

To use DHCP and add specific DHCP options, define config_eth0 and dhcp_eth0:

Code Listing 14: Automatically obtaining an IP address for eth0

config_eth0=( "dhcp" ) dhcp_eth0="nodns nontp nonis"

Please read /etc/conf.d/net.example for a list of all available options.

If you have several network interfaces repeat the above steps for config_eth1, config_eth2, etc.

Now save the configuration and exit to continue.

Automatically Start Networking at Boot

To have your network interfaces activated at boot, you need to add them to the default runlevel. If you have PCMCIA interfaces you should skip this action as the PCMCIA interfaces are started by the PCMCIA init script.

Code Listing 15: Adding net.eth0 to the default runlevel

# rc-update add net.eth0 default

If you have several network interfaces, you need to create the appropriate net.eth1, net.eth2 etc. initscripts for those. You can use ln to do this:

Code Listing 16: Creating extra initscripts

# cd /etc/init.d # ln -s net.eth0 net.eth1 # rc-update add net.eth1 default

Writing Down Network Information

You now need to inform Linux about your network. This is defined in /etc/hosts and helps in resolving hostnames to IP addresses for hosts that aren't resolved by your nameserver. For instance, if your internal network consists of three PCs called jenny (192.168.0.5), benny (192.168.0.6) and tux (192.168.0.7 - this system) you would open /etc/hosts and fill in the values:

Code Listing 17: Opening /etc/hosts

# nano -w /etc/hosts

Code Listing 18: Filling in the networking information

127.0.0.1 localhost 192.168.0.5 jenny.homenetwork jenny 192.168.0.6 benny.homenetwork benny 192.168.0.7 tux.homenetwork tux

If your system is the only system (or the nameservers handle all name resolution) a single line is sufficient. For instance, if you want to call your system tux:

Code Listing 19: /etc/hosts for lonely or fully integrated PCs

127.0.0.1 localhost tux

Save and exit the editor to continue.

If you don't have PCMCIA, you can now continue with System Information. PCMCIA-users should read the following topic on PCMCIA.

Optional: Get PCMCIA Working

Note: pcmcia-cs is only available for x86, amd64 and ppc platforms.

PCMCIA-users should first install the pcmcia-cs package. This also includes users who will be working with a 2.6 kernel (even though they won't be using the PCMCIA drivers from this package). The USE="-X" is necessary to avoid installing xorg-x11 at this moment:

Code Listing 20: Installing pcmcia-cs

# USE="-X" emerge pcmcia-cs

When pcmcia-cs is installed, add pcmcia to the default runlevel:

Code Listing 21: Adding pcmcia to the default runlevel

# rc-update add pcmcia default

8.c. System Information

Root Password

First we set the root password by typing:

Code Listing 22: Setting the root password

# passwd

If you want root to be able to log on through the serial console, add tts/0 to /etc/securetty:

Code Listing 23: Adding tts/0 to /etc/securetty

# echo "tts/0" >> /etc/securetty

System Information

Gentoo uses /etc/rc.conf for general, system-wide configuration. Open up /etc/rc.conf and enjoy all the comments in that file :)

Code Listing 24: Opening /etc/rc.conf

# nano -w /etc/rc.conf

When you're finished configuring /etc/rc.conf, save and exit.

As you can see, this file is well commented to help you set up the necessary configuration variables. You can configure your system to use unicode and define your default editor and your display manager (like gdm or kdm).

Gentoo uses /etc/conf.d/keymaps to handle keyboard configuration. Edit it to configure your keyboard.

Code Listing 25: Opening /etc/conf.d/keymaps

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

Take special care with the KEYMAP variable. If you select the wrong KEYMAP, you will get weird results when typing on your keyboard.

Note: Users of USB-based SPARC systems and SPARC clones might need to select an i386 keymap (such as "us") instead of "sunkeymap". PPC uses x86 keymaps on most systems. Users who want to be able to use ADB keymaps on boot have to enable ADB keycode sendings in their kernel and have to set a mac/ppc keymap in /etc/conf.d/keymaps.

When you're finished configuring /etc/conf.d/keymaps, save and exit.

Gentoo uses /etc/conf.d/clock to set clock options. Edit it according to your needs.

Code Listing 26: Opening /etc/conf.d/clock

# nano -w /etc/conf.d/clock

If your hardware clock is not using UTC, you need to add CLOCK="local" to the file. Otherwise you will notice some clock skew. Furthermore, Windows assumes that your hardware clock uses local time, so if you want to dualboot, you should set this variable appropriately, otherwise your clock will go crazy.

When you're finished configuring /etc/conf.d/clock, save and exit.

If you are not installing Gentoo on IBM PPC64 hardware, continue with Installing Necessary System Tools.

Configuring the Console

Note: The following section applies to the IBM PPC64 hardware platforms.

If you are running Gentoo on IBM PPC64 hardware and using a virtual console you must uncomment the appropriate line in /etc/inittab for the virtual console to spawn a login prompt.

Code Listing 27: Enabling hvc or hvsi support in /etc/inittab

hvc0:12345:respawn:/sbin/agetty -L 9600 hvc0 hvsi:12345:respawn:/sbin/agetty -L 19200 hvsi0

You should also take this time to verify that the appropriate console is listed in /etc/securetty.

You may now continue with Installing Necessary System Tools. 9. Installing Necessary System Tools

9.a. Device Manager

If you are using a 2.4 kernel and are installing Gentoo from stage 3, there are a few things you need to do. Since Gentoo now uses udev by default and udev is not supported by 2.4 kernels, you will have to make use of devfsd and remove udev.

Code Listing 1: Installing devfsd

(For those using 2.4.x kernels with a stage 3 install) # emerge --unmerge udev # emerge devfsd

9.b. System Logger

Some tools are missing from the stage3 archive because several packages provide the same functionality. It is now up to you to choose which ones you want to install.

The first tool you need to decide on has to provide logging facilities for your system. Unix and Linux have an excellent history of logging capabilities -- if you want you can log everything that happens on your system in logfiles. This happens through the system logger.

Gentoo offers several system loggers to choose from. There are sysklogd, which is the traditional set of system logging daemons, syslog-ng, an advanced system logger, and metalog which is a highly-configurable system logger. Others might be available through Portage as well - our number of available packages increases on a daily basis.

If you plan on using sysklogd or syslog-ng you might want to install logrotate afterwards as those system loggers don't provide any rotation mechanism for the log files.

To install the system logger of your choice, emerge it and have it added to the default runlevel using rc-update. The following example installs syslog-ng. Of course substitute with your system logger:

Code Listing 2: Installing a system logger

# emerge syslog-ng # rc-update add syslog-ng default

9.c. Optional: Cron Daemon

Next is the cron daemon. Although it is optional and not required for your system, it is wise to install one. But what is a cron daemon? A cron daemon executes scheduled commands. It is very handy if you need to execute some command regularly (for instance daily, weekly or monthly).

Gentoo offers three possible cron daemons: dcron, fcron and vixie-cron. Installing one of them is similar to installing a system logger. However, dcron and fcron require an extra configuration command, namely crontab /etc/crontab. If you don't know what to choose, use vixie-cron.

We only provide vixie-cron for networkless installations. If you want another cron daemon you can wait and install it later on.

Code Listing 3: Installing a cron daemon

# emerge vixie-cron # rc-update add vixie-cron default (Only if you have chosen dcron or fcron) # crontab /etc/crontab

9.d. Optional: File Indexing

If you want to index your system's files so you are able to quickly locate them using the locate tool, you need to install sys-apps/slocate.

Code Listing 4: Installing slocate

# emerge slocate

9.e. File System Tools

Depending on what file systems you are using, you need to install the necessary file system utilities (for checking the filesystem integrity, creating additional file systems etc.).

The following table lists the tools you need to install if you use a certain file system: File System Tool Install Command XFS xfsprogs emerge xfsprogs ReiserFS reiserfsprogs emerge reiserfsprogs JFS jfsutils emerge jfsutils

If you are an EVMS user, you also need to install evms:

Code Listing 5: Installing EVMS utilities

# USE="-gtk" emerge evms

The USE="-gtk" will prevent the installation of dependencies. If you want to enable the evms graphical tools, you can recompile evms later on.

If you don't require any additional networking-related tools (such as rp-pppoe or a dhcp client) continue with Configuring the Bootloader.

9.f. Networking Tools

Optional: Installing a DHCP Client

If you require Gentoo to automatically obtain an IP address for your network interface(s), you need to install dhcpcd (or any other DHCP Client) on your system. If you don't do this now, you might not be able to connect to the internet after the installation!

Code Listing 6: Installing dhcpcd

# emerge dhcpcd

Optional: Installing a PPPoE Client

If you need rp-pppoe to connect to the net, you need to install it.

Code Listing 7: Installing rp-pppoe

# USE="-X" emerge rp-pppoe

The USE="-X" will prohibit xorg-x11 to be installed as a dependency (rp-pppoe has graphical tools; if you want those enabled, you can recompile rp-pppoe later on or have xorg-x11 installed now -- which takes a long time to compile).

RAID utilities for IBM hardware

If you are using SCSI RAID on a POWER5-based system, you should consider installing the iprutils which will allow you to work with the RAID disk array, get status on the disks in the arrays, and update microcode among other functions.

Code Listing 8: Installing iprutils

# emerge iprutils

Now continue with Configuring the Bootloader. 10. Configuring the Bootloader

10.a. Making your Choice

Introduction

Now that your kernel is configured and compiled and the necessary system configuration files are filled in correctly, it is time to install a program that will fire up your kernel when you start the system. Such a program is called a bootloader. For x86, Gentoo Linux provides GRUB and LILO. But before we install one of these two bootloaders, we inform you how to configure framebuffer (assuming you want it of course). With framebuffer you can run the Linux command line with (limited) graphical features (such as using the nice bootsplash image Gentoo provides).

Optional: Framebuffer

If you have configured your kernel with framebuffer support (or you used genkernel's default kernel configuration), you can activate it by adding a vga and/or a video statement to your bootloader configuration file.

First of all you need to know what type of framebuffer device you're using. If you use a Gentoo patched kernel tree (such as gentoo-sources) you will have had the possibility of selecting vesafb-tng as the VESA driver type (which is default for these kernel sources). If this is the case, you are using vesafb-tng and do not need to set a vga statement. Otherwise you are using the vesafb driver and need to set the vga statement.

The vga statement controls the resolution and color depth of your framebuffer screen for vesafb. As stated in /usr/src/linux/Documentation/fb/vesafb.txt (which gets installed when you install a kernel source package), you need to pass the VESA number corresponding to the requested resolution and color depth to it.

The following table lists the available resolutions and colordepths and matches those against the value that you need to pass on to the vga statement.
640x480 800x600 1024x768 1280x1024
256 0x301 0x303 0x305 0x307 32k 0x310 0x313 0x316 0x319 64k 0x311 0x314 0x317 0x31A 16M 0x312 0x315 0x318 0x31B

The video statement controls framebuffer display options. It needs to be given the framebuffer driver (vesafb for 2.6 kernels, or vesa for 2.4 kernels) followed by the control statements you wish to enable. All variables are listed in /usr/src/linux/Documentation/fb/vesafb.txt, but we'll inform you about three most-used options: Control Description ywrap Assume that the graphical card can wrap around its memory (i.e. continue at the beginning when it has approached the end) mtrr Setup MTRR registers mode (vesafb-tng only) Set up the resolution, color depth and refresh rate. For instance, 1024x768-32@85 for a resolution of 1024x768, 32 bit color depth and a refresh rate of 85 Hz.

The result of those two statements could be something like vga=0x318 video=vesafb:mtrr,ywrap or video=vesafb:mtrr,ywrap,1024x768-32@85. Remember (or write down) this setting; you will need it shortly.

Now continue by installing GRUB or LILO.

10.b. Default: Using GRUB

Understanding GRUB's terminology

The most critical part of understanding GRUB is getting comfortable with how GRUB refers to hard drives and partitions. Your Linux partition /dev/hda1 will most likely be called (hd0,0) under GRUB. Notice the parenthesis around the hd0,0 - they are required.

Hard drives count from zero rather than "a" and partitions start at zero rather than one. Be aware too that with the hd devices, only hard drives are counted, not atapi-ide devices such as cdrom players and burners. Also, the same construct is used with SCSI drives. (Normally they get higher numbers than IDE drives except when the BIOS is configured to boot from SCSI devices.) When you ask the BIOS to boot from a different hard disk (for instance your primary slave), that harddisk is seen as hd0.

Assuming you have a hard drive on /dev/hda, a cdrom player on /dev/hdb, a burner on /dev/hdc, a second hard drive on /dev/hdd and no SCSI hard drive, /dev/hdd7 gets translated to (hd1,6). It might sound tricky and tricky it is indeed, but as we will see, GRUB offers a tab completion mechanism that comes handy for those of you having a lot of hard drives and partitions and who are a little lost in the GRUB numbering scheme.

Having gotten the feel for that, it is time to install GRUB.

Installing GRUB

To install GRUB, let's first emerge it:

Code Listing 1: Installing GRUB

# emerge grub

Although GRUB is now installed, we still need to write up a configuration file for it and place GRUB in our MBR so that GRUB automatically boots your newly created kernel. Create /boot/grub/grub.conf with nano (or, if applicable, another editor):

Code Listing 2: Creating /boot/grub/grub.conf

# nano -w /boot/grub/grub.conf

Now we are going to write up a grub.conf. Below you'll find two possible grub.conf for the partitioning example we use in this guide. We've only extensively commented the first grub.conf. Make sure you use your kernel image filename and, if appropriate, your initrd image filename.

  • The first grub.conf is for people who have not used genkernel to build their kernel
  • The second grub.conf is for people who have used genkernel to build their kernel

Note: If your root filesystem is JFS, you must add " ro" to the kernel line since JFS needs to replay its log before it allows read-write mounting.

Code Listing 3: grub.conf for non-genkernel users

# Which listing to boot as default. 0 is the first, 1 the second etc. default 0 # How many seconds to wait before the default listing is booted. timeout 30 # Nice, fat splash-image to spice things up :) # Comment out if you don't have a graphics card installed splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title=Gentoo Linux 2.6.12-r10 # Partition where the kernel image (or operating system) is located root (hd0,0) kernel /boot/kernel-2.6.12-gentoo-r10 root=/dev/hda3

# The next four lines are only if you dualboot with a Windows system. # In this case, Windows is hosted on /dev/hda6. title=Windows XP rootnoverify (hd0,5) makeactive chainloader +1

Code Listing 4: grub.conf for genkernel users

default 0 timeout 30 splashimage=(hd0,0)/boot/grub/splash.xpm.gz

title=Gentoo Linux 2.6.12-r10 root (hd0,0) kernel /boot/kernel-genkernel-x86-2.6.12-gentoo-r10 root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda3 udev initrd /boot/initramfs-genkernel-x86-2.6.12-gentoo-r10

# Only in case you want to dual-boot title=Windows XP rootnoverify (hd0,5) makeactive chainloader +1

Note: The udev mentioned at the end of the kernel line is needed to work around a bug in some genkernel versions if you use udev in the first place (which is the default behaviour).

If you used a different partitioning scheme and/or kernel image, adjust accordingly. However, make sure that anything that follows a GRUB-device (such as (hd0,0)) is relative to the mountpoint, not the root. In other words, (hd0,0)/grub/splash.xpm.gz is in reality /boot/grub/splash.xpm.gz since (hd0,0) is /boot.

Besides, if you chose to use a different partitioning scheme and did not put /boot in a separate partition, the /boot prefix used in the above code samples is really required. If you followed our suggested partitioning plan, the /boot prefix it not required, but a boot symlink makes it work. In short, the above examples should work whether you defined a separate /boot partition or not.

If you need to pass any additional options to the kernel, simply add them to the end of the kernel command. We're already passing one option (root=/dev/hda3 or real_root=/dev/hda3), but you can pass others as well, such as the video and/or vga statements for framebuffer as we discussed previously.

If you're using a 2.6.7 or higher kernel and you jumpered your harddrive because the BIOS can't handle large harddrives you'll need to append hdx=stroke.

genkernel users should know that their kernels use the same boot options as is used for the Installation CD. For instance, if you have SCSI devices, you should add doscsi as kernel option.

Now save the grub.conf file and exit. You still need to install GRUB in the MBR (Master Boot Record) so that GRUB is automatically executed when you boot your system.

The GRUB developers recommend the use of grub-install. However, if for some reason grub-install fails to work correctly you still have the option to manually install GRUB.

Continue with Default: Setting up GRUB using grub-install or Alternative: Setting up GRUB using manual instructions.

Default: Setting up GRUB using grub-install

To install GRUB you will need to issue the grub-install command. However, grub-install won't work off-the-shelf since we are inside a chrooted environment. We need to create /etc/mtab which lists all mounted filesystems. Fortunately, there is an easy way to accomplish this - just copy over /proc/mounts to /etc/mtab, excluding the rootfs line if you haven't created a separate boot partition. The following command will work in both cases:

Code Listing 5: Creating /etc/mtab

# grep -v rootfs /proc/mounts > /etc/mtab

Now we can install GRUB using grub-install:

Code Listing 6: Running grub-install

# grub-install /dev/hda

If you have more questions regarding GRUB, please consult the GRUB FAQ or the GRUB Manual.

Continue with Rebooting the System.

Alternative: Setting up GRUB using manual instructions

To start configuring GRUB, you type in grub. You'll be presented with the grub> grub command-line prompt. Now, you need to type in the right commands to install the GRUB boot record onto your hard drive.

Code Listing 7: Starting the GRUB shell

# grub

Note: If your system does not have any floppy drives, add the --no-floppy option to the above command to prevent grub from probing the (non-existing) floppy drives.

In the example configuration we want to install GRUB so that it reads its information from the boot-partition /dev/hda1, and installs the GRUB boot record on the hard drive's MBR (master boot record) so that the first thing we see when we turn on the computer is the GRUB prompt. Of course, if you haven't followed the example configuration during the installation, change the commands accordingly.

The tab completion mechanism of GRUB can be used from within GRUB. For instance, if you type in "root (" followed by a TAB, you will be presented with a list of devices (such as hd0). If you type in "root (hd0," followed by a TAB, you will receive a list of available partitions to choose from (such as hd0,0).

By using the tab completion, setting up GRUB should be not that hard. Now go on, configure GRUB, shall we? :-)

Code Listing 8: Installing GRUB in the MBR

grub> root (hd0,0) (Specify where your /boot partition resides) grub> setup (hd0) (Install GRUB in the MBR) grub> quit (Exit the GRUB shell)

Note: If you want to install GRUB in a certain partition instead of the MBR, you have to alter the setup command so it points to the right partition. For instance, if you want GRUB installed in /dev/hda3, then the command becomes setup (hd0,2). Few users however want to do this.

If you have more questions regarding GRUB, please consult the GRUB FAQ or the GRUB Manual.

Note: When you reinstall a kernel, you do not need to copy over the files anymore. Just run make install after compiling the kernel; it will automatically copy the necessary files and adjust the GRUB configuration.

Continue with Rebooting the System.

10.c. Alternative: Using LILO

Installing LILO

LILO, the LInuxLOader, is the tried and true workhorse of Linux bootloaders. However, it lacks some features that GRUB has (which is also the reason why GRUB is currently gaining popularity). The reason why LILO is still used is that, on some systems, GRUB doesn't work and LILO does. Of course, it is also used because some people know LILO and want to stick with it. Either way, Gentoo supports both, and apparently you have chosen to use LILO.

Installing LILO is a breeze; just use emerge.

Code Listing 9: Installing LILO

# emerge lilo

Configuring LILO

To configure LILO, you must create /etc/lilo.conf. Fire up your favorite editor (in this handbook we use nano for consistency) and create the file.

Code Listing 10: Creating /etc/lilo.conf

# nano -w /etc/lilo.conf

Some sections ago we have asked you to remember the kernel-image name you have created. In the next example lilo.conf we use the example partitioning scheme. There are two separate parts:

  • One for those who have not used genkernel to build their kernel
  • One for those who have used genkernel to build their kernel

Make sure you use your kernel image filename and, if appropriate, your initrd image filename.

Note: If your root filesystem is JFS, you must add a append="ro" line after each boot item since JFS needs to replay its log before it allows read-write mounting.

Code Listing 11: Example /etc/lilo.conf

boot=/dev/hda # Install LILO in the MBR prompt # Give the user the chance to select another section timeout=50 # Wait 5 (five) seconds before booting the default section default=gentoo # When the timeout has passed, boot the "gentoo" section

# For non-genkernel users image=/boot/kernel-2.6.12-gentoo-r10
label=gentoo # Name we give to this section read-only # Start with a read-only root. Do not alter! root=/dev/hda3 # Location of the root filesystem

# For genkernel users image=/boot/kernel-genkernel-x86-2.6.12-gentoo-r10
label=gentoo read-only root=/dev/ram0 append="init=/linuxrc ramdisk=8192 real_root=/dev/hda3 udev" initrd=/boot/initramfs-genkernel-2.6.12-gentoo-r10

# The next two lines are only if you dualboot with a Windows system. # In this case, Windows is hosted on /dev/hda6. other=/dev/hda6
label=windows

Note: The udev mentioned at the end of the append line is needed to work around a bug in some genkernel versions if you use udev in the first place (which is the default behaviour).

Note: If you use a different partitioning scheme and/or kernel image, adjust accordingly.

If you need to pass any additional options to the kernel, add an append statement to the section. As an example, we add the video statement to enable framebuffer:

Code Listing 12: Using append to add kernel options

image=/boot/kernel-2.6.12-gentoo-r10
label=gentoo read-only root=/dev/hda3 append="video=vesafb:mtrr,ywrap,1024x768-32@85"

If you're using a 2.6.7 or higher kernel and you jumpered your harddrive because the BIOS can't handle large harddrives you'll need to append hdx=stroke.

genkernel users should know that their kernels use the same boot options as is used for the Installation CD. For instance, if you have SCSI devices, you should add doscsi as kernel option.

Now save the file and exit. To finish up, you have to run /sbin/lilo so LILO can apply the /etc/lilo.conf to your system (i.e. install itself on the disk). Keep in mind that you'll also have to rerun /sbin/lilo every time you install a new kernel or make any changes to the menu.

Code Listing 13: Finishing the LILO installation

# /sbin/lilo

Note: When you reinstall a kernel, you do not need to copy over the files anymore. Just run make install after compiling the kernel; it will automatically copy the necessary files and adjust the LILO configuration.

You can now continue with Rebooting the System.

10.d. Rebooting the System

Exit the chrooted environment and unmount all mounted partitions. Then type in that one magical command you have been waiting for: reboot.

Code Listing 14: Unmounting all partitions and rebooting

# exit cdimage ~# cd cdimage ~# umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo cdimage ~# reboot

Of course, don't forget to remove the bootable CD, otherwise the CD will be booted again instead of your new Gentoo system.

Once rebooted in your Gentoo installation, finish up with Finalizing your Gentoo Installation. 11. Finalizing your Gentoo Installation

11.a. User Administration

Adding a User for Daily Use

Working as root on a Unix/Linux system is dangerous and should be avoided as much as possible. Therefore it is strongly recommended to add a user for day-to-day use.

The groups the user is member of define what activities the user can perform. The following table lists a number of important groups you might wish to use: Group Description audio be able to access the audio devices cdrom be able to directly access optical devices floppy be able to directly access floppy devices games be able to play games portage be able to use emerge --pretend as a normal user usb be able to access USB devices plugdev Be able to mount and use pluggable devices such as cameras and USB sticks video be able to access video capturing hardware and doing hardware acceleration wheel be able to use su

For instance, to create a user called john who is member of the wheel, users and audio groups, log in as root first (only root can create users) and run useradd:

Code Listing 1: Adding a user for day-to-day use

Login: root Password: (Your root password)

# useradd -m -G users,wheel,audio -s /bin/bash john # passwd john Password: (Enter the password for john) Re-enter password: (Re-enter the password to verify)

If a user ever needs to perform some task as root, they can use su - to temporarily receive root privileges. Another way is to use the sudo package which is, if correctly configured, very secure. 12. Where to go from here?

12.a. Documentation

Congratulations! You now have a working Gentoo system. But where to go from here? What are your options now? What to explore first? Gentoo provides its users with lots of possibilities, and therefore lots of documented (and less documented) features.

You should definitely take a look at the next part of the Gentoo Handbook entitled Working with Gentoo which explains how to keep your software up to date, how to install more software, what USE flags are, how the Gentoo Init system works, etc.

If you are interested in optimizing your system for desktop use, or you want to learn how to configure your system to be a full working desktop system, consult our extensive Gentoo Desktop Documentation Resources. Besides, you might want to use our localization guide to make your system feel more at home.

We also have a Gentoo Security Handbook which is worth reading.

For a full listing of all our available documentation check out our Documentation Resources page.

12.b. Gentoo Online

You are of course always welcome on our Gentoo Forums or on one of our many Gentoo IRC channels.

We also have several mailinglists open to all our users. Information on how to join is contained in that page.

We'll shut up now and let you enjoy your installation :) B. Working with Gentoo 1. A Portage Introduction

1.a. Welcome to Portage

Portage is probably Gentoo's most notable innovation in software management. With its high flexibility and enormous amount of features it is frequently seen as the best software management tool available for Linux.

Portage is completely written in Python and Bash and therefore fully visible to the users as both are scripting languages.

Most users will work with Portage through the emerge tool. This chapter is not meant to duplicate the information available from the emerge man page. For a complete rundown of emerge's options, please consult the man page:

Code Listing 1: Reading the emerge man page

$ man emerge

1.b. The Portage Tree

Ebuilds

When we talk about packages, we often mean software titles that are available to the Gentoo users through the Portage tree. The Portage tree is a collection of ebuilds, files that contain all information Portage needs to maintain software (install, search, query, ...). These ebuilds reside in /usr/portage by default.

Whenever you ask Portage to perform some action regarding software titles, it will use the ebuilds on your system as a base. It is therefore important that you regularly update the ebuilds on your system so Portage knows about new software, security updates, etc.

Updating the Portage Tree

The Portage tree is usually updated with rsync, a fast incremental file transfer utility. Updating is fairly simple as the emerge command provides a front-end for rsync:

Code Listing 2: Updating the Portage tree

# emerge --sync

If you are unable to rsync due to firewall restrictions you can still update your Portage tree by using our daily generated Portage tree snapshots. The emerge-webrsync tool automatically fetches and installs the latest snapshot on your system:

Code Listing 3: Running emerge-webrsync

# emerge-webrsync

1.c. Maintaining Software

Searching for Software

To search through the Portage tree after software titles, you can use emerge built-in search capabilities. By default, emerge --search returns the names of packages whose title matches (either fully or partially) the given search term.

For instance, to search for all packages who have "pdf" in their name:

Code Listing 4: Searching for pdf-named packages

$ emerge --search pdf

If you want to search through the descriptions as well you can use the --searchdesc (or -S) switch:

Code Listing 5: Searching for pdf-related packages

$ emerge --searchdesc pdf

When you take a look at the output, you'll notice that it gives you a lot of information. The fields are clearly labelled so we won't go further into their meanings:

Code Listing 6: Example 'emerge --search' output

* net-print/cups-pdf
Latest version available: 1.5.2 Latest version installed: Not Installed Size of downloaded files: 15 kB Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/ Description: Provides a virtual printer for CUPS to produce PDF files. License: GPL-2

Installing Software

Once you've found a software title to your liking, you can easily install it with emerge: just add the package name. For instance, to install gnumeric:

Code Listing 7: Installing gnumeric

# emerge gnumeric

Since many applications depend on each other, any attempt to install a certain software package might result in the installation of several dependencies as well. Don't worry, Portage handles dependencies well. If you want to find out what Portage would install when you ask it to install a certain package, add the --pretend switch. For instance:

Code Listing 8: Pretend to install gnumeric

# emerge --pretend gnumeric

When you ask Portage to install a package, it will download the necessary source code from the internet (if necessary) and store it by default in /usr/portage/distfiles. After this it will unpack, compile and install the package. If you want Portage to only download the sources without installing them, add the --fetchonly option to the emerge command:

Code Listing 9: Download the sourcecode for gnumeric

# emerge --fetchonly gnumeric

Finding Installed Package Documentation

Many packages come with their own documentation. Sometimes, the doc USE flag determines whether the package documentation should be installed or not. You can check the existence of a doc USE flag with the emerge -vp <package name> command.

Code Listing 10: Checking the existence of a doc USE flag

(alsa-lib is just an example, of course.) # emerge -vp alsa-lib ebuild N media-libs/alsa-lib-1.0.9_rc3 +doc -jack 674 kB

You can enable or disable the doc USE flag either globally in the /etc/make.conf file or per package in the /etc/portage/package.use file. The USE Flags chapter covers this aspect in detail.

Once the package installed, its documentation is generally found in a subdirectory named after the package under the /usr/share/doc directory. You can also list all installed files with the equery tool which is part of the app-portage/gentoolkit package.

Code Listing 11: Locating package documentation

# ls -l /usr/share/doc/alsa-lib-1.0.9_rc3 total 28 -rw-rr 1 root root 669 May 17 21:54 ChangeLog.gz -rw-rr 1 root root 9373 May 17 21:54 COPYING.gz drwxr-xr-x 2 root root 8560 May 17 21:54 html -rw-rr 1 root root 196 May 17 21:54 TODO.gz

(Alternatively, use equery to locate interesting files:) # equery files alsa-lib | less media-libs/alsa-lib-1.0.9_rc3 * Contents of media-libs/alsa-lib-1.0.9_rc3: /usr /usr/bin /usr/bin/alsalisp (Output truncated)

Removing Software

When you want to remove a software package from your system, use emerge --unmerge. This will tell Portage to remove all files installed by that package from your system except the configuration files of that application if you have altered those after the installation. Leaving the configuration files allows you to continue working with the package if you ever decide to install it again.

However, a big warning applies: Portage will not check if the package you want to remove is required by another package. It will however warn you when you want to remove an important package that breaks your system if you unmerge it.

Code Listing 12: Removing gnumeric from the system

# emerge --unmerge gnumeric

When you remove a package from your system, the dependencies of that package that were installed automatically when you installed the software are left. To have Portage locate all dependencies that can now be removed, use emerge's --depclean functionality. We will talk about this later on.

Updating your System

To keep your system in perfect shape (and not to mention install the latest security updates) you need to update your system regularly. Since Portage only checks the ebuilds in your Portage tree you first have to update your Portage tree. When your Portage tree is updated, you can update your system with emerge --update world. In the next example, we'll also use the --ask switch which will tell Portage to display the list of packages it wants to upgrade and ask you if you want to continue:

Code Listing 13: Updating your system

# emerge --update --ask world

Portage will then search for newer version of the applications you have installed. However, it will only verify the versions for the applications you have explicitly installed - not the dependencies. If you want to update every single package on your system, add the --deep argument:

Code Listing 14: Updating your entire system

# emerge --update --deep world

Since security updates also happen in packages you have not explicitly installed on your system (but that are pulled in as dependencies of other programs), it is recommended to run this command once in a while.

If you have altered any of your USE flags lately you might want to add --newuse as well. Portage will then verify if the change requires the installation of new packages or recompilation of existing ones:

Code Listing 15: Performing a full update

# emerge --update --deep --newuse world

Metapackages

Some packages in the Portage tree don't have any real content but are used to install a collection of packages. For instance, the kde package will install a complete KDE environment on your system by pulling in various KDE-related packages as dependencies.

If you ever want to remove such a package from your system, running emerge --unmerge on the package won't have much effect as the dependencies remain on the system.

Portage has the functionality to remove orphaned dependencies as well, but since the availability of software is dynamically dependent you first need to update your entire system fully, including the new changes you applied when changing USE flags. After this you can run emerge --depclean to remove the orphaned dependencies. When this is done, you need to rebuild the applications that were dynamically linked to the now-removed software titles but don't require them anymore.

All this is handled with the following three commands:

Code Listing 16: Removing orphaned dependencies

# emerge --update --deep --newuse world # emerge --depclean # revdep-rebuild

revdep-rebuild is provided by the gentoolkit package; don't forget to emerge it first:

Code Listing 17: Installing the gentoolkit package

# emerge gentoolkit

1.d. When Portage is Complaining...

About SLOTs, Virtuals, Branches, Architectures and Profiles

As we stated before, Portage is extremely powerful and supports many features that other software management tools lack. To understand this, we explain a few aspects of Portage without going into too much detail.

With Portage different versions of a single package can coexist on a system. While other distributions tend to name their package to those versions (like freetype and freetype2) Portage uses a technology called SLOTs. An ebuild declares a certain SLOT for its version. Ebuilds with different SLOTs can coexist on the same system. For instance, the freetype package has ebuilds with SLOT="1" and SLOT="2".

There are also packages that provide the same functionality but are implemented differently. For instance, metalogd, sysklogd and syslog-ng are all system loggers. Applications that rely on the availability of "a system logger" cannot depend on, for instance, metalogd, as the other system loggers are as good a choice as any. Portage allows for virtuals: each system logger provides virtual/syslog so that applications can depend on virtual/syslog.

Software in the Portage tree can reside in different branches. By default your system only accepts packages that Gentoo deems stable. Most new software titles, when committed, are added to the testing branch, meaning more testing needs to be done before it is marked as stable. Although you will see the ebuilds for those software in the Portage tree, Portage will not update them before they are placed in the stable branch.

Some software is only available for a few architectures. Or the software doesn't work on the other architectures, or it needs more testing, or the developer that committed the software to the Portage tree is unable to verify if the package works on different architectures.

Each Gentoo installation adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.

Blocked Packages

Code Listing 18: Portage warning about blocked packages (with --pretend)

blocks B mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)

Code Listing 19: Portage warning about blocked packages (without --pretend)

!!! Error: the mail-mta/postfix package conflicts with another package. !!! both can't be installed on the same system together. !!! Please use 'emerge --pretend' to determine blockers.

Ebuilds contain specific fields that inform Portage about its dependencies. There are two possible dependencies: build dependencies, declared in DEPEND and run-time dependencies, declared in RDEPEND. When one of these dependencies explicitly marks a package or virtual as being not compatible, it triggers a blockage.

To fix a blockage, you can choose to not install the package or unmerge the conflicting package first. In the given example, you can opt not to install postfix or to remove ssmtp first.

It is also possible that two packages that are yet to be installed are blocking each other. In this rare case, you should find out why you need to install both. In most cases you can do with one of the packages alone. If not, please file a bug on Gentoo's bugtracking system.

Masked Packages

Code Listing 20: Portage warning about masked packages

!!! all ebuilds that could satisfy "bootsplash" have been masked.

Code Listing 21: Portage warning about masked packages - reason

!!! possible candidates are:

- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword) - lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword) - sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword) - dev-util/cvsd-1.0.2 (masked by: missing keyword) - media-video/ati-gatos-4.3.0 (masked by: package.mask) - sys-libs/glibc-2.3.2-r11 (masked by: profile)

When you want to install a package that isn't available for your system, you will receive this masking error. You should try installing a different application that is available for your system or wait until the package is put available. There is always a reason why a package is masked:

  • ~arch keyword means that the application is not tested sufficiently to be put in the stable branch. Wait a few days or weeks and try again.
  • -arch keyword or -* keyword means that the application does not work on your architecture. If you believe the package does work file a bug at our bugzilla website.
  • missing keyword means that the application has not been tested on your architecture yet. Ask the architecture porting team to test the package or test it for them and report your findings on our bugzilla website.
  • package.mask means that the package has been found corrupt, unstable or worse and has been deliberately marked as do-not-use.
  • profile means that the package has been found not suitable for your profile. The application might break your system if you installed it or is just not compatible with the profile you use.

Missing Dependencies

Code Listing 22: Portage warning about missing dependency

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".

!!! Problem with ebuild sys-devel/gcc-3.4.2-r2 !!! Possibly a DEPEND/*DEPEND problem.

The application you are trying to install depends on another package that is not available for your system. Please check bugzilla if the issue is known and if not, please report it. Unless you are mixing branches this should not occur and is therefore a bug.

Ambiguous Ebuild Name

Code Listing 23: Portage warning about ambiguous ebuild names

!!! The short ebuild name "aterm" is ambiguous. Please specify !!! one of the following fully-qualified ebuild names instead:

dev-libs/aterm x11-terms/aterm

The application you want to install has a name that corresponds with more than one package. You need to supply the category name as well. Portage will inform you of possible matches to choose from.

Circular Dependencies

Code Listing 24: Portage warning about circular dependencies

!!! Error: circular dependencies:

ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1 ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2

Two (or more) packages you want to install depend on each other and can therefore not be installed. This is most likely a bug in the Portage tree. Please resync after a while and try again. You can also check bugzilla if the issue is known and if not, report it.

Fetch failed

Code Listing 25: Portage warning about fetch failed

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing... (...) !!! Some fetch errors were encountered. Please see above for details.

Portage was unable to download the sources for the given application and will try to continue installing the other applications (if applicable). This failure can be due to a mirror that has not synchronised correctly or because the ebuild points to an incorrect location. The server where the sources reside can also be down for some reason.

Retry after one hour to see if the issue still persists.

System Profile Protection

Code Listing 26: Portage warning about profile-protected package

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage' !!! This could be damaging to your system.

You have asked to remove a package that is part of your system's core packages. It is listed in your profile as required and should therefore not be removed from the system. 2. USE flags

2.a. What are USE-flags?

The ideas behind USE-flags

When you are installing Gentoo (or any other distribution, or even operating system for that matter) you make choices depending on the environment you are working with. A setup for a server differs from a setup for a workstation. A gaming workstation differs from a 3D rendering workstation.

This is not only true for choosing what packages you want to install, but also what features a certain package should support. If you don't need OpenGL, why would you bother installing OpenGL and build OpenGL support in most of your packages? If you don't want to use KDE, why would you bother compiling packages with KDE-support if those packages work flawlessly without?

To help users in deciding what to install/activate and what not, we wanted the user to specify his/her environment in an easy way. This forces the user into deciding what they really want and eases the process for Portage, our package managment system, to make useful decisions.

Definition of a USE-flag

Enter the USE-flags. Such a flag is a keyword that embodies support and dependency-information for a certain concept. If you define a certain USE-flag, Portage will know that you want support for the chosen keyword. Of course this also alters the dependency information for a package.

Let us take a look at a specific example: the kde keyword. If you do not have this keyword in your USE variable, all packages that have optional KDE support will be compiled without KDE support. All packages that have an optional KDE dependency will be installed without installing the KDE libraries (as dependency). If you have defined the kde keyword, then those packages will be compiled with KDE support, and the KDE libraries will be installed as dependency.

By correctly defining the keywords you will receive a system tailored specifically to your needs.

What USE-flags exist?

There are two types of USE-flags: global and local USE-flags.

  • A global USE-flag is used by several packages, system-wide. This is what most people see as USE-flags.
  • A local USE-flag is used by a single package to make package-specific decisions.

A list of available global USE-flags can be found online or locally in /usr/portage/profiles/use.desc.

A list of available local USE-flags can be found locally in /usr/portage/profiles/use.local.desc.

2.b. Using USE-flags

Declare permanent USE-flags

In the hope you are convinced of the importance of USE-flags we will now inform you how to declare USE-flags.

As previously mentioned, all USE-flags are declared inside the USE variable. To make it easy for users to search and pick USE-flags, we already provide a default USE setting. This setting is a collection of USE-flags we think are commonly used by the Gentoo users. This default setting is declared in the make.defaults files part of your profile.

The profile your system listens to is pointed to by the /etc/make.profile symlink. Each profile works on top of another, larger profile, the end result is therefore the sum of all profiles. The top profile is the base profile (/usr/portage/profiles/base).

Let us take a look at this default setting for the 2004.3 profile:

Code Listing 1: Cumulative make.defaults USE variable for the 2004.3 profile

(This example is the sum of the settings in base, default-linux,
default-linux/x86 and default-linux/x86/2004.3)
USE="x86 oss apm arts avi berkdb bitmap-fonts crypt cups encode fortran f77
foomaticdb gdbm gif gpm gtk imlib jpeg kde gnome libg++ libwww mad mikmod motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt quicktime readline sdl spell ssl svga tcpd truetype X xml2 xmms xv zlib"

As you can see, this variable already contains quite a lot of keywords. Do not alter any make.defaults file to tailor the USE variable to your needs: changes in this file will be undone when you update Portage!

To change this default setting, you need to add or remove keywords to the USE variable. This is done globally by defining the USE variable in /etc/make.conf. In this variable you add the extra USE-flags you require, or remove the USE-flags you don't want. This latter is done by prefixing the keyword with the minus-sign ("-").

For instance, to remove support for KDE and QT but add support for ldap, the following USE can be defined in /etc/make.conf:

Code Listing 2: An example USE setting in /etc/make.conf

USE="-kde -qt ldap"

Declaring USE flags for individual packages

Sometimes you want to declare a certain USE flag for one (or a couple) of applications but not system-wide. To accomplish this, you will need to create the /etc/portage directory (if it doesn't exist yet) and edit /etc/portage/package.use.

For instance, if you don't want berkdb support globally but you do want it for mysql, you would add:

Code Listing 3: /etc/portage/package.use example

dev-db/mysql berkdb

You can of course also explicitly disable USE flags for a certain application. For instance, if you don't want java support in PHP:

Code Listing 4: /etc/portage/package.use 2nd example

dev-php/php -java

Declare temporary USE-flags

Sometimes you want to set a certain USE-setting only once. Instead of editing /etc/make.conf twice (to do and undo the USE-changes) you can just declare the USE-variable as environment variable. Remember that, when you re-emerge or update this application (either explicitly or as part of a system update) your changes will be lost!

As an example we will temporarily remove java from the USE-setting during the installation of mozilla.

Code Listing 5: Using USE as environment variable

# USE="-java" emerge mozilla

Automatic USE Flags

After certain packages are installed, additional USE flags will automatically be enabled for you if you do not explicitly disable them. To view the list of packages that trigger automatic USE-flags, check /etc/make.profile/use.defaults and the use.defaults files of the parent profiles.

Code Listing 6: A snippet from /etc/make.profile/use.defaults

gnome gnome-base/gnome gtk x11-libs/gtk+ qt x11-libs/qt kde kde-base/kdebase motif x11-libs/openmotif

Precedence

Of course there is a certain precedence on what setting has priority over the USE setting. You don't want to declare USE="-java" only to see that java is still used due to a setting that has a higher priority. The precedence for the USE setting is, ordered by priority (first has lowest priority):

  1. Default USE setting declared in the make.defaults files part of your profile
  2. Inherited USE setting if a package from profile use.defaults is installed
  3. User-defined USE setting in /etc/make.conf
  4. User-defined USE setting in /etc/portage/package.use
  5. User-defined USE setting as environment variable

To view the final USE setting as seen by Portage, run emerge --info. This will list all relevant variables (including the USE variable) with the content used by Portage.

Code Listing 7: Running emerge --info

# emerge --info

Adapting your Entire System to New USE Flags

If you have altered your USE flags and you wish to update your entire system to use the new USE flags, use emerge's --newuse option:

Code Listing 8: Rebuilding your entire system

# emerge --update --deep --newuse world

Next, run Portage's depclean to remove the conditional dependencies that were emerged on your "old" system but that have been obsoleted by the new USE flags.

Warning: Running emerge --depclean is a dangerous operation and should be handled with care. Double-check the provided list of "obsoleted" packages to make sure it doesn't remove packages you need. In the following example we add the -p switch to have depclean only list the packages without removing them.

Code Listing 9: Removing obsoleted packages

# emerge -p --depclean

When depclean has finished, run revdep-rebuild to rebuild the applications that are dynamically linked against shared objects provided by possibly removed packages. revdep-rebuild is part of the gentoolkit package; don't forget to emerge it first.

Code Listing 10: Running revdep-rebuild

# revdep-rebuild

When all this is accomplished, your system is using the new USE flag settings.

2.c. Package specific USE-flags

Viewing available USE-flags

Let us take the example of mozilla: what USE-flags does it listen to? To find out, we use emerge with the --pretend and --verbose options:

Code Listing 11: Viewing the used USE-flags

# emerge --pretend --verbose mozilla These are the packages that I would merge, in order:

Calculating dependencies ...done! ebuild R www-client/mozilla-1.7.12-r2 USE="crypt gnome java mozsvg ssl truetype xprint -debug -ipv6 -ldap -mozcalendar -mozdevelop -moznocompose -moznoirc -moznomail -moznoxft -postgres -xinerama" 0 kB

emerge isn't the only tool for this job. In fact, we have a tool dedicated to package information called equery which resides in the gentoolkit package. First, install gentoolkit:

Code Listing 12: Installing gentoolkit

# emerge gentoolkit

Now run equery with the uses argument to view the USE-flags of a certain package. For instance, for the gnumeric package:

Code Listing 13: Using equery to view used USE-flags

# equery uses gnumeric Colour Code : set unset Legend : (U) Col 1 - Current USE flags : (I) Col 2 - Installed With USE flags

U I Found these USE variables in : app-office/gnumeric-1.2.0 - - libgda : Adds GNU Data Access (CORBA wrapper) support for gnumeric - - gnomedb : unknown + + python : Adds support/bindings for the Python language + + bonobo : Adds support for gnome-base/bonobo (Gnome CORBA interfaces)

3. Portage Features

3.a. Portage Features

Portage has several additional features that makes your Gentoo experience even better. Many of these features rely on certain software tools that improve performance, reliability, security, ...

To enable or disable certain Portage features you need to edit /etc/make.conf's FEATURES variable which contains the various feature keywords, separated by white space. In several cases you will also need to install the additional tool on which the feature relies.

Not all features that Portage supports are listed here. For a full overview, please consult the make.conf man page:

Code Listing 1: Consulting the make.conf man page

$ man make.conf

To find out what FEATURES are default set, run emerge --info and search for the FEATURES variable or grep it out:

Code Listing 2: Finding out the FEATURES that are already set

$ emerge --info | grep FEATURES

3.b. Distributed Compiling

Using distcc

distcc is a program to distribute compilations across several, not necessarily identical, machines on a network. The distcc client sends all necessary information to the available distcc servers (running distccd) so they can compile pieces of source code for the client. The net result is a faster compilation time.

You can find more information about distcc (and how to have it work with Gentoo) in our Gentoo Distcc Documentation.

Installing distcc

Distcc ships with a graphical monitor to monitor tasks that your computer is sending away for compilation. If you use Gnome then put 'gnome' in your USE variable. However, if you don't use Gnome and would still like to have the monitor then you should put 'gtk' in your USE variable.

Code Listing 3: Installing distcc

# emerge distcc

Activating Portage Support

Add distcc to the FEATURES variable inside /etc/make.conf. Next, edit the MAKEOPTS variable to your liking. A known guideline is to fill in "-jX" with X the number of CPUs that run distccd (including the current host) plus one, but you might have better results with other numbers.

Now run distcc-config and enter the list of available distcc servers. For a simple example we assume that the available DistCC servers are 192.168.1.102 (the current host), 192.168.1.103 and 192.168.1.104 (two "remote" hosts):

Code Listing 4: Configuring distcc to use three available distcc servers

# distcc-config --set-hosts "192.168.1.102 192.168.1.103 192.168.1.104"

Don't forget to run the distccd daemon as well:

Code Listing 5: Starting the distccd daemons

# rc-update add distccd default # /etc/init.d/distccd start

3.c. Caching Compilation

About ccache

ccache is a fast compiler cache. When you compile a program, it will cache intermediate results so that, whenever you recompile the same program, the compilation time is greatly reduced. In common compilations this can result in 5 to 10 times faster compilation times.

If you are interested in the ins and outs of ccache, please visit the ccache homepage.

Installing ccache

To install ccache, run emerge ccache:

Code Listing 6: Installing ccache

# emerge ccache

Activating Portage Support

Open /etc/make.conf and add ccache to the FEATURES variable. Next, add a new variable called CCACHE_SIZE and set it to "2G":

Code Listing 7: Editing CCACHE_SIZE in /etc/make.conf

CCACHE_SIZE="2G"

To check if ccache functions, ask ccache to provide you with its statistics. Because Portage uses a different ccache home directory, you need to set the CCACHE_DIR variable as well:

Code Listing 8: Viewing ccache statistics

# CCACHE_DIR="/var/tmp/ccache" ccache -s

The /var/tmp/ccache location is Portage' default ccache home directory; if you want to alter this setting you can set the CCACHE_DIR variable in /etc/make.conf.

However, if you would run ccache, it would use the default location of ${HOME}/.ccache, which is why you needed to set the CCACHE_DIR variable when asking for the (Portage) ccache statistics.

Using ccache for non-Portage C Compiling

If you would like to use ccache for non-Portage compilations, add /usr/lib/ccache/bin to the beginning of your PATH variable (before /usr/bin). This can be accomplished by editing /etc/env.d/00basic, which is the first environment file that defines the PATH variable:

Code Listing 9: Editing /etc/env.d/00basic

PATH="/usr/lib/ccache/bin:/opt/bin"

3.d. Binary Package Support

Creating Prebuilt Packages

Portage supports the installation of prebuilt packages. Even though Gentoo does not provide prebuilt packages by itself (except for the GRP snapshots) Portage can be made fully aware of prebuilt packages.

To create a prebuilt package you can use quickpkg if the package is already installed on your system, or emerge with the --buildpkg or --buildpkgonly options.

If you want Portage to create prebuilt packages of every single package you install, add buildpkg to the FEATURES variable.

More extended support for creating prebuilt package sets can be obtained with catalyst. For more information on catalyst please read the Catalyst Reference Manual and Catalyst Frequently Asked Questions.

Installing Prebuilt Packages

Although Gentoo doesn't provide one, you can create a central repository where you store prebuilt packages. If you want to use this repository, you need to make Portage aware of it by having the PORTAGE_BINHOST variable point to it. For instance, if the prebuilt packages are on ftp://buildhost/gentoo:

Code Listing 10: Setting PORTAGE_BINHOST in /etc/make.conf

PORTAGE_BINHOST="ftp://buildhost/gentoo"

When you want to install a prebuilt package, add the --getbinpkg option to the emerge command alongside of the --usepkg option. The former tells emerge to download the prebuilt package from the previously defined server while the latter asks emerge to try to install the prebuilt package first before fetching the sources and compiling it.

For instance, to install gnumeric with prebuilt packages:

Code Listing 11: Installing the gnumeric prebuilt package

# emerge --usepkg --getbinpkg gnumeric

More information about emerge's prebuilt package options can be found in the emerge man page:

Code Listing 12: Reading the emerge man page

$ man emerge

4. Initscripts

4.a. Runlevels

Booting your System

When you boot your system, you will notice lots of text floating by. If you pay close attention, you will notice this text is the same every time you reboot your system. The sequence of all these actions is called the boot sequence and is (more or less) statically defined.

First, your boot loader will load the kernel image you have defined in the boot loader configuration into memory after which it tells the CPU to run the kernel. When the kernel is loaded and run, it initializes all kernel-specific structures and tasks and starts the init process.

This process then makes sure that all filesystems (defined in /etc/fstab) are mounted and ready to be used. Then it executes several scripts located in /etc/init.d, which will start the services you need in order to have a successfully booted system.

Finally, when all scripts are executed, init activates the terminals (in most cases just the virtual consoles which are hidden beneath Alt-F1, Alt-F2, etc.) attaching a special process called agetty to it. This process will then make sure you are able to log on through these terminals by running login.

Init Scripts

Now init doesn't just execute the scripts in /etc/init.d randomly. Even more, it doesn't run all scripts in /etc/init.d, only the scripts it is told to execute. It decides which scripts to execute by looking into /etc/runlevels.

First, init runs all scripts from /etc/init.d that have symbolic links inside /etc/runlevels/boot. Usually, it will start the scripts in alphabetical order, but some scripts have dependency information in them, telling the system that another script must be run before they can be started.

When all /etc/runlevels/boot referenced scripts are executed, init continues with running the scripts that have a symbolic link to them in /etc/runlevels/default. Again, it will use the alphabetical order to decide what script to run first, unless a script has dependency information in it, in which case the order is changed to provide a valid start-up sequence.

How Init Works

Of course init doesn't decide all that by itself. It needs a configuration file that specifies what actions need to be taken. This configuration file is /etc/inittab.

If you remember the boot sequence we have just described, you will remember that init's first action is to mount all filesystems. This is defined in the following line from /etc/inittab:

Code Listing 1: The system initialisation line in /etc/inittab

si::sysinit:/sbin/rc sysinit

This line tells init that it must run /sbin/rc sysinit to initialize the system. The /sbin/rc script takes care of the initialisation, so you might say that init doesn't do much -- it delegates the task of initialising the system to another process.

Second, init executed all scripts that had symbolic links in /etc/runlevels/boot. This is defined in the following line:

Code Listing 2: The system initialisation, continued

rc::bootwait:/sbin/rc boot

Again the rc script performs the necessary tasks. Note that the option given to rc (boot) is the same as the subdirectory of /etc/runlevels that is used.

Now init checks its configuration file to see what runlevel it should run. To decide this, it reads the following line from /etc/inittab:

Code Listing 3: The initdefault line

id:3:initdefault:

In this case (which the majority of Gentoo users will use), the runlevel id is 3. Using this information, init checks what it must run to start runlevel 3:

Code Listing 4: The runlevel definitions

l0:0:wait:/sbin/rc shutdown l1:S1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default l4:4:wait:/sbin/rc default l5:5:wait:/sbin/rc default l6:6:wait:/sbin/rc reboot

The line that defines level 3, again, uses the rc script to start the services (now with argument default). Again note that the argument of rc is the same as the subdirectory from /etc/runlevels.

When rc has finished, init decides what virtual consoles it should activate and what commands need to be run at each console:

Code Listing 5: The virtual consoles definition

c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux

What is a runlevel?

You have seen that init uses a numbering scheme to decide what runlevel it should activate. A runlevel is a state in which your system is running and contains a collection of scripts (runlevel scripts or initscripts) that must be executed when you enter or leave a runlevel.

In Gentoo, there are seven runlevels defined: three internal runlevels, and four user-defined runlevels. The internal runlevels are called sysinit, shutdown and reboot and do exactly what their names imply: initialize the system, powering off the system and rebooting the system.

The user-defined runlevels are those with an accompanying /etc/runlevels subdirectory: boot, default, nonetwork and single. The boot runlevel starts all system-necessary services which all other runlevels use. The remaining three runlevels differ in what services they start: default is used for day-to-day operations, nonetwork is used in case no network connectivity is required, and single is used when you need to fix the system.

Working with the Init Scripts

The scripts that the rc process starts are called init scripts. Each script in /etc/init.d can be executed with the arguments start, stop, restart, pause, zap, status, ineed, iuse, needsme, usesme or broken.

To start, stop or restart a service (and all depending services), start, stop and restart should be used:

Code Listing 6: Starting Postfix

# /etc/init.d/postfix start

Note: Only the services that need the given service are stopped or restarted. The other depending services (those that use the service but don't need it) are left untouched.

If you want to stop a service, but not the services that depend on it, you can use the pause argument:

Code Listing 7: Stopping Postfix but keep the depending services running

# /etc/init.d/postfix pause

If you want to see what status a service has (started, stopped, paused, ...) you can use the status argument:

Code Listing 8: Status information for postfix

# /etc/init.d/postfix status

If the status information tells you that the service is running, but you know that it is not, then you can reset the status information to "stopped" with the zap argument:

Code Listing 9: Resetting status information for postfix

# /etc/init.d/postfix zap

To also ask what dependencies the service has, you can use iuse or ineed. With ineed you can see the services that are really necessary for the correct functioning of the service. iuse on the other hand shows the services that can be used by the service, but are not necessary for the correct functioning.

Code Listing 10: Requesting a list of all necessary services on which Postfix depends

# /etc/init.d/postfix ineed

Similarly, you can ask what services require the service (needsme) or can use it (usesme):

Code Listing 11: Requesting a list of all services that require Postfix

# /etc/init.d/postfix needsme

Finally, you can ask what dependencies the service requires that are missing:

Code Listing 12: Requesting a list of missing dependencies for Postfix

# /etc/init.d/postfix broken

4.b. Working with rc-update

What is rc-update?

Gentoo's init system uses a dependency-tree to decide what service needs to be started first. As this is a tedious task that we wouldn't want our users to have to do manually, we have created tools that ease the administration of the runlevels and init scripts.

With rc-update you can add and remove init scripts to a runlevel. The rc-update tool will then automatically ask the depscan.sh script to rebuild the dependency tree.

Adding and Removing Services

You have already added init scripts to the "default" runlevel during the installation of Gentoo. At that time you might not have had a clue what the "default" is for, but now you should. The rc-update script requires a second argument that defines the action: add, del or show.

To add or remove an init script, just give rc-update the add or del argument, followed by the init script and the runlevel. For instance:

Code Listing 13: Removing Postfix from the default runlevel

# rc-update del postfix default

The rc-update show command will show all the available init scripts and list at which runlevels they will execute:

Code Listing 14: Receiving init script information

# rc-update show

4.c. Configuring Services

Why the Need for Extra Configuration?

Init scripts can be quite complex. It is therefore not really desirable to have the users edit the init script directly, as it would make it more error-prone. It is however important to be able to configure such a service. For instance, you might want to give more options to the service itself.

A second reason to have this configuration outside the init script is to be able to update the init scripts without the fear that your configuration changes will be undone.

The /etc/conf.d Directory

Gentoo provides an easy way to configure such a service: every init script that can be configured has a file in /etc/conf.d. For instance, the apache2 initscript (called /etc/init.d/apache2) has a configuration file called /etc/conf.d/apache2, which can contain the options you want to give to the Apache 2 server when it is started:

Code Listing 15: Variable defined in /etc/conf.d/apache2

APACHE2_OPTS="-D PHP4"

Such a configuration file contains variables and variables alone (just like /etc/make.conf), making it very easy to configure services. It also allows us to provide more information about the variables (as comments).

4.d. Writing Init Scripts

Do I Have To?

No, writing an init script is usually not necessary as Gentoo provides ready-to-use init scripts for all provided services. However, you might have installed a service without using Portage, in which case you will most likely have to create an init script.

Do not use the init script provided by the service if it isn't explicitly written for Gentoo: Gentoo's init scripts are not compatible with the init scripts used by other distributions!

Layout

The basic layout of an init script is shown below.

Code Listing 16: Basic layout of an init script

#!/sbin/runscript

depend() {
(Dependency information)
}

start() {
(Commands necessary to start the service)
}

stop() {
(Commands necessary to stop the service)
}

restart() {
(Commands necessary to restart the service)
}

Any init script requires the start() function to be defined. All other sections are optional.

Dependencies

There are two dependencies you can define: use and need. As we have mentioned before, the need dependency is more strict than the use dependency. Following this dependency type you enter the service you depend on, or the virtual dependency.

A virtual dependency is a dependency that a service provides, but that is not provided solely by that service. Your init script can depend on a system logger, but there are many system loggers available (metalogd, syslog-ng, sysklogd, ...). As you cannot need every single one of them (no sensible system has all these system loggers installed and running) we made sure that all these services provide a virtual dependency.

Let us take a look at the dependency information for the postfix service.

Code Listing 17: Dependency information for Postfix

depend() {
need net use logger dns provide mta
}

As you can see, the postfix service:

  • requires the (virtual) net dependency (which is provided by, for instance, /etc/init.d/net.eth0)
  • uses the (virtual) logger dependency (which is provided by, for instance, /etc/init.d/syslog-ng)
  • uses the (virtual) dns dependency (which is provided by, for instance, /etc/init.d/named)
  • provides the (virtual) mta dependency (which is common for all mail servers)

Controlling the Order

In some cases you might not require a service, but want your service to be started before (or after) another service if it is available on the system (note the conditional - this is no dependency anymore) and run in the same runlevel (note the conditional - only services in the same runlevel are involved). You can provide this information using the before or after settings.

As an example we view the settings of the Portmap service:

Code Listing 18: The depend() function in the Portmap service

depend() {
need net before inetd before xinetd
}

You can also use the "*" glob to catch all services in the same runlevel, although this isn't advisable.

Code Listing 19: Running an init script as first script in the runlevel

depend() {
before *
}

Standard Functions

Next to the depend() functionality, you also need to define the start() function. This one contains all the commands necessary to initialize your service. It is advisable to use the ebegin and eend functions to inform the user about what is happening:

Code Listing 20: Example start() function

start() {
ebegin "Starting my_service" start-stop-daemon --start --quiet --exec /path/to/my_service eend $?
}

If you need more examples of the start() function, please read the source code of the available init scripts in your /etc/init.d directory. As for start-stop-daemon, there is an excellent man page available if you need more information:

Code Listing 21: Getting the man page for start-stop-daemon

# man start-stop-daemon

Other functions you can define are: stop() and restart(). You are not obliged to define these functions! Our init system is intelligent enough to fill these functions by itself if you use start-stop-daemon.

Gentoo's init script syntax is based on the Bourne Again Shell (bash) so you are free to use bash-compatible constructs inside your init script.

Adding Custom Options

If you want your init script to support more options than the ones we have already encountered, you should add the option to the opts variable, and create a function with the same name as the option. For instance, to support an option called restartdelay:

Code Listing 22: Supporting the restartdelay option

opts="${opts} restartdelay"

restartdelay() {
stop sleep 3 # Wait 3 seconds before starting again start
}

Service Configuration Variables

You don't have to do anything to support a configuration file in /etc/conf.d: if your init script is executed, the following files are automatically sourced (i.e. the variables are available to use):

  • /etc/conf.d/<your init script>
  • /etc/conf.d/basic
  • /etc/rc.conf

Also, if your init script provides a virtual dependency (such as net), the file associated with that dependency (such as /etc/conf.d/net) will be sourced too.

4.e. Changing the Runlevel Behaviour

Who might benefit from this?

Many laptop users know the situation: at home you need to start net.eth0 while you don't want to start net.eth0 while you're on the road (as there is no network available). With Gentoo you can alter the runlevel behaviour to your own will.

For instance you can create a second "default" runlevel which you can boot that has other init scripts assigned to it. You can then select at boottime what default runlevel you want to use.

Using softlevel

First of all, create the runlevel directory for your second "default" runlevel. As an example we create the offline runlevel:

Code Listing 23: Creating a runlevel directory

# mkdir /etc/runlevels/offline

Add the necessary init scripts to the newly created runlevels. For instance, if you want to have an exact copy of your current default runlevel but without net.eth0:

Code Listing 24: Adding the necessary init scripts

(Copy all services from default runlevel to offline runlevel) # cd /etc/runlevels/default # for service in *; do rc-update add $service offline; done (Remove unwanted service from offline runlevel) # rc-update del net.eth0 offline (Display active services for offline runlevel) # rc-update show offline (Partial sample Output)
acpid | offline
domainname | offline
local | offline
net.eth0 |

Now edit your bootloader configuration and add a new entry for the offline runlevel. For instance, in /boot/grub/grub.conf:

Code Listing 25: Adding an entry for the offline runlevel

title Gentoo Linux Offline Usage
root (hd0,0) kernel (hd0,0)/kernel-2.4.25 root=/dev/hda3 softlevel=offline

Voilà, you're all set now. If you boot your system and select the newly added entry at boot, the offline runlevel will be used instead of the default one.

Using bootlevel

Using bootlevel is completely analogous to softlevel. The only difference here is that you define a second "boot" runlevel instead of a second "default" runlevel. 5. Environment Variables

5.a. Environment Variables?

What they are

An environment variable is a named object that contains information used by one or more applications. Many users (and especially those new to Linux) find this a bit weird or unmanageable. However, this is a mistake: by using environment variables one can easily change a configuration setting for one or more applications.

Important Examples

The following table lists a number of variables used by a Linux system and describes their use. Example values are presented after the table. Variable Description PATH This variable contains a colon-separated list of directories in which your system looks for executable files. If you enter a name of an executable (such as ls, rc-update or emerge) but this executable is not located in a listed directory, your system will not execute it (unless you enter the full path as command, such as /bin/ls). ROOTPATH This variable has the same function as PATH, but this one only lists the directories that should be checked when the root-user enters a command. LDPATH This variable contains a colon-separated list of directories in which the dynamical linker searches through to find a library. MANPATH This variable contains a colon-separated list of directories in which the man command searches for the man pages. INFODIR This variable contains a colon-separated list of directories in which the info command searches for the info pages. PAGER This variable contains the path to the program used to list the contents of files through (such as less or more). EDITOR This variable contains the path to the program used to change the contents of files with (such as nano or vi). KDEDIRS This variable contains a colon-separated list of directories which contain KDE-specific material. CLASSPATH This variable contains a colon-separated list of directories which contain Java classes. CONFIG_PROTECT This variable contains a space-delimited list of directories which should be protected by Portage during updates. CONFIG_PROTECT_MASK This variable contains a space-delimited list of directories which should not be protected by Portage during updates.

Below you will find an example definition of all these variables:

Code Listing 1: Example definitions

PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin" ROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin" LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" MANPATH="/usr/share/man:/usr/local/share/man" INFODIR="/usr/share/info:/usr/local/share/info" PAGER="/usr/bin/less" EDITOR="/usr/bin/vim" KDEDIRS="/usr" CLASSPATH="/opt/blackdown-jre-1.4.1/lib/rt.jar:." CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \
/usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \ /usr/share/texmf/tex/platex/config/ /usr/share/config"
CONFIG_PROTECT_MASK="/etc/gconf

5.b. Defining Variables Globally

The /etc/env.d Directory

To centralise the definitions of these variables, Gentoo introduced the /etc/env.d directory. Inside this directory you will find a number of files, such as 00basic, 05gcc, etc. which contain the variables needed by the application mentioned in their name.

For instance, when you installed gcc, a file called 05gcc was created by the ebuild which contains the definitions of the following variables:

Code Listing 2: /etc/env.d/05gcc

PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

Other distributions tell you to change or add such environment variable definitions in /etc/profile or other locations. Gentoo on the other hand makes it easy for you (and for Portage) to maintain and manage the environment variables without having to pay attention to the numerous files that can contain environment variables.

For instance, when gcc is updated, the /etc/env.d/05gcc file is updated too without requesting any user-interaction.

This not only benefits Portage, but also you, as user. Occasionally you might be asked to set a certain environment variable system-wide. As an example we take the http_proxy variable. Instead of messing about with /etc/profile, you can now just create a file (/etc/env.d/99local) and enter your definition(s) in it:

Code Listing 3: /etc/env.d/99local

http_proxy="proxy.server.com:8080"

By using the same file for all your variables, you have a quick overview on the variables you have defined yourself.

The env-update Script

Several files in /etc/env.d define the PATH variable. This is not a mistake: when you run env-update, it will append the several definitions before it updates the environment variables, thereby making it easy for packages (or users) to add their own environment variable settings without interfering with the already existing values.

The env-update script will append the values in the alphabetical order of the /etc/env.d files. The file names must begin with two decimal digits.

Code Listing 4: Update order used by env-update

00basic 99kde-env 99local
+-----------+------------+-----------+
PATH="/bin:/usr/bin:/usr/kde/3.2/bin:/usr/local/bin"

The concatenation of variables does not always happen, only with the following variables: KDEDIRS, PATH, CLASSPATH, LDPATH, MANPATH, INFODIR, INFOPATH, ROOTPATH, CONFIG_PROTECT, CONFIG_PROTECT_MASK, PRELINK_PATH and PRELINK_PATH_MASK. For all other variables the latest defined value (in alphabetical order of the files in /etc/env.d) is used.

When you run env-update, the script will create all environment variables and place them in /etc/profile.env (which is used by /etc/profile). It will also extract the information from the LDPATH variable and use that to create /etc/ld.so.conf. After this, it will run ldconfig to recreate the /etc/ld.so.cache file used by the dynamical linker.

If you want to notice the effect of env-update immediately after you run it, execute the following command to update your environment. Users who have installed Gentoo themselves will probably remember this from the installation instructions:

Code Listing 5: Updating the environment

# env-update && source /etc/profile

Note: The above command only updates the variables in your current terminal, new consoles, and their children. Thus, if you are working in X11, you will need to either type source /etc/profile in every new terminal you open or restart X so that all new terminals source the new variables. If you use a login manager, become root and type /etc/init.d/xdm restart. If not, you will need to logout and log back in for X to spawn children with the new variable values.

5.c. Defining Variables Locally

User Specific

You do not always want to define an environment variable globally. For instance, you might want to add /home/my_user/bin and the current working directory (the directory you are in) to the PATH variable but don't want all other users on your system to have that in their PATH too. If you want to define an environment variable locally, you should use ~/.bashrc or ~/.bash_profile:

Code Listing 6: Extending PATH for local usage in ~/.bashrc

(A colon followed by no directory is treated as the current working directory) PATH="${PATH}:/home/my_user/bin:"

When you relogin, your PATH variable will be updated.

Session Specific

Sometimes even stricter definitions are requested. You might want to be able to use binaries from a temporary directory you created without using the path to the binaries themselves or editing ~/.bashrc for the short time you need it.

In this case, you can just define the PATH variable in your current session by using the export command. As long as you don't log out, the PATH variable will be using the temporary settings.

Code Listing 7: Defining a session-specific environment variable

# export PATH="${PATH}:/home/my_user/tmp/usr/bin"

C. Working with Portage 1. Files and Directories

1.a. Portage Files

Configuration Directives

Portage comes with a default configuration stored in /etc/make.globals. When you take a look at it, you'll notice that all Portage configuration is handled through variables. What variables Portage listens to and what they mean are described later.

Since many configuration directives differ between architectures, Portage also has default configuration files which are part of your profile. Your profile is pointed to by the /etc/make.profile symlink; Portage' configurations are set in the make.defaults files of your profile and all parent profiles. We'll explain more about profiles and the /etc/make.profile directory later on.

If you're planning on changing a configuration variable, don't alter /etc/make.globals or make.defaults. Instead use /etc/make.conf which has precedence over the previous files. You'll also find a /etc/make.conf.example. As the name implies, this is merely an example file - Portage does not read in this file.

You can also define a Portage configuration variable as an environment variable, but we don't recommend this.

Profile-Specific Information

We've already encountered the /etc/make.profile directory. Well, this isn't exactly a directory but a symbolic link to a profile, by default one inside /usr/portage/profiles although you can create your own profiles elsewhere and point to them. The profile this symlink points to is the profile to which your system adheres.

A profile contains architecture-specific information for Portage, such as a list of packages that belong to the system corresponding with that profile, a list of packages that don't work (or are masked-out) for that profile, etc.

User-Specific Configuration

When you need to override Portage's behaviour regarding the installation of software, you will end up editing files within /etc/portage. You are highly recommended to use files within /etc/portage and highly discouraged to override the behaviour through environment variables!

Within /etc/portage you can create the following files:

  • package.mask which lists the packages you never want Portage to install
  • package.unmask which lists the packages you want to be able to install even though the Gentoo developers highly discourage you from emerging them
  • package.keywords which lists the packages you want to be able to install even though the package hasn't been found suitable for your system or architecture (yet)
  • package.use which lists the USE flags you want to use for certain packages without having the entire system use those USE flags

More information about the /etc/portage directory and a full list of possible files you can create can be found in the Portage man page:

Code Listing 1: Reading the Portage man page

$ man portage

Changing Portage File & Directory Locations

The previously mentioned configuration files cannot be stored elsewhere - Portage will always look for those configuration files at those exact locations. However, Portage uses many other locations for various purposes: build directory, source code storage, Portage tree location, ...

All these purposes have well-known default locations but can be altered to your own taste through /etc/make.conf. The rest of this chapter explains what special-purpose locations Portage uses and how to alter their placement on your filesystem.

This document isn't meant to be used as a reference though. If you need 100% coverage, please consult the Portage and make.conf man pages:

Code Listing 2: Reading the Portage and make.conf man pages

$ man portage $ man make.conf

1.b. Storing Files

The Portage Tree

The Portage tree default location is /usr/portage. This is defined by the PORTDIR variable. When you store the Portage tree elsewhere (by altering this variable), don't forget to change the /etc/make.profile symbolic link accordingly.

If you alter the PORTDIR variable, you might want to alter the following variables as well since they will not notice the PORTDIR change. This is due to how Portage handles variables: PKGDIR, DISTDIR, RPMDIR.

Prebuilt Binaries

Even though Portage doesn't use prebuilt binaries by default, it has extensive support for them. When you ask Portage to work with prebuilt packages, it will look for them in /usr/portage/packages. This location is defined by the PKGDIR variable.

Source Code

Application source code is stored in /usr/portage/distfiles by default. This location is defined by the DISTDIR variable.

RPM Files

Even though Portage cannot use RPM files, it is able to generate them using the ebuild command (see The Ebuild Application). The default location where Portage stores RPM files is /usr/portage/rpm and is defined by the RPMDIR variable.

Portage Database

Portage stores the state of your system (what packages are installed, what files belong to which package, ...) in /var/db/pkg. Do not alter these files manually! It might break Portage's knowledge of your system.

Portage Cache

The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in /var/cache/edb. This location really is a cache: you can clean it if you are not running any portage-related application at that moment.

1.c. Building Software

Temporary Portage Files

Portage's temporary files are stored in /var/tmp by default. This is defined by the PORTAGE_TMPDIR variable.

If you alter the PORTAGE_TMPDIR variable, you might want to alter the following variables as well since they will not notice the PORTAGE_TMPDIR change. This is due to how Portage handles variables: BUILD_PREFIX.

Building Directory

Portage creates specific build directories for each package it emerges inside /var/tmp/portage. This location is defined by the BUILD_PREFIX variable.

Live Filesystem Location

By default Portage installs all files on the current filesystem (/), but you can change this by setting the ROOT environment variable. This is useful when you want to create new build images.

1.d. Logging Features

Ebuild Logging

Portage can create per-ebuild logfiles, but only when the PORT_LOGDIR variable is set to a location that is writable by Portage (the portage user). By default this variable is unset. 2. Configuring through Variables

2.a. Portage Configuration

As noted previously, Portage is configurable through many variables which you should define in /etc/make.conf. Please refer to the make.conf man page for more and complete information:

Code Listing 1: Reading the make.conf man page

$ man make.conf

2.b. Build-specific Options

Configure and Compiler Options

When Portage builds applications, it passes the contents of the following variables to the compiler and configure script:

  • CFLAGS & CXXFLAGS define the desired compiler flags for C and C++ compiling.
  • CHOST defines the build host information for the application's configure script
  • MAKEOPTS is passed to the make command and is usually set to define the amount of parallelism used during the compilation. More information about the make options can be found in the make man page.

The USE variable is also used during configure and compilations but has been explained in great detail in previous chapters.

Merge Options

When Portage has merged a newer version of a certain software title, it will remove the obsoleted files of the older version from your system. Portage gives the user a 5 second delay before unmerging the older version. These 5 seconds are defined by the CLEAN_DELAY variable.

2.c. Configuration File Protection

Portage's Protected Locations

Portage overwrites files provided by newer versions of a software title if the files aren't stored in a protected location. These protected locations are defined by the CONFIG_PROTECT variable and are generally configuration file locations. The directory listing is space-delimited.

A file that would be written in such a protected location is renamed and the user is warned about the presence of a newer version of the (presumable) configuration file.

You can find out about the current CONFIG_PROTECT setting from the emerge --info output:

Code Listing 2: Getting the CONFIG_PROTECT setting

$ emerge --info | grep 'CONFIG_PROTECT='

More information about Portage's Configuration File Protection is available through emerge:

Code Listing 3: More information about Configuration File Protection

$ emerge --help config

Excluding Directories

To 'unprotect' certain subdirectories of protected locations you can use the CONFIG_PROTECT_MASK variable.

2.d. Download Options

Server Locations

When the requested information or data is not available on your system, Portage will retrieve it from the Internet. The server locations for the various information and data channels are defined by the following variables:

  • GENTOO_MIRRORS defines a list of server locations which contain source code (distfiles)
  • PORTAGE_BINHOST defines a particular server location containing prebuilt packages for your system

A third setting involves the location of the rsync server which you use when you update your Portage tree:

  • SYNC defines a particular server which Portage uses to fetch the Portage tree from

The GENTOO_MIRRORS and SYNC variables can be set automatically through the mirrorselect application. You need to emerge mirrorselect first before you can use it. For more information, see mirrorselect's online help:

Code Listing 4: More information about mirrorselect

# mirrorselect --help

If your environment requires you to use a proxy server, you can use the HTTP_PROXY, FTP_PROXY and RSYNC_PROXY variables to declare a proxy server.

Fetch Commands

When Portage needs to fetch source code, it uses wget by default. You can change this through the FETCHCOMMAND variable.

Portage is able to resume partially downloaded source code. It uses wget by default, but this can be altered through the RESUMECOMMAND variable.

Make sure that your FETCHCOMMAND and RESUMECOMMAND stores the source code in the correct location. Inside the variables you should use \${URI} and \${DISTDIR} to point to the source code location and distfiles location respectively.

You can also define protocol-specific handlers with FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, and so on.

Rsync Settings

You cannot alter the rsync command used by Portage to update the Portage tree, but you can set some variables related to the rsync command:

  • RSYNC_EXCLUDEFROM points to a file listing the packages and/or categories rsync should ignore during the update process
  • RSYNC_RETRIES defines how many times rsync should try connecting to the mirror pointed to by the SYNC variable before bailing out. This variable defaults to 3.
  • RSYNC_TIMEOUT defines the number of seconds an rsync connection can idle before rsync sees the connection as timed-out. This variable defaults to 180 but dialup users or individuals with slow computers might want to set this to 300 or higher.

2.e. Gentoo Configuration

Branch Selection

You can change your default branch with the ACCEPT_KEYWORDS variable. It defaults to your architecture's stable branch. More information on Gentoo's branches can be found in the next chapter.

Portage Features

You can activate certain Portage features through the FEATURES variable. The Portage Features have been discussed in previous chapters, such as Portage Features.

2.f. Portage Behaviour

Resource Management

With the PORTAGE_NICENESS variable you can augment or reduce the nice value Portage runs with. The PORTAGE_NICENESS value is added to the current nice value.

For more information about nice values, see the nice man page:

Code Listing 5: More information about nice

$ man nice

Output Behaviour

The NOCOLOR, which defaults to "false", defines if Portage should disable the use of coloured output. 3. Mixing Software Branches

3.a. Using One Branch

The Stable Branch

The ACCEPT_KEYWORDS variable defines what software branch you use on your system. It defaults to the stable software branch for your architecture, for instance x86.

We recommend that you only use the stable branch. However, if you don't care about stability this much and you want to help out Gentoo by submitting bugreports to http://bugs.gentoo.org, read on.

The Testing Branch

If you want to use more recent software, you can consider using the testing branch instead. To have Portage use the testing branch, add a ~ in front of your architecture.

The testing branch is exactly what it says - Testing. If a package is in testing, it means that the developers feel that it is functional but has not been thoroughly tested. You could very well be the first to discover a bug in the package in which case you could file a bugreport to let the developers know about it.

Beware though, you might notice stability issues, imperfect package handling (for instance wrong/missing dependencies), too frequent updates (resulting in lots of building) or broken packages. If you do not know how Gentoo works and how to solve problems, we recommend that you stick with the stable and tested branch.

For example, to select the testing branch for the x86 architecture, edit /etc/make.conf and set:

Code Listing 1: Setting the ACCEPT_KEYWORDS variable

ACCEPT_KEYWORDS="~x86"

If you update your system now, you will find out that lots of packages will be updated. Mind you though: when you have updated your system to use the testing branch there is usually no easy way back to the stable, official branch (except for using backups of course).

3.b. Mixing Stable with Testing

The package.keywords file

You can ask Portage to allow the testing branch for particular packages but use the stable branch for the rest of the system. To achieve this, add the package category and name you want to use the testing branch of in /etc/portage/package.keywords. For instance, to use the testing branch for gnumeric:

Code Listing 2: /etc/portage/package.keywords setting for gnumeric, full line

app-office/gnumeric ~x86

Test Particular Versions

If you want to use a specific software version from the testing branch but you don't want Portage to use the testing branch for subsequent versions, you can add in the version in the package.keywords file. In this case you must use the = operator. You can also enter a version range using the <=, <, > or >= operators.

In any case, if you add version information, you must use an operator. If you leave out version information, you cannot use an operator.

In the following example we ask Portage to accept gnumeric-1.2.13:

Code Listing 3: Enabling a particular gnumeric test version

=app-office/gnumeric-1.2.13 ~x86

3.c. Using Masked Packages

The package.unmask file

The Gentoo developers do not support the use of these files. Please exercise due caution when doing so. Support requests related to package.unmask and/or package.mask will not be answered. You have been warned.

When a package has been masked by the Gentoo developers and you still want to use it despite the reason mentioned in the package.mask file (situated in /usr/portage/profiles by default), add the exact same line in /etc/portage/package.unmask.

For instance, if =net-mail/hotwayd-0.8 is masked, you can unmask it by adding the exact same line in the package.unmask file:

Code Listing 4: /etc/portage/package.unmask

=net-mail/hotwayd-0.8

The package.mask file

When you don't want Portage to take a certain package or a specific version of a package into account you can mask it yourself by adding an appropriate line to /etc/portage/package.mask.

For instance, if you don't want Portage to install newer kernel sources than gentoo-sources-2.6.8.1, you add the following line to package.mask:

Code Listing 5: /etc/portage/package.mask example

sys-kernel/gentoo-sources-2.6.8.1

4. Additional Portage Tools

4.a. etc-update

etc-update is a tool that aids in merging the ._cfg0000_<name> files. It provides an interactive merging setup and can also auto-merge trivial changes. ._cfg0000_<name> files are generated by Portage when it wants to overwrite a file in a directory protected by the CONFIG_PROTECT variable.

Running etc-update is pretty straight-forward:

Code Listing 1: Running etc-update

# etc-update

After merging the straightforward changes, you will be prompted with a list of protected files that have an update waiting. At the bottom you are greeted by the possible options:

Code Listing 2: etc-update options

Please select a file to edit by entering the corresponding number.
(-1 to exit) (-3 to auto merge all remaining files)
(-5 to auto-merge AND not use 'mv -i'):

If you enter -1, etc-update will exit and discontinue any further changes. If you enter -3 or -5, all listed configuration files will be overwritten with the newer versions. It is therefore very important to first select the configuration files that should not be automatically updated. This is simply a matter of entering the number listed to the left of that configuration file.

As an example, we select the configuration file /etc/pear.conf:

Code Listing 3: Updating a specific configuration file

Beginning of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf ... End of differences between /etc/pear.conf and /etc/._cfg0000_pear.conf 1) Replace original with update 2) Delete update, keeping original as is 3) Interactively merge original with update 4) Show differences again

You can now see the differences between the two files. If you believe that the updated configuration file can be used without problems, enter 1. If you believe that the updated configuration file isn't necessary, or doesn't provide any new or useful information, enter 2. If you want to interactively update your current configuration file, enter 3.

There is no point in further elaborating the interactive merging here. For completeness sake, we will list the possible commands you can use while you are interactively merging the two files. You are greeted with two lines (the original one, and the proposed new one) and a prompt at which you can enter one of the following commands:

Code Listing 4: Commands available for the interactive merging

ed: Edit then use both versions, each decorated with a header. eb: Edit then use both versions. el: Edit then use the left version. er: Edit then use the right version. e: Edit a new version. l: Use the left version. r: Use the right version. s: Silently include common lines. v: Verbosely include common lines. q: Quit.

When you have finished updating the important configuration files, you can now automatically update all the other configuration files. etc-update will exit if it doesn't find any more updateable configuration files.

4.b. dispatch-conf

Using dispatch-conf you are able to merge updates to your configuration files while keeping track of all changes. dispatch-conf stores the differences between the configuration files as patches or by using the RCS revision system.

Like etc-update, you can ask to keep the configuration file as-is, use the new configuration file, edit the current one or merge the changes interactively. However, dispatch-conf also has some nice additional features:

  • Automatically merge configuration file updates that only contain updates to comments
  • Automatically merge configuration files which only differ in the amount of whitespace

Make certain you edit /etc/dispatch-conf.conf first and create the directory referenced by the archive-dir variable.

For more information, check out the dispatch-conf man page:

Code Listing 5: Reading the dispatch-conf man page

$ man dispatch-conf

4.c. quickpkg

With quickpkg you can create archives of the packages that are already merged on your system. These archives can be used as prebuilt packages. Running quickpkg is straightforward: just add the names of the packages you want to archive.

For instance, to archive curl, arts and procps:

Code Listing 6: Example quickpkg usage

# quickpkg curl arts procps

The prebuilt packages will be stored in $PKGDIR/All (/usr/portage/packages/All by default). Symbolic links pointing to these packages are placed in $PKGDIR/<category>. 5. Diverting from the Official Tree

5.a. Using a Portage Tree Subset

Excluding Packages/Categories

You can selectively update certain categories/packages and ignore the other categories/packages. We achieve this by having rsync exclude categories/packages during the emerge --sync step.

You need to define the name of the file that contains the exclude patterns in the RSYNC_EXCLUDEFROM variable in your /etc/make.conf.

Code Listing 1: Defining the exclude file in /etc/make.conf

RSYNC_EXCLUDEFROM=/etc/portage/rsync_excludes

Code Listing 2: Excluding all games in /etc/portage/rsync_excludes

games-*/*

Note however that this may lead to dependency issues since new, allowed packages might depend on new but excluded packages.

5.b. Adding Unofficial Ebuilds

Defining a Portage Overlay Directory

You can ask Portage to use ebuilds that are not officially available through the Portage tree. Create a new directory (for instance /usr/local/portage) in which you store the 3rd-party ebuilds. Use the same directory structure as the official Portage tree!

Then define PORTDIR_OVERLAY in /etc/make.conf and have it point to the previously defined directory. When you use Portage now, it will take those ebuilds into account as well without removing/overwriting those ebuilds the next time you run emerge --sync.

Working with Several Overlays

For the powerusers who develop on several overlays, test packages before they hit the Portage tree or just want to use unofficial ebuilds from various sources, the app-portage/gentoolkit-dev package brings you gensync, a tool to help you keep the overlay repositories up to date.

With gensync you can update all the repositories at once, or select just a few of them. Each repository should have a .syncsource file in the /etc/gensync/ configuration directory which contains the repository location, name, ID, etc.

Suppose you have two additional repositories called java (for the in-development java ebuilds) and entapps (for the applications developed in-house for your enterprise). You can update those repositories with the following command:

Code Listing 3: Using gensync to update a few repositories

# gensync java entapps

5.c. Non-Portage Maintained Software

Using Portage with Self-Maintained Software

In some cases you want to configure, install and maintain software yourself without having Portage automate the process for you, even though Portage can provide the software titles. Known cases are kernel sources and nvidia drivers. You can configure Portage so it knows that a certain package is manually installed on your system. This process is called injecting and supported by Portage through the /etc/portage/profile/package.provided file.

For instance, if you want to inform Portage about vanilla-sources-2.6.11.6 which you've installed manually, add the following line to /etc/portage/profile/package.provided:

Code Listing 4: Example line for package.provided

sys-kernel/vanilla-sources-2.6.11.6

6. The Ebuild Application

6.a. Emerge and Ebuild

The ebuild application is a lower level interface to the Portage system. Using this application you can execute specific actions against a given ebuild. For instance, you can perform the individual merging steps by yourself.

Using ebuild is more for development purposes; more information about ebuild can therefore be found in the Developers Handbook. However, we will explain which ebuild instances are invoked by Portage during the merge process of a certain software title, and how to invoke the post-configuration steps some ebuilds allow you to perform.

6.b. Manually Installing Software

Fetching the Sources & Checksumming

Whenever you invoke ebuild against a given ebuild file, it will verify if the checksums of all involved files are equal to those given in the accompanying Manifest or files/digest-<name>-<version> file. This happens after the sources have been fetched.

To fetch the sources using ebuild, run:

Code Listing 1: Fetching the sources

# ebuild path/to/ebuild fetch

If the ebuild's md5sum does not match the one listed in the Manifest file, or one of the downloaded sources don't match those listed in the files/digest-<package> file, you will receive an error similar to this:

Code Listing 2: Ebuild checksum failure

!!! File is corrupt or incomplete. (Digests do not match)
our recorded digest: db20421ce35e8e54346e3ef19e60e4ee your file's digest: f10392b7c0b2bbc463ad09642606a7d6


The subsequent line will mention the erroneous file.

If you are certain that the sources you've fetched and the ebuild itself are valid, you can regenerate the Manifest and digest-<package> file using ebuild's digest functionality:

Code Listing 3: Regenerate Manifest and digest

# ebuild path/to/ebuild digest

Unpacking the Sources

To unpack the sources in /var/tmp/portage (or any other directory location you have specified in /etc/make.conf), run ebuild's unpack functionality:

Code Listing 4: Unpacking the sources

# ebuild path/to/ebuild unpack

This will execute the ebuild's src_unpack() function (which defaults to plain extraction if no src_unpack() function is defined). It is also in this step that all necessary patches are applied.

Compiling the Sources

The next step in the merge process is to compile the sources. The ebuild's compile functionality takes care of this step by executing the src_compile() function in the ebuild. This also includes the configure steps if appropriate.

Code Listing 5: Compiling the sources

# ebuild path/to/ebuild compile

You are advised to edit the ebuild's src_compile() function if you want to change the compilation instructions. However, you can also trick Portage into believing that the ebuild application has finished the compile steps. Run all necessary commands yourself and create an empty file called .compiled in the working directory:

Code Listing 6: Informing Portage about the finished compilation jobs

# touch .compiled

Installing the Files in a Temporary Location

In the next step Portage will install all necessary files in a temporary location. This directory will then contain all files that are to be merged on the live filesystem. You can accomplish this by running ebuild's install functionality, which executes the ebuild's src_install() function:

Code Listing 7: Installing the files

# ebuild path/to/ebuild install

Merging the Files onto the Live Filesystem

The final step is to merge all files onto the live filesystem and register those in the Portage backend. ebuild calls this step "qmerge" and involves the following steps:

  • Execute the pkg_preinst() function if specified
  • Copy over all files to the live filesystem
  • Register the files in the Portage backend
  • Execute the pkg_postinst() function if specified

Run ebuild's qmerge functionality to accomplish these steps:

Code Listing 8: Merging the files on the live filesystem

# ebuild path/to/ebuild qmerge

Cleaning the Temporary Directory

Finally you can clean the temporary directory using ebuild's clean functionality:

Code Listing 9: Cleaning the temporary directory

# ebuild path/to/ebuild clean

6.c. Additional Ebuild Features

Running all Merge-related Commands

Using ebuild's merge functionality you can run the fetch, unpack, compile, install and qmerge commands in one go:

Code Listing 10: Installing software

# ebuild path/to/ebuild merge

Performing Configuration Actions

Some applications include instructions that configure the package further on your system. These instructions can be interactive and are therefore not automatically executed. To run these configuration steps, which are enlisted in the ebuild's (optional) config() function, use ebuild's config functionality:

Code Listing 11: Configuring a package

# ebuild path/to/ebuild config

Building an (RPM) Package

You can instruct Portage to create a binary package of an ebuild or even an RPM file. Use ebuild's package or rpm functionality to create these archives. There are a few differences between those functionalities though:

  • The package functionality is a lot like the merge functionality, executing all necessary steps (fetch, unpack, compile, install) before creating the package
  • The rpm functionality builds an RPM package from the files created after having run ebuild's install functionality

Code Listing 12: Creating packages

(For a Portage-compatible binary package) # ebuild path/to/ebuild package

(For an RPM package) # ebuild path/to/ebuild rpm

The created RPM file however does not contain the ebuild's dependency information.

6.d. More Information

Please consult the following man pages for more information about Portage, the ebuild application and the ebuild files:

Code Listing 13: Man pages

$ man portage (Portage itself) $ man emerge (The emerge command) $ man ebuild (The ebuild command) $ man 5 ebuild (The ebuild file syntax)

You will also find more development-related information in the Developers Handbook. D. Gentoo Network Configuration 1. Getting Started

1.a. Getting started

Note: This document assumes that you have correctly configured your kernel, its modules for your hardware and you know the interface name of your hardware. We also assume that you are configuring eth0, but it could also be eth1, wlan0, etc.

Note: This document requires you are running baselayout-1.11.11 or better.

To get started configuring your network card, you need to tell the Gentoo RC system about it. This is done by creating a symbolic link from net.lo to net.eth0 in /etc/init.d.

Code Listing 1: Symlinking net.eth0 to net.lo

# cd /etc/init.d # ln -s net.lo net.eth0

Gentoo's RC system now knows about that interface. It also needs to know how to configure the new interface. All the network interfaces are configured in /etc/conf.d/net. Below is a sample configuration for DHCP and static addresses.

Code Listing 2: Examples for /etc/conf.d/net

# For DHCP config_eth0=( "dhcp" )

# For static IP using CIDR notation config_eth0=( "192.168.0.7/24" ) routes_eth0=( "default via 192.168.0.1" )

# For static IP using netmask notation config_eth0=( "192.168.0.7 netmask 255.255.255.0" ) routes_eth0=( "default gw 192.168.0.1" )

Note: If you do not specify a configuration for your interface then DHCP is assumed.

Note: CIDR stands for Classless InterDomain Routing. Originally, IPv4 addresses were classified as A, B, or C. The early classification system did not envision the massive popularity of the Internet, and is in danger of running out of new unique addresses. CIDR is an addressing scheme that allows one IP address to designate many IP addresses. A CIDR IP address looks like a normal IP address except that it ends with a slash followed by a number; for example, 192.168.0.0/16. CIDR is described in RFC 1519.

Now that we have configured our interface, we can start and stop it using the below commands

Code Listing 3: Starting and stopping network scripts

# /etc/init.d/net.eth0 start # /etc/init.d/net.eth0 stop

Important: When troubleshooting networking, it is recommended to set RC_VERBOSE="yes" in /etc/conf.d/rc so that you get more information about what's happening.

Now that you have successfully started and stopped your network interface, you may wish to get it to start when Gentoo boots. Here's how to do this. The last "rc" command instructs Gentoo to start any scripts in the current runlevel that have not yet been started.

Code Listing 4: Configuring a network interface to load at boot time

# rc-update add net.eth0 default # rc

2. Advanced Configuration

2.a. Advanced Configuration

The config_eth0 variable is the heart of an interface configuration. It's a high level instruction list for configuring the interface (eth0 in this case). Each command in the instruction list is performed sequentially. The interface is deemed OK if at least one command works.

Here's a list of in-built instructions. Command Description null Do nothing noop If the interface is up and there is an address then abort configuration successfully an IPv4 or IPv6 address Add the address to the interface dhcp, adsl or apipa (or a custom command from a 3rd party module) Run the module which provides the command. For example dhcp will run a module that provides DHCP which can be one of either dhcpcd, udhcpc, dhclient or pump.

If a command fails, you can specify a fallback command. The fallback has to match the config structure exactly.

You can chain these commands together. Here are some real world examples.

Code Listing 1: Configuration examples

# Adding three IPv4 addresses config_eth0=(
"192.168.0.2/24" "192.168.0.3/24" "192.168.0.4/24"
)

# Adding an IPv4 address and two IPv6 addresses config_eth0=(
"192.168.0.2/24" "4321:0:1:2:3:4:567:89ab" "4321:0:1:2:3:4:567:89ac"
)

# Keep our kernel assigned address, unless the interface goes # down so assign another via DHCP. If DHCP fails then add a # static address determined by APIPA config_eth0=(
"noop" "dhcp"
) fallback_eth0=(
"null" "apipa"
)

Note: When using the ifconfig module and adding more than one address, interface aliases are created for each extra address. So with the above two examples you will get interfaces eth0, eth0:1 and eth0:2. You cannot do anything special with these interfaces as the kernel and other programs will just treat eth0:1 and eth0:2 as eth0.

Important: The fallback order is important! If we did not specify the null option then the apipa command would only be run if the noop command failed.

Note: APIPA and DHCP are discussed later.

2.b. Network Dependencies

Init scripts in /etc/init.d can depend on a specific network interface or just net. net can be defined in /etc/conf.d/rc to mean different things using the RC_NET_STRICT_CHECKING variable. Value Description none The net service is always considered up no This basically means that at least one net.* service besides net.lo must be up. This can be used by notebook users that have a WIFI and a static NIC, and only wants one up at any given time to have the net service seen as up. lo This is the same as the no option, but net.lo is also counted. This should be useful to people that do not care about any specific interface being up at boot. yes For this ALL network interfaces MUST be up for the net service to be considered up.

But what about net.br0 depending on net.eth0 and net.eth1? net.eth1 may be a wireless or PPP device that needs configuration before it can be added to the bridge. This cannot be done in /etc/init.d/net.br0 as that's a symbolic link to net.lo.

The answer is making your own depend() function in /etc/conf.d/net.

Code Listing 2: net.br0 dependency in /etc/conf.d/net

# You can use any dependency (use, after, before) as found in current scripts depend_br0() {
need net.eth0 net.eth1
}

For a more detailed discussion about dependency, consult the section Writing Init Scripts in the Gentoo Handbook.

2.c. Variable names and values

Variable names are dynamic. They normally follow the structure of variable_${interface|mac|essid|apmac}. For example, the variable dhcpcd_eth0 holds the value for dhcpcd options for eth0 and dhcpcd_essid holds the value for dhcpcd options when any interface connects to the ESSID "essid".

However, there is no hard and fast rule that states interface names must be ethx. In fact, many wireless interfaces have names like wlanx, rax as well as ethx. Also, some user defined interfaces such as bridges can be given any name, such as foo. To make life more interesting, wireless Access Points can have names with non alpha-numeric characters in them - this is important because you can configure networking parameters per ESSID.

The downside of all this is that Gentoo uses bash variables for networking - and bash cannot use anything outside of English alpha-numerics. To get around this limitation we change every character that is not an English alpha-numeric into a _ character.

Another downside of bash is the content of variables - some characters need to be escaped. This can be achived by placing the \ character in front of the character that needs to be escaped. The following list of characters needs to be escaped in this way: ", ' and \.

In this example we use wireless ESSID as they can contain the widest scope of characters. We shall use the ESSID My "\ NET:

Code Listing 3: variable name example

# This does work, but the domain is invalid dns_domain_My____NET="My \"\\ NET"

# The above sets the dns domain to My "\ NET when a wireless card # connects to an AP whose ESSID is My "\ NET

3. Modular Networking

3.a. Network Modules

We now support modular networking scripts, which means we can easily add support for new interface types and configuration modules while keeping compatibility with existing ones.

Modules load by default if the package they need is installed. If you specify a module here that doesn't have its package installed then you get an error stating which package you need to install. Ideally, you only use the modules setting when you have two or more packages installed that supply the same service and you need to prefer one over the other.

Code Listing 1: Module preference

# Prefer iproute2 over ifconfig modules=( "iproute2" )

# You can also specify other modules for an interface # In this case we prefer udhcpc over dhcpcd modules_eth0=( "udhcpc" )

# You can also specify which modules not to use - for example you may be # using a supplicant or linux-wlan-ng to control wireless configuration but # you still want to configure network settings per ESSID associated with. modules=( "!iwconfig" )

3.b. Interface Handlers

We provide two interface handlers presently: ifconfig and iproute2. You need one of these to do any kind of network configuration.

ifconfig is the current Gentoo default and it's included in the system profile. iproute2 is a more powerful and flexible package, but it's not included by default.

Code Listing 2: To install iproute2

# emerge sys-apps/iproute2

# To prefer iproute2 over ifconfig if both are installed modules=( "iproute2" )

As both ifconfig and iproute2 do very similar things we allow their basic configuration to work with each other. For example both the below code snippet work regardless of which module you are using.

Code Listing 3: ifconfig and iproute2 examples

config_eth0=( "192.168.0.2/24" ) config_eth0=( "192.168.0.2 netmask 255.255.255.0" )

# We can also specify broadcast config_eth0=( "192.168.0.2/24 brd 192.168.0.255" ) config_eth0=( "192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255" )

3.c. DHCP

DHCP is a means of obtaining network information (IP address, DNS servers, Gateway, etc) from a DHCP server. This means that if there is a DHCP server running on the network, you just have to tell each client to use DHCP and it sets up the network all by itself. Of course, you will have to configure for other things like wireless, PPP or other things if required before you can use DHCP.

DHCP can be provided by dhclient, dhcpcd, pump or udhcpc. Each DHCP module has its pros and cons - here's a quick run down. DHCP Module Package Pros Cons dhclient net-misc/dhcp Made by ISC, the same people who make the BIND DNS software. Very configurable Configuration is overly complex, software is quite bloated, cannot get NTP servers from DHCP, does not send hostname by default dhcpcd net-misc/dhcpcd Long time Gentoo default, no reliance on outside tools No longer maintained upstream, can be slow at times, does not daemonize when lease is infinite pump net-misc/pump Lightweight, no reliance on outside tools No longer maintained upstream, unreliable, especially over modems, cannot get NIS servers from DHCP udhcpc net-misc/udhcp Lightweight - smallest DHCP client around, made for embedded systems Unproven - no distro uses it by default, cannot define a timeout beyond 3 seconds

If you have more than one DHCP client installed, you need to specify which one to use - otherwise we default to dhcpcd if available.

To send specific options to the DHCP module, use module_eth0="..." (change module to the DHCP module you're using - ie dhcpcd_eth0).

We try and make DHCP relatively agnostic - as such we support the following commands using the dhcp_eth0 variable. The default is not to set any of them:

  • release - releases the IP address for re-use
  • nodns - don't overwrite /etc/resolv.conf
  • nontp - don't overwrite /etc/ntp.conf
  • nonis - don't overwrite /etc/yp.conf

Code Listing 4: Sample DHCP configuration in /etc/conf.d/net

# Only needed if you have more than one DHCP module installed modules=( "dhcpcd" )

config_eth0=( "dhcp" ) dhcpcd_eth0="-t 10" # Timeout after 10 seconds dhcp_eth0="release nodns nontp nonis" # Only get an address

Note: dhcpcd, udhcpc and pump send the current hostname to the DHCP server by default so you don't need to specify this anymore.

3.d. ADSL Modem

First we need to install the ADSL software.

Code Listing 5: Install the rp-pppoe package

# emerge net-dialup/rp-pppoe

Warning: baselayout-1.11.x supports PPPoE only. Hopefully future versions will support PPPoA.

Now we need to instruct configure eth0 to be an ADSL interface and enter our username.

Code Listing 6: Configure eth0 for ADSL

config_eth0=( "adsl" ) adsl_user_eth0="username"

Finally you need to define your username and password in /etc/ppp/pap-secrets.

Code Listing 7: sample /etc/ppp/pap-secrets

# The * is important "username" * "password"

3.e. APIPA (Automatic Private IP Addressing)

APIPA tries to find a free address in the range 169.254.0.0-169.254.255.255 by arping a random address in that range on the interface. If no reply is found then we assign that address to the interface.

This is only useful for LANs where there is no DHCP server and you don't connect directly to the internet and all other computers use APIPA.

For APIPA support, emerge net-misc/iputils or net-analyzer/arping.

Code Listing 8: APIPA configuration in /etc/conf.d/net

# Try DHCP first - if that fails then fallback to APIPA config_eth0=( "dhcp" ) fallback_eth0=( "apipa" )

# Just use APIPA config_eth0=( "apipa" )

3.f. Bonding

For link bonding/trunking emerge net-misc/ifenslave.

Bonding is used to increase network bandwidth. If you have two network cards going to the same network, you can bond them together so your applications see just one interface but they really use both network cards.

Code Listing 9: bonding configuration in /etc/conf.d/net

# To bond interfaces together slaves_bond0="eth0 eth1 eth2"

# You may not want to assign an IP to the bonded interface config_bond0=( "null" )

# Depend on eth0, eth1 and eth2 as they may require extra configuration depend_bond0() {
need net.eth0 net.eth1 net.eth2
}

3.g. Bridging (802.1d support)

For bridging support emerge net-misc/bridge-utils.

Bridging is used to join networks together. For example, you may have a server that connects to the internet via an ADSL modem and a wireless access card to enable other computers to connect to the internet via the ADSL modem. You could create a bridge to join the two interfaces together.

Code Listing 10: Bridge configuration in /etc/conf.d/net

# Configure the bridge - "man btctl" for more details brctl_br0=( "setfd 0" "sethello 0" "stp off" )

# To add ports to bridge br0 bridge_br0="eth0 eth1"

# You need to configure the ports to null values so dhcp does not get started config_eth0=( "null" ) config_eth1=( "null" )

# Finally give the bridge an address - you could use DHCP as well config_br0=( "192.168.0.1/24" )

# Depend on eth0 and eth1 as they may require extra configuration depend_br0() {
need net.eth0 net.eth1
}

Important: For using some bridge setups, you may need to consult the variable name documentation.

3.h. MAC Address

You don't need to emerge anything for changing the MAC address of your interface if you have sys-apps/baselayout-1.11.14 or newer and want to change to a specific MAC address. However, if you need to change to a random MAC address or have a baselayout older than the version mentioned above, you have to emerge net-analyzer/macchanger to be able to make use of this feature.

Code Listing 11: MAC Address change example

# To set the MAC address of the interface mac_eth0="00:11:22:33:44:55"

# To randomize the last 3 bytes only mac_eth0="random-ending"

# To randomize between the same physical type of connection (eg fibre, # copper, wireless) , all vendors mac_eth0="random-samekind"

# To randomize between any physical type of connection (eg fibre, copper, # wireless) , all vendors mac_eth0="random-anykind"

# Full randomization - WARNING: some MAC addresses generated by this may # NOT act as expected mac_eth0="random-full"

3.i. Tunnelling

You don't need to emerge anything for tunnelling as the interface handler can do it for you.

Code Listing 12: Tunnelling configuration in /etc/conf.d/net

# For GRE tunnels iptunnel_vpn0="mode gre remote 207.170.82.1 key 0xffffffff ttl 255"

# For IPIP tunnels iptunnel_vpn0="mode ipip remote 207.170.82.2 ttl 255"

# To configure the interface config_vpn0=( "192.168.0.2 peer 192.168.1.1" )

3.j. VLAN (802.1q support)

For VLAN support, emerge net-misc/vconfig.

Virtual LAN is a group of network devices that behave as if they were connected to a single network segment - even though they may not be. VLAN members can only see members of the same VLAN even though they may share the same physical network.

Code Listing 13: VLAN configuration in /etc/conf.d/net

# Specify the VLAN numbers for the interface like so # Please ensure your VLAN IDs are NOT zero-padded vlans_eth0="1 2"

# You can also configure the VLAN # see for vconfig man page for more details vconfig_eth0=( "set_name_type VLAN_PLUS_VID_NO_PAD" ) vconfig_vlan1=( "set_flag 1" "set_egress_map 2 6" )

# Configure the interface as usual config_vlan1=( "172.16.3.1 netmask 255.255.254.0" ) config_vlan2=( "172.16.2.1 netmask 255.255.254.0" )

Important: For using some VLAN setups, you may need to consult the variable name documentation. 4. Wireless Networking

4.a. Introduction

Currently we support wireless setup either by wireless-tools or wpa_supplicant. The important thing to remember is that you configure for wireless networks on a global basis and not an interface basis.

wpa_supplicant is the best choice, but it does not support all drivers. For a list of supported drivers, read the wpa_supplicant site. Also, wpa_supplicant can currently only connect to SSID's that you have configured for.

wireless-tools supports nearly all cards and drivers, but it cannot connect to WPA only Access Points.

Warning: The linux-wlan-ng driver is not supported by baselayout at this time. This is because linux-wlan-ng have their own setup and configuration which is completely different to everyone else's. The linux-wlan-ng developers are rumoured to be changing their setup over to wireless-tools - when this happens you may use linux-wlan-ng with baselayout.

4.b. WPA Supplicant

WPA Supplicant is a package that allows you to connect to WPA enabled access points. It's setup is fairly fluid as it is still in beta - however it works fine for the most part.

Code Listing 1: Install wpa_supplicant

# emerge net-wireless/wpa_supplicant

Important: You have to have CONFIG_PACKET enabled in your kernel for wpa_supplicant to work.

Now we have to configure /etc/conf.d/net to so that we prefer wpa_supplicant over wireless-tools (if both are installed, wireless-tools is the default).

Code Listing 2: configure /etc/conf.d/net for wpa_supplicant

# Prefer wpa_supplicant over wireless-tools modules=( "wpa_supplicant" )

# It's important that we tell wpa_supplicant which driver we should # be using as it's not very good at guessing yet wpa_supplicant_eth0="-Dmadwifi"

Note: If you're using the host-ap driver you will need to put the card in Managed mode before it can be used with wpa_supplicant correctly. You can use iwconfig_eth0="mode managed" to achieve this in /etc/conf.d/net.

That was simple, wasn't it? However, we still have to configure wpa_supplicant itself which is a bit more tricky depending on how secure the Access Points are that you are trying to connect to. The below example is taken and simplified from /etc/wpa_supplicant.conf.example which ships with wpa_supplicant.

Code Listing 3: an example /etc/wpa_supplicant.conf

# The below line not be changed otherwise we refuse to work ctrl_interface=/var/run/wpa_supplicant

# Ensure that only root can read the WPA configuration ctrl_interface_group=0

# Let wpa_supplicant take care of scanning and AP selection ap_scan=1

# Simple case: WPA-PSK, PSK as an ASCII passphrase, allow all valid ciphers network={
ssid="simple" psk="very secret passphrase" # The higher the priority the sooner we are matched priority=5
}

# Same as previous, but request SSID-specific scanning (for APs that reject # broadcast SSID) network={
ssid="second ssid" scan_ssid=1 psk="very secret passphrase" priority=2
}

# Only WPA-PSK is used. Any valid cipher combination is accepted network={
ssid="example" proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk=06b4be19da289f475aa46a33cb793029d4ab3db7a23ee92382eb0106c72ac7bb priority=2
}

# Plaintext connection (no WPA, no IEEE 802.1X) network={
ssid="plaintext-test" key_mgmt=NONE
}

# Shared WEP key connection (no WPA, no IEEE 802.1X) network={
ssid="static-wep-test" key_mgmt=NONE wep_key0="abcde" wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5
}

# Shared WEP key connection (no WPA, no IEEE 802.1X) using Shared Key # IEEE 802.11 authentication network={
ssid="static-wep-test2" key_mgmt=NONE wep_key0="abcde" wep_key1=0102030405 wep_key2="1234567890123" wep_tx_keyidx=0 priority=5 auth_alg=SHARED
}

# IBSS/ad-hoc network with WPA-None/TKIP network={
ssid="test adhoc" mode=1 proto=WPA key_mgmt=WPA-NONE pairwise=NONE group=TKIP psk="secret passphrase"
}

4.c. Wireless Tools

Initial setup and Managed Mode

Wireless Tools provide a generic way to configure basic wireless interfaces up to the WEP security level. While WEP is a weak security method it's also the most prevalent.

Wireless Tools configuration is controlled by a few main variables. The sample configuration file below should describe all you need. One thing to bear in mind is that no configuration means "connect to the strongest unencrypted Access Point" - we will always try and connect you to something.

Code Listing 4: Install wireless-tools

# emerge net-wireless/wireless-tools

Note: Although you can store your wireless settings in /etc/conf.d/wireless this guide recommends you store them in /etc/conf.d/net.

Important: You will need to consult the variable name documentation.

Code Listing 5: sample iwconfig setup in /etc/conf.d/net

# Prefer iwconfig over wpa_supplicant modules=( "iwconfig" )

# Configure WEP keys for Access Points called ESSID1 and ESSID2 # You may configure up to 4 WEP keys, but only 1 can be active at # any time so we supply a default index of 1 to set key 1 and then # again afterwards to change the active key to 1 # We do this incase you define other ESSID's to use WEP keys other than 1 # # Prefixing the key with s: means it's an ASCII key, otherwise a HEX key # # enc open specified open security (most secure) # enc restricted specified restricted security (least secure) key_ESSID1="1 s:yourkeyhere key 1 enc open" key_ESSID2="1 aaaa-bbbb-cccc-dd key 1 enc restricted"

# The below only work when we scan for available Access Points

# Sometimes more than one Access Point is visible so we need to # define a preferred order to connect in preferred_aps=( "ESSID1" "ESSID2" )

Fine tune Access Point Selection

You can add some extra options to fine-tune your Access Point selection, but these are not normally required.

You can decide whether we only connect to preferred Access Points or not. By default if everything configured has failed and we can connect to an unencrypted Access Point then we will. This can be controlled by the associate_order variable. Here's a table of values and how they control this. Value Description any Default behaviour preferredonly We will only connect to visible APs in the preferred list forcepreferred We will forceably connect to APs in the preferred order if they are not found in a scan forcepreferredonly Do not scan for APs - instead just try to connect to each one in order forceany Same as forcepreferred + connect to any other available AP

Finally we have some blacklist_aps and unique_ap selection. blacklist_aps works in a similar way to preferred_aps. unique_ap is a yes or no value that says if a second wireless interface can connect to the same Access Point as the first interface.

Code Listing 6: blacklist_aps and unique_ap example

# Sometimes you never want to connect to certain access points blacklist_aps=( "ESSID3" "ESSID4" )

# If you have more than one wireless card, you can say if you want # to allow each card to associate with the same Access Point or not # Values are "yes" and "no" # Default is "yes" unique_ap="yes"

Ad-Hoc and Master Modes

If you want to set yourself up as an Ad-Hoc node if you fail to connect to any Access Point in managed mode, you can do that too.

Code Listing 7: fallback to ad-hoc mode

adhoc_essid_eth0="This Adhoc Node"

What about connecting to Ad-Hoc networks or running in Master mode to become an Access Point? Here's a configuration just for that! You may need to specify WEP keys as shown above.

Code Listing 8: sample ad-hoc/master configuration

# Set the mode - can be managed (default), ad-hoc or master # Not all drivers support all modes mode_eth0="ad-hoc"

# Set the ESSID of the interface # In managed mode, this forces the interface to try and connect to the # specified ESSID and nothing else essid_eth0="This Adhoc Node"

# We use channel 3 if you don't specify one channel_eth0="9"

Important: The below is taken verbatim from the BSD wavelan documentation found at the NetBSD documentation. There are 14 channels possible; We are told that channels 1-11 are legal for North America, channels 1-13 for most of Europe, channels 10-13 for France, and only channel 14 for Japan. If in doubt, please refer to the documentation that came with your card or access point. Make sure that the channel you select is the same channel your access point (or the other card in an ad-hoc network) is on. The default for cards sold in North America and most of Europe is 3; the default for cards sold in France is 11, and the default for cards sold in Japan is 14.

Troubleshooting Wireless Tools

There are some more variables you can use to help get your wireless up and running due to driver or environment problems. Here's a table of other things you can try. Variable Default Value Description iwconfig_eth0 See the iwconfig man page for details on what to send iwconfig iwpriv_eth0 See the iwpriv man page for details on what to send iwpriv sleep_scan_eth0 0 The number of seconds to sleep before attempting to scan. This is needed when the driver/firmware needs more time to active before it can be used. sleep_associate_eth0 5 The number of seconds to wait for the interface to associate with the Access Point before moving onto the next one associate_test_eth0 MAC Some drivers do not reset the MAC address associated with an invalid one when they lose or attempt association. Some drivers do not reset the quality level when they lose or attempt association. Valid settings are MAC, quality and all. scan_mode_eth0 Some drivers have to scan in ad-hoc mode, so if scanning fails try setting ad-hoc here iwpriv_scan_pre_eth0 Sends some iwpriv commands to the interface before scanning. See the iwpriv man page for more details. iwpriv_scan_post_eth0 Sends some iwpriv commands to the interface after scanning. See the iwpriv man page for more details.

4.d. Defining network configuration per ESSID

Sometimes, you need a static IP when you connect to ESSID1 and you need DHCP when you connect to ESSID2. In fact, most module variables can be defined per ESSID. Here's how we do this.

Note: These work if you're using WPA Supplicant or Wireless Tools.

Important: You will need to consult the variable name documentation.

Code Listing 9: override network settings per ESSID

config_ESSID1=( "192.168.0.3/24 brd 192.168.0.255" ) routes_ESSID1=( "default via 192.168.0.1" )

config_ESSID2=( "dhcp" ) fallback_ESSID2=( "192.168.3.4/24" ) fallback_route_ESSID2=( "default via 192.168.3.1" )

# We can define nameservers and other things too # NOTE: DHCP will override these unless it's told not too dns_servers_ESSID1=( "192.168.0.1" "192.168.0.2" ) dns_domain_ESSID1="some.domain" dns_search_domains_ESSID1="search.this.domain search.that.domain"

# You override by the MAC address of the Access Point # This handy if you goto different locations that have the same ESSID config_001122334455=( "dhcp" ) dhcpcd_001122334455="-t 10" dns_servers_001122334455=( "192.168.0.1" "192.168.0.2" )

5. Adding Functionality

5.a. Standard function hooks

Four functions can be defined which will be called surrounding the start/stop operations. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preup() and predown() functions should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preup() returns a non-zero value, then interface configuration will be aborted. If predown() returns a non-zero value, then the interface will not be allowed to continue deconfiguration.

The return values for the postup() and postdown() functions are ignored since there's nothing to do if they indicate failure.

${IFACE} is set to the interface being brought up/down. ${IFVAR} is ${IFACE} converted to variable name bash allows.

Code Listing 1: pre/post up/down function examples

preup() {
# Test for link on the interface prior to bringing it up. This # only works on some network adapters and requires the mii-diag # package to be installed. if mii-tool ${IFACE} 2> /dev/null | grep -q 'no link'; then
ewarn "No link on ${IFACE}, aborting configuration" return 1
fi

# Test for link on the interface prior to bringing it up. This # only works on some network adapters and requires the ethtool # package to be installed. if ethtool ${IFACE} | grep -q 'Link detected: no'; then
ewarn "No link on ${IFACE}, aborting configuration" return 1
fi

# Remember to return 0 on success return 0
}

predown() {
# The default in the script is to test for NFS root and disallow # downing interfaces in that case. Note that if you specify a # predown() function you will override that logic. Here it is, in # case you still want it... if is_net_fs /; then
eerror "root filesystem is network mounted -- can't stop ${IFACE}" return 1
fi

# Remember to return 0 on success return 0
}

postup() {
# This function could be used, for example, to register with a # dynamic DNS service. Another possibility would be to # send/receive mail once the interface is brought up.
return 0
}

postdown() {
# This function is mostly here for completeness... I haven't # thought of anything nifty to do with it yet ;-) return 0
}

5.b. Wireless Tools function hooks

Note: This will not work with WPA Supplicant - but the ${ESSID} and ${ESSIDVAR} variables are available in the postup() function.

Two functions can be defined which will be called surrounding the associate function. The functions are called with the interface name first so that one function can control multiple adapters.

The return values for the preassociate() function should be 0 (success) to indicate that configuration or deconfiguration of the interface can continue. If preassociate() returns a non-zero value, then interface configuration will be aborted.

The return value for the postassociate() function is ignored since there's nothing to do if it indicates failure.

${ESSID} is set to the exact ESSID of the AP you're connecting to. ${ESSIDVAR} is ${ESSID} converted to variable name bash allows.

Code Listing 2: pre/post association functions

preassociate() {
# The below adds two configuration variables leap_user_ESSID # and leap_pass_ESSID. When they are both configured for the ESSID # being connected to then we run the CISCO LEAP script

local user pass eval user=\"\$\{leap_user_${ESSIDVAR}\}\" eval pass=\"\$\{leap_pass_${ESSIDVAR}\}\"

if -n ${user} && -n ${pass} ; then
if ! -x /opt/cisco/bin/leapscript ; then
eend "For LEAP support, please emerge net-misc/cisco-aironet-client-utils" return 1
fi einfo "Waiting for LEAP Authentication on \"${ESSID//\\\\//}\"" if /opt/cisco/bin/leapscript ${user} ${pass} | grep -q 'Login incorrect'; then
ewarn "Login Failed for ${user}" return 1
fi
fi

return 0
}

postassociate() {
# This function is mostly here for completeness... I haven't # thought of anything nifty to do with it yet ;-)

return 0
}

Note: ${ESSID} and ${ESSIDVAR} are unavailable in predown() and postdown() functions. 6. Network Management

6.a. Network Management

If you and your computer are always on the move, you may not always have an ethernet cable or plugged in or an access point available. Also, we may want networking to automatically work when an ethernet cable is plugged in or an access point is found.

Here you can find some tools that helps you manage this.

Note: This document only talks about ifplugd, but there are alternatives you can look into like quickswitch.

6.b. ifplugd

ifplugd is a daemon that starts and stops interfaces when an ethernet cable is inserted or removed. It can also manage detecting association to Access Points or when new ones come in range.

Code Listing 1: Installing ifplugd

# emerge sys-apps/ifplugd

Configuration for ifplugd is fairly straightforward too. The configuration file is held in /etc/conf.d/ifplugd. Run man ifplugd for details on what the variables do.

Code Listing 2: sample ifplug configuration

# Define which interfaces we monitor INTERFACES="eth0"

AUTO="no" BEEP="yes" IGNORE_FAIL="yes" IGNORE_FAIL_POSITIVE="no" IGNORE_RETVAL="yes" POLL_TIME="1" DELAY_UP="0" DELAY_DOWN="0" API_MODE="auto" SHUTDOWN="no" WAIT_ON_FORK="no" MONITOR="no" ARGS=""

# Additional parameters for ifplugd for the specified interface. Note that # the global variable is ignored, when a variable like this is set for an # interface MONITOR_wlan0="yes" DELAY_UP_wlan0="5" DELAY_DOWN_wlan0="5"



sponsored by andamiro
sponsored by cdnetworks
sponsored by HP

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2008-08-25 19:15:30
Processing time 0.1136 sec