Jump to content 日本-日本語
製品  >  ソフトウェア  >  Linux

cciss.o, cpqarray.oバージョンアップによる起動失敗回避方法

Open Source & Linux

導入事例

product

ハードウェア
ソフトウェア
サービス & サポート

buy now?

HPE OPEN SERVICES
保守サービス
教育プログラム

support

OS対応表
システム構成図
技術文書
FAQ
ディストリ対応表
サポート & ドライバ
リンク
SDR - 設定方法
FreeBSD
サイトマップ
HPE & Red Hat情報ポータル HPEとRed Hatが実現するオープンなイノベーション
BSD 動作確認レポート等を掲載
コンテンツに進む
revised 24-DEC-02
 本ページに記載してある内容は限られた評価環境に於ける検証結果に基づいたものです。本ページの情報を利用する前に予めサイト内リンク技術情報サイト内リンク保証について、ディストリビュータが提供する WEBサイト等をご覧ください。

発生する現象について

 SmartArray用ドライバ cciss.o, cpqarray.oは下記のバージョンから、kernel 2.4.xxで利用可能になった concurrent multiple scan schmeを利用した PCIデバイスのスキャン方法に変更されました。この変更により、自動パーティション設定利用時に ProLiant内蔵デバイスや高速コントローラの優先利用を考慮したインストールが可能になります。
  • cciss.oの v2.4.5以降
  • cpqarray.oの v2.4.20以降
 PCIデバイスのスキャン方法が変更された事により、ドライバの更新を行う事でデバイスファイルのアサイン順が変更され、システムが起動しなくなる場合があります。
case1    
VFS: Cannot open root device "4805" or 48:05
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 48:05
/etc/fstabの設定ミス
もしくは…
case2    
Mounting root filesystem
mount: error 6 mounting ext2
pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2
Freeing unused kernel memory: 224k freed
Kernel panic: No init found. Try passing init= option to kernel.
/etc/lilo.confの設定ミス

 但し、/etc/fstab/etc/lilo.confの両方の設定ミスが原因の場合もありますので、必ず両方の設定ファイルを見直してください。
 
 各ディストリビューションが装備する driver version一覧はサイト内リンクこちらをご覧ください。

e2labelについて

 Red Hat 7.2等の /etc/fstab内の記述で #e2labelを利用して ext2/ext3ファイルシステムの mountを行っているディストリビューションの場合、本現象は発生しません。これはデバイスファイルを直接指定せず LABEL=で指定しているためデバイスファイル名のアサイン順が変更されても問題なくファイルシステムの #mountが可能なためです。
 
 但し、SWAPはデバイスファイル名で指定しなければならないので、正常に #swaponされているか確認してください。

該当する環境について

 本現象は全ての環境で発生する訳ではありません。下記の両方が当てはまる場合に発生します。
  • 同一ドライバを利用する SmartArrayを複数枚装備している場合*
  • ドライバを単独アップデートした場合、もしくは kernelアップデートに伴い、ドライバがアップデートされた場合
    *複数ポートを装備した SmartArrayを 1枚だけ装備している場合や、cciss系 SmartArrayと cpqarray系 SmartArrayを 1枚ずつ装備している場合には、本現象は発生しません。


 kernelのアップデート作業やドライバのアップデート作業を行う場合には、必ずシステムのフルバックアップを行ってください。本作業の失敗は即、システムの起動不能状態に繋がります
 /etc/fstab内の記述は /dev/...の device file名ではなく、LABEL=で指定する事で、本作業で必要な作業は SWAPファイルの device file名の変更だけですみます。この場合、SWAPファイルの device file名の指定に失敗しても SWAPファイルが mountされないだけでシステムの起動に影響は与えません。ext2, ext3ファイルシステムを利用されている場合、LABEL=を利用される事を強くおすすめします。


環境の変更について

 上記の作業を行う前に、インストール時に作成した起動用 FDからシステムが正常起動できる事を必ず確認しておいてください。作成していない場合 #mkbootdisk --device /dev/fd0 `uname -r`で作成してください。
 
 kernelのアップデートは #rpm -Uvhではなく #rpm -ivhで追加導入する事を強くおすすめします。以前の kernel環境を残す理由は、アップデートした kernel環境が起動しなくなった場合に、復旧作業用に利用するためです。アップデートした kernel環境が問題なく稼動する事を確認した後、必要に応じて以前の kernel環境を削除してください。

