Sun Developer Network 공식 블로그

Rich Teer

소개

이 글은 OpenSolaris 소스 코드를 빌드 하는 법을 소개하는 두 개의 문서중 두번째 입니다. 첫번째 문서는 모든 필요한 배경 정보(단어나, 툴 등) 그리고 기본적인 컴파일과 설치에 대해 설명했습니다. 첫번째 글에서 수행했던 단계들 중에 우리의 요구에 맞지 않게 부족한 부분이 있었습니다. 이 글에서는 부족한 나머지 부분을 채우는 것에 대해 설명할 것입니다.

이 글은 독자들이 첫번째 글에 친숙하다는 가정하에 또는 적어도 OpenSolaris 소스 코드를 얻어서 빌드하고 인스톨 하는 방법을 안다는 가정하에서 쓰여 졌습니다. 일관성을 위해서 첫번째 글과 같은 소스 코드 버전을 사용할 것입니다.


간단한 복습

첫번째 글에서 우리는 OenSolaris를 다룰때 마주치는 각 단어들에 대해 정의를 내렸습니다. 또한 소스코드를 얻는 방법과 컴파일 하는 방법 그리고 OpenSolaris를 설치 하는 방법에 대해서도 다루었습니다. 이러한 단계들은:

1. www.opensolaris.org 또는 미러사이트에서 소스 코드, 바이너리. 컴파일러 그리고 빌드 툴을 얻음.
2. ON 빌드 툴 그리고 썬 스튜디오 컴파일러를 /opt 에 설치 하고 디렉토리들을 PATH에 추가.
3. 소스 그리고 바이너리들의 tar ball을 압축해제.
4. opensolaris.sh 스크립트를 복사하고 수정.
5. nightly 스크립트를 이용하여 소스 코드를 빌드.
6. Install 스크립트를 이용하여 새로운 커널을 인스톨.
7. 새로운 커널을 이용하여 재부팅.

이러한 단계들은 새로운 커널을 빌드하고 테스트 하는데에는 아주 적합합니다. 그러나 이것으로는 부족할 때도 있습니다: 새로운 사용자 영역 컴포넌트들을 설치하거나 새롭게 빌드된 커널이 사용자 영역 의 라이브러리, 어플리케이션과 충돌하는 경우. 후자의 시나리오는 Flag Day 라고 불립니다. Flag Day의 또다른 예로는 그 자신들을 의존하고 있는 라이브러리와 커맨드를 이용하여 업데이트를 수행할 때 입니다.


Flag Days

Flag Day 란 ON 컴포넌트들을 사용하기 전에 최신버전의 시스템 패키지들이 반드시 먼저 설치 되어야 함을 뜻합니다. 만약 이러한 상황이 발생한다면 Flag Day 공지가 OpenSolaris 웹 사이트(www.opensolaris.org/os/community/onnv) 에 올라올 것입니다. 이러한 공지는 새롭게 요구되는 소프트웨어를 빌드하거나 인스톨하는 방법에 대한 설명을 포함할 것입니다. 특별히 이글은 BFU 유틸리티 사용에 촛점을 맞추어 표준 솔라리스 패키지에서 업데이트가 불가능한 컴포넌트들을 업그레이드 하는 방법에 대해 설명할 것입니다. 이러한 방법에 의문이 생긴다면 최신의 Solaris Express를 설치 하는 것이 갖아 좋은 선택이 될것입니다. 사실 BFU 는 ON 코드의 능동적인 개발자들이 사용하기를 권장합니다. (또는 최신 기술에 목말라 있는 개발자들).


BFU 기본

ON의 모든 부분을 설치 하는 절차를 BFU 라고 부릅니다. 이 것은 Blindingly Fast Upgrade (또는 Bonwick-Faulkner Upgrade, 본래의 개발자 이름인 Jeff Bonwick 그리고 Roger Faulkner의 이름을 본따서)의 약자입니다. BFU는 cpio 어카이브를 이용하여 기존에 시스템의 존재하는 컴포넌트들을 직접적으로 덮어 씌우는데 사용됩니다. (BFU를 수행하고 나서 솔라리스 패키징 툴을 더이상 사용하지 않아도 되는 이유이기도 함); 이러한 어카이브들은 nightly 빌드 절차의 일부로 만들어 졌고 이 전에 글에서도 이미 언급한 바 있습니다.


