カテゴリー: サーバ

投稿日:

Windows Server 2008 SP2にInternet Explorer 9をインストールする 2022/07/06版

検証のためにWindows Server 2008 SP2をセットアップしたわけだが、オフライン状態でInernet Explorer 9をインストールするために必要なものとして http://go.microsoft.com/fwlink/?LinkId=185111 を案内され、インストールの前提条件Internet Explorer 9に飛ばされ、下記を入手しろ、と言われる

  • サービス パック 2 for Windows Vista および Windows Server 2008 (KB948465) に関する情報
  • グラフィックス、イメージングWindows XPS ライブラリの説明 (KB971512)
  • Windows Vista および Windows Server 2008 のプラットフォーム更新プログラムの補足 (KB2117917) 
  • 注意 この更新プログラムをインストールする前971512更新プログラムをインストールする必要があります。

しかし、これらのリンクが機能しておらずアップデート用のファイルが入手できない。

試行錯誤してたどり着いた結果を書いておく。

Windows Sevrer 2008 SP2の入手について

今回SP2適用済みメディアを使用したが、SP2ことKB948465はMicrosoft Updateカタログで「KB948465」を検索して「windows6.0-kb948465-x64_2eedca0bfa5ae8d1b0acf2117ddc4f15ac5183c9.exe」を入手してインストール。

1個目 KB2117917 適用

Microsoft Updateカタログで「KB2117917」を検索して「windows6.0-kb2117917-x64_655a21758801e9648702791d7bf30f81b58884b3.msu」を入手してインストール。再起動はしなくても大丈夫

2個目KB2506014適用

Microsoft Updateカタログで「KB2506014」を検索して「windows6.0-kb2506014-x64_e4a62be05adf6d07841dd3df49fb5d63d1d3ba05.msu」を入手してインストール。再起動はしなくても大丈夫

3個目KB971512適用

Microsoft Updateカタログで「KB971512」を検索して「windows6.0-kb971512-x64_0b329b985437c6c572529e5fd0042b9d54aeaa0c.msu」を入手してインストール。再起動はしなくても大丈夫

問題発生

これでインストールの前提条件Internet Explorer 9に書かれている前提条件をクリアしているはずなのだが、インストールが拒否される。

まだ適用が必要な更新があるらしい。

「更新プログラムの取得」をクリックするとInternetExplorer8でhttp://go.microsoft.com/fwlink/?LinkId=185111 を開こうとするが開けずエラーとなる。

再起動して、もう１回、「windows6.0-kb971512-x64_0b329b985437c6c572529e5fd0042b9d54aeaa0c.msu」をインストールすると今回はなぜか完了した。

？？？と思ってWindows Updateの更新履歴を確認すると「KB2999226」が追加されている・・・

これは「Windows での汎用の C ランタイムの更新プログラム」であるようで、Windows Updateによりインストールされていた模様

4個目 KB2999226適用

というわけで、Microsoft Updateカタログで「KB2999226」を検索して「windows6.0-kb2999226-x64_0befbb0b78588f7c9f17ead1da3abeda2b6f4c7f.msu」を入手してインストール。

今回は再起動は必須。

Internet Explorer 9インストール

Microsoft Updateカタログで「Internet Explorer 9 2008用」を検索して3ページ目に出てくる「x64 ベース システム Windows Server 2008 用 Windows Internet Explorer 9」から「wu-ie9-windowsvista-x64_f599c02e7e1ea8a4e1029f0e49418a8be8416367.exe」を入手してインストール。

再起動は必須。

なお、 IE9.0の日本語化を「ie9-langpack-windowsvista-x64-jpn_331d32d2b458301c359cb95b639425ff2dbaf2a1.exe」のインストールで行おうとしたのですが、実行しても何も起こらず、日本語化も行われませんでした。

ルート証明書の更新

2022/07/06時点ではWindows Server 2008 SP2に含まれているルート証明書はすべて期限切れになっています。

httpsで使うためのルート証明書がないので、最近のほとんどのWebサイトにアクセスできません。

ルート証明書の更新についての調査過程メモ