回避方法

 本現象を回避するには、下記の作業が必要になります。
  • /etc/fstabファイルの修正
  • /etc/lilo.conf等のブートローダ設定ファイルの修正
  • #lilo -v実行によるブートローダ設定変更の実行

 具体的に必要な変更としては、デバイスファイルのアサイン順が変更されるのに合わせ、上記の設定ファイル内でのコントローラの順番に関する部分を入れ替える作業となります。
 
 例えば、2枚の SmartArrayコントローラを装備している場合、c0d0pの、コントローラ番号部分である 'c0'と 'c1'を入れ替えます。

回避例 #1 - original kernelで起動可能な場合

 errata kernelを追加導入した場合等が、この例にあたります。例えば Red Hat 7.1の環境に errata kernel 2.4.9-34環境を追加導入した場合。kernel 2.4.9-34ではシステムが起動しませんが、original kernel 2.4.2-2では問題なく起動します。この場合、original kernel 2.4.2-2でシステムを起動し、設定ファイルの修正を行います。
boot: linux  original kernel 2.4.2-2を起動
     ・
     ・
#vi /etc/fstab  'c0'と 'c1'の入れ替え
#vi /etc/lilo.conf  boot=root=の 'c0'と 'c1'の入れ替え
#lilo -v
#reboot

回避例 #2 - maintenaceモードで起動してしまう場合

 正常に起動する環境が無い場合で、maintenanceモードでシステムの起動が停止してしまう場合等が、この例にあたります。/を rwモードで remountし設定ファイルの修正を行います。/bootを単独パーティションとして確保している場合、/etc/lilo.confの修正も行う場合に mountしておく必要があります。
boot: linux-2.4.9-34
     ・
     ・
*** An error occured during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D for normal startup): rootのパスワード入力
(Repair filesystem)1 #mount -o remount ,rw /
(Repair filesystem)2 #vi /etc/fstab  'c0'と 'c1'の入れ替え
(Repair filesystem)3 #vi /etc/lilo.conf  boot=root=の 'c0'と 'c1'の入れ替え
(Repair filesystem)4 #mount /dev/ida/c1d0p1 /boot
(Repair filesystem)5 #lilo -v  ワーニングメッセージは無視
(Repair filesystem)6 #reboot

回避例 #3 - 起動用 FDを利用する場合

 インストール時に作成した、起動用 FDからシステムを起動し、設定ファイルの修正を行います。詳細はディストリビューションに付属のマニュアル、もしくは各種 HowTo文書をご覧ください。

回避例 #4 - 全く起動しない場合

 正常に起動する環境が全く無い場合で、maintenanceモードにすら移行できない場合等が、この例にあたります。インストール CD-ROMの Rescueモードでシステムを起動し、設定ファイルの修正を行います。viでのキーマップは、[Ctrl]+[p]/上、[Ctrl]+[j]/下、[Ctrl]+[h]/左で利用してください。この例では Red Hat 7.2*の CD-ROM #1を利用しています。
boot: linux rescue
     ・
     ・
English or Japanese  'English'
Keyboard  'jp106'

HDD上の //mnt/sysimageに mountするのに失敗する場合の作業…
 sh-2.05# mkdir /mnt/sysimage/boot
 sh-2.05# mount /dev/ida/c1d0p1 /mnt/sysimage/boot
 sh-2.05# mount /dev/ida/c1d0p5 /mnt/sysimage
 sh-2.05# /mnt/sysimage/bin/vi /mydev/root/etc/fstab  'c0'と 'c1'の入れ替え
 sh-2.05# exit
HDD上の //mnt/sysimageに mountするのに成功する場合の作業…
 sh-2.05# vi /mnt/sysimage/etc/fstab  'c0'と 'c1'の入れ替え
 sh-2.05# exit
