3    アップデート・インストレーションの実行

この章の説明では,CD-ROM 配布メディアからシングル・システムでオペレーティング・システムをアップデートすることを前提としています。 アップデート・インストレーションRIS サーバから実行する場合は,『インストレーション・ガイド -- 上級ユーザ編』でリモート・サーバの使用方法を参照してください。 その後,本書で残りの手順を参照してください。

注意

実行するアップデート・インストレーションが,クラスタのローリング・アップグレードの一環である場合は,先行クラスタ・メンバでアップデート・インストレーションを実行する前に,TruCluster Server 『クラスタ・インストレーション・ガイド』 に記載されたローリング・アップグレードの準備および設定ステージを実行してください。 TruCluster Server 『クラスタ・インストレーション・ガイド』 は,TruCluster Server ドキュメント・キットに含まれています。 オンライン・ドキュメントは,次の Web サイトで入手できます。


http://h50146.www5.hp.com/products/software/oe/tru64unix/manual/

アップデート・インストレーション手順の要約

  1. 準備作業を行い,アップデート・インストレーションの準備を整えます (3.1 節)。

  2. アップデート・インストレーションを開始するために,システムをシャットダウンしてシングルユーザ・モードにします (3.2 節)。

  3. CD-ROM からアップデート・インストレーションを開始します (3.3 節)。

  4. アップデート・インストレーションのオプションを選択します (3.4 節)。

  5. アップデート・インストレーションの分析フェーズを監視します (3.5 節)。

  6. アップデート・インストレーション処理の開始を確認します (3.6 節)。

  7. アップデート・インストレーションの完了後,root ユーザとしてログインします (3.7 節)。

  8. アップデートの完了後,インストレーション・ログ・ファイルを調べます (3.8 節)。

  9. 必要に応じて,ファイルのカスタマイズ部分を手作業でマージします (3.9 節)。

  10. 必要に応じて,アップデート・インストレーション・クリーンアップ・ユーティリティを実行し,アップデート・インストレーションの結果,システムに残ったファイルを削除します (3.10 節)。

3.1    [ステップ 1]: アップデート・インストレーションの準備

