만일 여러분의 커널이 커널 업그레이드 과정을 거친 후에 정말 이상하게 되었다면,
새 커널을 컴파일하기 전에 make clean
하는 것을 잊은 것이다. 여러분의 시스템이
잘못되어가는 증상은, 이상하고 낯선 I/O 문제 등의 어떠한 것이든 될 수 있다.
make dep
를 하는 것도 반드시 확인하기 바란다.
만일 커널이 너무 커서 많은 메모리를 차지하고/거나, 여러분이 새로운 콰드바질리움-III/4400 (해석: 빠른 CPU) 에서 사용할 때조차 컴파일하는데 너무나 많은 시간이 걸린다면,여러분은 아마도 필요하지 않은 것(장치 드라이버들이나, 파일 시스템들 등등) 들을 너무많이 구성하여 집어넣었을 것이다. 여러분이 사용하지 않는 것이라면, 넣지 마라. 그것은 메모리를 차지한다. 부풀린 커널의 가장 명확한 증상은 스와핑이 극에 달해서 디스크에 메모리가 부족해지는 것이다.만일 여러분의 디스크가 너무 소리가 많이 나고, 전원을 끌때 제트기가 뜨는 것 같은 소리가 나는 구형 Fujitsu Eagle(하드 디스크 모델인것 같다:역자주)이 아니라면, 여러분의 커널 구성을 조사해 보기 바란다.
여러분은 여러분 머신의 총메모리 양에서 차지하는 것과 /proc/meminfo
내용중에
``total mem
''의 양에서 빼거나 `free
'명령의 결과를 통해서 커널이 얼마나 많은
양의 메모리를 사용하는지 알아낼 수 있을 것이다.
PC에서는 구성 목록중 `General Setup' 에서 `Parallel port support' 과 `PC-style hardware' 를 선택한다. 그 후에 `Character devices' 에서 `Parallel printer support'를 선택한다.
그 후에는 파일 이름 문제가 있다. Linux 2.2는 이전 버젼과 다른 프린터 이름을
쓴다. 결론적으로는 이전 버젼의 리눅스에 프린터가 lp1
였다면 새
커넬에서는 lp0
일 것이다. `dmesg
'나 /var/log
에
나오는 로그를 보고 어느것인자 알아봐라.
만약 컴파일되지 않는다면, 패치가 실패했거나, 아니면 여러분의 소스가 어떻게해서든
방해를 받았다는 것이다. 여러분의 gcc 버전이 맞지 않다거나, 그렇지 않아도 역시
중지될 수 있다(예를 들면, 포함하는 파일들이 에러가 있다면).
Linus가 README
에서 설명한대로 심볼릭 링크가 제대로 되어 있는지 확인하라.
보통, 표준 커널이 컴파일되지 않으면, 시스템에 심각한 문제들이 있으므로,
특정한 도구들은 재설치를 할 필요가 있을 것이다.
어떤 경우에는, 하드웨어의 문제 때문에 gcc가 잘못될 경우도 있다. 그 에러 메세지는 ``xxx exited with signal 15''같은 것인데, 보통 매우 색다르게 보일것이다. 이것은 말하기 싫지만, 나에게도 이런일이 한번 일어난 적이 있다. 나는 약간 좋지 않은 캐쉬 메모리를 가지고 있었는데, 컴파일러가 갑자기 에러 메세지를 내보내면서 제대로 작동하지 않았다. 만일 여러분이 문제에 닥치면 제일 먼저 gcc를 재설치하라. 여러분의 커널이 RAM 양을 줄이고 외부 캐쉬를 끌때에만 제대로 컴파일된다면, 한번 의심해보기 바란다.
기계에 문제가 있다고 누가 그러면 골치가 아파질 것이다.
http://www.bitwizard.nl/sig11/
에 FAQ까지있으니 믿을 만한 이야기다.
여러분이 LILO를 실행하지 않았거나, 아니면 설정을 제대로 하지 않은 것이다.
내가 ``겪었던'' 것들중의 하나는 설정 파일내의 문제였다. 그것은 바로
`boot = /dev/hda
' 대신에 `boot = /dev/hda1
' 라고 한 것이다.(이것은 처음에는
정말로 화가날 수 있는 것이지만, 제대로 작동하는 설정 파일을 가지고
있을 때는, 그것을 바꿀 필요가 없다.).
저런! 여기에서 여러분이 할 수 있는 가장 최선의 방법은 플로피 디스크나
CDROM으로 부팅하고 또다른 부팅가능한 플로피를 준비하는것이다(`make zdisk
'
같은 것으로 할 수 있다). 여러분은 여러분의 루트(/
파일 시스템이 어디에 있고,
어떤 타입(예. second extended, minix)인지를 알아야만 한다. 아래의 예에서는,
또한 여러분의 /usr/src/linux
소스 트리가 어떤 타입의 파일 시스템에 있고,
보통 어디에 마운트되어 있는지 알아야만 한다.
다음 예에서는 /
는 /dev/hda1
이고 /usr/src/linux
가 있는 곳은
/dev/hda3
이며,
보통 /usr
에 마운트되어 있다. 둘다 second extended 파일시스템으로 되어 있다.
사용하는 커널은 /usr/src/linux/arch/i386/boot
에 있는 zImage
이다.
제대로 작동하는 bzImage
가 있다면, 새 플로피를 사용하는 것도 가능하다. 또 다른
방법에 대해서는, 그것이 더 좋을 수도 있고 아닐 수도 있지만, 이 예 다음에
논하기로 한다.(이것은 여러분이 여러분의 시스템을 혼란에 빠뜨린 방법에 따라
다르다.)
우선, 부트/루트나 복구용 디스크로 부팅한다. 그리고 커널 이미지가 있는 파일 시스템을 마운트한다.
mkdir /mnt mount -t ext2 /dev/hda3 /mnt
만일 mkdir
이 디렉토리가 이미 존재한다고 하면, 무시하라. 자, 커널 이미지가
있는 디렉토리로 들어가자.
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
포맷된 디스크를 ``A:'' 드라이브에 넣고(부트나 루트 디스크가 아니다!), 이미지를 디스크로 복사한다. 그리고 여러분의 루트 파일 시스템에 그것을 설정한다.
cd /mnt/src/linux/arch/i386/boot dd if=bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1
/
로 들어가서 /usr
파일 시스템을 언마운트시킨다.
cd / umount /mnt
이제 여러분은 이 플로피로 보통때처럼 여러분의 시스템을 재부팅할 수 있을 것이다. 재부팅후에 리로(또는 여러분이 잘못한 것이 무엇이든)를 실행하는 것을 잊지 말라!
위에서 말한것처럼, 일상적인 다른 방법이 있다. 만일 여러분이 /
에 커널이미지를
가지고서(예로 /vmlinuz
) 이런 상황이 일어났다면, 이것을 부트디스크로
사용할 수 있다.위의 상황을 모두 가정하고, 내 커널 이미지가 /vmlinuz
일때,
위의 예를 다음과 같이 하라. /dev/hda3
를 /dev/hda1
(/
파일 시스템)으로 바꾸고,
/mnt/src/linux
를 /mnt
로 바꾼다. 그리고 if=bzImage
를 if=vmlinuz
으로
바꾼다. 어떻게 /mnt/src/linux
가 무시되는지 확실하게 알아두어라.
큰 용량(1024 실린더 이상의)의 드라이브들에서 리로를 사용하는 것은 문제를 일으킬 수도 있다. 그것에 대한 것은 도움말 문서나 LILO mini-HOWTO를 보아라.
이것은 큰 문제일 수 있다. 커넬 1.0부터는 (1994년 4월 20일 정도)
`update
' 이라는 정기적으로 파일 시스템의 버퍼을 비워주는
프로그램이 바뀌었다. 해결책은 `bdflush
'라는 프로그램의 소스를
구해서 (커넬 소스를 구한 곳에서 구할 수 있을 것이다) 설치하라 (이때 아마도
옛 커넬 안에서 하는 것이 좋을 것이다). 이 프로그램은 자신을
`update
'라는 이름으로 설치할 것이고, 재부팅 후에는 더이상 에러를
안 낼 것이다.
이것은 심각한 문제가 될 수 있다. 정기적으로 파일 시스템 버퍼를 모두 소비시키는
`update
'라고 불리는 프로그램은 커널 버전 1.0(1994년 4월 20일 경) 이후에서
시작해서 업그레이드/대체 되었다. `bdflush
'에 커널 소스를 가져와서 (여러분의
커널 소스를 어디서 가져왔는지는 여러분이 찾아야한다), 그것을 설치하라(여러분은
여러분의 시스템이 이것을 하는 동안은 이전 커널에서 실행되기를 원할 것이다).
그것은 그 자신이 `update
로 설치되고 재부팅한 후에는 더이상 불평하지 않을 것이다.
이상하게도, 많은 사람들의 ATAPI 드라이브들이 작동하지 않는데, 이것은 아마도 잘못될 수 있는 것들이 많기 때문일 것이다.
만일 여러분의 CD-ROM 드리이브가 단지 특정 IDE 인터페이스에 있는 장치라면, 틀림없이 점퍼가 ``master'' 나 ``single''로 설정되어 있을 것이다. 이것은 가장 일상적인 에러이다.
예로, Creative Labs 는 IDE 인터페이스를 그들의 사운드 카드에 장착하고 있다. 그러나, 이것은 몇몇 사람들은 단지 하나의 인터페이스를 가지고 있는 반면에 많은 사람들은 그들의 마더보드에 두개의 IDE 인터페이스(보통 IRQ 15에)를 내장하고 있어서 아주 흥미로운 문제를 야기시킨다. 그래서 보통은 사운드 블러스터의 인터페이스를 세번째 IDE 포트(내가 들은 바로는 IRQ11)로 만든다.
이것은 1.2.x 버전의 리눅스가 새번째 IDE 인터페이스를 지원하지 않음으로 해서 문제를 발생시킨다.(1.3.x대의 어디에선가 이것을 지원한다. 하지만 기억해 둘것은 그것은 개발중이므로 자동으로 찾아주지는 않는다). 이에 대해서는, 몇가지 선택이 있다.
여러분이 이미 두번째 IDE 포트를 가지고 있다면, 그것을 사용하지 않아서 아직 두개의 장치를 가지지 않은 것이다. ATAPI 드라이브를 사운드 카드에서 꺼내서 두번째 인터페이스에 연결한다. 그리고 나서는 사운드 카드의 인터페이스를 사용할 수 없게 함으로써 어떤식으로든 IRQ를 아낀다.
여러분이 두번째 인터페이스를 가지고 있지 않다면, 사운드 카드의 인터페이스의 점퍼 (사운드 카드의 사운드 부분이 아니다)를 IRQ15, 즉 두번째 인터페이스로 설정한다. 이제 작동할 것이다.
새버전의 route
프로그램과 라우트 조작을 하는 다른 프로그램들을 가져온다.
/usr/include/linux/route.h
(실제로 /usr/src/linux
에 있는 파일)이
바뀌었다.
적어도 1.2.1 버전으로 업그레이드 하라.
부트 이미지로 /usr/src/linux
에 생성된 vmlinux
파일을 사용하지 말라.
[..]/arch/i386/boot/zImage
가 옳은 것이다.
/etc/termcap
의 콘솔 termcap
내용중에서 단어 dumb
를
linux
로 바꾸라. 또한 여러분은 terminfo 내용을 만들어야 할 것이다.
리눅스 커널 소스는 /usr/include
에 있는 표준들이 참고로하는 많은 include
파일들(끝이 .h
로 끝나는 것)을 포함하고 있다. 그들은 보통 다음과 같이 참조되었다.
(xyzzy.h
는 /usr/include/linux
에 있는 것이다.)
#include <linux/xyzzy.h>
보통, /usr/include
에는 linux
라는 여러분의 커널 소스내의
include/linux
디렉토리로의
링크가 있다(전통적인 시스템에서는 /usr/src/linux/include/linux
). 만일 이 링크가
없거나 잘못된 곳을 가리키고 있을며 대부분은 전혀 컴파일되지 않을 것이다. 만일
여러분이 커널 소스가 디스크를 너무 많이 차지해서 지우기로 했다면, 이것은 명백히
문제가 될 것이다. 그것이 잘못될 수 있는 또다른 방법은 파일 퍼미션(허가)에 있다.
만일 여러분의 루트
가 기본설정에 의해서 다른 사용자들이 파일들을 볼 수 없게하는
umask
를 가지고 있고, 여러분이 p
옵션(보존 파일모드) 없이 커널 소스를 풀었다면,
그 사용자들은 C 컴파일러를 사용하지 못할 것이다. 여러분이 이것을 고치기 위해서
chmod
명령을 쓴다고해도, 아마 include 파일들을 다시 푸는 것이 더 쉬울 것이다.
여러분은 단지 아규면트를 추가함으로써, 처음 시작때에 전체 소스를 가지고 했던것과
같은 방법으로 할 수 있다.
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Note: ``make config
''은 /usr/src/linux
로의 소프트 링크를
를 필요한대로 만들것이다.
다음은 커넬에 속해 있는 용량을 늘이는 방법의 예이다.
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages