HPE Superdome Flex 280サーバーではLinuxのサポートについて注意が必要(現状RHEL9.0はサポートしない)


2022/12/05追記:2022/11/30にRHEL9.0対応のI/O Service Pack for HPE Superdome Flex Servers Familyがリリースされてました。


HPE Superdome Flex 280サーバーを導入するにあたってLinuxのサポートも必要という話で、RedHat Enterprise Linuxを導入する、という話になった。

ドキュメントを探すと「Installing Operating Systems on HPE Superdome Flex 280 Server」がもっともまとまっている感じだった。

ここの「Supported operating systems」には下記の様に書かれている。

HPE Foundation Software (HFS) version support matrix」を見るとRHEL9.0をサポートしていると読める記述がある。

Software Delivery Repositoryにある「HPE Foundation Software Repository」を見ても指定できるディストリビューションバージョンに9.0が含まれている。

ISOファイルとして入手する場合は「HPE Foundation Software ISO Image for HPE Superdome Flex Servers Family」から入手でき、RHEL9/Oracle Linux 9がサポート対象として記載されている。

上記ページにリンクがある「Running Linux on HPE Superdome Flex 280 Server」は冒頭の「Installing Operating Systems on HPE Superdome Flex 280 Server」を切り出した感じのドキュメントになってようにみえ、特にRHEL9がサポートされない、という認識ではなかった。

しかし!

hpeから、2022年11月2日時点で、HPEがサポートするのはRHEL8.5までで、RHEL8.6とRHEL9.0は現状はサポートしない、との通告を受けた。

なぜ?と聞くと「I/O Service Pack」の対応バージョンが出ていないから、という

確認してみると「Running Linux on HPE Superdome Flex 280 Server」の方には記述がないが、「Installing Operating Systems on HPE Superdome Flex 280 Server」には「HPE Superdome Flex 280 Server I/O Service Pack」という項目がある・・・

しかし、「Customers can use the HPE Superdome Flex 280 Server I/O Service Pack」という表現なので「要求」じゃないはずなのに、要求されている。

ダウンロードリンクは「I/O Service Pack for HPE Superdome Flex Servers Family

firmwareとdriverを新しいものに更新するために使うので、必須ではないはずなのだが、hpeサポートは必須と主張してくる感じです。

じゃあ、RHEL9.0対応版はいつでるの?ときいいてみるものの「不明」という回答。

大丈夫なんか?HPE


2022/11/14追記

RHEL9をサポートするI/O Service Packのリリース見込みがついた、という連絡があったので、とりあえず本件はなんとかなりそう


2022/12/05追記

2022/11/30付けでRHEL8.6とRHEL9.0に対応した「I/O Service Pack for HPE Superdome Flex Servers Family 2022.09」がリリースされていました。

RHEL/AlmaLinux/OracleLinux 9.0でIntel VROCを使うとreboot/shutdown時にハングアップする


Intelのサーバ向けチップセットC600/C220に搭載されているオンボードsSATA RAID機能のIntel® Virtual RAID on CPU(VROC)が使える。

資料は「Support for Intel® Virtual RAID on CPU (Intel® VROC)」からだいたいたどりつけるが重要なものは下記となる。

インテル® Virtual RAID on CPU・ユーザーガイド
 Windows, Linux, ESXiでの利用についてのpdfがある

Linuxの場合、kernelにドライバが組み込まれ、RAID管理はmdadmコマンドを利用して行うようになっている。

RHEL/CentOS 7.3ぐらい以降であれば問題は無い。

当然RHEL/AlmaLinux 9.0でも問題ないのであろうと思ってインストールしてみたところ、再起動/停止(reboot/shutdown)にて問題が発生した。

シャットダウン/再起動実行後、umountの途中で止まる。

上記で少しとまった後、1分ぐらいすると下記の追加出力がある。

そのあと、タイムアウトが終わると下記のdumpを出力して完全に止まる。

RHEL9, AlmaLinux 9, Oracle Linux 9 で試したところ、全て同じエラーで止まっている。

エラーメッセージの中で特徴的な「Unmounting /oldroot timed out」で検索したところ、「Bug 1956133 – System hangs in shutdown stage – mdmon killed by dracut shutdown script」から「Bug 1970610 – On shutdown, “mdadm -vv –wait-clean –scan” hangs, preventing a reboot or poweroff」に到達。