アップデート・インストレーションを開始する前に,次の作業を実行してください。

  1. ユーザへの影響をできるだけ少なくするために,CPU の使用量とユーザの作業が少ない時期にアップデート・インストレーションを行うように計画します。 たとえば,週末や,業務時間後または深夜が考えられます。

    インストレーション処理中はシステムが利用できなくなるため,アップデート・インストレーションの予定を,時間的な余裕をもってユーザへ通知するようにします。 アップデート・インストレーションは,一般的に 45 分〜 120 分かかります。 新しい高速のマシン (ES,DS,GS シリーズなど) では,所要時間が短くなります。

  2. 現在のオペレーティング・システム上のユーザ・データをバックアップします。

    アップデート・インストレーションを開始する前に,ユーザ・データのバックアップをとることをお勧めします。 アップデート・インストレーション処理がソフトウェア・サブセットをロードしているときに何らかの中断があると,アップデート・インストレーションは正常には完了せず,システムが不完全な状態になります。 このような場合,元のバージョンのオペレーティング・システムをリストアしてから,再度アップデート・インストレーションを実行する必要があります。 現在のオペレーティング・システムをバックアップする方法については,『システム管理ガイド』を参照してください。

  3. 本バージョンの『リリース・ノート』を読んでください。 特に,アップデート・インストレーションに関する注意事項が記述されていないか確認してください。

    リリース・ノート』には,本書に記載されていない,ソフトウェア,ファームウェア,またはハードウェアの変更点が説明されていることがありますので,参照することをお勧めします。 『リリース・ノート』には,新しいバージョンのオペレーティング・システムに追加された機能の要約も記載されています。

  4. 配布メディアをブートしてアップグレード・インストレーションを実行するために使用する CD-ROM のデバイス名を確認します。

    デバイス名が分からない場合は,システムがマルチユーザ・モードで動いている間に,次のコマンドを入力して CD-ROM のデバイス名を調べます。

    $ ls /dev/disk/cdrom*c
    /dev/disk/cdrom0c
    

  5. システムで AdvFS ファイル・システムを使用している場合は,次の手順を実行して,AdvFS ファイル・ドメイン上のデータを保護します。 AdvFS ファイル・システムがない場合は,手順 6 に進みます。

    1. root としてログインするか,su コマンドを使用して,スーパユーザ特権を得ます。

    2. shutdown コマンドを使用して,システムをシングルユーザ・モードにします。

    3. umount -A コマンドを使用して,すべてのローカル・ファイル・システムをアンマウントします。

    4. 各ドメイン上で,verify ユーティリティを実行します (ルート・ドメインをチェックする場合は,-a フラグを指定します)。 問題があった場合は,先に進む前に修複します。 詳細は, verify(8) を参照してください。

    5. mount コマンドを使用して,検証済みのローカル・ファイル・システムをすべてマウントします。

    6. quotacheck コマンドを使用して,マウントされているローカル・ファイル・システムのクォータ (制限値) を修正します。 quotacheck コマンドが正しく実行できない場合は,/etc/fstab ファイルを編集してから再実行してください。 詳細は, quotacheck(8) を参照してください。

    AdvFS ファイル・システムの管理についての詳細は,『AdvFS 管理ガイド』を参照してください。

  6. コンテキスト依存シンボリック・リンク (CDSL) の内容を調べて,すべてのリンクが正しいことを確認してください。

    Version 5.1 または Version 5.1A システムの CDSL が削除されている場合および破損している場合,アップデート・インストレーションが古い CDSL を新しいバージョンで上書きするため,CDSL の内容に施したカスタマイズが失われます。 CDSL の内容を確認するには,次のコマンドを入力します。

    # /usr/sbin/cdslinvchk
    

    変更,消失,置換された CDSL は,特に指定しないかぎり /var/adm/cdsl_check_list ファイルに記録されます。 失われた,または破損した CDSL を再度作成する方法については,『システム管理ガイド』 を参照してください。 詳細は, cdslinvchk(8) を参照してください。

  7. システムのファームウェアを更新します。

    ファームウェアの更新データは,インストレーション・キットに付属の 「Alpha Systems Firmware」CD-ROM に収められています。 ファームウェアの更新を開始するには,次の手順に従います。

    1. システムをシャットダウンして,コンソール・モードにします。

      # shutdown -h now
      

    2. 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 コマンドで,このデバイス名を指定します。

    3. ファームウェア CD-ROM をドライブに挿入し,そのドライブからブートします。

      >>> boot cdrom_console_device_name
      

      ファームウェア更新ユーティリティは自動的にシステムのタイプとモデルを識別し,システムに必要な正しいファームウェア・リビジョンを判断します。

    4. 画面上の指示に従います。 更新に含まれるファームウェアの変更点について説明する READ-ME-FIRST ファイルが自動的に表示されます。

    5. ファームウェアの更新の完了時に,最低 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 ドライブの速度,アップデートするソフトウェア・サブセットの数によって左右されます。

  1. ローカル・ファイル・システムをマウントします。

    # /sbin/bcheckrc
    

    bcheckrc コマンドは,mount -a コマンドを呼び出します。 これにより,標準の UNIX ファイル・システム (/usrvar) だけでなく,/etc/fstab ファイルにリストされているすべてのファイル・システムがマウントされます。 bcheckrc コマンドは,UNIX ファイル・システム (UFS) に対して fsck も実行し,必要に応じて LSM (Logical Storage Manager) を起動します。 fsck によって / (root) パーティションに問題が見つかると,システムはシャットダウンした後リブートして,その問題を修正します。

  2. Operating System, Volume 1」 の CD-ROM をドライブに挿入します。

  3. 次の構文で /sbin/installupdate コマンドを入力して,アップデート・インストレーションを開始します。

    /sbin/installupdate [-u] [-nogui] {location}

    各オプションについて,以下に説明します。

    アップデート・インストレーションを開始するコマンドの例を以下に示します。 状況に合ったコマンドを使用してください。

アップデート・インストレーション処理は,3.4 節の説明に続きます。

3.4    [ステップ 4]: アップデート・インストレーション・オプションの選択

アップデート・インストレーションの開始後に何が表示されるかは,システムがグラフィック表示機能を備えているかどうかによって決まります。

アップデート・インストレーションを最初に起動したときに決定しなければならない事項を 表 3-1 に示します。 オプションを片方だけ選択することも,両方選択することも,両方とも選択しないこともできます。