2022/07/06時点ではWindows Server 2008 SP2に含まれているルート証明書はすべて期限切れになっています。

この更新に関して調べて見ると「【Windows】オフライン環境でルート証明書更新プログラムを利用する構成について」にて KB2813430 で提供されているという話があった。

Microsoft Updateカタログで「KB2813430」で検索して適用

その後、グループポリシーエディッタを「gpedit.msc」で起動して、[コンピュータの構成]-[管理用テンプレート]-[システム]-[インターネット通信の管理]-[インターネット通信の設定]を開き、「ルート証明書の自動更新をオフにする」を「未構成」から「無効」に変更します。

これでいけるかなぁ・・・と思ったのですが、再起動したり２４時間放置してみたりしても状況に変化はなし。

Microsoftのページに「リリース ノート – Microsoft の信頼されたルート証明書プログラム」というのがあり、ルート証明書更新プログラムパッケージを https://aka.ms/CTLDownload というURLで配布している。

個々にアクセスすると、authrootstl.cab がダウンロードできるのでコマンドプロンプトから「certutil -syncWithWU ～\authrootstl.cab」と実行してみたが、現状有効なルート証明書がないようで、失敗した。

Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\Users\Administrator>certutil -syncWithWU C:\Users\Administrator\Downloads\aut
hrootstl.cab
証明書チェーンは処理されましたが、信頼プロバイダが信頼していないルート証明書で強
制終了しました。 0x800b0109 (-2146762487) -- authrootstl.cab
CertUtil: -syncWithWU コマンド エラーです: 0x800b0109 (-2146762487)
CertUtil: 証明書チェーンは処理されましたが、信頼プロバイダが信頼していないルート
証明書で強制終了しました。

C:\Users\Administrator>

WSUS Offline Updateでルート証明書の更新をやっている部分を確認すると、win\glb\ディレクトリ内に拡張子crt(セキュリティ証明書)と拡張子crl(証明書失効リスト)のファイルがあり、certuril -addstore Root ～ という形で登録していました。

この証明書ファイル群はどこで入手？と調べたところMicrosoft Japan Windows Technology Support Blogの「ルート証明書更新プログラムの仕組みについて」にいろいろ記述を発見

信頼できるルート証明書のリスト http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab というのは、さきほどダウンロードしたやつ。

しかし、これの中を確認してもバイナリなので、リストに記載されているというルート証明書が分からない・・・

Windows Server 2008R2であれば「Support for urgent Trusted Root updates for Windows Root Certificate Program in Windows(3024777.)」でアップデートが提供されている。

Cirtixのサポート情報として「Windows Server 2008 のルート証明書の更新機能でルート証明書を自動更新できない場合に Hotfix のインストールに失敗する」(CTX130025)というのがあり、対策２が使えそうだが、初手のルート証明書入手先が現存していない。(英語版KB Hotfix Installation Fails if the Update Root Certificates Feature in Windows Server 2008 Cannot Automatically Update the Root Certificates (CTX129998)も同じ)

HPE KB「HP Insight Remote Support Advanced Software – Version A.05.50 with Windows 2008 and IE x64 and Remote Support Client RSC Fails to Register」も同じ入手先URLでアクセスできず。

「McAfee Enterprise 製品のインストール/アップグレードを成功させるためにルート証明機関を更新する方法」に、バッチファイル(2022_Certificates.bat.txt)とレジストリ設定用ファイル(2022_Certificates.reg.txt)を実行することで登録される、という手法が書いてある。

いい方法ないなぁ、と思ったら https://gist.github.com/mateusaubin/3671126 のコメントで「ASHER TOOLS Root Certificate Updater」 というのが紹介されていた。

内容はPowerShellでソースコードは https://github.com/asheroto/Root-Certificate-Updater で公開されている。

「certutil -f -addstore root ファイル名」で実行すると登録できた模様。

なるほど・・・

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc749331(v=ws.10)?redirectedfrom=MSDN

投稿日:

Windows Server 2008をいまさらセットアップした(作業メモ版)

2022/07/08追記

何回か実行してみたところ、いろんな問題があったため、新しい記事「Windows Server 2008 SP2のWindows Updateがうまくいかない件への対処策 2022/07/07版」としてまとめ直しました。

とあるバックアップソフトの対象機種からWindows Server 2008が外れた。

これは「ホントにインストールできない」という意味なのか、それとも「インストールできるけどサポート対象と認定しない」という意味なのか、どちらなんだろ？と確認するため、Windows Server 2008環境を新規でセットアップした。

Windows Server 2008 SP2 のISOイメージを使ってvSphere環境でインストールを実施。

まず、VMware Toolsをインストールしようとしたら対応していないOSと言われてしまう。

調べると最後のWindows Server 2008 SP2対応はVMware Tools 11.0.6だったらしい。

このバージョンのVMware toolsダウンロードを https://packages.vmware.com/tools/releases/11.0.6/ から行ってインストールを実施。

続いて、Windows OSのアップデートは WSUS Offline Updateを使ってオフライン状態でアップデートできないかな、と確認してみると、ESR versionの 11.9.1 であればWindows Server 2008に対応していたので、ISOイメージを作成した。

が・・・ ListMissingUpdateIds.vbs で、「信頼プロバイダが信頼していないルート証明書で強制終了しました」というエラーで失敗して、パッチ適用の本編に進まない。

certmgr.mscを起動して確認してみると「証明書失効リスト」にいろいろある・・・

ListMissingUpdateIds.vbs の処理を修正しないとダメっぽいんだけど、うまくデバグできなかったので対処を諦めて普通にWindows Updateを実施。

しかし、最後10個ぐらいのところで、それ以上進まなくなる、という現象が発生。

2回実施中2回とも発生なので、特定の何かで問題が発生している模様。

この状態になると強制電源OFF/ONして、Windows Updateのロールバック処理を行うぐらいしか対処方法が無かった。

ロールバック完了後に再度Windows Updateを実行してみると半分以上がまだ未適用でした・・・面倒くさい

この後のWindows Updateはハングアップすることはなく普通に進み、とはいえ、何回か再起動とWindows Updateの再実行が必要でした。

で・・・

今回、Windows Server 2008環境を構築するきっかけとなった非対応問題ですが、「インストールできない」という状況でした。

なぜインストールできないのか、というのは前提条件である.NET Framework 4.6.2がWindows Server 2008に非対応だったから、ということでした。

なお、Windows Server 2008については古いバージョンをインストールしておけばサーバ側が新しいバージョンであってもバックアップ/リストアが問題無く動作していました。

WSUS Offline Updateを使わないでいきなりWindows Updateしてみると、Microsoftサイトにアクセスできずに終わります。

なぜかこのような状態になっているかと言えば、といえばhttpsアクセス時に使用する証明書が全て有効期限切れとなっているためですね。

これはcertmgr.mscを起動して確認出来る信頼されたルート証明書機関の有効期限を見ればわかります。

WSUS Offline Updateはルート証明書の更新はやってくれて下記の様な感じになっています。これによりhttpsによるアクセスが成功するようになっている感じですね。

投稿日:

ClonezillaをLACP+タグVLAN環境で使う

システムディスクのバックアップ/リストアを行えるDebian/Ubuntuベースで構成されているClonezilla を使ってシステム障害に備えたバックアップディスクを取得しようと思ったのだが、ネットワークがLACP (802.3ad) +タグVLANで作成されていることに気がついた。

複数NICが搭載されている環境でClonzillaを起動すると、ネットワーク設定の際に「bond0 Use_channel_bonding」という選択肢が表示される。

しかし、次のNetwork Configで「static Use static IP address」を選択してみてもIPアドレスに関する設定のみでLACPで使うNICの選択やVLANに関する入力する場面はない。

というわけで、「enter_shell Enter_command_line_prompt._Do_it_manually」を選択してみるしかない。

選択してみると、設定したあと「exit」すれば続きから始まるよ、といわれる。

では、どのように設定を行うのか？下記でヒントを発見

Clonezillaの機能追加希望「#61 no lacp / etherchannel / Bonding support」(2015年07月15日～2016年10月13日)
Clonezillaのフォーラム「VLANs / bonding configuration」(2020年12月09日～2020年12月14日)

