xz -cd linux-4.X.tar.xz | tar xvf -

"X"를 최신 커널의 버전 번호로 바꾸십시오.

/usr/src/linux/ 영역을 사용하지 마십시오! 이 영역에는 라이브러리 헤더 파일에서 사용되는 (일반적으로 불완전한) 커널 헤더 세트가 있습니다. 이들은 라이브러리와 일치해야 하며, 우연히 발생하는 커널에 의해 엉망이 되어서는 안 됩니다.

소프트웨어 요구 사항

4.x 커널을 컴파일하고 실행하려면 다양한 소프트웨어 패키지의 최신 버전이 필요합니다. 필요한 최소 버전 번호와 이러한 패키지의 업데이트를 얻는 방법은 Documentation/Changes를 참조하십시오. 이러한 패키지의 지나치게 오래된 버전을 사용하면 추적하기 매우 어려운 간접 오류가 발생할 수 있으므로, 빌드 또는 작동 중 명백한 문제가 발생할 때만 패키지를 업데이트할 수 있다고 가정하지 마십시오.

커널 빌드 디렉토리:

커널을 컴파일할 때, 모든 출력 파일은 기본적으로 커널 소스 코드와 함께 저장됩니다. "make O=output/dir" 옵션을 사용하면 출력 파일( .config 포함)의 대체 위치를 지정할 수 있습니다. 예:

커널을 구성하고 빌드하려면 다음을 사용하십시오.

참고: 'O=output/dir' 옵션을 사용하는 경우, 모든 make 호출에 대해 동일하게 사용해야 합니다.

커널 구성:

사소한 버전만 업그레이드하더라도 이 단계를 건너뛰지 마십시오. 각 릴리스에서 새로운 구성 옵션이 추가되며, 구성 파일이 예상대로 설정되지 않으면 이상한 문제가 발생합니다. 최소한의 작업으로 기존 구성을 새 버전으로 가져오려면 "make oldconfig"를 사용하십시오. 그러면 새로운 질문에 대한 답변만 묻습니다.

• 대체 구성 명령은 다음과 같습니다.

  "make config" 일반 텍스트 인터페이스.

  "make menuconfig" 텍스트 기반 컬러 메뉴, 라디오리스트 및 대화상자.

  "make nconfig" 향상된 텍스트 기반 컬러 메뉴.

  "make xconfig" X 윈도우(Qt) 기반 구성 도구.

  "make gconfig" X 윈도우(Gtk) 기반 구성 도구.

  "make oldconfig" 기존 ./.config 파일의 내용을 기반으로 모든 질문에 기본값을 사용하고 새로운 구성 심볼에 대해 묻습니다.

  "make silentoldconfig" 위와 유사하지만, 이미 답변된 질문으로 화면을 복잡하게 만들지 않습니다. 추가로 종속성을 업데이트합니다.

  "make olddefconfig" 위와 유사하지만, 새로운 심볼을 묻지 않고 기본값으로 설정합니다.

  "make defconfig" 아키텍처에 따라 arch/$ARCH/defconfig 또는 arch/$ARCH/configs/${PLATFORM}_defconfig의 기본 심볼 값을 사용하여 ./.config 파일을 만듭니다.

  "make ${PLATFORM}_defconfig" arch/$ARCH/configs/${PLATFORM}_defconfig의 기본 심볼 값을 사용하여 ./.config 파일을 만듭니다. "make help"를 사용하여 아키텍처의 사용 가능한 모든 플랫폼 목록을 확인하십시오.

  "make allyesconfig" 심볼 값을 최대한 'y'로 설정하여 ./.config 파일을 만듭니다.

  "make allmodconfig" 심볼 값을 최대한 'm'으로 설정하여 ./.config 파일을 만듭니다.

  "make allnoconfig" 심볼 값을 최대한 'n'으로 설정하여 ./.config 파일을 만듭니다.

  "make randconfig" 심볼 값을 임의의 값으로 설정하여 ./.config 파일을 만듭니다.

  "make localmodconfig" 현재 구성 및 로드된 모듈(lsmod)을 기반으로 구성을 만듭니다. 로드된 모듈에 필요하지 않은 모듈 옵션을 비활성화합니다.

  root@kitploit:~

                      다른 시스템의 localmodconfig를 만들려면,
                      해당 시스템의 lsmod를 파일에 저장하고
                      LSMOD 매개변수로 전달하십시오.
  
              target$ lsmod > /tmp/mylsmod
              target$ scp /tmp/mylsmod host:/tmp
  
              host$ make LSMOD=/tmp/mylsmod localmodconfig
  
                      위는 크로스 컴파일할 때도 작동합니다.
  

  "make localyesconfig" localmodconfig와 유사하지만, 모든 모듈 옵션을 내장(=y) 옵션으로 변환합니다.

  Linux 커널 구성 도구 사용에 대한 자세한 내용은 Documentation/kbuild/kconfig.txt에서 찾을 수 있습니다.