表 3-1:  初期画面でのアップデート・インストレーション・オプション

オプション 説明
オプションのカーネル構成要素の選択 (select optional kernel components)

オプションのカーネル構成要素を使用して構築されたカスタム・カーネルを現在のシステムで実行している場合や,新しいカーネルをカスタマイズしたい場合には,このオプションを選択します。 このオプションを選択すると,カーネルに組み込むオプションのカーネル構成要素を選択することができます。

このオプションを選択しなかった場合は,インストールされているソフトウェアを実行するために必要な必須カーネル構成要素だけで新しいカーネルが構築されます。

旧ファイルの保管 (archive obsolete files)

アップデート・インストレーションによって自動的に削除される前に旧ファイル保管しておきたい場合は,このオプションを選択します。 旧ファイルとは,Version 5.1 または Version 5.1A では提供されていて,Version 5.1B では必要でなくなったファイルのことです。 このオプションを選択すると,アップデート・インストレーションの分析フェーズになったときに,旧ファイルのリストが表示されます。 このとき,保管するファイルを 1 つ以上選択し,アーカイブ・ファイルに付ける名前を指定することができます。 このアーカイブ・ファイルは,いつでも削除することができます。

このオプションを選択しなかった場合は,旧ファイルは,保管するかどうかの確認なしにシステムから削除されます。

注意

この章の以降の説明は,グラフィカル・ユーザ・インタフェースとテキスト・ベース・ユーザ・インタフェースの両方に適用されます。 ただし,インタフェースの例を両方とも記載しているわけではありません。 グラフィカル・ユーザ・インタフェースの画面のみを使用して,アップデート処理とユーザの操作を示します。 テキスト・ベース・インタフェースを使用する場合も,手順は同じです。

3.5    [ステップ 5]: 分析フェーズの監視

アップデート・インストレーション・オプションの選択を終えると,アップデート・インストレーション・プロセスは現在のシステムの分析を開始します。

システムがグラフィック機能を備えている場合,分析フェーズは 図 3-2 に示すダイアログ・ボックスで開始されます。

図 3-2:  アップデート・インストレーションの「Preload Analysis」ダイアログ・ボックス

このダイアログ・ボックスのチェック・マークは,その分析ステップが完了したことを示しています。 ダイアログ・ボックスの下部に表示される進行インジケータは,強調表示されている分析ステップに対応しています。

以降の項では,各分析ステップの詳細について説明します。 また,ユーザの対処が必要な場合は,必要となるユーザ対処についても説明します。

3.5.1    ソフトウェアの矛盾の検索

アップデート・インストレーションに影響を与えるレイヤード・プロダクトは,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」ダイアログ・ボックス

3.5.2    インストール済みソフトウェアの確認

分析ステップのこの部分では,アップデート・インストレーション・プロセスは,何をアップデートしなければならないかを把握するために,どのソフトウェアがインストールされているかを調べます。