手動で設定する場合のやりかたと、ocs-live-nicbonding というスクリプトを追加して今後のバージョンで使える様にする、というものになる。

Clonezilla 2.8.0で確認してみると ocs-live-nicbonding は存在していた。

しかし、ドキュメントが見当たらないので、スクリプトを読んでみると下記仕様のようだった。

・bond0 を mode=802.3ad(LACP) 、miimon=100 で作成する
・ocs-live-nicbonding のオプションとして指定したNICがスレーブデバイスとして登録される
・xmit_hash_policy は指定しないのでデフォルトのlayer2設定

というわけで、eth3,eth4を使用してbond0を作成する場合は「ocs-live-nicbonding eth3 eth4」と実行する

「ip a s bond0」を実行してbond0が作成されていることを確認

bond0へのタグVLAN追加はvconfigコマンドで実行。

「vconfig add bond0 <VLANID>」を実行する

そうすると「bond0.<VLAN ID>」というデバイスが作成される(「ip a s bond0.<VLANID>」で確認)

IPアドレスを「ifconfig bond0.<VLANID> <IPアドレス> netmask <ネットマスク> up」を実行して設定。

で「exit」を実行すると、下記の様にClonezillaの操作に戻ります。

投稿日:

CentOS7,RHEL8,Ubuntu 20.04などでコンソール解像度を低くする

RHEL/CentOS6以降やUbuntu 18.04(?)以降など、最近にLinuxでは起動時に接続しているディスプレイの解像度を認識し、高解像度で表示しようとする。

これは Kernel Mode Setting (KMS) (kernel.orgの説明 / archlinux wikiの説明)の機能により実現されている。

しかし、複数台のサーバを設定する場合、モニタが１台しかないのでつなぎ替えて設定しようとすると、起動時にモニタがつながっていたサーバだけ解像度が高くなってしまう、という弊害がある。

この問題は、DELLサーバに搭載されるiDRAC機能によるリモートコンソール接続の時にも発生してしまい、起動時に物理モニタが接続されているサーバだけブラウザ上のコンソール表示が高解像度で表示されます。

これを避けるには強制的に解像度を指定する必要があります。

参考にした情報源

RedHat KB: RHEL 6 および RHEL 7 で VGA コンソールのテキスト解像度を 80×25 に設定する方法
archlinux wiki: GRUB/ヒントとテクニック の「3.1 フレームバッファの解像度を設定する」
grubマニュアル: 6.1 Simple configuration handling
centos.org forum: How to change Grub menu resolution?

Ubuntu 20.04 Serverの場合

インストール直後は、起動直後に下記のようなgrubメニューが表示されない設定となっています。まずは、grubメニューが表示されるよう設定変更してください。（なお、設定手法については後述の /etc/default/grub の所に書いてあります)

grubメニューが表示されるようになったら、上記で止めて「c」を入力し、コマンドラインモードに変更します。

ここで「videoinfo」と入力します。

そうすると対応できる表示モードの一覧が出力されますが、モードが多い場合はスクロールしてしまい、全部を見ることができない場合があります。

そのような場合は「set pager=1」と入力し、そのあとに「videoinfo」を実行します。

なお、日本語キーボード利用時、= は、「^ へ ～」キー(通常の=の右隣)で入力出来ます。

解像度指定は「800x600x32」といったような形で行います。

実際にそれが使用できるかは「videotest 800x600x32」と実行します。

そうすると、下記の様に表示されます。これが読める状態であれば問題ありません。

このテストは終了する手法がないため、強制再起動します。(ctrl+alt+deleteなどで)

設定する解像度が決まったら普通にUbuntuを起動します。

設定するファイルは /etc/default/grub です。

Ubuntu 20.04をvSphere上でインストールした場合の初期値では下記の様になっていました。

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

grubメニューを表示して10秒まつ設定(“GRUB_TIMEOUT_STYLE=menu”と”GRUB_TIMEOUT=10” ) を入れて

そこに、コンソール解像度を設定するための以下の設定を入れます。