いわく、systemdとmdadmのバグで適切にunmountできないために発生、とのこと。

このBugはFedora 34についてのもので、Fedora 34はRHEL 9.0の元となるバージョンとなる。

RHEL9.0は systemd-250-6、mdadm-4.2-2 で、直っていてもよさそうなんですけど…

出力されているエラーメッセージはxfsに関わるものが多いので、使用するファイルシステムを標準のxfsではなく、ext4に変更すればうまくいくのではないか?と変更してみたところ

ext4でインストールしたRHEL9.0/OracleLinux 9.0は問題無く再起動/停止を行うことができました。

インテルサーバのオンボードRAID(VROC)を使う場合、systemd/mdadmが修正されるまではRHEL9系の導入を見合わせた方がよさそうですね。


2022/11/07追記 なお、この現象が発生したサーバを使わないことになったので、その後の状況については不明です


2023/03/06追記

Lenovoサイトに「RHEL 9.0 fails to reboot or shut down on systems with XFS file system and Intel software SATA/NVME RAID – Lenovo ThinkSystem」という記載を発見

Workaround

There are two workarounds for this issue:

  1. Use the ext4 file system instead of the default xfs.
  2. If the xfs file system must be used, use the following command to shut down or reboot:
    #reboot -f #For restart the machine
    #poweroff -f #For shutdown the machine

「xfsじゃなくてext4を使え」というのはこちらで調査した通りのもの

もう1つは「reboot -f」もしくは「poweroff -f」コマンドを使うと強制的に実行できる、というもの。

なるほど

「This behavior will be corrected in a future release scheduled for First Quarter 2023.」とあるので、そろそろ対処されたものがでるのか?

HPEからも「アドバイザリ: (改訂版) Red Hat Enterprise Linux - Red Hat Enterprise Linux 8.6またはRed Hat Enterprise Linux 9.0で、シャットダウンまたは再起動中にインテルVirtual RAID on CPU (インテルVROC) mdraidアレイがアンマウントされると、システムが応答を停止することがある」(英語版)というのが出てるのだが、「Red Hat Enterprise Linux 9.0については、systemdパッケージを250-6.el9_0.1 (またはそれ以降) にアップグレードします。」という内容。

それじゃ対処されてないはずなんだけどなぁ・・・


2023/05/11追記

どうなったかな?とLenovoとHPEの記述を確認してみたが、変更は無かった。

RedHat「Installing RHEL 9.0 GA on Intel VROC RAID (NVMe) get failed」にも記載がある模様

Windows Server インストール時にドライバ追加したけど、このドライブにインストールすることはできません となる場合


Windows Server 2012R2 / Windows Server 2016 / Windows Server 2019 / Windows Server 2022 の標準的なインストールメディア内にストレージドライバが含まれていない場合、インストール途中にドライバが含まれてるメディアに差し替えて読み込む必要がある。

ストレージがなにも認識されていないので「ドライバーの読み込み」を選択

Windows Serverのインストール用DVDを抜いて、ドライバが含まれているCDに交換して、OK

該当するストレージのドライバディレクトリを指定

指定したドライバが正解であるなら「インストールするドライバーの選択」に表示されます。

次へをクリックしてドライバを読み込みます。

スキャンが終了すると、以下の様にディスクが表示されます。

しかし、よく見てみると「このドライブに Microsoft サーバー オペレーティング システムをインストールすることはできません (詳しい情報の表示) 」という注意マークがついています。

選択した場所に Microsoft Server オペレーティングをインストールできませんでした。 メディアドライブを確認してください。詳細については、次の情報をご覧ください: 0x80300001

これはWindows Serverのインストール用DVDが認識できない場合の表示です。

先ほどドライバが含まれているCDに交換しているので、Windows Server のインストール用DVDに交換し、「最新の情報に更新」をクリックします。

上記の様に警告が消えて「次へ」が選択できるようになりました。

あとは普通に進めていけば大丈夫です。

この現象はWindows Server 2012R2 , 2016, 2019, 2022で発生することを確認しました。

出したくないのであれば、Windows Serverのインストールメディアにドライバを組み込むか、DVDドライブやUSBメモリを複数用意し、同時にマウントするかです。