ワールドワイド言語サポート (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.5.3    カーネル構成要素の選択

オプションのカーネル構成要素をカーネルに組み込むことを選択した場合 (表 3-1 の説明を参照) は,図 3-5 に示す「Kernel Configuration」ダイアログ・ボックスを使用して,カーネルに組み込む,オプションのカーネル構成要素を選択します。 以前にオプションのカーネル構成要素をカーネルに組み込んでいる場合は,ここでもその構成要素を選択しなければなりません。 アップデート・インストレーション・プロセスには,現在のカーネルの内容は分かりません。 カーネル構成要素を選択するには,選択したい構成要素をクリックし,[Select] をクリックします。 選択がすべて終わったら,[OK] をクリックします。

この時点でカーネル構成要素の選択を取り消すと,アップデート・インストレーションは,インストールされているソフトウェア・サブセットに関連する必須のカーネル構成要素だけを使用してカーネルを構築します。

図 3-5:  「Kernel Configuration」ダイアログ・ボックス

3.5.4    特殊な構成オプションを手作業でカーネルに追加する

アップデート・インストレーションでは,必須のカーネル構成要素すべてと,先ほど選択したオプションの構成要素をサポートする,基本カーネル構成ファイルが提供されます。 ただし,アップデート・インストレーションでは,カーネル構成ファイルに追加した特殊な構成オプションやカスタム構成オプションは継承されません。

カーネル構成ファイルを手作業で編集した場合や,非標準のカーネル・オプション,擬似デバイス,コントローラ,またはその他の変更を組み込むレイヤード・プロダクトをインストールした結果,カーネル構成ファイルが編集されている場合は,それらのオプション,擬似デバイス,コントローラ,またはその他の変更を,新しいカーネル構成ファイル (/sys/conf/host_name) に取り込む必要があります。

テキスト・ベース・インタフェースを使用している場合は,アップデート・インストレーション時にカーネル構成ファイルを編集することができます。 テキスト・ベース・インタフェースを使用していない場合は,アップデート・インストレーションの完了後にこのファイルを編集してから, doconfig(8) コマンドを使用してカーネルを再構築します。

3.5.5    ファイル・タイプの矛盾の検索

アップデート・インストレーションでは,アップデート後のバージョンのオペレーティング・システムと互換性のないファイル・タイプを検索します。 オペレーティング・システムと一緒に出荷されるファイルは,システム・ファイルとも呼ばれ,いくつかのファイル・タイプに分類されます。 ファイルは,filedirectoryhard linksymbolic linkblock device,または pipe のいずれかに分類できます。 アップデート・インストレーション・プロシージャは,システム・ファイルのタイプが,以前のバージョンのベース・オペレーティング・システムが出荷されたときと同じであることを前提としています。 ファイル・タイプが変更されている場合は,ファイル・タイプの矛盾となります。

ファイル・タイプの矛盾には,次の 2 種類があります。

この機能は,インストールするソフトウェア・プロダクトの完全性を保つために提供されています。 どちらの場合も,アップデート・インストレーションでは矛盾が検出され,矛盾の解決に必要な対処方法がユーザに通知されます。

3.5.5.1    アップデートが中止されるファイル・タイプ矛盾

深刻なファイル・タイプ矛盾が発生すると,システムをアップデートしないでアップデート・インストレーションを終了する必要があります。 アップデート・インストレーションを続行すると,システムが壊れることがあります。 このような深刻な矛盾が検出された場合は,手作業で矛盾を解決してから,アップデート・インストレーションを再開しなければなりません。 次のようなファイル・タイプ矛盾が検出された場合,アップデート・インストレーションは続行できません。

たとえば,Version 5.1 または Version 5.1A でディレクトリとして出荷されたファイルをシンボリック・リンクに変更した場合,同じファイルが Version 5.1B でもディレクトリとして出荷されると,アップデート・インストレーション・プロシージャはこの違いを検出し,図 3-6 に示すダイアログ・ボックスを表示します。

図 3-6:  「File Type Conflict」ダイアログ・ボックス

3.5.5.2    深刻でないファイル・タイプ矛盾

3.5.5.1 項で説明したファイル・タイプ矛盾以外は,深刻でないファイル・タイプ矛盾です。 アップデート・インストレーション処理は,ファイル・タイプが変更されているファイルのコピーを .PreUPD という拡張子のファイル (たとえば,/etc/hosts.PreUPD) に保存することにより,自動的に矛盾を解決します。 新しいバージョンのオペレーティング・システムがロードされると,オリジナルのファイル (たとえば,/etc/hosts) は,オペレーティング・システムの一部として出荷された新しいバージョンに置き換えられます。 つまり,このファイルのファイル・タイプは,新しいバージョンのオペレーティング・システムとして出荷されたファイル・タイプに変更されます。 ファイル・タイプが変更されたファイル内のカスタマイズは,アップデート・インストレーション完了後に,.PreUPD バージョンから新しいバージョンのファイルに,手作業でマージする必要があります。 図 3-7に,深刻でないファイル・タイプ矛盾が検出された場合に表示されるダイアログ・ボックスを示します。

図 3-7:  「File Type Conflict Warning」ダイアログ・ボックス

3.5.6    旧ファイルの検索

旧ファイルとは,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」ダイアログ・ボックス

3.5.7    ファイル・システムの空き容量の確認

Version 5.1B のオペレーティング・システムは,Version 5.1 または Version 5.1A より多くのディスク・スペースを必要とします。 アップデート・インストレーション・プロシージャは,新しいバージョンのソフトウェア用に十分なスペースがあるかどうか,また処理用に十分な一時スペースがあるかをどうかを調べます。

アップデート・インストレーション・プロシージャは,十分なディスク・スペースがないと判断すると,ディスク・スペースの状態と,ディスク・スペースを回復するためのオプションを表示します。 図 3-9 に,ディスク・スペースの回復に使用するダイアログ・ボックスを示します。

図 3-9:  「Recover Disk Space」ダイアログ・ボックス

次の順序で,ディスク・スペースを回復してください。

  1. システムのクリーンアップ

    core ファイルと余分なカーネル・ファイルを削除します。

    アプリケーションやシステムがクラッシュするたびに,core という名前のクラッシュ・ファイルが作成されます。 このファイルはサイズが大きいことが多く,クラッシュの後で常に削除しておかないと,かなりの量のディスク・スペースが占有されます。 システムやアプリケーションのクラッシュ後にファイルのクリーンアップを行っていない場合は,この操作で必要なディスク・スペースを確保できることがあります。

    アップデート・インストレーション・プロシージャは,/sys/HOST_NAME ディレクトリと /var/adm/crash ディレクトリ内の余分なカーネル・ファイル (vmunix.* という名前のファイル) と,//usr/var ファイル・システム内の core ファイルを探します。

  2. .PreUPD ファイルの削除

    アップデート・インストレーション・プロシージャはカスタマイズされているシステム・ファイルを探し,.PreUPD という拡張子を持つファイルにコピーすることにより,そのファイルを保護します。 core ファイルと余分な vmunix ファイルを削除しても十分なディスク・スペースを確保できない場合は,必要に応じて .PreUPD ファイルを削除します。 [Remove .PreUPD Files] をクリックするとダイアログ・ボックスが表示され,削除するファイルを選択できます。

    注意

    ここで .PreUPD ファイルを削除すると,手作業で変更内容をマージするときに参照できなくなります。 .PreUPD ファイルは,変更されていて保護されていないシステム・ファイルの唯一のバックアップ・コピーです。

  3. ソフトウェア・サブセットの削除

    使用されていないソフトウェア・サブセットがあれば,それらを削除します。 この時点で削除したソフトウェア・サブセットは,アップデートされません。 [Remove Software Subsets] をクリックすると,図 3-10 に示すダイアログ・ボックスが表示されます。

    ソフトウェア・サブセットを削除してディスク・スペースを回復すると,アップデート・インストレーション処理は,「Total Needed」カテゴリに表示されているディスク容量を再計算します。 アップデートを続行して,現在インストールされているソフトウェア・サブセットに基づいてディスク容量を再計算させてください。

    注意

    setld コマンド以外のコマンドで,インストール済みのベース・オペレーティング・システムまたは WLS ソフトウェアの一部のファイルを削除しても,空きスペースは増えません。 これは,アップデート・インストレーション・プロシージャは,削除した古いファイルが新しいバージョンのファイルに置き換えられることを計算にいれているためです。

図 3-10:  「Remove Subsets」ダイアログ・ボックス

ファイル・システムで利用できるディスク・スペースが,必要なディスク・スペースより大きくなるまで,これらのオプションを使用して空きスペースを広げてください。 これらのオプションを使用しても必要な空きスペースが確保できない場合は,ファイル・システムのレイアウトを変更するか,フル・インストレーション手順で推奨ディスク・パーティションを使用してフル・インストレーションを実行することにより,インストールされているソフトウェアに対応できるだけの十分な大きさのディスク・パーティションにします。

3.6    [ステップ 6]: アップデート・インストレーション処理の開始の確認

分析フェーズが完了したら,アップデート・インストレーション処理の開始を確認します。 グラフィカル・ユーザ・インタフェースを使用している場合,図 3-11 のダイアログ・ボックスを使用して確認を行います。

図 3-11:  「Ready to Begin Update」ダイアログ・ボックス

次のいずれかを選択できます。

アップデート・インストレーションは,通常,45 〜 120 分で完了します。 ただし,DS シリーズや GS シリーズなどの新しい高速のマシンでは,少し短縮されます。 実際にかかる時間は,プロセッサ・タイプ,アップデートされるソフトウェア・サブセットの数,アップデート・インストレーションの実行に使用されるメディアのタイプ (CD-ROM あるいはリモート・サーバ),CD-ROM ドライブの速度 (CD-ROM を使用する場合),ネットワークの通信量 (リモート・サーバを使用する場合) によって左右されます。

3.7    [ステップ 7]: システムへのログイン

アップデート・インストレーションが完了したら,root ユーザとしてログインして3.8 節3.9 節で説明するインストール後の作業を実行します。 この作業は,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]: 必要に応じてカスタマイズ部分をマージする