grubでの解像度を指定するための「GRUB_GFXMODE=800×600」
grubでの設定内容をkernel起動後も維持するための「GRUB_GFXPAYLOAD_LINUX=keep」と、「GRUB_CMDLINE_LINUX_DEFAULT=」行への「nomodeset」追加

これを行った後の /etc/default/grub の内容は下記の様になります。

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity nomodeset"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
GRUB_GFXMODE=800x600
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

書き換えたらgrub.cfgを生成するため「sudo update-grub2」を実行します。

instadmin@ubuntu:~$ sudo update-grub2
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-91-generic
Found initrd image: /boot/initrd.img-5.4.0-91-generic
done
instadmin@ubuntu:~$

設定後、再起動して解像度が指定通りになっていることを確認します。

CentOS7の場合

RedHatのKBに記載があります：「RHEL 6 および RHEL 7 で VGA コンソールのテキスト解像度を 80×25 に設定する方法」

上記KBでは640×480に設定していますが、他の解像度が指定できないものかCentOS7でいろいろ試してみましたが出来ませんでした。

設定は /etc/default/grub に行います。

CentOS7をvSphere環境上にインストールした場合、下記の様になっていました。

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rd.lvm.lv=centos/root rd.lvm.lv=centos/swap"
GRUB_DISABLE_RECOVERY="true"

この「GRUB_CMDLINE_LINUX=」行に「video=640×480」と「nomodeset」の両方を追加します。

RedHat KBではvideoだけでもいけるようなことを書いていましたが、実サーバ(DELL PowerEdge R640 UEFI設定)では問題なかったものの、vSphere仮想環境(BIOS設定)では起動途中で解像度が変わる動作をしたため「nomodeset」を追加しています。

ただ、KBにはnomodesetは悪、的な記述もあるので、ダメだったら追加する、ぐらいの方がいいかもしれません

追加後は以下の様な形になります。

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rd.lvm.lv=centos/root rd.lvm.lv=centos/swap video=640x480 nomodeset"
#GRUB_GFXMODE=800x600x24
GRUB_DISABLE_RECOVERY="true"

EFI環境の場合「grub2-mkconfig -o /etc/grub2-efi.cfg」、BIOS環境の場合「grub2-mkconfig -o /etc/grub2.cfg」を実行してgrub設定を更新します。

[root@centos7 ~]# grub2-mkconfig -o /etc/grub2.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-1160.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-2c896cb2eafd4db586ecfbd67535d5dc
Found initrd image: /boot/initramfs-0-rescue-2c896cb2eafd4db586ecfbd67535d5dc.img
done
[root@centos7 ~]#

この後、再起動して解像度が設定されていることを確認します。

参考情報

CentOS7の場合、Ubuntu 20.04と異なり、grubでのvideoinfo/videotestコマンドがなく、vdeinfo/vbetestコマンドとなります。

参考として、下記にCentOS7での実行の様子を記載します。

grubメニューで止めて、「c」を入力し、コマンドラインモードに入ります。

CentOS7の場合はvideoinfoが搭載されていないgrubなので「vbeinfo」を実行します。

CentOS7の場合は set pager=1 の設定がされているようで出力が多い場合でも表示を止めてくれます。

表示テストは「vbetest 800x600x32」といった形で実施します。(おなじくvideotestコマンドが無い)

vbetestの終了は強制再起動(ctrl+alt+deleteなど)を行います。

Oracle Linux 8の場合(2021/12/08)

/etc/default/grub にいろいろ記述を入れてみてるのですが、解像度変更ができる気配がない・・・

また、grubでのvideoinfo, vbeinfo, videotest, vbetest はない模様

RHEL 8.6/Oracle Linux 8.6の場合(2022/07/11)

/etc/default/grubのGRUB_CMDLINE_LINUXに「video=800×600」を追加してみたところ、それっぽく動いている。

なお、去年試した時と同じくgrubでのvideoinfo, vbeinfo, videotest, vbetest は存在していないようだ。

/etc/default/grubのGRUB_CMDLINE_LINUXに「video=1024×768」を追加でも大丈夫だった。

投稿日:

LSILogic RAIDのディスク交換をMegaCliを使って行う場合の手順メモ