BFU를 이용하여 새롭게 컴파일된 컴포넌트들을 인스톨 하기 전에 우리는 다음과 같은 세가지의 환경 변수들을 정의해야 합니다. 그 것들은:

FASTFS 보통 /opt/onbld/bin/`uname -p`/fastfs 에 존재.
BFULD 보통 /opt/onbld/bin/`uname -p`/bfuld에 존재.
GZIPBIN 보통 /bin/gzip에 존재.

이러한 변수들을 쉘의 시작 스크립트에 지정합니다.(예를 들어 .profile) 이렇게 해놓는 것이 BFU를 자주 사용할때 편한 방법이 될것입니다. 첫 번째 글에서 설명했던 opensolaris.sh 환경 파일 또한 이러한 변수들을 지정합니다. bfu를 사용하기전에 bldenv opensolaris.sh usr/src/tools/env/opensolaris.sh 에서 처음 파일을 카피해 와서 필요에 맞게 고침) 을 이용하는 것이 최고의 방법입니다. 각 소스 버전을 가져 올때 마다 opensolaris.sh 의 카피를 수정하는 버릇을 들이는 것을 권장합니다. 왜냐하면 새로운 환경변수들을 자동으로 가져 오는 것을 확실히 해주기 때문입니다.

BFU 를 이용하여 ON 인스톨하기

BFU를 이용하여 OpenSolaris의 ON 부분을 인스톨하는 것은 상대적으로 쉬운 작업입니다.: bfu 명령어를 어카이브를 인스톨하고자 하는 패스를 지정하는 하나의 인자와 실행시키는 것입니다.

첫번째 글에서 우리는 $HOME/open_solaris/build-17/testws 디렉토리를 워크스페이스 디렉토리로 사용했습니다. 이 글에서도 마찬가지로 같은 디렉토리를 사용하여 bfu를 실행시킵니다:

# bfu `pwd`/archives/`uname -p`/nightly

시스템 파일들이 덮어 씌여지기 때문에 bfu 는 반드시 루트 권한으로 수행되어야 합니다. 또한 /opt/onbld/bin 디렉토리가 루트의 PATH에 추가되어 있어야 합니다.

bfu은 다음과 같은 출력을 나타냅니다:

# bfu `pwd`/archives/`uname -p`/nightly
Copying /opt/onbld/bin/bfu to /tmp/bfu.1100
Executing /tmp/bfu.1100 /home/rich/open_solaris/build-17/testws/archives/i386/nightly

Loading /home/rich/open_solaris/build-17/testws/archives/i386/nightly on /

Creating bfu execution environment ...
/tmp/bfu.1100[2261]: /net/onnv.eng/export/gate/public/bin/acr: cannot open
chmod: WARNING: can't access /tmp/bfubin/acr
Verifying archives ...
Performing basic sanity checks ...
/etc/svc/repository.db: passed integrity check
Disabling kernel module unloading ... moddebug: 0 = 0x20000
Quiescing init ...
Unmounting /lib/libc.so.1 ...
Disabling sendmail temporarily ...
Disabling remote logins ...
Disabling syslog temporarily ...
Killing httpd ...
Disabling fmd temporarily ...
Killing nscd ...
Turning on delayed i/o ...
Filesystem Mode
/ safe
/usr safe
2423 blocks