アップデート・インストレーションでは,特定のカスタマイズ部分は自動的にはマージされず,それらのカスタマイズ部分を手作業で新しいファイルに追加しなければならない場合があります。 手作業でマージを行うには,新しいバージョンのシステム・ファイルをテキスト・エディタで編集して,カスタマイズ部分を組み込みます。 カスタマイズ部分を新しいバージョンにマージできるように,以下の情報が保存されます。

手作業でのマージ作業がすべて完了すると,システムは利用可能な状態になります。 この時点で,Version 5.1B の配布メディアで提供されている,オプションの追加ソフトウェア・サブセットをインストールすることができます。 オプションのソフトウェア・サブセットのインストール方法については,第 9 章を参照してください。

3.10    [ステップ 10]: アップデート・インストレーション・クリーンアップ・ユーティリティの実行 (オプション)

アップデート・インストレーションで作成されたバックアップ・ファイル .PreMRG.PreUPD を削除または保管するには,アップデート・インストレーション・クリーンアップ・ユーティリティを使用します。 アップデート処理中にマージに失敗したファイルがある場合は,新しいバージョンのファイルへカスタマイズ内容をマージするときの参考として,これらのバックアップ・ファイルを使用することができます。 手作業でのマージがすべて完了すると,.PreMRG ファイルと .PreUPD ファイルは不要になります。