IBM x3650サーバに入っているLSILogic RAIDカードにて、構成しているディスクが故障したので、ディスクを調達して交換したい。という話があったので、交換手順を確認した。

ついでに一般公開

参考文献
・やっ太郎ブログ:「Megacli64でディスク交換太郎」
・チラシの裏的なBlog:「【備忘録】MegaRAIDでのエラーHDD交換手順」
・IBM Docs:「2073-720 で障害予知機能 (PFA) イベントを報告する、障害が発生したドライブの取り替え」
・Qiita:「HW保守で使いそうなTips 〜ディスク周り〜」

(1) コマンドがある場所に移動

標準では /opt/MegaRAID/MegaCli/ にインストールされていて、PATHは通っていないことが多いので、ディレクトリ移動しておくと以降のコマンドが実行しやすい。

# cd /opt/MegaRAID/MegaCli/
#

(2) コマンド名確認

/opt/MegaRAID/MegaCli/に MegaCliもしくはMegaCli64があるかを確認
移行の手順はMegaCliだったものとして記載している

# ls -F

(3) RAID構成の状態を確認

Stateの状態を確認

# ./MegaCli -LDInfo -Lall -aALL

(4) 物理ディスクの状態を確認

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'

「Firmware state」がディスクの状態でFailedとなっているものが壊れている。

そのディスクについての「Enclosure Device ID」と「Slot Number」の値をこの後の手順で使うので記録しておく。

また「Inquiry Data」にあるディスク型番とシリアルが抜いたディスクとあっているかを確認出来るので、それも記録しておく。

(5) 壊れているディスクの場所を確認

壊れているディスクのLEDを点灯させて交換するディスクと、コマンドで指定する「 physdrv 」の指定が一致していることを、スロットのランプを点灯させて確認する。

下記コマンドを実行すると該当ディスクスロットのランプが点灯

# ./MegaCli -Pdlocate start physdrv[Enclosure Device ID:Slot Number] -a0

下記コマンドを実行すると該当ディスクスロットのランプが消灯

# ./MegaCli -Pdlocate stop physdrv[Enclosure Device ID:Slot Number] -a0

たとえば、Enclosure Device IDが252, Slot Numberが2の場合下記の様に実行する。

  # ./MegaCli -Pdlocate start physdrv[252:2] -a0
  # ./MegaCli -Pdlocate stop physdrv[252:2] -a0

(6) 壊れているディスクをオフラインにする

壊れているディスクをオフラインにする。

# ./MegaCli -PDOffline -PhysDrv [Enclosure Device ID:Slot Number] -a0

Enclosure Device IDが252, Slot Numberが2の場合下記の様になる

# ./MegaCli -PDOffline -PhysDrv [252:2] -a0

なお、壊れ方によっては、すでにオフライン扱いになっていて、このコマンドでエラーとなる場合がある。

(7) 欠落マークがついたRAIDがあるか確認する

6でエラーとなっている場合は、下記コマンドを実行した際に 「Array」と「Row」 といった情報が出力される。このArrayとRowの値はあとで使用します。

# ./MegaCli -PDGetMissing -aALL

6がエラーとなっていない場合は、Array/Rowの出力はないと思われます。

また、MegaCliコマンドのバージョンによっては、このオプションが存在せず、エラーとなる場合があるようです。その際はこの手順を飛ばします。

(8) 壊れているディスクに欠落マークを付ける

まだ壊れていることがきちんと認識されていない場合、壊れていることを確定させます。

# ./MegaCli -PDMarkMissing -PhysDrv [Enclosure Device ID:Slot Number] -a0

Enclosure Device IDが252, Slot Numberが2の場合下記の様になる

# ./MegaCli -PDMarkMissing -PhysDrv [252:2] -a0

MegaCliコマンドのバージョンによっては、PDMarkMissingオプションがないようです
その場合はこの手順を飛ばします。

また、6ですでに欠落マークがついたRAIDが認識されている場合もこの手順は不要であるはずです。

(9) 欠落マークがついたRAIDが認識されたことを確認する

欠落マークがついたRAIDが表示されることを確認します。

# ./MegaCli -PDGetMissing -aALL

