IBMサーバーは、UEFIからOSへの起動に長い時間がかかります
IBM System x3620サーバーのペアを持っています。これらのサーバーは、オペレーティングシステムが引き継ぐポイントに最終的に到達すると問題なく動作しますが、新しい永遠に新たな問題のあるUEFIブートシステムを通過するには5分ほどかかります。多分もっと長い。計時はしていませんが、待っている間に一杯のコーヒーを飲みに行くようなもので、戻ってきたときもそうです。
通常、これらをシャットダウンするのは、毎月のメンテナンスサイクル（通常はWindowsの更新のみ）のみです。組み込みのメンテナンス時間なので、余分な5分はSLAにカウントされず、大したことではありません。ただし、機能停止が発生する可能性がある場合は、その5分を元に戻したいと思います。先に進んで起動するように彼らに伝えるために何かできることはありますか？追加のブートオプションに関する限り、無効にできることがわかっているものはすべて無効にしています。
すべてのIBM uEFIマシンの起動にはagesが必要です。これは、uEFIの初期化とモジュールの起動後、レガシーBIOSエミュレーションが起動し、PCI-EオプションROMが実行されるなどです。これは「通常」です。 "すべてのIBM uEFIマシン-ブレードサーバーか標準ラックサーバーかに関係なく。
レガシーBIOSブート、オプションROMを無効にし、ブート順序を最適化し、通常、そのマシンをIBMが提供する最新のファームウェアレベルに保つことができます。
System X uEFIのレガシー実装は非常に遅いため、クライアントへのプラットフォームとしての販売を避けることすらできるかもしれません。
OSプロンプトが表示されるまでレガシーUSBキーブートを開始する時間をIBMから測定すると、途方もなく長いです。私はPuppy Linuxのように動作するSmartOS（illumos/opensolarisの派生物であり、起動すると目的が実行され、Solaris 11のように動作します）を使用しています。 275MBの「圧縮」ブロブ（OS全体）をロードしてから、メモリ内でOSを起動します。 これは、レガシーブートのIBM uEFI実装の問題を実際に示しています。
BEG：1:27:05 pm（SmartOS USB 2.0 USBキーを開始） END：1:33:38 pm（SmartOSの実行を完了-275MB読み取ります） - - TOOK：6:33（6分33秒-かなり遅い-わずか0.75MB /秒）
これは、UEFI実装が、読み取り中に大きなバッファーではなく、512バイトの読み取りのような小さなブロックサイズを使用するかのようです。 OSに入ると、起動したUSBキーのパフォーマンスをベンチマークできます。IBMUEFIコードが8192ブロックサイズまたは32768ブロックサイズを読み取れば、ブートは非常に高速になります。
したがって、SmartOSオペレーティングシステムで、USBキーの512バイトから131072バイトまでのパフォーマンス特性を確認しました。 8192ブロックサイズ（ブートされたOSで12.3 MB /秒）または32768ブロックサイズ（ブートされたOSで20.2 MB /秒）のどちらかが良い選択のようです。また、512のブロックサイズ（ブートされたOSでは0.64 MB /秒）と一致しているように見えます。これは、長いブーツで経験しているように見える結果にかなり近いものです。
time dd if =/dev/dsk/c1t0d0p0 of =/dev/null bs = 512 count = 524288 524288 + 0 records in 524288 + 0 records out 実31m19.499s => 00.64MB /秒。 Solaris 11のようなSmartOS（これはIBM BIOSの起動速度です） time dd if =/dev/dsk/c1t0d0p0 of =/dev/null bs = 1024 count = 262144 262144 + 0レコードイン 262144 + 0レコードアウト 実1m39.989s => 02.56MB /秒。 Solaris 11のようなSmartOS time dd if =/dev/dsk/c1t0d0p0 of =/dev/null bs = 2048 count = 131072 131072 + 0 records in 131072 + 0は記録します 実0m50.215s => 05.09MB /秒。 SmartOS like Solaris 11 time dd if =/dev/dsk/c1t0d0p0 of =/dev/null bs = 4096 count = 65536 65536 + 0 records in 65536 + 0は記録します 実0m33.056s => 07.74MB /秒。 SmartOS like Solaris 11 time dd if =/dev/dsk/c1t0d0p0 of =/dev/null bs = 8192 count = 32768 32768 + 0 records in 32768 + 0は記録します 実0m20.757s => 12.33MB /秒。 SmartOS like Solaris 11 time dd if =/dev/dsk/c1t0d0p0 of =/dev/null bs = 32768 count = 8192 8192 + 0 records in 8192 + 0はレコードを記録します 実0m12.785s => 20.02MB /秒。 Solaris 11のようなSmartOS（Win7ボックスで予想され、見られるように） time dd if =/dev/dsk/c1t0d0p0 of =/dev/null bs = 131072 count = 2048 2048 + 0レコードイン 2048 + 0レコードアウト リアル0m11.532s => 22.19MB /秒。 Solaris 11のようなSmartOS
UEFI（BIOS）rev 1.13（12GB ram、1つの2.266GHz Xenonプロセッサー）を搭載した次の新しいIBM x3550 M3を使用していました
ファームウェアタイプバージョン文字列リリース日 IMM YUOOC7E 09/30/2011 UEFI D6E154A 09/23/2011 DSA DSYT89P 2011/10/28
IBM UEFI実装のレガシーBIOSモードでのUSBブートの「速度」に私は非常にがっかりしていると言わざるを得ません。
私の275MBイメージを考えるための食料Supermicro XSCA9FまたはOracle-Sun X4275は、それぞれ275 MBのUSBキーイメージを32または33秒で起動しますが、IBM x3550 M3は363秒以上かかります同じ画像（11倍遅い）の場合。
このパフォーマンスは完全に許容できず、問題はSystem Xライン全体に存在します。私はIBMと連絡を取りましたが、彼らはuEFIブートロードを試すと言っています（これは、UEFI仕様を学び、GRUB2を学び、独自のカスタムブートローダーを書くように言うのと同じですが、実行可能ですが、追加の2はありません-3週間でこの問題が発生します）。はい、「純粋な」uEFIブートを使用すると高速に動作するはずですが、それを証明することはできませんが、「標準のディストリビューション」を使用できず、また、自分のuEFIブートローダーを書かざるを得ませんでした。
この「レガシーブートが遅い」という問題は、IBM問題/チケット番号A02PGGKで報告されました。uEFI開発者（Michael Brinkmanだと思います）に直接問い合わせてみましたが、IBMはこの問題を認めようとはしていません。影響を受ける人々と企業の大きなコミュニティ。
http://communities.intel.com/thread/3909?wapkw=uEFI にも同様の分析をスレッドに投稿しており、2009年9月の「スローブート」についても説明しています。私が見てきた同じ問題
起動時間が遅すぎる。 EFIを使用した場合、VMware ESXの起動には約20分かかりますが、通常のBIOSでは2分未満です
これは、私が経験する10倍または11倍のスローダウンと同じです。うまくいけば、いつかIBMがこれを修正するでしょう。
ジョン・ストラバラ