アップデート・インストレーション実行後のアップデート・インストレーション・クリーンアップ・ユーティリティの実行ステップは,オプションです。 このようなバックアップ・ファイルが占めているディスク・スペースを回復したい場合は,このユーティリティを使用してください。 これらのファイルを保管する場合,保管先には,tar コマンドがサポートする任意の保管先 (ファイル,テープ・デバイス,またはディスク) を指定できます。

クラスタのローリング・アップグレードを実行する際は,クリーン・ステージの一環として Update Administration Cleanup Utility を実行することもできます。 Update Installation Cleanup ユーティリティは,すべてのクラスタ・メンバがロールされ,ローリング・アップグレードが完了するまでは実行しないでください。 ローリング・アップグレードの実行中にクリーンアップ・ユーティリティを実行しようとすると,このユーティリティはメッセージを出力します。

次のいずれかの方法を使用して,アップデート・インストレーション・クリーンアップ・ユーティリティを起動します。

3.11    エラー回復

エラーの中には,アップデート・インストレーション処理が停止し,ユーザの介入を必要とするものがあります。 このようなエラーは,アップデートでの次の時点で発生することがあります。

3.11.1    分析フェーズの失敗

ロード前の分析フェーズであれば,どこでアップデート・インストレーションが失敗しても,回復することができます。 次のコマンドを実行することによって,システムをマルチユーザ・モードに戻すことができます。

# init 3

エラー・メッセージで報告されたエラーを修正して,アップデート・インストレーション・プロセスを再スタートしてください。

3.11.2    ソフトウェア・サブセットのロードの失敗

ロード処理中に,ネットワークの中断,ハードウェアの障害,ファイル確認エラーなどが発生すると,ロードできないソフトウェア・サブセットが出る可能性があります。

3.11.3    カーネルの構築の失敗

カーネルのレイヤード・プロダクトと新しいバージョンのオペレーティング・システムに互換性がないために,アップデート・インストレーションの最後で,最適化カーネルの構築が失敗することがあります。

このような場合,システムは,レイヤード・プロダクトのサポートを含まないカーネルを再構築します。 次の手順に従って,レイヤード・プロダクトのサポートを含むカーネルを構築してください。

  1. カーネル構築の失敗の原因が記録されているファイル,/var/adm/smlogs/it.log を調べます。

  2. setld コマンドを使用して,失敗の原因となったレイヤード・プロダクトを削除します。

  3. setld コマンドを使用して,最新バージョンのレイヤード・プロダクトを再インストールします。

  4. /usr/sbin/doconfig コマンドを使用して,レイヤード・プロダクトのサポートが組み込まれた新しいカスタム・カーネルを構築します。