この出力中の「Array」と「Row」の番号はあとで使用します。
PDMarkMissingオプションが実行できなかった場合、これも実行できない
と思います。その場合は飛ばします。

(10) 壊れているディスクを抜くことをRAIDコントローラに通知します

下記を実行して、指定したディスクを取り外すことをRAIDコントローラに通告します。

# ./MegaCli -PDPrpRmv -PhysDrv [Enclosure Device ID:Slot Number] -a0

下記の様に実行する

# ./MegaCli -PDPrpRmv -PhysDrv [252:2] -a0

なお、たぶん(6)の段階で欠落マークがついているような場合は、このコマンドを実行するまでもなくディスクが完全に壊れている、と認識されて、すでに抜けるような状態になっているようです。

(11) 壊れているディスクを物理的に抜く

(12) 1分ぐらい待つ

ここで待つのは気休めです。

RAIDコントローラの情報更新間隔がよくわからないので入れてますが、たぶん、すぐに実行しても問題ないような気がします・・・

(13) RAID構成/ディスク認識の状態を確認

ディスクの認識を抜いたことにより、RAID構成の状態が変わっているかを確認します。

# ./MegaCli -LDInfo -Lall -aALL

Stateの状態を確認します。（変わるのかどうかは把握していません）

次に、物理ディスクの状態変化を確認します。

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'

先ほど抜いたディスクに関する表示が消えているはずです。

(14) 新しいディスクを入れる

(15) RAID構成/ディスク認識の状態を確認

RAID状態が変わっているかを確認します。

# ./MegaCli -LDInfo -Lall -aALL

Stateの状態を確認します。
また、RAID構成が新しく認識されていたりしないか確認します。（中古ディスクに情報が残っている場合に発生する可能性がある）

交換したディスクが認識されているかを下記のコマンドで確認します。

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'

(16) 再構築が開始されているかを確認する

RAIDコントローラの設定および交換したディスクの状態によっては、ディスクを交換した時点で、自動的に再構築が開始されます。

下記コマンドで状況を確認します。

# ./MegaCli -pdrbld -showprog -physdrv [Enclosure Device ID:Slot Number] -a0

実行例は下記のようになります。

# ./MegaCli -pdrbld -showprog -physdrv [252:2] -a0

再構築が始まっている場合は progressの数値が徐々に増加していくはずです。

(17) RAIDにディスク交換されたことを認識させる

交換したディスクがスペアディスクなどとして認識されなかった場合は、手動で設定します。

# ./MegaCli -PdReplaceMissing -PhysDrv [Enclosure Device ID:Slot Number] -Array0 -row0 -a0

手順7か手順9で確認したArrayとRowの番号を使ってコマンドを実行します。実行例は下記のようになります。

# ./MegaCli -PdReplaceMissing -PhysDrv [252:2] -Array0 -row0 -a0

PDMarkMissingオプションが実行できなかった場合、これも実行できない
と思います。その場合は飛ばします。

(18) 再構築開始

手動で再構築開始を実行する場合は下記コマンドを実行します。

# ./MegaCli -PDRbld -Start -PhysDrv [Enclosure Device ID:Slot Number] -a0


下記の様に実行します。

# ./MegaCli -PDRbld -Start -PhysDrv [252:2] -a0

(19) 再構築状況を確認

再構築の状況を確認します。

# ./MegaCli -pdrbld -showprog -physdrv [Enclosure Device ID:Slot Number] -a0

下記の様に実行します。

# ./MegaCli -pdrbld -showprog -physdrv [252:2] -a0

(20) RAID構成/ディスク認識の状態を確認

RAID状態が変わっているかを確認します。

# ./MegaCli -LDInfo -Lall -aALL

Stateの状態を確認します。おそらくrebuildなどのステータスになっているかと思います。

また、交換したディスクが認識されているかを下記のコマンドで確認します。

# ./MegaCli -PDList -aALL
# ./MegaCli -PD List  -aALL | egrep 'Slot|Firmware state|Inquiry|Enclo'
# ./MegaCli -PD List  -aALL | egrep 'Slot|state|Data|Raw'