この章の説明では,CD-ROM 配布メディアからシングル・システムでオペレーティング・システムをアップデートすることを前提としています。 アップデート・インストレーションを RIS サーバから実行する場合は,『インストレーション・ガイド -- 上級ユーザ編』でリモート・サーバの使用方法を参照してください。 その後,本書で残りの手順を参照してください。
注意
実行するアップデート・インストレーションが,クラスタのローリング・アップグレードの一環である場合は,先行クラスタ・メンバでアップデート・インストレーションを実行する前に,TruCluster Server 『クラスタ・インストレーション・ガイド』 に記載されたローリング・アップグレードの準備および設定ステージを実行してください。 TruCluster Server 『クラスタ・インストレーション・ガイド』 は,TruCluster Server ドキュメント・キットに含まれています。 オンライン・ドキュメントは,次の Web サイトで入手できます。
http://h50146.www5.hp.com/products/software/oe/tru64unix/manual/
準備作業を行い,アップデート・インストレーションの準備を整えます (3.1 節)。
アップデート・インストレーションを開始するために,システムをシャットダウンしてシングルユーザ・モードにします (3.2 節)。
CD-ROM からアップデート・インストレーションを開始します (3.3 節)。
アップデート・インストレーションのオプションを選択します (3.4 節)。
アップデート・インストレーションの分析フェーズを監視します (3.5 節)。
アップデート・インストレーション処理の開始を確認します (3.6 節)。
アップデート・インストレーションの完了後,root
ユーザとしてログインします (3.7 節)。
アップデートの完了後,インストレーション・ログ・ファイルを調べます (3.8 節)。
必要に応じて,ファイルのカスタマイズ部分を手作業でマージします (3.9 節)。
必要に応じて,アップデート・インストレーション・クリーンアップ・ユーティリティを実行し,アップデート・インストレーションの結果,システムに残ったファイルを削除します (3.10 節)。
3.1 [ステップ 1]: アップデート・インストレーションの準備
アップデート・インストレーションを開始する前に,次の作業を実行してください。
ユーザへの影響をできるだけ少なくするために,CPU の使用量とユーザの作業が少ない時期にアップデート・インストレーションを行うように計画します。 たとえば,週末や,業務時間後または深夜が考えられます。
インストレーション処理中はシステムが利用できなくなるため,アップデート・インストレーションの予定を,時間的な余裕をもってユーザへ通知するようにします。 アップデート・インストレーションは,一般的に 45 分〜 120 分かかります。 新しい高速のマシン (ES,DS,GS シリーズなど) では,所要時間が短くなります。
現在のオペレーティング・システム上のユーザ・データをバックアップします。
アップデート・インストレーションを開始する前に,ユーザ・データのバックアップをとることをお勧めします。 アップデート・インストレーション処理がソフトウェア・サブセットをロードしているときに何らかの中断があると,アップデート・インストレーションは正常には完了せず,システムが不完全な状態になります。 このような場合,元のバージョンのオペレーティング・システムをリストアしてから,再度アップデート・インストレーションを実行する必要があります。 現在のオペレーティング・システムをバックアップする方法については,『システム管理ガイド』を参照してください。
本バージョンの『リリース・ノート』を読んでください。 特に,アップデート・インストレーションに関する注意事項が記述されていないか確認してください。
『リリース・ノート』には,本書に記載されていない,ソフトウェア,ファームウェア,またはハードウェアの変更点が説明されていることがありますので,参照することをお勧めします。 『リリース・ノート』には,新しいバージョンのオペレーティング・システムに追加された機能の要約も記載されています。
配布メディアをブートしてアップグレード・インストレーションを実行するために使用する CD-ROM のデバイス名を確認します。
デバイス名が分からない場合は,システムがマルチユーザ・モードで動いている間に,次のコマンドを入力して CD-ROM のデバイス名を調べます。
$ ls /dev/disk/cdrom*c /dev/disk/cdrom0c
システムで AdvFS ファイル・システムを使用している場合は,次の手順を実行して,AdvFS ファイル・ドメイン上のデータを保護します。 AdvFS ファイル・システムがない場合は,手順 6 に進みます。
shutdown
コマンドを使用して,システムをシングルユーザ・モードにします。
umount -A
コマンドを使用して,すべてのローカル・ファイル・システムをアンマウントします。
各ドメイン上で,verify
ユーティリティを実行します (ルート・ドメインをチェックする場合は,-a
フラグを指定します)。
問題があった場合は,先に進む前に修複します。
詳細は,
verify
(8)
mount
コマンドを使用して,検証済みのローカル・ファイル・システムをすべてマウントします。
quotacheck
コマンドを使用して,マウントされているローカル・ファイル・システムのクォータ (制限値) を修正します。
quotacheck
コマンドが正しく実行できない場合は,/etc/fstab
ファイルを編集してから再実行してください。
詳細は,
quotacheck
(8)
AdvFS ファイル・システムの管理についての詳細は,『AdvFS 管理ガイド』を参照してください。
コンテキスト依存シンボリック・リンク (CDSL) の内容を調べて,すべてのリンクが正しいことを確認してください。
Version 5.1 または Version 5.1A システムの CDSL が削除されている場合および破損している場合,アップデート・インストレーションが古い CDSL を新しいバージョンで上書きするため,CDSL の内容に施したカスタマイズが失われます。 CDSL の内容を確認するには,次のコマンドを入力します。
# /usr/sbin/cdslinvchk
変更,消失,置換された CDSL は,特に指定しないかぎり
/var/adm/cdsl_check_list
ファイルに記録されます。
失われた,または破損した CDSL を再度作成する方法については,『システム管理ガイド』 を参照してください。
詳細は,
cdslinvchk
(8)
システムのファームウェアを更新します。
ファームウェアの更新データは,インストレーション・キットに付属の 「Alpha Systems Firmware」CD-ROM に収められています。 ファームウェアの更新を開始するには,次の手順に従います。
システムをシャットダウンして,コンソール・モードにします。
# shutdown -h now
CD-ROM デバイスのコンソール・デバイス名を確認します。
>>> show device
システムのタイプに応じて,次のようなデバイス情報の一覧表が表示されます。
dka0.0.0.0.0 DKA0 RZ28 dkb0.0.0.1.0 DKB0 RZ28 dkc0.0.0.2.0 DKC0 RZ26 dkc100.1.0.2.0 DKC100 RZ26 dkc200.2.0.2.0 DKC200 RZ26 dkc300.3.0.2.0 DKC300 RZ26 dke100.1.0.4.0 DKE100 RRD43 <== mka500.0.0.0.0 MKA500 TLZ04 mke0.0.0.4.0 MKE0 TZ85 ewa0.0.0.6.0 EWA0 08-00-2B-2C-CE-DE
左から 3 番目の欄に
RRD
または
CD-ROM
という文字列がある行を探してください。
これらの文字列は,CD-ROM デバイスを意味します。
また,この表の 2 番目の欄は,システム上の各デバイスに割り当てられているコンソール・デバイス名を示します。
この例では,RRD43
CD-ROM のコンソール・デバイス名は
DKE100
です。
次のステップの
boot
コマンドで,このデバイス名を指定します。
ファームウェア CD-ROM をドライブに挿入し,そのドライブからブートします。
>>> boot cdrom_console_device_name
ファームウェア更新ユーティリティは自動的にシステムのタイプとモデルを識別し,システムに必要な正しいファームウェア・リビジョンを判断します。
画面上の指示に従います。
更新に含まれるファームウェアの変更点について説明する
READ-ME-FIRST
ファイルが自動的に表示されます。
ファームウェアの更新の完了時に,最低 10 秒間プロセッサの電源をオフにし,新しいファームウェアを初期化します。
ファームウェア CD-ROM の内容は,次のインターネット・サイトから anonymous FTP (ファイル転送プロトコル) で入手することもできます。
http://ftp.digital.com/pub/Digital/Alpha/firmware/readme.html
また,ファームウェアの更新データは,インターネット上のサーバ
ftp.europe.digital.com
から anonymous FTP で入手することもできます。
3.2 [ステップ 2]: シャットダウンによるシングルユーザ・モードへの移行
アップデート・インストレーションは,シングルユーザ・モードから実行します。
root
としてログインするか,su
コマンドを使用して,スーパユーザ特権を得ます。
次の例は,スーパユーザになる方法と,スーパユーザになってからシステムをシャットダウンしてシングルユーザ・モードにする方法を示します。
# su - password: # shutdown +10 Please log out--ready to update system
この例では,+10
と指定することで,システムを 10 分後にシャットダウンし,Please log out--ready to update system
というメッセージをすべてのログイン・ユーザに送ります。
注意
システムがコンソール・モード・プロンプト (
>>>
) の場合,マルチユーザ・モードでブートしてからシャットダウンしてシングルユーザ・モードにしなければなりません。 システムをブートして直接シングルユーザ・モードにしてはいけません。
システムがシングルユーザ・モードになると,次のメッセージが表示されます。
Halting processes ... INIT: SINGLE-USER MODE #
3.3 [ステップ 3]: アップデート・インストレーションの開始
アップデート・インストレーションが完了するまでには,45 〜 120 分かかります。 ただし,DS シリーズや GS シリーズなどの新しい高速のマシンでは,少し短縮されます。 実際にかかる時間は,プロセッサ・タイプ,CD-ROM ドライブの速度,アップデートするソフトウェア・サブセットの数によって左右されます。
ローカル・ファイル・システムをマウントします。
# /sbin/bcheckrc
bcheckrc
コマンドは,mount -a
コマンドを呼び出します。
これにより,標準の UNIX ファイル・システム (/
,usr
,var
) だけでなく,/etc/fstab
ファイルにリストされているすべてのファイル・システムがマウントされます。
bcheckrc
コマンドは,UNIX ファイル・システム (UFS) に対して
fsck
も実行し,必要に応じて
LSM
(Logical Storage Manager) を起動します。
fsck
によって
/
(root) パーティションに問題が見つかると,システムはシャットダウンした後リブートして,その問題を修正します。
「Operating System, Volume 1」 の CD-ROM をドライブに挿入します。
次の構文で
/sbin/installupdate
コマンドを入力して,アップデート・インストレーションを開始します。
/sbin/installupdate
[-u
]
[-nogui
]
{location
}
各オプションについて,以下に説明します。
省略可能な
-u
フラグを指定すると,アップデート・インストレーションが自動 (unattended) モードで実行されます。
自動モードでは,アップデート・インストレーションで問題 (ディスク・スペース不足,ファイル・タイプの矛盾,レイヤード・プロダクトのブロックなど) が発生しないかぎり,ユーザの介入を必要としません。
ただし例外として,WLS
ソフトウェアをアップデートする場合は,CD-ROM の交換が必要になります。
-u
フラグを指定すると,すべてのカーネル構成要素を使用してカーネルが構築されます。
また,旧ファイルを保管することはできません。
分析フェーズでファイル・タイプの矛盾が検出されず,アップデート・インストレーションを実行するために十分な空きディスク・スペースがシステムにあり,ブロック状態になるレイヤード・プロダクトがインストールされていない場合,次の作業は,3.7 節 で説明した方法で,アップデートしたシステムにログインすることです。 アップデート・インストレーションが正常に完了しない場合は,3.11.1 項 を参照してください。
システムがグラフィック機能を備えている場合でも,オプションの
-nogui
フラグを指定すると,テキスト・ベース・インタフェースで実行できます。
必須の location 引数には,ソフトウェアのソースを指定します。 location には,次のいずれかを指定できます。
Version 5.1B の配布メディアが収められているローカル・ディスクまたは CD-ROM ドライブ (たとえば,/dev/disk/cdrom0c
)。
オペレーティング・システム・メディアがマウントされているローカルのマウント・ポイント。
たとえば
/mnt
など。
Version 5.1B のオペレーティング・システムをサービスしている
RIS サーバの名前。
後にコロンを付加します (たとえば,server1:
)。
アップデート・インストレーションを開始するコマンドの例を以下に示します。 状況に合ったコマンドを使用してください。
CD-ROM デバイス
cdrom0c
から自動アップデート・インストレーションを開始するには,次のコマンドを使用します。
# /sbin/installupdate -u /dev/disk/cdrom0c
すでにマウント・ポイント
/cdrom
にマウントされている CD-ROM デバイスからアップデート・インストレーションを開始するには,次のコマンドを使用します。
# /sbin/installupdate /cdrom
グラフィカル・インタフェースを使用しないで,テキスト・ベース・インタフェースで CD-ROM からアップデート・インストレーションを開始するには,次のコマンドを使用します。
# /sbin/installupdate -nogui /dev/disk/cdrom0c
server1
という名前の
RIS サーバからアップデート・インストレーションを開始するには,次のコマンドを使用します。
# /sbin/installupdate server1:
アップデート・インストレーション処理は,3.4 節の説明に続きます。
3.4 [ステップ 4]: アップデート・インストレーション・オプションの選択
アップデート・インストレーションの開始後に何が表示されるかは,システムがグラフィック表示機能を備えているかどうかによって決まります。
システムがグラフィック表示機能を備えている場合は,図 3-1
に示す「Update Installation」ダイアログ・ボックスが表示されます。
グラフィカル・インタフェースでは,アップデート・インストレーション処理の各ダイアログ・ボックスやフィールドについて説明するオンライン・ヘルプが使用できます。
図 3-1: 「Update Installation」メイン・ウィンドウ
システムがグラフィック機能を備えていない場合や,コマンド行で
-nogui
フラグを指定した場合は,次のような画面が表示されます。
Update Installation has detected the following update installable products on your system: Tru64 UNIX Operating System ( Rev nnn) These products will be updated to the following versions: Tru64 UNIX Version 5.1B Operating System (Rev nnn) It is recommended that you update your system firmware and perform a complete system backup before proceeding. A log of this update installation can be found at /var/adm/smlogs/update.log. Do you want to continue the Update Installation? (y/n) []: Do you want to select optional kernel components? (y/n) [n]: Do you want to archive obsolete files? (y/n) [n]:
アップデート・インストレーションを最初に起動したときに決定しなければならない事項を
表 3-1
に示します。
オプションを片方だけ選択することも,両方選択することも,両方とも選択しないこともできます。
表 3-1: 初期画面でのアップデート・インストレーション・オプション
オプション | 説明 |
オプションのカーネル構成要素の選択
(select optional kernel components ) |
オプションのカーネル構成要素を使用して構築されたカスタム・カーネルを現在のシステムで実行している場合や,新しいカーネルをカスタマイズしたい場合には,このオプションを選択します。 このオプションを選択すると,カーネルに組み込むオプションのカーネル構成要素を選択することができます。 このオプションを選択しなかった場合は,インストールされているソフトウェアを実行するために必要な必須カーネル構成要素だけで新しいカーネルが構築されます。 |
旧ファイルの保管
(archive obsolete files ) |
アップデート・インストレーションによって自動的に削除される前に旧ファイルを保管しておきたい場合は,このオプションを選択します。 旧ファイルとは,Version 5.1 または Version 5.1A では提供されていて,Version 5.1B では必要でなくなったファイルのことです。 このオプションを選択すると,アップデート・インストレーションの分析フェーズになったときに,旧ファイルのリストが表示されます。 このとき,保管するファイルを 1 つ以上選択し,アーカイブ・ファイルに付ける名前を指定することができます。 このアーカイブ・ファイルは,いつでも削除することができます。 このオプションを選択しなかった場合は,旧ファイルは,保管するかどうかの確認なしにシステムから削除されます。 |
注意
この章の以降の説明は,グラフィカル・ユーザ・インタフェースとテキスト・ベース・ユーザ・インタフェースの両方に適用されます。 ただし,インタフェースの例を両方とも記載しているわけではありません。 グラフィカル・ユーザ・インタフェースの画面のみを使用して,アップデート処理とユーザの操作を示します。 テキスト・ベース・インタフェースを使用する場合も,手順は同じです。
アップデート・インストレーション・オプションの選択を終えると,アップデート・インストレーション・プロセスは現在のシステムの分析を開始します。
システムがグラフィック機能を備えている場合,分析フェーズは
図 3-2
に示すダイアログ・ボックスで開始されます。
図 3-2: アップデート・インストレーションの「Preload Analysis」ダイアログ・ボックス
このダイアログ・ボックスのチェック・マークは,その分析ステップが完了したことを示しています。 ダイアログ・ボックスの下部に表示される進行インジケータは,強調表示されている分析ステップに対応しています。
以降の項では,各分析ステップの詳細について説明します。 また,ユーザの対処が必要な場合は,必要となるユーザ対処についても説明します。
レイヤード・ソフトウェアの矛盾の検索 (3.5.1 項)
インストール済みソフトウェアの確認 (3.5.2 項)
カーネル構成要素の決定とオプションの選択処理 (3.5.3 項)
ファイル・タイプの矛盾の検索 (3.5.5 項)
アップデート・インストレーションに影響を与えるレイヤード・プロダクトは,2 種類あります。1 つは,
アップデート・インストレーションは実行できるが,後で再インストールが必要になるレイヤード・ソフトウェア・プロダクト,もう 1 つは,アップデート・インストレーションを実行するためには削除しなければならないレイヤード・ソフトウェア・プロダクトです。
3.5.1.1 ソフトウェア再インストールの警告
新しいバージョンのオペレーティング・システムにアップデートした後で再インストールが必要になるレイヤード・ソフトウェア・プロダクトがアップデート・インストレーションで検出された場合,図 3-3 に示すダイアログ・ボックスが表示されます。 ユーザは,アップデート・インストレーションを中止して手作業でこのソフトウェアを削除するか,あるいはアップデート・インストレーションを続行するかを選択できます。
レイヤード・ソフトウェア・プロダクトを削除しないで続行した場合は,アップデート・インストレーションの完了後,そのソフトウェアをテストしてください。
オペレーティング・システムを使用する上で重要なレイヤード・ソフトウェア・プロダクトについては,新しいバージョンのオペレーティング・システムと互換性がありサポートされているバージョンを再インストールすることをお勧めします。
図 3-3: 「Software Reinstallation Warning」ダイアログ・ボックス
3.5.1.2 矛盾するソフトウェアが検出されたためにアップデート・インストレーションが続行できなくなる場合
アップデート・インストレーションの中止につながるレイヤード・ソフトウェア・プロダクトの矛盾をアップデート・インストレーションが検出した場合,図 3-4 に示すダイアログ・ボックスが表示されます。 ユーザは,そのプロダクトを削除してアップデート・インストレーションを続行するように指示するか,またはアップデート・インストレーションを中止することができます。 この矛盾するソフトウェアを削除しないかぎり,システムを新しいバージョンのオペレーティング・システムにアップデートすることはできません。 この時点でアップデート・インストレーションの終了を選択した場合は,システムは変更されません。 矛盾するソフトウェアが新しいバージョンのオペレーティング・システムではサポートされておらず,そのソフトウェアがシステムにとって重要な場合は,アップデート・インストレーションを続行しないでください。
注意
削除操作は,すぐに実行されます。 このため,後でアップデート・インストレーションを取り消しても,削除したソフトウェアは復元できません。
図 3-4: 「Conflicting Software Found」ダイアログ・ボックス
分析ステップのこの部分では,アップデート・インストレーション・プロセスは,何をアップデートしなければならないかを把握するために,どのソフトウェアがインストールされているかを調べます。
ワールドワイド言語サポート (WLS) ソフトウェアがインストールされている場合は,図 3-2 に示す「Preload Analysis」ダイアログ・ボックスに分析ステップ「Determining Installed Worldwide Language Support Software」が追加表示されます。
アップデート・インストレーションを CD-ROM から実行している場合,システムに WLS ソフトウェアがインストールされていれば,Version 5.1B の WLS ソフトウェア・メディアの位置 (ローカル・ディスク,RIS サーバ,または CD-ROM デバイス名) を指定するように求められます。 システムのリブート後,いつ WLS メディアへの交換を促すかは,アップデート・インストレーション・プロセスが判断します。
注意
ローリング・アップグレードの一環として先行クラスタ・メンバでアップデート・インストレーションを実行する場合は,RIS 領域または CD-ROM に TruCluster Server ソフトウェアがなくてもかまいません。
clu_upgrade -preinstall
コマンドで先行メンバの/var/adm/update/TruClusterKit
領域にキットがすでにコピーされ,アップデート・インストレーションでソフトウェアが使用できるようになっているためです。
オプションのカーネル構成要素をカーネルに組み込むことを選択した場合 (表 3-1 の説明を参照) は,図 3-5 に示す「Kernel Configuration」ダイアログ・ボックスを使用して,カーネルに組み込む,オプションのカーネル構成要素を選択します。 以前にオプションのカーネル構成要素をカーネルに組み込んでいる場合は,ここでもその構成要素を選択しなければなりません。 アップデート・インストレーション・プロセスには,現在のカーネルの内容は分かりません。 カーネル構成要素を選択するには,選択したい構成要素をクリックし,[Select] をクリックします。 選択がすべて終わったら,[OK] をクリックします。
この時点でカーネル構成要素の選択を取り消すと,アップデート・インストレーションは,インストールされているソフトウェア・サブセットに関連する必須のカーネル構成要素だけを使用してカーネルを構築します。
図 3-5: 「Kernel Configuration」ダイアログ・ボックス
3.5.4 特殊な構成オプションを手作業でカーネルに追加する
アップデート・インストレーションでは,必須のカーネル構成要素すべてと,先ほど選択したオプションの構成要素をサポートする,基本カーネル構成ファイルが提供されます。 ただし,アップデート・インストレーションでは,カーネル構成ファイルに追加した特殊な構成オプションやカスタム構成オプションは継承されません。
カーネル構成ファイルを手作業で編集した場合や,非標準のカーネル・オプション,擬似デバイス,コントローラ,またはその他の変更を組み込むレイヤード・プロダクトをインストールした結果,カーネル構成ファイルが編集されている場合は,それらのオプション,擬似デバイス,コントローラ,またはその他の変更を,新しいカーネル構成ファイル (/sys/conf/host_name
) に取り込む必要があります。
テキスト・ベース・インタフェースを使用している場合は,アップデート・インストレーション時にカーネル構成ファイルを編集することができます。
テキスト・ベース・インタフェースを使用していない場合は,アップデート・インストレーションの完了後にこのファイルを編集してから,
doconfig
(8)3.5.5 ファイル・タイプの矛盾の検索
アップデート・インストレーションでは,アップデート後のバージョンのオペレーティング・システムと互換性のないファイル・タイプを検索します。
オペレーティング・システムと一緒に出荷されるファイルは,システム・ファイルとも呼ばれ,いくつかのファイル・タイプに分類されます。
ファイルは,file
,directory
,hard link
,symbolic link
,block device
,または
pipe
のいずれかに分類できます。
アップデート・インストレーション・プロシージャは,システム・ファイルのタイプが,以前のバージョンのベース・オペレーティング・システムが出荷されたときと同じであることを前提としています。
ファイル・タイプが変更されている場合は,ファイル・タイプの矛盾となります。
ファイル・タイプの矛盾には,次の 2 種類があります。
一部のファイル矛盾ではアップデート・インストレーションが中止されるため,矛盾を解決してからアップデート・インストレーションを再開する必要があります。
この他のファイル矛盾は深刻なものではなく,矛盾を解決しないでアップデート・インストレーションを続行することができます。
この機能は,インストールするソフトウェア・プロダクトの完全性を保つために提供されています。
どちらの場合も,アップデート・インストレーションでは矛盾が検出され,矛盾の解決に必要な対処方法がユーザに通知されます。
3.5.5.1 アップデートが中止されるファイル・タイプ矛盾
深刻なファイル・タイプ矛盾が発生すると,システムをアップデートしないでアップデート・インストレーションを終了する必要があります。 アップデート・インストレーションを続行すると,システムが壊れることがあります。 このような深刻な矛盾が検出された場合は,手作業で矛盾を解決してから,アップデート・インストレーションを再開しなければなりません。 次のようなファイル・タイプ矛盾が検出された場合,アップデート・インストレーションは続行できません。
directory
タイプとして出荷されたファイルが,file
タイプに変更されている。
directory
タイプとして出荷されたファイルが,symbolic link
タイプに変更されている。
symbolic link
タイプとして出荷されたファイルが,directory
タイプに変更されている。
たとえば,Version 5.1 または Version 5.1A でディレクトリとして出荷されたファイルをシンボリック・リンクに変更した場合,同じファイルが Version 5.1B でもディレクトリとして出荷されると,アップデート・インストレーション・プロシージャはこの違いを検出し,図 3-6
に示すダイアログ・ボックスを表示します。
図 3-6: 「File Type Conflict」ダイアログ・ボックス
3.5.5.1 項で説明したファイル・タイプ矛盾以外は,深刻でないファイル・タイプ矛盾です。
アップデート・インストレーション処理は,ファイル・タイプが変更されているファイルのコピーを
.PreUPD
という拡張子のファイル (たとえば,/etc/hosts.PreUPD
) に保存することにより,自動的に矛盾を解決します。
新しいバージョンのオペレーティング・システムがロードされると,オリジナルのファイル (たとえば,/etc/hosts
) は,オペレーティング・システムの一部として出荷された新しいバージョンに置き換えられます。
つまり,このファイルのファイル・タイプは,新しいバージョンのオペレーティング・システムとして出荷されたファイル・タイプに変更されます。
ファイル・タイプが変更されたファイル内のカスタマイズは,アップデート・インストレーション完了後に,.PreUPD
バージョンから新しいバージョンのファイルに,手作業でマージする必要があります。
図 3-7に,深刻でないファイル・タイプ矛盾が検出された場合に表示されるダイアログ・ボックスを示します。
図 3-7: 「File Type Conflict Warning」ダイアログ・ボックス
旧ファイルとは,Version 5.1 または Version 5.1A のオペレーティング・システムでは提供されていて,Version 5.1B には含まれていないファイルのことです。
アップデート・インストレーション・プロシージャは,自動的に旧ファイルを探して削除します。
表 3-1で説明した旧ファイル保管オプションを選択すると,旧ファイルを 1 つの
.tar
ファイルに保存できます。
また,gzip
ユーティリティを使用して,この
tar
ファイルを圧縮することもできます。
省略時のファイル名は,/var/adm/update/backup.tar
です。
注意
ファイルを保管したかどうかに関係なく,アップデート・インストレーション・プロシージャは分析フェーズの完了後に旧ファイルを削除します。 図 3-8 に,旧ファイルの選択と保管に使用するダイアログ・ボックスを示します。
図 3-8: 「Archive Obsolete Files」ダイアログ・ボックス
Version 5.1B のオペレーティング・システムは,Version 5.1 または Version 5.1A より多くのディスク・スペースを必要とします。 アップデート・インストレーション・プロシージャは,新しいバージョンのソフトウェア用に十分なスペースがあるかどうか,また処理用に十分な一時スペースがあるかをどうかを調べます。
アップデート・インストレーション・プロシージャは,十分なディスク・スペースがないと判断すると,ディスク・スペースの状態と,ディスク・スペースを回復するためのオプションを表示します。
図 3-9
に,ディスク・スペースの回復に使用するダイアログ・ボックスを示します。
図 3-9: 「Recover Disk Space」ダイアログ・ボックス
システムのクリーンアップ
アプリケーションやシステムがクラッシュするたびに,core
という名前のクラッシュ・ファイルが作成されます。
このファイルはサイズが大きいことが多く,クラッシュの後で常に削除しておかないと,かなりの量のディスク・スペースが占有されます。
システムやアプリケーションのクラッシュ後にファイルのクリーンアップを行っていない場合は,この操作で必要なディスク・スペースを確保できることがあります。
アップデート・インストレーション・プロシージャは,/sys/HOST_NAME
ディレクトリと
/var/adm/crash
ディレクトリ内の余分なカーネル・ファイル (vmunix.*
という名前のファイル) と,/
,/usr
,/var
ファイル・システム内の
core
ファイルを探します。
アップデート・インストレーション・プロシージャはカスタマイズされているシステム・ファイルを探し,.PreUPD
という拡張子を持つファイルにコピーすることにより,そのファイルを保護します。
core
ファイルと余分な
vmunix
ファイルを削除しても十分なディスク・スペースを確保できない場合は,必要に応じて
.PreUPD
ファイルを削除します。
[Remove .PreUPD Files
] をクリックするとダイアログ・ボックスが表示され,削除するファイルを選択できます。
注意
ここで
.PreUPD
ファイルを削除すると,手作業で変更内容をマージするときに参照できなくなります。.PreUPD
ファイルは,変更されていて保護されていないシステム・ファイルの唯一のバックアップ・コピーです。
使用されていないソフトウェア・サブセットがあれば,それらを削除します。
この時点で削除したソフトウェア・サブセットは,アップデートされません。
[Remove Software Subsets
] をクリックすると,図 3-10
に示すダイアログ・ボックスが表示されます。
ソフトウェア・サブセットを削除してディスク・スペースを回復すると,アップデート・インストレーション処理は,「Total Needed」カテゴリに表示されているディスク容量を再計算します。 アップデートを続行して,現在インストールされているソフトウェア・サブセットに基づいてディスク容量を再計算させてください。
注意
setld
コマンド以外のコマンドで,インストール済みのベース・オペレーティング・システムまたは WLS ソフトウェアの一部のファイルを削除しても,空きスペースは増えません。 これは,アップデート・インストレーション・プロシージャは,削除した古いファイルが新しいバージョンのファイルに置き換えられることを計算にいれているためです。
図 3-10: 「Remove Subsets」ダイアログ・ボックス
各ファイル・システムで利用できるディスク・スペースが,必要なディスク・スペースより大きくなるまで,これらのオプションを使用して空きスペースを広げてください。
これらのオプションを使用しても必要な空きスペースが確保できない場合は,ファイル・システムのレイアウトを変更するか,フル・インストレーション手順で推奨ディスク・パーティションを使用してフル・インストレーションを実行することにより,インストールされているソフトウェアに対応できるだけの十分な大きさのディスク・パーティションにします。
3.6 [ステップ 6]: アップデート・インストレーション処理の開始の確認
分析フェーズが完了したら,アップデート・インストレーション処理の開始を確認します。
グラフィカル・ユーザ・インタフェースを使用している場合,図 3-11
のダイアログ・ボックスを使用して確認を行います。
図 3-11: 「Ready to Begin Update」ダイアログ・ボックス
次のいずれかを選択できます。
選択されている項目がすべて正しければ,[OK] をクリックして選択を保存し,システムのアップデートを開始します。 アップデートの開始を確認すると,システムの変更が開始され,元に戻すことはできなくなります。
注意
ソフトウェア・サブセットのロード中に,何らかの方法 (電源コードを抜く,停止 (halt) ボタンを押すなど) でアップデート・インストレーションを停止させると,オペレーティング・システムに重大な損傷を与え,オペレーティング・システムが使用できなくなることがあります。 アップデート・インストレーションをやり直す前に,バックアップ媒体からオペレーティング・システムをリストアしなければならないことがあります。
アップデート・インストレーション・プロセスを誤って停止しないように,動作の中断に使用するキー・シーケンス [Ctrl/c] は,ソフトウェア・サブセットをロードするフェーズでは無効になっています。
この時点でアップデート・インストレーションを続行したくない場合は,[Exit Update] を選択します。 [Exit Update] を選択すると,システムをマルチユーザ・モードに戻すことができます。 システムはアップデート前の状態に戻ります (ただし,ディスク・スペースの回復処理中に削除したファイルを除く)。
アップデート・インストレーションは,通常,45 〜 120 分で完了します。
ただし,DS シリーズや GS シリーズなどの新しい高速のマシンでは,少し短縮されます。
実際にかかる時間は,プロセッサ・タイプ,アップデートされるソフトウェア・サブセットの数,アップデート・インストレーションの実行に使用されるメディアのタイプ (CD-ROM あるいはリモート・サーバ),CD-ROM ドライブの速度 (CD-ROM を使用する場合),ネットワークの通信量 (リモート・サーバを使用する場合) によって左右されます。
3.7 [ステップ 7]: システムへのログイン
アップデート・インストレーションが完了したら,root
ユーザとしてログインして3.8 節と3.9 節で説明するインストール後の作業を実行します。
この作業は,root
ユーザのみ実行できます。
初めてログインしたときにどのような処理が行われるかは,グラフィック・ワークステーションの場合と,グラフィック機能のない端末の場合で異なります。
グラフィック・ワークステーションの場合は,共通デスクトップ環境 (CDE) のログイン・ウィンドウが表示されます。
グラフィックス機能のないワークステーションの場合は,login
プロンプトに対してユーザ名
root
を入力し,password
プロンプトに対して
root
ユーザのパスワードを入力して,ログインします。
注意
Version 5.0 以降のオペレーティング・システムでは,ディスクとテープのデバイス特殊ファイル名の命名規則が,以前のバージョンのオペレーティング・システムと異なります。 アップデート・インストレーション処理の結果,ユニット番号が再編成されることがあります。 システムの新旧デバイス名の対応を調べたい場合は,
/etc/dfsl.dat
ファイルを参照してください。デバイス命名規則と,アップデート・インストレーション処理での命令規則の適用方法については,A.5 節を参照してください。
3.8 [ステップ 8]: アップデート・インストレーションのログ・ファイルのチェック
アップデート・インストレーションの実行状況は,参照できるように,ログ・ファイルに保存されます。
インストレーションと構成に関するデータは,以前のアップデート・インストレーション時から使用されているログ・ファイルに追加されます。
アップデート中にエラーがなく,すべてのファイルが正しくマージされたことを確認するために,アップデートの完了後,ログ・ファイルを調べてください。
ログ・ファイルは,以下の場所にあります。
表 3-2: アップデート・インストレーションのログ・ファイル
説明 | ファイル名 |
アップデート・インストレーションのログ | /var/adm/smlogs/update.log |
ソフトウェア構成に関する情報 | /var/adm/smlogs/it.log |
カスタマイズされたファイルのリスト | /var/adm/smlogs/upd_custom_files |
失敗したマージのリスト | /var/adm/smlogs/upd_mergefail_files |
付録 F
では,アップデート・インストレーション中に作成されるすべてのログ・ファイルの内容を説明しています。
アップデート・インストレーション中に,カスタマイズされたファイルやマージに失敗したファイルが検出されなかった場合は,該当するログ・ファイルにはデータは入っていません。
3.9 [ステップ 9]: 必要に応じてカスタマイズ部分をマージする
アップデート・インストレーションでは,特定のカスタマイズ部分は自動的にはマージされず,それらのカスタマイズ部分を手作業で新しいファイルに追加しなければならない場合があります。 手作業でマージを行うには,新しいバージョンのシステム・ファイルをテキスト・エディタで編集して,カスタマイズ部分を組み込みます。 カスタマイズ部分を新しいバージョンにマージできるように,以下の情報が保存されます。
アップデート・インストレーションが完了したら,保存されたファイルの名前が
/var/adm/smlogs/upd_custom_files
ファイルに記録されていないか探してください。
記録されている各ファイルの新しいバージョンを編集して,カスタマイズ部分を組み込みます。
各ファイルの以前のバージョンは,filename.PreUPD
として保存されています。
カーネル構成ファイル
以前のバージョンのオペレーティング・システムでカーネル構成ファイル
/sys/conf/HOSTNAME
をカスタマイズした場合は,カーネル構成ファイルを編集する必要があります。
カーネル構成ファイルの保存版は,/sys/conf/HOSTNAME.bck
に置かれます。
この後,新たに加えた変更を有効にするため,最適化カーネルを再構築する必要があります。
最適化カーネルの構築についての詳細は,
doconfig
(8)
失敗したマージ
アップデート・インストレーション時にマージできなかったファイルがある場合は,画面上にエラー・メッセージが表示されます。
マージに失敗したファイルのログは,/var/adm/smlogs/upd_mergefail_files
ファイルに記録されます。
update.log
ファイルと
it.log
ファイルを見て,マージ・エラーを確認してください。
そして,マージできなかったファイルを手作業で編集して,カスタマイズ部分を追加してください。
アップデート前のカスタマイズ・ファイルは,参照できるように,filename.PreMRG
というファイル命名規則で保存されます。
手作業でのマージ作業がすべて完了すると,システムは利用可能な状態になります。
この時点で,Version 5.1B の配布メディアで提供されている,オプションの追加ソフトウェア・サブセットをインストールすることができます。
オプションのソフトウェア・サブセットのインストール方法については,第 9 章を参照してください。
3.10 [ステップ 10]: アップデート・インストレーション・クリーンアップ・ユーティリティの実行 (オプション)
アップデート・インストレーションで作成されたバックアップ・ファイル
.PreMRG
と
.PreUPD
を削除または保管するには,アップデート・インストレーション・クリーンアップ・ユーティリティを使用します。
アップデート処理中にマージに失敗したファイルがある場合は,新しいバージョンのファイルへカスタマイズ内容をマージするときの参考として,これらのバックアップ・ファイルを使用することができます。
手作業でのマージがすべて完了すると,.PreMRG
ファイルと
.PreUPD
ファイルは不要になります。
アップデート・インストレーション実行後のアップデート・インストレーション・クリーンアップ・ユーティリティの実行ステップは,オプションです。
このようなバックアップ・ファイルが占めているディスク・スペースを回復したい場合は,このユーティリティを使用してください。
これらのファイルを保管する場合,保管先には,tar
コマンドがサポートする任意の保管先 (ファイル,テープ・デバイス,またはディスク) を指定できます。
クラスタのローリング・アップグレードを実行する際は,クリーン・ステージの一環として Update Administration Cleanup Utility を実行することもできます。 Update Installation Cleanup ユーティリティは,すべてのクラスタ・メンバがロールされ,ローリング・アップグレードが完了するまでは実行しないでください。 ローリング・アップグレードの実行中にクリーンアップ・ユーティリティを実行しようとすると,このユーティリティはメッセージを出力します。
次のいずれかの方法を使用して,アップデート・インストレーション・クリーンアップ・ユーティリティを起動します。
SysMan Menu
(/usr/sbin/sysman
) から,次の項目を選択する。
ソフトウェア・ブランチ (Software branch)
インストレーション・ブランチ (Installation branch)
OS アップデート後のクリーンアップ作業 (updadmin)
CDE のフロント・パネルで,SysMan アプリケーションのアイコンから [Software Management] を選択する。 詳細説明が必要な場合は,グラフィカル・ユーザ・インタフェースで提供されているオンライン・ヘルプを参照してください。
コマンド行で
/usr/sbin/updadmin
と入力する。
詳細は,
updadmin
(8)
エラーの中には,アップデート・インストレーション処理が停止し,ユーザの介入を必要とするものがあります。 このようなエラーは,アップデートでの次の時点で発生することがあります。
ロード前の分析フェーズであれば,どこでアップデート・インストレーションが失敗しても,回復することができます。 次のコマンドを実行することによって,システムをマルチユーザ・モードに戻すことができます。
# init 3
エラー・メッセージで報告されたエラーを修正して,アップデート・インストレーション・プロセスを再スタートしてください。
3.11.2 ソフトウェア・サブセットのロードの失敗
ロード処理中に,ネットワークの中断,ハードウェアの障害,ファイル確認エラーなどが発生すると,ロードできないソフトウェア・サブセットが出る可能性があります。
オプションのソフトウェア・サブセットがロードできない場合は,アップデート・インストレーションの完了後に
setld
コマンドを使用してインストールすることができます。
必須ソフトウェア・サブセットのロードに失敗した場合は,アップデート・インストレーション・プロシージャは終了します。
この場合,システムは使用できない状態になっている可能性があります。
このような状態の場合は,オペレーティング・システムのバックアップ・バージョンをリストアしてから,アップデート・インストレーションを再実行する必要があります。
ただし,必須ソフトウェア・サブセット
OSFBASE540
のインストールが成功している場合は,オペレーティング・システムのバックアップ・バージョンをリストアしなくても,アップデート・インストレーションを再実行できることがあります。
カーネルのレイヤード・プロダクトと新しいバージョンのオペレーティング・システムに互換性がないために,アップデート・インストレーションの最後で,最適化カーネルの構築が失敗することがあります。
このような場合,システムは,レイヤード・プロダクトのサポートを含まないカーネルを再構築します。 次の手順に従って,レイヤード・プロダクトのサポートを含むカーネルを構築してください。
カーネル構築の失敗の原因が記録されているファイル,/var/adm/smlogs/it.log
を調べます。
setld
コマンドを使用して,失敗の原因となったレイヤード・プロダクトを削除します。
setld
コマンドを使用して,最新バージョンのレイヤード・プロダクトを再インストールします。
/usr/sbin/doconfig
コマンドを使用して,レイヤード・プロダクトのサポートが組み込まれた新しいカスタム・カーネルを構築します。