[ 이전 ] [ 차례 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 다음 ]
업그레이드를 하기 전헤 모든 내용을 백업하두고 잃어버릴 수 있는 최소의 데이터나 설정을 백업해둔다. 업그레이드 도구나 프로세스는 매우 믿을만 하지만, 업그레이드 도중 하드웨어가 문제를 발생시켜 시스템에 심각한 문제를 낳을 수 있다.
여러분인 백업할 주요 파일들은 /etc, /var/lib/dpkg
이고 dpkg --get-selections \*의 결과내용이다.
업그레이드 과정 자체는 /home 내용을 바꾸지 않는다. 그런데 KDE나
모질라와 같은 어플리케이션들은 기존 사용자 설정을 새로운 디폴트 값으로
바꿔버리는데 이는 사용자가 그 어플리케이션을 새롭게 시작하면 적용된다. 우선
미리 숨김 파일과 디렉토리(".으로 시작하는 파일들")을 사용자 홈
디렉토리에서 백업을 철처히 하라. 사용자들에게 이 내용을 알려주는 일이
중요하다.
여러분이 계확하는 내용의 업그레이드를 모든 사용자에게 알려주고 SSH 사용자들은
거의 그 변화를 알지 못하겠지만 계속 작업하길 바라기 때문에 내용을 알려주면
된다. 다른 주의 사항과 사용자 파티션( /home)백업 마운트 해제가
빌요하다면 하라. 재부팅은 필요없을 것이다.
텍스트모드 가상 콘솔에서 로컬에서 작업해야하며(직접 연결된 시리얼 터미널에서),
또는 ssh를 통해서 원격에서 작업 할 수 있다.
중요: telnet, rlogin, rsh,
xdm, gdm, kdm과 같은 것을 통해서
업그레이드 해선 안된다. 이 이유는 업그레이동안 서비스가 끊기고
시스템이 완전히 업그레이드 안된 상세에서 접근할수 없는 상황을 만들 수
있다.
업그레이드하는 가장 좋은 방법은 aptitude를 쓰는 것이다. 내장
의존성 분석을 통해 부드럽게 업그레이드하고 쉽게 설치해준다.
어떤 패키지를 설치해도 항상 루트로 작업을 해야하는데 su 나
sudo를 써서 필요한 접근 권한을 얻으면 된다.
업그레이드 과정은 "순수하게" woody에서 업그레이드 하는 부분만 다룬다. 여러분 시스템이 woody의 가장 최신 상태에 있다고 가정한다. 확실하지 않으면 woody 시스템 업그레이드하기, A.1를 따라하라.
여기서는 aptitude가 woody의 버전으로 설치되었다고 가정한다. 이를
확인하려면
$ dpkg -l aptitude
만일 결과가 "i"로 시작하지 않으면, aptitude의 woody 버전 설치, A.2 것처럼 업그레이드를 시작하라.
테스팅 이상의 배포본에서 어떤 패키지를 설치하기 위해 APT를 설정 했다면
/etc/apt/preferences에 들어있는 APT 핀 설정을 바꿔서 패키지
업그레이드가 새로운 안정 버전으로 되게 해주면 된다. APT 핀기능에 대한 나용은
apt_preferences(5) 에서 찾을 수 있다.
업그레이드에 필요한 방법을 뭘 쓰던, 우선 모든 패키지를 검토하는 게 가장 먼저이고 모든 패키지가 업그레이드 상태인지 확인해야한다. 다음 명령은 반정도만 설치됐는지 설정 실패인지 아니면 다른 에러를 가진 패키지인지 확인해준다.
# dpkg --audit
여러분 시스템에 있는 모든 패키지 상태를 dselect,
aptitude,나 다음과 같은 방법으로 확인할 수 있다
# dpkg -l | pager
나
# dpkg --get-selections > ~/curr-pkgs.txt
업그레이드 하면서 모든 홀드 상태는 다 없애길 바란다. 업그레이드에 필요한 패키지가 홀드상태라면, 업그레이드는 실패할 것이다. 홀드 상태인지 아닌지는 다음으로 확인가능
# dpkg --get-selections | grep hold
패키지를 로컬에서 변형했거나 다시 컴파일한 경우는, 이름을 바꾸지 않고 그 상태로
두고 싶다면 업그레이드 하지 않도록 홀드상태로 두라. `hold' 패키지 상태는
aptitude를 통해서 다음처럼 하면 된다 `hold' 패키지 상태는
aptitude를 써서 바꿀 수 있다:
aptitude hold | unhold <package>
고쳐야할 것이 있다면 소스 리스트
확인, A.3에서 말한 것처럼 sources.list에서 woody 를 여전히
참고하게 하라.
여러분 시스템에 데비안 패키지가 아닌 패키지가 있다면 업그레 이드 도중에 의존성
충돌로 삭제될 수 있다. 이 패키지들은 /etc/apt/sources.list에 추가
패키지로 등록해서 설치했다면 sarge에 맞게 다시 패키지가 나왔는지 확인 하고
데비안 패키지용 소스 라인을 동시에 바꿔서 관리한다.
몇몇 사용자들은 백포트된 비공식인 "좀더 새로운" 이미 woody 시스템에 설치된 데비안에 있는 패키지를 쓸 수 있다. 이 패키지들은 업그레이드 도중 문제를 발생시키기 일쑤있다. 특히 파일 충돌 [1]. 업그레이드 도중 가능한 일들, 4.4.5섹션에 이런 파일 충돌 문제를 다루는 방법이 나와있다.
업그레이드를 시작하기 전에 apt 설정 파일을
/etc/apt/sources.list에 맞게 해줘라.
apt는 "deb" 줄 내용을 따라서 패키지를
검색하고 높은 버전을 먼저 설치하면서 처음줄에 있는 내용에 우선순위를 준다(이런
식으로, 여러 미러가 있을 때, 로컬 하드 디스크, CD-ROM, HTTP/FTP 미러순으로
하게된다).
릴리즈 이름이 코드이름(예를들어, woody, sarge) 와 상태 이름(oldstable, stable, testing, unstable)을 모두 참조 할 수 있다. 코드이름으로 참조하면 새로운 릴리즈가 나왔을 때 절대 놀랄 일이 없다. 또한 여러분이 릴리즈 공고를 계속해서 살펴볼 수 있다는 뜻이기도 하다. 대신 상태 이름을 쓴다면, 릴리즈가 됐을 때 가능한 패키지 업데이트 양을 볼 수 있을 것이다.
기본 설정은 주 데비안 인터넷 서버에서 받아서 설치하게 돼있고
/etc/apt/sources.list를 바꿔서 다른 미러를 쓸 수 있고 여러분
위치에서 가까운 미러를 쓰면 된다.
데비안 HTTP나 FTP 미러 주소는 http://www.debian.org/distrib/ftplist에서
볼 수 있다("모든 미러 목록"을 보라). HTTP 미러는 FTP보다 일반적으로
빠르다.
예를들어, 여러분의 가장 가까운 데비안 미러가 http://mirrors.kernel.org/debian/라고 가정하자. 웹 서버나 FTP 프로그 램을 써서 이 미러를 찾아보면 주 디렉토리가 다음과 같이 돼 있을 것이다:
http://mirrors.kernel.org/debian/dists/stable/main/binary-ia64/...
http://mirrors.kernel.org/debian/dists/stable/contrib/binary-ia64/...
apt로 이 미러를 쓰려면, 다음 내용을 sources.list 에
더하라:
deb http://mirrors.kernel.org/debian sarge main contrib
`dists'는 이미 있는 것이고 릴리즈 이름 뒤에 오는 내용들은 다중 디렉토리로 경로를 확장하는데 쓴다.
새로운 소스를 더한 뒤에, sources.list에 있는 이미 있는
"deb"로 시작하는 라인에 #를 맨 앞에 넣어서
사용하지 못하도록 한다.
설치할 모든 패키지는 네트워크로 받아서 /var/cache/apt/archives에
둔다. 다운로드 중에는 partial/이라는 내부 디렉토리에 둔다.
그렇게 해서 설치에 필요한 공간이 우선 충분한지 확인해야한다. 확장된 데비안
설치에는 적어도 300MB 다운로드 자료 공간이 든다.
HTTP나 FTP 패키지 미러를 쓰는 대신 /etc/apt/sources.list 을
수정해서 NFS로 마운트된 로컬 디스크를 미러로 쓸 수 있다.
예를 들어, 여러분 패키지 미러를 /var/ftp/debian/ 에 둘 수 있고
다음과 같이 주 디렉토리로 할 수 있다:
/var/ftp/debian/dists/stable/main/binary-ia64/...
/var/ftp/debian/dists/stable/contrib/binary-ia64/...
apt로 이를 쓰기 위해선, 다음 내용을 sources.list 에
다음을 더하라:
deb file:/var/ftp/debian stable main contrib
`dists'는 당연히 들어가는 것이고 릴리즈 이름 뒤에 들어가는 내용은 다중 디렉토리로 가는 경로를 확장하는데 쓴다.
새로운 소스를 더하려한다면, 이미 나와있던 "deb"을
sources.list에서 #을 맨 앞에 더해서 못쓰게 만들면
된다.
단지 CD를 사용하고자 한다면, /etc/apt/sources.list 에
"deb"앞에 # 처리를 해서 못쓰게 만든다.
/etc/fstab안에 CD-ROM이 /cdrom로 마운트 되는지
확인하라. /cdrom 마운트 지점은 apt-cdrom에게
필요하다. 예를 들면, /dev/hdc 가 CD-ROM이라면
/etc/fstab에 다음 내용을 담고 있어야 한다:
/dev/hdc /cdrom auto defaults,noauto,ro 0 0
네번째 부분에 defaults,noauto,ro에 사이에 어떤 공간도 없다.
확인하려면, CD를 넣고 시도해보라
# mount /cdrom # CD를 마운트 지점으로 마운트 하고
# ls -alF /cdrom # CD의 루트디렉토리를 보여주고
# umount /cdrom # CD를 언마운트한다.
다시 실행한다:
# apt-cdrom add
각각의 데비안 바이너리 CD-ROM을 가지고 있으면 각 CD를 APT database에 집어넣도록 한다.
Debian GNU/Linux 릴리즈 사이에 업그레이드하는 추천하는 방법은 패키지 관리도구인
aptitude를 쓰는 일이다. 이 도구는 apt-get을
바로쓰면서 가질 수 있는 위험성을 줄이는 도구이다.
루트로 작업을 해서 모든 필요한 파티션 마운트작업을 잊지 말고 다음 명령으로 파티션을 읽기-쓰기 가능하게 만들어라:
# mount -o remount,rw /mountpoint
/etc/apt/sources.list에 APT 소스 항에 'stable'
배포본을 더하고 코드 이름으로 참조하게 하지마라(예를 들어 woody).
/usr/bin/script 프로그램을 써서 upgrade 세션 내용을 저장하고
만주게 발생하면 버그 리포트에 정확한 정보를 이 저장 내용을 바탕으로 주라.
기록을 시작하려면, 다음 내용을 쳐넣어라:
# script -a ~/upgrade-to-sarge.typescript
typescript파일을 /tmp나 /var/tmp에 두지 마라 이 곳은
업그레이드를 하거나 재부팅을 하면 지워질 수 있기 때문이다.
typescript는 스크롤을 넘어간 화면을 모두 보여주는 기능을 가지고 있다. alt-F2를 이용해서 VT2로 넘어간 뒤에 다시 로그인을 해서 less ~root/upgrade-to-sarge.typescript 을 해서 파일 내용을 살펴보라.
모든 업그레이드가 끝나면 typescript를 exit를 입력
해서 typescript를 끝내라.
새로운 릴리즈에 필요한 패키지 리스트를 가져와야한다. 이는 [2] 로 할 수 있다:
# apt-get update
업그레이드 테스트는 sarge 버전의 aptitude가 업그레이드를 하는
도중에 문제를 apt-get나 woody의 aptitude를 쓰는
것보다 해결 능력이 좋다. 우선 다음을 사용해서 업그레이드 해야한다:
# aptitude install aptitude
변화목록과 이를 확인할 부분을 보게 될 것이다. 제안된 변화 를 유심히 살펴보고 없어지는 패키지를 더 잘보라.
몇몇 경우에 많은 패키지가 없어질 목록에 있다면, 이 목록을
aptitude를 따라서 선택된 다른 패키지를 "pre-upgrading"
을 통해 목록을 줄일 수 있다. 예제는 이를 확실히 보여준다. KDE가 깔린 시스템을
써서 업그레이드 테스트 하는 도중, 이 과정이 수많은 KDE 패키지와 perl을 지우는
경우가 있었다. 해결책은 install aptitude perl을 install
aptitude대신 써서 하는 것이다.
doc-base를 설치했다면, 반드시 다른 부분보다 먼저
업그레이드 해야한다. 이유는 동시에 perl이 업그레이드 되면
업그레이드가 안된다. 다음 명령을 통해서 설치 되었는지 확인가능하다:
# dpkg -l doc-base
결과 내용에 "i"라고 설치 정보가 나오면 설치된 것이고 계속 작업 하기 위해서 업그레이드가 반드시 필요하다.
# aptitude install doc-base
업그레이드의 주요 부분을 작업하려면 다음을 실행하라:
# aptitude -f --with-recommends dist-upgrade
이는 시스템의 완전한 업그레이드를 해줄것인데 이 뜻은 모든 패키지의 가장 최신
버전을 쓰게 해준다는 뜻이고 다른 릴리즈 사이의 패키지 사이에 발생할 수 있는
가능한 의존성 문제를 모두 해결해준다. 필요하다면, 몇몇 새로운 패키지(대개는
새로운 라이브러리나 다른 이름으로 바뀐 패키지)를 설치할 것이고 충돌문제를
일으키는 오래된 패키지를 모두 지워줄 것이다(예를 들어
console-tools-libs).
CD-ROM에서 업그레이드를 할 경우, 업그레이드 도중 특정 CD를 몇몇 특정시점에 넣어야할 것이다. 동일한 CD를 여러번 넣을 때도 있다; 이는 CD에 퍼져있는 서로 연관되 패키지 의존성 때문이다.
다른 패키지의 설치 상태를 바꾸는 일이 없으면 업그레이드가 안되는 새로운 버전
패키지는 현재 상태로 "홀드"되어 있을 것입니다. 이는
aptitude를 통해서 이 패키지를 선택하거나 aptitude -f install
<package>를 통해 할 수 있다.
--fix-broken (또는 -f) 옵션은 apt가 깨진
의존성 을 수정하려고 할 때 쓴다. apt는 기본적으로 깨진 패키지는
시스템에 그냥 두지 않게 되어있다.
aptitude, apt-get, dpkg가 작동하는
도중에 다음 에러를 주면서 업그레이드 실패할 수 있다.
E: Dynamic MMap ran out of room
기본 캐시 공간은 부족하다. 이를 해결할 방법은
/etc/apt/sources.list에서 필요없는 부분을 주석처리 하거나 없애고
캐시 크기를 늘리면 해결할 수 있다. 캐시 크기는 /etc/apt/apt.conf
에 있는 APT::Cache-Limit을 수정하면 늘릴 수 있다. 다음 명령은
업그레이드에 충분하게 만들어줄 것이다:
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
여기선 그 파일 안에 변수 모음이 없다고 가정한다.
때로 APT::Force-LoopBreak 옵션을 써서 임시적으로 필수 패키지를
Conflicts/Pre-Depends 순환 때문에 지우게 해줄 수 있다. aptitude
는 이를 경고해주고 업그레이드를 말릴 것이다. -o
APT::Force-LoopBreak=1을 aptitude 명령행에 정해서 쓸 수
있다.
시스템 의존성 구조는 수동으로 할 필요가 있을 때가 있다. 이런 경우는
aptitude를 쓰거나
# dpkg --remove packagename
를 하면서 다른 패키지에 안좋은 영향을 주는 패키지를 지우거나
# aptitude --fix-broken install
# dpkg --configure --pending
극단의 경우 강제 옵션으로 설치를 해야한다.
# dpkg --install /path/to/packagename.deb
"순수한" woody 시스템에서는 파일 충돌이 일어 나서는 안된다. 하지만 비공식 백포트를 쓰고 있다면 일어날 수 있다. 파일 충돌은 다음과 같이 일어날 수 있다:
Unpacking replacement <package-foo> ...
dpkg: error processing <package-name-for-foo> (--unpack):
trying to overwrite `<some-file-name>',
which is also in package <package-bar>
이런 경우 에러 메시지가 있는 마지막 라인에 패키지를 강제로 지워서 해결할 수 있다:
# dpkg -r --force-depends packagename
모든 문제를 해결하고 나서, 다시 업그레이드를 aptitude 명령을 통해서 할 수 있어야한다.
업그레이드 도중, 몇몇 패키지에 대한 설정 문제와 만날 것이다.
/etc/init.d나 /etc/terminfo 디렉토리나
/etc/manpath.config에 대한 파일 설정 문제와 만난다면, 파일은
패키지 관리자 버전으로 바뀌고 시스템 일관성 에 맞추기 위해서 `yes'라고 답을
하는게 필요하다. 오래된 버전으로 .dpkg-old을 통해서 갈 수 있다.
무엇을 해야할지 모른다면, 패키지나 파일 이름을 적어두고 나중에 정리하라. typescript 파일을 살펴보고 업그레이드 도중 일어나는 일에 대한 정보를 알 수 있다.
aptitude dist-upgrade가 끝나면, "정상" 업그레이드가 끝나지만 재부팅을 하기 전에 확인 해야할 부분이 있다.
우선 /usr/share/doc/xfree86-common/README.Debian-upgrade.gz 파일을
엑스 윈도우 시스템 패키지에 대한 더 자세한 정보니 꼭 읽기 바라고 이는 모든 지난
데비안 릴리즈 사용자에게 해당하는 것이니 꼭 읽기 바란다.
리눅스 커널은 이 과정에서 업그레이드 되지 않는다. 이를 하고자 한다면,
kernel-image-* 패키지중 하나를 선택해서 깔고 소스에서 자신에 맞게
만들어 써야한다.
Debian GNU/Linux은 2.4.27 커널과 함께 나오지만 더 나은 성능과 더 나은 하드웨어 지원을 위해서 2.6을 쓸 수 있다.
그런데, 2.6으로 업그레이드 하지 하지 않기를 충고한다. 여기서 커널을 woody에서 sarge로 업그레이드 하는 하나의 부분으로 하지 않는게 좋다고 다시 말한다. 커널 2.6으로 올리는 내용은 2.6 커널로 업그레이드, 5.2에 잘 나와있다.
커널을 업그레이드 하기 위해서. 여러분의 하위아키텍처에 맞는 것을 선택하고 모른 커널 목록은 다음 명령으로 찾을 수 있다:
# apt-cache search ^kernel-image
설치를 하기 위해서 aptitude install을 해야한다. 새로운 커널을 설치하게 되면 재부팅을 해야 동작하게 된다.
woody 설치시스템은 여러분 시스템에 커널을 설치하지 않을 것이다. 이는 sarge에서 변했고 여러 분은 버추얼 패키지를 설치해서 커널 변화를 계속 따라갈 수 있다. 이 패키지들은 kernel-image-VERSION-ARCH 으로 이름을 짓는데 VERSION은 커널버전을 뜻하는 2.4나 2.6을 뜻하고 ARCH는 지원 아키텍처를 뜻한다. 패키지 관리에 들어가 있는 커널에 대한 보안 지원을 원한다면 커널 패키지를 설치하는데 업그레이드 뒤에 여러분 하드웨어에 딱맞는 것을 쓰면 된다.
더 많은 모험을 좋아한다면, Debian GNU/Linux에서 여러분에 맞는 커널을 컴파일
하는 손쉬운 방법이 있다. kernel-package 도구를 설치하고
/usr/share/doc/kernel-package에 있는 문서를 읽으면 된다.
수천개의 새로운 패키지가 sarge에 들어왔고 또 2천개 패키지가 예전 woody에 있던 오래된 것은 빠져나갔다. 더이상 업그레이드가 없어서 퇴출당했고 필요하면 이 오래된 패키지 를 써도 상관은 없는데 데비안 프로젝트는 대개 보안 지원을 sarge가 나온 뒤로 1년 동안 연속으로 하지 않을 것이다 [3], 그리고 그동안 다른 지원은 보통 하지 않을 것이다. 이 패키지들을 다른 대체할 수 있는 것으로 쓰기를 권하는 바이다.
왜 패키지가 배포본에서 없어질 수 밖에 없는지 많은 이유가 있다: 더이상 상위 소스 개발이 되지 않는다; 더이상 그 패키지 를 관리하는 데비안 관리자가 없다; 그 패키지들이 제공하는 기능이 다른(보통 새버전) 패키지가 대체했다; 또는 버그 때문에 sarge에 적합하지 않는 경우가 있다. 보통 마지막 경우는 "불안정" 배포본에 여전히 있게 된다.
업데이트 시스템에서 "오래된" 패키지를 알아내는 방법은 아주 쉬운데
패키지 관리 프론트-엔드들이 이를 쉽게 알려준다. aptitude를
쓴다면, 이들 패키지를 "Obsolete and Locally Created Packages"
항목에서 보여줄 것이다. dselect는 비슷한 선택을 보여주긴 하지만
그 목록은 다르다. aptitude를 써서 패키지를 woody 있던걸 수동으로
설치했다면, 이 패키지를 추적해줄 것이고 오래된 패키지라고 의존성에서 따로
떨어져서 있게 되는데 패키지를 지우려면 더이상 필요하지 않다고 알려줄 것이다.
또, deborphan과 달리, aptitude는 수동으로 설치한
오래된 패키지를 표시 하지 않을 것인데 이는 자동으로 의존성 때문에 걸린 놈들과는
반대로 작동한다.
오래된 패키지를 찾는 다른 방법은 deborphan,
debfoster, cruft가 있다. deborphan을
가장 추천한다. 그런데 기본으로 오래된 라이브러리를 보여줄것인데:
"libs"나 "oldlibs" 섹션에 있는 패키지들은 다른 패키지들이
쓰지 않는 것들이다. 무조건 눈가리고 여기에 나온 패키지를 지우지 마라 잘못된
정보를 줄 수 있는 경우가 종종 있기 때문이다. 패키지를 하나하나 찾아보고 지우는
것이 가장 좋다( 내용과 크기, 설명).
Debian Bug Tracking System은
가끔 왜 패키지들이 없어졌는지 이유를 알려준다. 모아진 버그 보고를 그 패키지
자체에 대해서 살펴보고 그 내용은 ftp.debian.org
pseudo-package를 살펴보기 바란다.
woody에서 온 몇몇 패키지들은 sarge에서 나뉘어서 시스템 관리가 편하게 만들었다. 이런 경우 업그레이드 경로를 쉽게 다루기 위해 sarge는 "dummy" 패키지를 준다: 새로운 패키지를 설치하게 만드는 의존성을 가진 woody에 있는 오래된 패키지와 동일한 이를을 가진 비어있는 패키지들. 이 "dummy" 패키지들은 업그레이드 뒤에 오래된 패키지가 되고 쉽게 없앨 수 있게 된다.
다 그런건 아니지만 대부분dummy 패키지들의 설명을 보면 그것들의 목적을 알 수
있다. dummy 패키지에 있는 패키지 설명은 균일하진 않고
deborphan에서 --guess 옵션으 로 여러분의 시스템에서
검색할 수 있다. 몇몇 dummy 패키지들은 업그레이드 뒤에 없어지지 않게 되었는데
대신 프로그램의 가능한 현재 버전을 따라가게 만들었다.
[ 이전 ] [ 차례 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 다음 ]
Debian GNU/Linux 3.1 (`sarge'), IA-64 릴리즈 노트
$Id: release-notes.ko.sgml,v 1.7 2005/06/10 12:35:31 jseidel Exp $debian-doc@lists.debian.org