インストールメディアにドライバを組み込む際の参考資料:UEFIブートのサーバでWindows Server 2016のインストール用USBメモリが起動しない

初期インストール状態のWindows Server 2008 SP2のルート証明書を更新する 2022/07/07版


2022/07/07時点でWindows Server 2008 SP2を新規インストールすると、OSが持っているルート証明書の有効期限が1つ残りして他は切れています。

この結果、何がおこるかと言えば、Windows Update に失敗します。

これはWindows Updateは SSL証明書を使用する https通信を利用していて、いま残っているルート証明書だけでは目的とするサイトにアクセスできないために発生しています。

WIndows Server 2008 R2であればルート証明書の更新プログラムが提供されているのですが、Windows Server 2008には有りません。

いろいろ調べていくとASHER TOOLSの「Root Certificate Updater」というのを発見しました。

こちらPower Shellスクリプトとして作成されており github にてソースコードが公開されています → https://github.com/asheroto/Root-Certificate-Updater

内容を確認すると至って簡単で、要約すると以下を実行しているだけです。

rem 信頼できるルート証明書をダウンロード
certutil -urlcache -f http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab authrootstl.cab

rem 信頼されていない証明書をダウンロード
certutil -urlcache -f http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab disallowedcertstl.cab

rem ダウンロードしたcabファイルを展開
expand authrootstl.cab -R .\
expand disallowedcertstl.cab -R .\

rem 証明書を登録
certutil -addstore -f root authroot.stl
certutil -addstore -f disallowed disallowedcert.stl

実際に実行してみます。

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

C:\Users\Administrator>mkdir t

C:\Users\Administrator>cd t

C:\Users\Administrator\t>certutil -urlcache -f http://ctldl.windowsupdate.com/ms
download/update/v3/static/trustedr/en/authrootstl.cab authrootstl.cab
****  Online  ****
CertUtil: -URLCache コマンドは正常に完了しました。

C:\Users\Administrator\t>certutil -urlcache -f http://ctldl.windowsupdate.com/ms
download/update/v3/static/trustedr/en/disallowedcertstl.cab disallowedcertstl.ca
b
****  Online  ****
CertUtil: -URLCache コマンドは正常に完了しました。

C:\Users\Administrator\t>expand authrootstl.cab -R .\
Microsoft (R) File Expansion Utility  Version 6.0.6001.18000
Copyright (c) Microsoft Corporation. All rights reserved.

.\authroot.stl を展開キューに追加しています

ファイルを解凍しています...

ファイルの解凍が完了しました...

C:\Users\Administrator\t>expand disallowedcertstl.cab -R .\
Microsoft (R) File Expansion Utility  Version 6.0.6001.18000
Copyright (c) Microsoft Corporation. All rights reserved.

.\disallowedcert.stl を展開キューに追加しています

ファイルを解凍しています...

ファイルの解凍が完了しました...

C:\Users\Administrator\t>certutil -addstore -f root authroot.stl
root
証明書 "CN=Microsoft Certificate List CA 2011, O=Microsoft Corporation, L=Redmon
d, S=Washington, C=US" がストアに追加されました。
証明書 "CN=Microsoft Certificate Trust List Publisher, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US" がストアに追加されました。
CertUtil: -addstore コマンドは正常に完了しました。

C:\Users\Administrator\t>certutil -addstore -f disallowed disallowedcert.stl
disallowed
証明書 "CN=Microsoft Certificate List CA 2011, O=Microsoft Corporation, L=Redmon
d, S=Washington, C=US" がストアに追加されました。
証明書 "CN=Microsoft Certificate Trust List Publisher, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US" がストアに追加されました。
CertUtil: -addstore コマンドは正常に完了しました。

C:\Users\Administrator\t>

実行後はOSの再起動が必須です。

再起動後 certmgr.msc を実行して確認すると有効期限が切れていない証明書が増えています。

これでWindows Updateもうまくいことでしょう!

あれ?

次!

エラーコード 80072efeで検索すると「Windows Server 2008 R2 でWindows Updateが実行できない」というのを発見

こちらはWindows Server 2008 R2の事例ですが、「トランスポート層セキュリティ 1.0 および 1.1 の無効化」によりTLS1.0/TLS1.1アクセスが廃止されたためにアクセスできないのでは?という推測から対処を行っているが、KB3140245 はWindows Server 2008に対応して折らず、またレジストリを設定してみても状況は変わらない。

お手上げになったのでとりあえずWSUS Offline Updateを適用してみて、何のパッチが増えたのかを確認

まず、ルート証明書が増えている

しかし、WSUS Offline Update実行中にKB???? といったファイルが8個ぐらい適用されたような感じだったのに、更新履歴にはない

しかし、Windows Updateはできるようになった。

WSUS Offline Updateのログは %SystemRoot%\wsusofflineupdate.log にあるので確認してみる

2022/07/07 17:23:37.24 - Info: Started service 'Windows Update' (wuauserv)
2022/07/07 17:23:39.39 - Info: Installed ..\w60-x64\glb\windows6.0-kb3205638-x64_e32da6effffd299aaacb0f293602c7e55832bfad.cab
2022/07/07 17:23:45.73 - Info: Installed ..\w60-x64\glb\windows6.0-kb4012583-x64_e881e527ca32b3c47b008fd42ea1ecc87c017a71.cab
2022/07/07 17:23:47.38 - Info: Installed ..\w60-x64\glb\windows6.0-kb4022887-x64_fb2bd4b42ea68149eeffc1ef53bb469345c36f26.cab
2022/07/07 17:23:49.11 - Info: Installed ..\w60-x64\glb\windows6.0-kb4022883-x64_519ce72edf20b1a75c181362d75e13a22242f455.cab
2022/07/07 17:23:53.48 - Info: Installed ..\w60-x64\glb\windows6.0-kb4493730-x64_de2cd401093a5c42254c7bd69349821ad10341ff.cab
2022/07/07 17:24:32.75 - Info: Installed ..\w60-x64\glb\windows6.0-kb4474419-v4-x64_a5f1b40e6afb4874248c3a71583010b4b7d4512e.cab
2022/07/07 17:25:47.35 - Info: Installed ..\w60-x64\glb\windows6.0-kb4537830-x64_b91926b46eb406b6a52766e7fc8c88e4255a192c.cab
2022/07/07 17:26:50.90 - Info: Installed ..\w60-x64\glb\ie9-windows6.0-kb4525106-x64_72d91f2712d4a944b285407f774db20298b19624.cab
2022/07/07 17:26:50.93 - Info: Installed 8 updates
2022/07/07 17:26:50.93 - Info: Installed Windows Update scan prerequisites
2022/07/07 17:26:50.93 - Info: Installation successful (Updates pending)
2022/07/07 17:26:50.95 - Info: Ending WSUS Offline Update

Windows Updateを適用するために上記8個の更新を適用しているらしい。

とりあえず、Windows Server 2008 SP2+Internet Explorer 9インストール直後という状態にもどしてから、下記をダウンロードして順に適用してみた。

KB3205638は何故かWindows Server 2008 for x64-Based System用だけない けどVista x64用で適用できた

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4012583)

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4022887)

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4022883)

Windows Server 2008 for x64-Based Systems 用セキュリティ更新プログラム (KB4493730)

2019-09 x64 ベース システム用 Windows Server 2008 のセキュリティ更新プログラム (KB4474419)

2020-02×64 ベース システム用 Windows Server 2008 サービス スタック更新プログラム (KB4537830)2019-11×64 ベース システム Windows Server 2008 用 Internet Explorer 9 の累積的なセキュリティ更新プログラム (KB4525106) は下記の様なメッセージが出て適用失敗。おそらく証明書更新関連の問題している。

再起動後、Windows Update履歴を確認すると下記の状態となっている。

certmgr.mscを確認すると、Microsoft関連のルート証明書が追加されているのを確認。

また、Windows Updateもできるようになっていた。

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 を開こうとするが開けずエラーとなる。

再起動して、もう1回、「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」で起動して、[コンピュータの構成]-[管理用テンプレート]-[システム]-[インターネット通信の管理]-[インターネット通信の設定]を開き、「ルート証明書の自動更新をオフにする」を「未構成」から「無効」に変更します。

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

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)というのがあり、対策2が使えそうだが、初手のルート証明書入手先が現存していない。(英語版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