• "make config"에 대한 참고 사항:

  • 불필요한 드라이버가 있으면 커널이 더 커지고, 어떤 상황에서는 문제가 발생할 수 있습니다. 존재하지 않는 컨트롤러 카드를 프로빙하면 다른 컨트롤러가 혼란스러워질 수 있습니다.

  • "Processor type"을 386보다 높게 설정하여 커널을 컴파일하면 386에서 작동하지 않는 커널이 생성됩니다. 커널은 부팅 시 이를 감지하고 포기합니다.

  • 수학 에뮬레이션이 컴파일된 커널은 코프로세서가 있는 경우 계속 사용합니다. 수학 에뮬레이션은 그 경우 사용되지 않습니다. 커널은 약간 더 커지지만, 수학 코프로세서가 있든 없든 다른 시스템에서 작동합니다.

  • "kernel hacking" 구성 세부 사항은 일반적으로 더 크거나 느린 커널(또는 둘 다)을 초래하며, 일부 루틴을 구성하여 잘못된 코드를 적극적으로 깨뜨려 커널 문제(kmalloc())를 찾도록 하면 커널을 덜 안정적으로 만들 수도 있습니다. 따라서 "development", "experimental" 또는 "debugging" 기능에 대한 질문에는 'n'이라고 대답해야 합니다.

커널 컴파일:

• 최소 gcc 3.2가 있는지 확인하십시오. 자세한 내용은 Documentation/Changes를 참조하십시오.

  이 커널에서 a.out 사용자 프로그램을 계속 실행할 수 있습니다.

• "make"를 실행하여 압축된 커널 이미지를 만듭니다. lilo가 커널 makefile에 맞게 설치되어 있으면 "make install"도 가능하지만, 먼저 특정 lilo 설정을 확인하는 것이 좋습니다.

  실제 설치를 수행하려면 root여야 하지만, 일반적인 빌드에는 root가 필요하지 않습니다. root의 이름을 함부로 사용하지 마십시오.

• 커널의 일부를 modules로 구성한 경우, "make modules_install"도 수행해야 합니다.

• 자세한 커널 컴파일/빌드 출력:

  일반적으로 커널 빌드 시스템은 상당히 조용한 모드로 실행됩니다(완전히 조용하지는 않음). 그러나 때로는 사용자나 다른 커널 개발자가 컴파일, 링크 또는 기타 명령이 정확히 어떻게 실행되는지 확인해야 할 수 있습니다. 이 경우 "verbose" 빌드 모드를 사용하십시오. 이는 "make" 명령에 "V=1"을 삽입하여 수행됩니다. 예:

  make V=1 all

  빌드 시스템이 각 대상의 재빌드 이유도 알려주도록 하려면 "V=2"를 사용하십시오. 기본값은 "V=0"입니다.

• 문제가 발생할 경우를 대비하여 백업 커널을 준비하십시오. 이는 특히 개발 릴리스의 경우 중요합니다. 각각의 새 릴리스에는 디버깅되지 않은 새 코드가 포함되어 있기 때문입니다. 해당 커널에 해당하는 모듈의 백업도 보관하십시오. 작동 중인 커널과 동일한 버전 번호의 새 커널을 설치하는 경우, "make modules_install"을 실행하기 전에 모듈 디렉토리를 백업하십시오.

  또는 컴파일하기 전에 커널 구성 옵션 "LOCALVERSION"을 사용하여 일반 커널 버전에 고유한 접미사를 추가하십시오. LOCALVERSION은 "General Setup" 메뉴에서 설정할 수 있습니다.

• 새 커널을 부팅하려면 커널 이미지(예: 컴파일 후 .../linux/arch/i386/boot/bzImage)를 일반 부팅 가능한 커널이 있는 위치로 복사해야 합니다.

• LILO와 같은 부트로더의 도움 없이 플로피에서 직접 커널을 부팅하는 것은 더 이상 지원되지 않습니다.

  하드 드라이브에서 Linux를 부팅하는 경우, 아마도 LILO를 사용할 것입니다. LILO는 /etc/lilo.conf 파일에 지정된 커널 이미지를 사용합니다. 커널 이미지 파일은 일반적으로 /vmlinuz, /boot/vmlinuz, /bzImage 또는 /boot/bzImage입니다. 새 커널을 사용하려면 이전 이미지의 복사본을 저장하고 새 이미지를 이전 이미지 위에 복사하십시오. 그런 다음, 로딩 맵을 업데이트하기 위해 LILO를 다시 실행해야 합니다!! 그렇지 않으면 새 커널 이미지를 부팅할 수 없습니다.

  LILO 재설치는 일반적으로 /sbin/lilo를 실행하는 것입니다. 새 커널이 작동하지 않을 경우를 대비하여 이전 커널 이미지(예: /vmlinux.old)에 대한 항목을 지정하기 위해 /etc/lilo.conf를 편집할 수 있습니다. 자세한 내용은 LILO 문서를 참조하십시오.

  LILO를 다시 설치한 후에는 모든 것이 준비되어야 합니다. 시스템을 종료하고, 재부팅하고 즐기십시오!

  커널 이미지에서 기본 루트 장치, 비디오 모드, 램디스크 크기 등을 변경해야 하는 경우 'rdev' 프로그램(또는 적절한 경우 LILO 부트 옵션)을 사용하십시오. 이러한 매개변수를 변경하기 위해 커널을 다시 컴파일할 필요가 없습니다.

• 새 커널로 재부팅하고 즐기십시오.

문제 발생 시:

• 커널 버그로 인한 문제가 있는 경우, MAINTAINERS 파일을 확인하여 문제가 있는 커널 부분과 관련된 특정 사람이 있는지 확인하십시오. 거기에 아무도 나열되어 있지 않으면, 두 번째로 좋은 방법은 저([email protected])에게 메일을 보내거나, 가능하면 다른 관련 메일링 리스트나 뉴스그룹에 보내는 것입니다.

• 모든 버그 보고서에서는 반드시 어떤 커널에 대해 이야기하고 있는지, 문제를 재현하는 방법, 그리고 설정이 무엇인지(상식적으로) 알려주십시오. 문제가 새로운 것이라면 그렇게 말해주고, 문제가 오래된 것이라면 언제 처음 발견했는지 알려주십시오.

• 버그로 인해 다음과 같은 메시지가 나타나는 경우

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  또는 화면이나 시스템 로그에 유사한 커널 디버깅 정보가 표시되면, 정확히 복제해 주십시오. 덤프는 이해하기 어려워 보일 수 있지만, 문제 디버깅에 도움이 될 수 있는 정보를 포함하고 있습니다. 덤프 위의 텍스트도 중요합니다. 커널이 코드를 덤프한 이유에 대해 알려줍니다 (위의 예에서는 잘못된 커널 포인터 때문입니다). 덤프를 이해하는 방법에 대한 자세한 정보는 Documentation/oops-tracing.txt에 있습니다.

• CONFIG_KALLSYMS로 커널을 컴파일한 경우 덤프를 그대로 보낼 수 있습니다. 그렇지 않으면 "ksymoops" 프로그램을 사용하여 덤프를 이해해야 합니다 (하지만 CONFIG_KALLSYMS로 컴파일하는 것이 일반적으로 선호됩니다). 이 유틸리티는 다음에서 다운로드할 수 있습니다. ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . 또는 수동으로 덤프를 조회할 수 있습니다.

• 위와 같은 디버깅 덤프에서 EIP 값이 무엇을 의미하는지 조회할 수 있으면 크게 도움이 됩니다. 16진수 값 자체는 저나 다른 사람에게 별로 도움이 되지 않습니다. 특정 커널 설정에 따라 달라지기 때문입니다. EIP 라인에서 16진수 값을 가져와서 ( "0010:"은 무시) 커널 namelist에서 조회하여 문제의 주소를 포함하는 커널 함수를 찾아야 합니다.

  커널 함수 이름을 찾으려면 증상을 보인 커널과 관련된 시스템 바이너리를 찾아야 합니다. 이것은 'linux/vmlinux' 파일입니다. namelist를 추출하고 커널 충돌의 EIP와 일치시키려면 다음을 수행하십시오.

  nm vmlinux | sort | less

  그러면 오름차순으로 정렬된 커널 주소 목록이 표시되며, 여기에서 문제의 주소를 포함하는 함수를 쉽게 찾을 수 있습니다. 커널 디버깅 메시지에 제공된 주소가 함수 주소와 정확히 일치하지는 않을 수 있습니다 (사실 그럴 가능성은 거의 없습니다). 따라서 목록을 단순히 'grep'할 수는 없습니다. 그러나 목록은 각 커널 함수의 시작점을 제공하므로, 찾고 있는 주소보다 낮은 시작 주소를 가지고 있지만 더 높은 주소를 가진 함수가 뒤따르는 함수를 찾으면 원하는 함수를 찾을 수 있습니다. 사실, 문제 보고서에 약간의 "컨텍스트"를 포함하여 관심 있는 줄 주변의 몇 줄을 제공하는 것이 좋습니다.

  어떤 이유로 위의 작업을 수행할 수 없는 경우(사전 컴파일된 커널 이미지 등), 가능한 한 많은 설정 정보를 알려주시면 도움이 됩니다. 자세한 내용은 REPORTING-BUGS 문서를 읽어 주십시오.

• 또는 실행 중인 커널에서 gdb를 사용할 수 있습니다(읽기 전용, 즉 값을 변경하거나 중단점을 설정할 수 없습니다). 이렇게 하려면 먼저 커널을 -g로 컴파일하십시오. arch/i386/Makefile을 적절히 편집한 다음 "make clean"을 수행하십시오. 또한 CONFIG_PROC_FS("make config"를 통해)를 활성화해야 합니다.

  새 커널로 재부팅한 후 "gdb vmlinux /proc/kcore"를 실행하십시오. 이제 모든 일반적인 gdb 명령을 사용할 수 있습니다. 시스템이 충돌한 지점을 조회하는 명령은 "l *0xXXXXXXXX"입니다. (XXX를 EIP 값으로 바꾸십시오.)

  실행되지 않는 커널에서 gdb를 사용하는 것은 현재 실패합니다. gdb가 (잘못) 커널이 컴파일된 시작 오프셋을 무시하기 때문입니다.