注1 Red Hat 7.1の CD-ROM #1から rescueモードでシステムを起動した場合、'Japanese'を選択すると LCD/CRTの周波数レンジを越えてしまう場合があります。
注2 Red Hat 7.2の CD-ROM #1から rescueモードでシステムを起動した場合、'Japanese'を選択すると説明画面が文字化けします。
注3 システム構成によっては、Red Hat 7.1の CD-ROM #1から rescueモードでシステムを起動すると Anacondaが異常終了する事があります。この場合、Red Hat 7.1環境であっても Red Hat 7.2版 CD-ROM #1を ftp等から入手し利用してください。
注4 Red Hat 7.2の CD-ROM #1から rescueモードでシステムを起動すると、システム構成によっては Anacondaは SmartArray上のデバイスを自動マウントしない場合があります。上記の方法で手動 mountしてください。
注5 この方法では /etc/lilo.confの修正・反映は行えません。起動用 FDを利用して修復してください。

例: Red Hat 7.1を kernelアップデートする場合…

 ProLiant DL360(ROC:内蔵SmartArrayを標準装備)に SmartArray 431(32bit/33MHz PCI slotに装着)を装備した環境に導入した Red Hat 7.1を errata kernel 2.4.9-34にアップデートした場合の設定ファイル変更例を説明します。本例では ROC上の HDDに /boot, /, SWAPを配置、SmartArray 431上の HDDに /homeを配置しています。
 
  • original kernel 2.4.2-2の場合
     この場合、Linuxからは ROCに接続した HDDが 2番目の HBA(/dev/ida/c1d0)、SmartArray 431に接続した HDDが 1番目の HBA(/dev/ida/c0d0)として認識されます。各設定ファイルの記述は下記になります。
    /etc/fstabの設定
    /dev/ida/c1d0p1 /boot
    /dev/ida/c1d0p5 /
    /dev/ida/c1d0p6 SWAP
    /dev/ida/c0d0p1 /home
    /etc/lilo.confの設定
    boot=/dev/ida/c1d0p1
    root=/dev/ida/c1d0p5


  • errata kernel 2.4.9-34の場合
     kernelをアップデートした事で cpqarray.oのバージョンも v2.4.20にあがります。このため Linuxからは ROCに接続した HDDが 1番目の HBA(/dev/ida/c0d0)と、アサイン順が変更されます。同様に SmartArray 431に接続した HDDは 2番目の HBA(/dev/ida/c1d0)になります。各設定ファイルの記述は下記になります。
    /etc/fstabの設定
    /dev/ida/c0d0p1 /boot
    /dev/ida/c0d0p5 /
    /dev/ida/c0d0p6 SWAP
    /dev/ida/c1d0p1 /home
    /etc/lilo.confの設定
    boot=/dev/ida/c0d0p1
    root=/dev/ida/c0d0p5


注1 /etc/lilo.conf内の 'root='の変更をし忘れると、システム起動時 case 2pivot_root failedとなります
注2 boot=の controller numberは、現在利用しているドライバによって変更します。古いドライバを含む kernelで起動している場合は、上記の例に於いては '1'になります。
注3 /etc/fstab内の変更をし忘れると、maintenanceモードで起動します

例: Red Hat 7.2を kernelアップデートする場合…

 Red Hat 7.2の original kernel 2.4.7-10を errata kernel 2.4.9-34にアップデートする場合、上記の Red Hat 7.1での例と同様に行ってください。
 
 Red Hat 7.2では /etc/fstab内の記述が LABEL=指定されているので、変更するのは SWAPのデバイスファイル名だけになります。

Grubの問題について

 Red Hat 7.3, 2.1AS迄の grubは、複数の HBAを利用する環境下では安定稼動しません。ブートローダには liloを利用する事を推奨します。

Grubなのに /bootを別途確保する必要があるのか?
Grub Hard Disk Errorが表示されるが?
ブートローダを好きなところにインスト出来ないが?
Red Hat 8.0で Grubは変わったか?

備考

 Red Hat 8.0で Grubを利用する場合、grub.conf内での root=の指定も 'LABEL='が利用される様になりました。
title Red Hat Linux (2.4.18-14smp)
   root (hd0,0)
   kernel /vmlinuz-2.4.18-14smp ro root=LABEL=/
   initrd /initrd-2.4.18-14smp.img
印刷用画面へ印刷用画面へ
プライバシー ご利用条件・免責事項