Saving configuration files in /bfu.child ... 4464 blocks
Removing init.d links ... done.
Removing obsolete rc.d scripts ... done.
Preserving user-installed perl modules...
cp: cannot access /usr/perl5/site_perl/5.8.3/*
Removing perl 5.8.3 packages
Removing perl 5.8.3 from /var/sadm/install/contents
Removing perl 5.8.3 from /usr/perl5
Extracting ufs modules for boot block ... 410 blocks
Extracting generic.usr ... 269143 blocks
Extracting i86pc.usr ... 410 blocks
Extracting generic.lib ... 34359 blocks
Extracting generic.sbin ... 1420 blocks
Extracting generic.kernel ... 108072 blocks
Extracting generic.root ... 3962 blocks
Extracting i86pc.root ... 6790 blocks
Extracting i86pc.boot ... 2430 blocks

Removing duplicate kernel binaries ...

Simulating SUNWcry* installation...

Cleaning up old Kerberos GSS-API mechanisms...

[... Conflict info (see later) omitted for brevity ...]

Create /platform/i86pc/boot_archive
updating /platform/i86pc/boot_archive...this may take a minute

For each file in conflict, your version has been restored.
The new versions are under /bfu.conflicts.

MAKE SURE YOU RESOLVE ALL CONFLICTS BEFORE REBOOTING.

To install resolved changes required for reboot in the boot
archive, invoke 'bootadm update-archive'

Removing obsolete smf services ...
Disabling unneeded inetd.conf entries ...
Connecting platform and name service profiles ...
Marking converted services as enabled ...
cp: cannot access /net/greenline.eng/meta0/smf/post-5090532/sysidtool.xml
bfu: could not copy /net/greenline.eng/meta0/smf/post-5090532/sysidtool.xml
cp: cannot access /net/greenline.eng/meta0/smf/post-5090532/kdmconfig.xml
bfu: could not copy /net/greenline.eng/meta0/smf/post-5090532/kdmconfig.xml
Upgrade of orac took 2:09.
Turning off delayed i/o and syncing filesystems ...
Filesystem Mode
/ safe
/usr safe

Entering post-bfu protected environment (shell: ksh).
Edit configuration files as necessary, then reboot.

BFU 절차(저자의 Ferrari 3400 랩탑에서 대략 2분 정도 소요 되었습니다)가 완료된 후에 새롭게 생성된 서브쉘을 볼 수 있습니다. 왜냐하면 새로운 명령어들과 라이브러리들은 기존의 커널과 호환되지 않을것 이기 때문입니다. 새로운 서브쉘은 PATH에 /tmp/bfubin 그리고 LD_LIBRARY_PATH 이 /tmp/bfulib에 지정되었음을 확인 할 수 있습니다. 이러한 디렉토리들은 명령어들과 라이브러리들의 구 버젼을 포함하는 디렉토리이고 문제를 해결하고 시스템을 재부팅 하는데 필요하게 됩니다. (/net/greenline.eng 를 엑세스 할때 발생하는 에러는 버그 4865419 이고 무시하셔도 됩니다.) 주의할 점은 init 또는 shutdown 은 BFU 작업이 끝난 후에 사용되어져야 합니다; reboot 명령을 대신 사용하시기 바랍니다.

Notice that the bfu 출력이 충돌을 해결하고 있음을 나타내는 출력에 주목하시기 바랍니다. 이 것들은 다음과 비슷한 bfu 출력을 찾음으로써 인식할 수 있습니다:

NEW conflict: boot/grub/menu.lst
NEW conflict: boot/solaris/bootenv.rc
NEW conflict: boot/solaris/devicedb/master
update: etc/.login
update: etc/aggregation.conf
NEW conflict: etc/auto_home
update: etc/auto_master
update: etc/bootrc

이러한 충돌들은 반드시 시스템이 재부팅 되기 전에 해결되어져야 합니다.


충돌 해결하기

솔라리스를 운용하는 모든 머신들은 다양한 설정 파일들을 가지고 있고 기본 인스톨시에 수정되어 집니다. 이러한 설정 파일에는 /etc/auto_home, /etc/nsswitch.conf, 그리고 /etc/path_to_inst와 같은 파일을 포함합니다. bfu 명령은 이러한 파일들의 목록을 보관하며 충돌 데이타베이스 라고 부릅니다.

BFU가 설정파일을 덮어씌울때 본래의 파일은 처음에 /bfu.child 아래에 저장됩니다. 새로운 파일의 카피(cpio 어카이브) 또한 under /bfu.parent 아래에 카피 되고 기존의 /bfu.parent (만약 존재합니다.) 디렉토리는 /bfu.ancestor 로 카피 됩니다. 이러한 파일들은 각각 child, parent, 그리고 ancestor 를 나타냅니다.

bfu가 cpio 어카이브들 추출작업을 완료 하면 여러 가지 버전의 파일들을 비교하고 다음과 같은 룰을 따릅니다:

• 만약 파일이 변경되지 않았다면 (예 parent와 child가 동일할때), nothing 즉 아무것도 할일이 없다고 알려줌.
• 만약 파일이 이전의 BFU 실행에서 이용되어 졌다면(예를 들어 child와 ancestor가 동일할때) parent는 자동적으로 이용되고 파일에 "update"를 마크 함. 이것은 또한 BFU를 수행하고 다른 어떠한 룰도 적용되지 않을때 수행되어 집.
• 만약 파일이 기존의 파일과 똑같은 구문으로 시작한다면 BFU는 유저가 마지막에 라인을 추가했다고 가정함.(다시 말해 child는 parent와 붙여진 라인으로 구성) child 버전은 저장되어 지고 파일에 "restore:"를 마크.
• 만약 parent와 child가 다르고 parent와 ancestor가 같다면 충돌은 오래된 충돌이라고 가정하고 파일에 "old: "를 마크.
• 최종적으로 parent와 child가 다르고 parent와 ancestor 또한 다르다면 충돌은 새로운 충돌이라고 가정하고 파일에 "NEW: "를 마크.

충돌이 NEW 라고 하면 기본 설정과 다르다고 간주되고 기본 설정이 수정되어 집니다. 이러한 문제를 해결하기 위해서는 새로운 빌드의 어떠한 변경 사항이든 기존의 파일에 기록해야 합니다.

비록 추가적인 조사 없이 parent를 사용할 수 있다고 가정하더라도 이러한 작업은 child에서 수정했던 작업들을 잃어 버릴 수도 있음을 유의해야 합니다. 이러한 수정 작업들은 ON 패키지가 아닌 스크립트들에 의해 수행되어 짐으로 아무런 의심없이 parent를 사용하는것은 시간 낭비를 초래할 수 있습니다. 그러므로 충돌은 수동적으로 하든 자동적으로 하든 반드시 해결되어져야 합니다. 해결 하는 방법은 추후에 설명합니다. 그러나 모든 충돌들이 자동적으로 해결되지 않는다면(또는 수동으로 라도) 기본적인 충돌 데이타베이스를 가지고 있는 것은 정말로 좋은 생각임을 알아야 합니다. 또한 이러한 작업은 BFU 어카이브를 현재 시스템 릴리즈에 맞게 설치 함으로써 수행될 수 있습니다.

다른 방법에 의해 벌써 설치된 빌드와 똑같은 빌드를 BFU 할때에는 모든 충돌을 안전하게 무시할 수 있습니다. 왜냐하면 현재의 설정파일이 동작이 가능함을 이미 알고 있기 ?문입니다. 재부팅은 새로운 빌드를 BFU하기 전에 반드시 수행되어야 합니다.


자동 충돌 해결

거의 대부분 충돌은 acr 스크립트를 이용하여 자동적으로 해결될 수 있습니다. 이 스크립트는 BFU 수행 후 안전이 보장된 환경을 수행하는데 사용되어 집니다.; 이러한 경우에 사용되면 커맨드 라인 옵션들은 필요하지 않습니다. (좀 더 특수화된 어플리케이션 acr 은 한개 혹은 두개의 커맨드 라인 옵션을 필요로함. 첫번째는 변경된 root 디렉토리의 경로 그리고 두번째는 BFU 어카이브를 포함하고 있는 디렉토리)

acr 은 conflict_resolution.gz, 이라는 nightly -a 옵션을 사용하여 수행시에 생성되어지는 파일을 사용합니다.(BFU 어카이브를 포함하고 있는 디렉토리와 같은 디렉토리에 저장됨). acr 스크립트는 표준 출력에 파일 리스트를 처리하고 자세한 결과를 allresults,라는 파일(/tmp에 저장됨) 에 저장합니다. 다음은 The acr 실행 출력의 예입니다:

bfu# acr
Getting conflict resolution information from /home/rich/open_solaris/build-17/testws/archives/i386/nightly/conflict_resolution.gz: 590 blocks
Building command list for the class action scripts:

Begin processing files
PROCESSING etc/devlink.tab
PROCESSING etc/driver_classes
PROCESSING etc/security/device_policy
PROCESSING etc/path_to_inst
PROCESSING etc/shadow
PROCESSING etc/vold.conf
PROCESSING etc/rmmount.conf
PROCESSING etc/inet/hosts
PROCESSING etc/inet/ipnodes
PROCESSING var/spool/cron/crontabs/root
PROCESSING etc/passwd
PROCESSING etc/inet/inetd.conf
PROCESSING etc/default/init
PROCESSING etc/remote
PROCESSING etc/nsswitch.conf
PROCESSING etc/inet/services
PROCESSING etc/security/auth_attr
PROCESSING etc/security/exec_attr
PROCESSING etc/security/prof_attr
PROCESSING etc/user_attr
PROCESSING etc/vfstab
PROCESSING etc/auto_home
PROCESSING etc/datalink.conf
PROCESSING boot/grub/menu.lst
PROCESSING etc/krb5/krb5.conf
PROCESSING etc/openwin/server/etc/OWconfig
PROCESSING kernel/drv/sd.conf
PROCESSING boot/solaris/bootenv.rc
PROCESSING boot/solaris/devicedb/master
See /tmp/acr.Yda49i/allresults for more information.

And this is the corresponding allresults file:

bfu# cat /tmp/acr.Yda49i/allresults
PROCESSING etc/devlink.tab
RETURN CODE : 0
PROCESSING etc/driver_classes
RETURN CODE : 0
PROCESSING etc/security/device_policy
RETURN CODE : 0
PROCESSING etc/path_to_inst
RETURN CODE : 0
PROCESSING etc/shadow
RETURN CODE : 0
PROCESSING etc/vold.conf
RETURN CODE : 0
PROCESSING etc/rmmount.conf
RETURN CODE : 0
PROCESSING etc/inet/hosts
RETURN CODE : 0
PROCESSING etc/inet/ipnodes
RETURN CODE : 0
PROCESSING var/spool/cron/crontabs/root
RETURN CODE : 0
PROCESSING etc/passwd
RETURN CODE : 0
PROCESSING etc/inet/inetd.conf
RETURN CODE : 0
PROCESSING etc/default/init
RETURN CODE : 0
PROCESSING etc/remote
RETURN CODE : 0
PROCESSING etc/nsswitch.conf
RETURN CODE : 0
PROCESSING etc/inet/services
RETURN CODE : 0
PROCESSING etc/security/auth_attr
RETURN CODE : 0
PROCESSING etc/security/exec_attr
RETURN CODE : 0
PROCESSING etc/security/prof_attr
RETURN CODE : 0
PROCESSING etc/user_attr
RETURN CODE : 0
PROCESSING etc/vfstab
RETURN CODE : 0
PROCESSING etc/auto_home
RETURN CODE : 0
PROCESSING etc/datalink.conf
RETURN CODE : 0
PROCESSING boot/grub/menu.lst
RETURN CODE : 0
PROCESSING etc/krb5/krb5.conf
RETURN CODE : 0
PROCESSING etc/openwin/server/etc/OWconfig
Converting old OWconfig file to new format.
RETURN CODE : 0
PROCESSING kernel/drv/sd.conf
RETURN CODE : 0
PROCESSING boot/solaris/bootenv.rc
RETURN CODE : 0
PROCESSING boot/solaris/devicedb/master
RETURN CODE : 0

allresults 파일은 acr 과정에서 발생된 에러를 확인 하기 위해 반드시 검사되어져야 합니다. 만약 어떠한 에러가 발생했다면 충돌은 반드시 수동으로 해결되어져야 합니다. acr 오류는 종종 스크립트의 버그를 나타낼 수도 있으므로 opensolaris-bug 메일링 리스트에 보고 하는 것도 좋은 생각입니다.


수동으로 충돌 해결

ancestor와 parent 버젼들의 파일을 diff 를 이용해서 수동으로 충돌을 해결 할 수 있습니다. 예를 들어서 다음과 같은 명령을 수행합니다.

bfu# diff /bfu.ancestor/$file /bfu.parent/$file

그리고 diif 결과를 수동으로 적용시켜 줍니다. (만약 BFU를 처음 수행하는 것이라면 /bfu.ancestor 는 존재하지 않을 것입니다. 많은 파일들을 검사 하기 위해 좀더 간단한 방법을 사용합니다. 모든 변경들이 추가 혹은 수정이라 가정할때 BFU 프로세스는 /bfu.conflicts,디렉토리를 남겨 줍니다.
bfu# pw
/bfu.conflicts
bfu# diff $file /$file

모든 diff 결과들은 오른쪽 괄호 (예를 들어 ">" 가 아닌 "<") 가 작업이 필요한 것임을 의미 합니다. 예를 들어:

bfu# diff boot/solaris/bootenv.rc /boot/solaris/bootenv.rc
5d4
< # CDDL HEADER START
7,10c6
< # The contents of this file are subject to the terms of the
< # Common Development and Distribution License, Version 1.0 only
< # (the "License"). You may not use this file except in compliance
< # with the License.
---
> #pragma ident "@(#)bootenv.rc 1.34 05/04/15 SMI"
12,26d7
< # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
< # or http://www.opensolaris.org/os/licensing.
< # See the License for the specific language governing permissions
< # and limitations under the License.
< #
< # When distributing Covered Code, include this CDDL HEADER in each
< # file and include the License file at usr/src/OPENSOLARIS.LICENSE.
< # If applicable, add the following below this CDDL HEADER, with the
< # fields enclosed by brackets "[]" replaced with your own identifying
< # information: Portions Copyright [yyyy] [name of copyright owner]
< #
< # CDDL HEADER END
< #
< #pragma ident "@(#)bootenv.rc 1.35 05/06/08 SMI"
< #
38a20,22
> setprop prealloc-chunk-size 0x2000
> setprop bootpath /pci@0,0/pci-ide@11,1/ide@0/cmdk@0,0:a
> setprop console 'text'

이 예에서 중요한 diff 라인들은 오른쪽을 가르키고 있으므로 별 문제가 없다고 간주할 수 있습니다.

비록 이러한 과정들이 대부분의 시간을 차지하지만 아래와 같이 몇가지 특별한 예외상황도 존재 합니다. 이러한 예외상황들은 etc/name_to_major, etc/security/*_attr, 그리고 /etc/path_to_inst입니다.

파일 etc/name_to_major 는 디바이스 이름들을 major 숫자들에 매핑 시켜 줍니다; 각 디바이스들은 반드시 고유의 major 숫자를 가지고 있어야 합니다. ancestor를 parent와 비교하는 것은 좋은 시작 방법입니다; 디바이스 이름은 중요하지만 major 숫자는 그렇지 않을 수도 있습니다. 이상적으로 더이상 사용되지 않는 디바이스들은 지워져아 하지만 그냥 놔두는 것도 보통 나쁘지 않습니다. 확실하지 않을 때는 그냥 놔두는 것이 좋습니다.

새로운 디바이스들은 사용되지 않은 major 숫자들에 추가되어져아 합니다. 만약 가능하다면 diff에서 나타난 것을 사용하기를 권장함.

작업을 마치고 난다음 다음의 두 sort 명령어를 이용하여 변경한 작업들을 확인할 수 있습니다:

bfu# sort -k1,1 /etc/name_to_major | sort -uc -k1,1
bfu# sort -k2n /etc/name_to_major | sort -uc -k2n

첫번째 명령어는 중복된 디바이스 이름을 보고해주고 두번째 명령어는 중복된 major 넘버중에서 가장 낮은 것을 보고해 줍니다. 두개의 명령 모드 재부팅 하기 전에 아무런 보고를 하지 않아야 합니다. (리부팅시에 커널은 이러한 충돌에 대해 경고할 것이지만 이때는 너무 늦습니다.)

The etc/security/*_attr 파일들은 class-action 스크립트 들에 의해 꽤 많은 부분이 변경 되므로 parent와 child 버젼들에는 큰 차이가 있을 수 있습니다. 즉 그전에 설명한 diff 방법이 효과적이지 않을 수도 있습니다.

마지막 예외상황은 /etc/path_to_inst입니다. 우리가 하고 있는 작업을 정확하게 알고 있더라도 이 파일은 수정하지 않기를 권장합니다.

일반적으로 NEW로 마크된 충돌들만 검사 해도 됩니다.


BFU 그리고 Zones

만약 BFU를 수행하는 호스트에 global 존이외에 존이 설치 되어 있다면 몇가지 추가적인 작업이 필요합니다. 왜냐하면 존을 생성할 때마다 글로벌존의 내용이 존으로 카피 되기 ?문에 모든 논-글로벌 존들의 내용이 글로벌 존과 호환이 유지되어야 하기 때문입니다. 다행히도 BFU는 글로벌 존이 업데이트 됐을때 논-글로벌 존들도 업데이트 하는 작업을 해 줍니다. 왜냐하면 각 존들은 글로벌 존과 조금 다른 설정 파일들을 가지고 있을 것이고 또한 각각 고유의 충돌 관리 디렉토리 또한 가지고 있을 것이기 때문입니다. 주의할점은 BFU를 수행하기 전에 모든 존들을 shut down 시키는 것입니다. 이유는 이 작업으로 인해서 존상에 파일들에 의해 의존성이 훼손되지 않도록 도와주기 때문입니다. BFU 작업 후에 새로운 존을 추가 했을때 다시 bfu를 하는것도 좋은 방법입니다.

싱글존만을 BFU하는 것은 불가능합니다. 만약 존의 유저 영역 변경을 테스트 하길 원한다면 작업 디렉토리에서 존으로 직접 파일들을 카피해야 합니다.

충돌은 글로벌존에서 해결 되어야 합니다. 그리고 그 다음에 리부팅 전에 각 논-글로벌 존에서도 처리가 되어야 합니다. 각 존에서의 충돌 처리는 글로벌 존에서의 작업과 똑같은 방법으로 진행됩니다. 그러나 많은 파일들이 글로벌 존의 상대적인 파일과 거의 동일할 것임으로 수동으로 합쳐 주는 작업은 필요하지 않을 것입니다:글로벌존에서 파일을 카피 하는 것만으로도 충분할 것입니다.

글로벌 존과 논-글로벌 존에서의 모든 충돌이 해결 되었다면 이제 시스템을 재부팅 시킬 수 있습니다. 주의할 점은 논-글로벌 존이 재부팅 되거전에 반드시 시스템이 먼저 재부팅 되어야 한다는 점입니다.


빌드 없이 BFU 작업하기

지금 까지는 직접 빌드한 어카이브를 이용해 BFU 작업을 하는것에 대해 설명했습니다. 만약 최신의 버전을 컴파일링 하지 않은 채 사용하고자 한다면 어떻게 해야 할까요? 다행히 미리 제작된 BFU 어카이브가 있습니다. 소스를 빌드하지 않고 BFU를 하고자 한다면 BFU 어카이브와 ON 빌드 툴들이 필요 합니다. 여기서 알아야 할 점은 현재의 빌드와 BFU를 하기를 원하는 빌드와의 차이가 있다면 BFU 작업을 여러번 진행해야 할 지도 모릅니다.

예를 봅시다. 현재의 BFU된 Build 17 시스템을 Build 18 버전으로 BFU 작업을 해 봅시다. 첫번째 글에서 우리는 두개의 필요한 파일들을 $HOME/open_solaris/build-18, 디렉토리에 다운로드 해 놓았기 때문에 현재 우리의 디렉토리는 저 디렉토리 입니다. 편의를 위해서 이 디렉토리를 $OPEN_SOL이라고 합니다.

먼저 BFU 어카이브들을 압축해제 합니다:

$ bzip2 -dc opensolaris-bfu-20050720.i386.tar.bz2 | tar xf -

이 작업은 archives-20050720,이란 디렉토리를 생성할 것이고 BFU 어카이브들을 포함할 것입니다. (이 파일의 이름 또는 비슷한 것은 각 릴리즈 버젼에서 바뀔 수 있습니다). root로 권한을 변경 한 후 ON 빌드 툴들을 설치 해야합니다.

# cd /tmp
# bzip2 -dc $OPEN_SOL/SUNWonbld-20050720.i386.tar.bz2 | tar xf -
# cd onbld
# pkgadd -d . SUNWonbld


간결함을 위해서 pkgadd 의 출력을 생략하였습니다. 다음 단계로 이 전의 예와 비슷한 커맨드를 사용하여 BFU를 진행합니다. (그 전에 FASTFS, BFULD, 그리고 GZIPBIN 이 올바르게 정의 되었고 /opt/onbld/bin 가 PATH에 지정되어 있는지 확인):

# bfu $OPEN_SOL/archives-20050720/`uname -p`

다음에는 충돌을 해결합니다.(이 예에서는 없음) 그리고 재부팅합니다:

bfu# acr
No conflicts to resolve.
bfu# reboot
updating /platform/i86pc/boot_archive...this may take a minute


위의 /platform/i86pc/boot_archive 이란 메세지는 x86 임을 의미합니다. 모든 작업이 순조로웠다면 머신은 새로운 빌드(이 경우에는 Build 18)을 순조롭게 부팅 시킬 것입니다. 로그인 후에 다음 명령을 이용하여 확인 할 수 있습니다.:

$ uname -a
SunOS orac 5.11 opensol-20050720 i86pc i386 i86pc


요약

이 글은 직접 빌드 한 소스를 통해 또는 opensolaris.org 사이트에서 다운로드 받은 BFU 어카이브를 통해 OpenSolaris의 버젼을 업데이트 시키는 방법에 대해 설명하였습니다. 또한 이전 글에서 BFU 작업 했었던 Build 17을 보여 주고 BFU를 이용하여 Build 17을 Build 18로 업데이트 하는 것에 대해서도 다루었습니다.

직접 빌드한 소스를 통해서 BFU를 수행하는 단계는 다음과 같습니다:

1. FASTFS, BFULD, 그리고 GZIPBIN 환경 변수가 올바르게 설정 되었음을 확인.
2. bfu 커맨드를 작업 디렉토리에서 루트 권한으로 수행 하고 커맨드 라인 옵션을 통해 어카이브의 이름을 넘겨줌. 보통 이 이름은 `pwd`/archives/`uname -p`/nightly가 될 것임.
3. acr 스크립트를 통해 충돌을 해결.
4. 아직 남아 있는 충돌을 수동으로 해결.
5. reboot 커맨드를 이용해 재부팅.(init 또는 shutdown 대신).

미리 빌드된 BFU 어카이브를 이용해 인스톨 하는 단계도 비슷함:

1. BFU 어카이브와 ON 빌드 도구들 을 opensolaris.org 사이트 또는 미러 사이트를 통해 다운로드.
2. BFU 어카이브 압축해제.
3. ON 빌드 도구들 설치.
4. FASTFS, BFULD, 그리고 GZIPBIN 환경변수가 올바로 설정 되었음을 확인.
5. 루트 권한으로 bfu 커맨드를 수행하고 2번 단계에서 압축해제 했던 BFU 어카이브의 이름을 커맨드라인 옵션으로 전달.
6. acr 스크립트를 통해 충돌을 해결.
7. 아직 남아 있는 충돌을 수동으로 해결.
8. reboot 커맨드를 이용해 재부팅.(init 또는 shutdown 대신).

이전에 경고 했듯이 한번 BFU되면 정상적인 시스템 업데이트 방법(예: 패치 또는 업그레이드 인스톨)은 사용되지 않을 것입니다: 완전히 새로운 인스톨 또는 다른 BFU의 설치가 필요합니다. 결국 BFU는 능동적은 OpenSolaris 개발자를 위한 것이라고 할 수 있습니다; 일반적인 용도로는 Solaris Express가 최고의 방법입니다.

권장하는 참고 글

opensolaris.org 웹 사이트는 OpenSolaris Developer's Reference 같은 몇가지 문서들을 가지고 있습니다. 또한 OpenSolaris Tools 커뮤니티와 썬 스튜디오 다운로드 사이트 http://opensolaris.org/os/community/too ··· tools%2F 를 참고하시기 바랍니다. 저자의 책인 Solaris Systems Programming [Teer 2005], 또한 OpenSolaris 코드의 사용자 영역 코드를 다루고자 할때 기본적인 도서 입니다. 그리고 Solaris Internals [Mauro 와 McDougall 2001] (Jim Mauro 와 Richard McDougall 지음.) 또한 OpenSolaris 커널 해커들의 기본적인 책 입니다. 커뮤니티의 블로그인 www.opensolaris.org/os/blogs/ 에도 방대한 양의 정보가 있습니다.
[Mauro 와 McDougall 2001]: Solaris Internals, ISBN 0-13-022496-0. 부가 정보는 www.solarisinternals.com/ 참고
[Teer 2005]: Solaris Systems Programming, ISBN 0-201-75039-2. 부가 정보는 www.rite-group.com/rich/ssp/ 참고


저자에 관하여

Rich Teer는 독립적인 솔라리스 컨설턴트로써 Solaris 커뮤니티에 10년 이상 활동한 멤버 입니다. 그는 베스트 셀러인 Solaris Systems Programming, 과 솔라리스에 관련한 글들로 유명합니다. OpenSolaris 파일럿 프로그램의 멤버였고 또한 현재 OpenSolaris Community Advisory Board(CAB)의 멤버이기도 합니다. 그의 웹사이트는 다음 링크에서 찾으 실 수 있습니다 www.rite-group.com/rich.