GRUB HDDアップグレード後、メニューの前にハングアップします。デバッグ方法は？

Question

4 x 1のサーバーで問題がありますTB Debian wheezyを実行しているドライブとGRUB 1.99-27 + deb7u3。

sdaとsdbには、（Linuxソフトウェア）RAID1を使用してミラーリングされたパーティションがあり、_/boot_が含まれています。 sdcとsddにはそれぞれ1つのパーティションがあり、LVM物理ボリュームをデータ用にミラーリングします。 GRUBはsdaとsdbにインストールされています。mdadmを_--fail_と_--remove_に使用しました1 TB sdc 、古いドライブ（ST91000640NS）を新しい2 TB ST2000NX0243。

新しいドライブが入った状態で、GRUBは

_GRUB loading.
Welcome to GRUB!
_

メニューを表示できません。 sdcのドライブライトは継続的に点灯しているので、おそらくGRUBコアは、/ boot/grubにアクセスする必要はありませんが、そのドライブを読み取ろうとしています。同じモデル。どちらもsmartctlで正常にテストされ、同じ結果が得られます。sdcドライブベイが空の場合、すべてが正常に起動します。システムはライブUSBから起動し、新しいドライブにアクセスできるため、ハードウェアではありません。 incompatibility（*）。削除されたのはsdcだったと思いますが、BIOSがドライブを再注文したことを示すものはありません。

（*）これは安全な仮定ではなかったかもしれません。回答を参照してください。

だから私は次の関連する質問があります：

1. GRUBコアに組み込まれたRAIDサポートで、変更された論理セクターサイズ（512バイトではなく4096）が問題を引き起こしている可能性がありますか？少なくとも_grub rescue>_プロンプト？4Kの問題により、ドライブをLinux RAIDに使用できなくなることはありますか？
2. これを解決する最も速い方法は何ですか？ [以前の提案が含まれています：新しいドライブを取り付けた状態でGRUBを再インストールする必要がありますか？その場合、どのようにですか？GRUB同じシステム）に同じ問題がありますか？それはGRUBの既知のバグですか？アップグレードする必要がありますか？これらに対する回答は次のようです：いいえ、はい、いいえ。] GRUB = Debianが使用するイメージプレフィックス？
3. GRUBのこの段階をデバッグするにはどうすればよいでしょうか？組み込まれているモジュールに敏感かもしれませんが、それをどのようにして見つけますか？

_debug=all_だけのdebug.cfgと次のようなものを考えています：

_grub-mkimage -c debug.cfg -o dcore.img configfile normal raid fs multiboot
grub-setup -c dcore.img /dev/sda
_

それはうまくいくでしょうか？ （私は自分の答えでこのポイント3に対処しますが、私の場合のハングは組み込み構成が実行される前に発生するようです。）

システムの詳細

視覚化に役立つ場合は、lsblkの出力の一部を次に示します。

_NAME                             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdb                                8:16   0 931.5G  0 disk  
├─sdb1                             8:17   0   957M  0 part  
│ └─md0                            9:0    0 956.9M  0 raid1 /boot
├─sdb2                             8:18   0   9.3G  0 part  
│ └─md1                            9:1    0   9.3G  0 raid1 /
├─sdb3                             8:19   0 279.4G  0 part  
│ └─md2                            9:2    0 279.4G  0 raid1 /var
└─sdb4                             8:20   0 641.9G  0 part  
  └─md3                            9:3    0 641.9G  0 raid1 
    ├─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
    └─vg0-swap (dm-2)            253:2    0    32G  0 lvm   [SWAP]
sdc                                8:32   0 931.5G  0 disk  
└─sdc1                             8:33   0 931.5G  0 part  
  └─md4                            9:4    0 931.5G  0 raid1 
    └─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
sdd                                8:48   0 931.5G  0 disk  
└─sdd1                             8:49   0 931.5G  0 part  
  └─md4                            9:4    0 931.5G  0 raid1 
    └─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
sda                                8:0    0 931.5G  0 disk  
├─sda1                             8:1    0   957M  0 part  
│ └─md0                            9:0    0 956.9M  0 raid1 /boot
├─sda2                             8:2    0   9.3G  0 part  
│ └─md1                            9:1    0   9.3G  0 raid1 /
├─sda3                             8:3    0 279.4G  0 part  
│ └─md2                            9:2    0 279.4G  0 raid1 /var
└─sda4                             8:4    0 641.9G  0 part  
  └─md3                            9:3    0 641.9G  0 raid1 
    ├─vg0-home (dm-0)            253:0    0   1.4T  0 lvm   /home
    └─vg0-swap (dm-2)            253:2    0    32G  0 lvm   [SWAP]
_

これは2010年より前のBIOSであり、EFI機能はありません。

無関係：実行中のシステムでは、grub-installで取得したものと同じLVMエラーが次のように表示されますが、すべてが機能しているように見えます（GRUB 2.02）で修正されているようです）。

_# grub-fstest /dev/sda cp '(loop0,msdos1)/grub/grub.cfg' grub.cfg
error: unknown LVM metadata header.
_

以下の回答のデバッグメソッドは、sd [ab]にインストールされるイメージのプレフィックスが次のとおりであることを示しています。

_grub-mkimage -d /usr/lib/grub/i386-pc -O i386-pc --output=/boot/grub/core.img '--prefix=(mduuid/<UUID of sdN1>)/grub' biosdisk ext2 part_msdos part_msdos raid mdraid09
_

'part_msdos'が繰り返される理由がわかりません。 gptテーブルはありません。 md0（ブート）はRAIDスーパーブロックバージョン0.9を使用し、md1、md2、md4（これらは古いアレイです）を使用します。 md3はスーパー1.2ですが、ブートに関与すべきではありません。

---

更新

これまでの提案に感謝します。さらにテストした後：

• BIOSはすでにsda（ata1.00）を使用して起動するように設定されています。 GRUBが_dpkg-reconfigure grub-pc_を使用してすべてのドライブに再インストールされた後、何も変更されず、GRUBが新しいドライブがSATAで接続されている場合でもメニューの前にハングします。これは、/ boot/grubの内容がコアイメージと一致しないために説明できなかった可能性があります。同様に、ドライブを物理的に再配置しても違いはありません。
• Debian JessieでのGRUBから2.02へのアップグレードは、_Welcome to GRUB!_メッセージが出力されないという効果しかありません-代わりに、グラフィックスモードを変更する限り発生します。条件。
• 組み込み構成がdebug変数を設定する前に、ハングが発生しているように見えます。有用なデバッグ情報は出力されません。
• GRUBは、プリフィックスがUUIDを使用しないリムーバブルメディアから起動したときにメニューを表示します。このようにして、物理的に存在するドライブでシステムを起動することができます。ただし、ドライブのTAB列挙はフリーズします。予想通り、ハードドライブからのチェーンロードGRUBは以前と同様にハングします。同じシステムから_grub-mkrescue_によって作成されたUSBドライブからのブートもハングします。
• 別の障害として、ライブシステム（Linux 3.2.0-4-AMD64）で、内部SATAまたはUSB経由で新しい4KnドライブをRAID1アレイに追加しようとすると、デバイスで_Bad block number requested_が発生し、その後mdシステムがドライブに障害を起こすと、_BUG: unable to handle kernel paging request_とカーネルがエラーになります。 （_mdadm --remove_は、失敗した要素がビジーであり、md-resyncプロセスがSIGKILLに応答しないことを示しています。私は_echo frozen > /sys/block/mdX/md/sync_action_を試していません。SATAでddを使用してドライブをテストすると、すべてが表示されます結構です。）。 Linux MDドライバーは4Knドライブを古いドライブと同期でき、BIOSを使用しませんか？

したがって、回避策には、非RAIDパーティションを_/boot/_としてマウントすることが含まれる場合があります。 GRUBをデバイス依存のプレフィックス付きでインストールする、またはBIOSをフラッシュする。最も賢明なことは、おそらくドライブを交換するためにサプライヤーに連絡することです。

言い換えると、質問3には、GRUB機能要求の対象となる可能性があるソリューションがあります。質問2は間違ったツリーを発生させていたので、私はそれを修正しました。トピックから遠く離れていませんが、ドライブがLinux RAIDに使用できないように見える理由について追加で説明しています。

このいずれかについてのきちんとした説明、RAID再同期バグに関する何か、または4Knサポートのためのflashromの使用の逸話、grub-installにUUIDを使用しないように指示する方法または関連するシステム管理者のヒント。

Answer 1

現在、自分の質問に答えています。1.これは4Kn（「高度なフォーマット」）の問題ですか？

はい

4Knドライブはあなたが思うほど広くサポートされていません ;たとえば、Windows 7またはGRUB 1または多くのIntelチップセット）と互換性がありません。私の場合、問題はマザーボード上のIntel 82801I Enterprise Southbridgeコントローラーチップ（ICH9ファミリー）のようです。これは、USB経由でもmd_resyncへのドライブが部分的に失敗する理由でもあると思います。上記のリンクの分析では、Intelの公式サポートがないにもかかわらず、Linux ata_piixドライバーがIntel ICH10経由で4Knで正常に機能しているようです。IドライブがAHCIで動作するか、SAS=モードで動作するかどうかをテストしていません。

ドライブの互換性情報を知っている可能性が高いのは、マザーボードの製造元、または完全なテストを実施した他の誰かだけです。単純な読み取りと書き込みが機能したからといって、「ハードウェアの非互換性ではない」と結論を下しました。このマザーボード用に更新されたBIOSが4Knをサポートしないのには理由があります。マザーボードが確実にサポートしないためです。

これらの状況で同等の512eドライブが機能しない理由はありません。

Answer 2

デバッグを有効にしてGRUBをインストールする手順について、質問の3番目の部分に回答します。問題が発生する可能性のある場所に関する情報に基づいた提案、またはダウンタイムを最小限に抑え、原因に関する情報を最大限に活用して解決するための戦略に感謝します。

---

いくつかの一般的なポイント：GRUBは他のデバッグ方法を提供します-grub-mkrescueは、組み込みが必要になる可能性があるすべてのモジュールを含む.isoを生成します。そのため、ライブUSBを使用してRAIDアレイをナビゲートすることができます.cfgファイルまたはカーネルをロードしてみます。 grub-emuエミュレーターはほとんどのディストリビューションで使用できますが、メニューがどのように表示されるかを重視しています。より高度なのは、標準のGRUBモジュール シリアルケーブルを介したgdbを使用したデバッグ です。

デバッグを有効にしてGRUBをインストールする手順

そのため、デバッグメッセージを取得する手順は GRUBマニュアル セクション6で言及されていますが、詳細は記載されていません。最初に検討したいのは、シリアルコンソールでデバッグを実行し、scriptの前にscreenを実行してデバッグメッセージを記録することです。明らかにroot権限が必要です。この回答のドライブレイアウトは必ずしも質問と一致せず、単なる例であることに注意してください。通常の（デバッグではない）GRUBが必要に応じて他のドライブにインストールされていると想定します。これは、ブートするドライブにデバッグGRUBをインストールするための手順にすぎません。 （つまり、デバッグメッセージにより、どのドライブが起動しているかが明確になります。RAIDパーティションにインストールする場合、プレフィックスはどちらの場合も同じである可能性が高いため、/dev/sdaに対して/dev/sdbと同じコマンドを実行できます。）

まず、既存のgrubファイルの場所、/boot/grub、または可能性の高い/boot/grub/<platform>を確認します。この場合、それらは/boot/grub/i386-pc/にあると想定します。そこにあるファイルは変更しませんが、デバッグを有効にしてコアイメージを追加します。 .cfgファイルが存在しないか変更されている場合は、grub-mkconfig -o /boot/grub/grub.cfgを使用して標準として再生成します。

インストールされているモジュールとプレフィックスの確認

コアイメージに既にコンパイルされているモジュールをすばやく簡単に表示するには、grub-installをもう一度実行します。これはGRUB 2.02で機能します。

grub-install -v /dev/sda 2>&1 | grep '\(mkimage\|setup\)'

RAIDまたはlvmのない単純なケースでは、これによりext2 part_gpt biosdiskのようなリストが表示される場合があります。ただし、GRUB 1.99は詳細に-vを使用しないため、代わりに--debugを使用します。これを、実際にイメージをインストールしないようにするトリックと組み合わせて、少し時間を節約します。

grub-install --debug --grub-setup=/bin/true /dev/sda 2>&1 | grep '\(-mkimage\|-setup\|true\)'

grub-installは、呼び出すプログラムの代わりにシェルスクリプトを実行できるため、代わりに次のようなことを行うことができます。

# create grub-mkimage wrapper
cat > /usr/local/bin/grub-mkimage.sh <<"EOF"
echo Arguments to grub-mkimage: $*
/usr/bin/grub-mkimage $*
EOF
# create a dummy grub-setup
cat > /usr/local/bin/grub-setup.sh <<"EOF"
#!/bin/bash
echo Arguments are: $*
EOF
# run grub-install using the above
chmod u+x /usr/local/bin/grub-*.sh
grub-install --grub-mkimage=/usr/local/bin/grub-mkimage.sh \
  --grub-setup=/usr/local/bin/grub-setup.sh /dev/sda 2>&1 \
  | grep 'Arguments' | tee grub-args.txt

もちろん、パスはディストリビューションと選択したシェルによって異なる場合があります。

デバッグ変数の設定

ここで、デバッグ設定でdebug.cfgを呼び出すことができるファイルを作成します。 （この段階でコメントが発生すると、コアは致命的でないエラーを生成するため、何も使用しません。）

set pager=1
set debug='init modules disk ata,scsi,linuxefi,efi,badram,drivemap linux,fs,elf,dl,chain serial,usb,usb_keyboard,video'
set

空白、,、;、または|の任意の組み合わせを使用して、文字列内のモジュール名を区切ることができます。

デバッグ機能のリストをGRUB 2.02ソースから抽出し、それらを意味的に順序付けました。 'all'は、scriptingインタープリターから大量のメモリー情報を生成します。 「xfs」や「reiserfs」、「net」、「partition」、「loader」などの特定のファイルシステム用の追加機能があります（「loader」は、メニューの前に興味があるものには遅すぎます。メニューを取得できます。そこでデバッグ変数を設定できます。）残念ながら「mdraid_linux」ソースにはデバッグメッセージはありませんが、diskは最も重要な操作を示します。

pager変数は、デバッグメッセージを読み取るために必要です（たとえばscriptを使用して）コンソールでキャプチャしない場合。 pagerはsleepやconfigfileのような追加のモジュールを含まないと機能しないことがわかりました。これは画像のサイズを2倍以上にします。デバッグ環境変数は関係なく有効になります。

取り付け

次に、デバッグするイメージのバリアントイメージを作成します。

grub-mkimage -p '(,msdos3)/boot/grub' -c debug.cfg \
   -O i386-pc -o dcore.img -C auto ext2 part_msdos biosdisk

ここで、モジュールのリストは、デバッグするgrub-installからのものであり、sleepまたは必要なその他のものを含めます。プレフィックス-pもgrub-installの出力からコピーする必要があります。これは、明らかにGRUBバナーの後に何が起こるかに大きな影響を与えるためです。ただし、標準のUUIDではなく、（この場合のように）GRUBデバイスコードを使用して実験することもできます。 lsblk -o NAME,TYPE,FSTYPE,LABEL,SIZE,STATE,UUIDまたはls -l /dev/disk/by-id/でUUIDを表示でき、mdadm --detail /dev/sdaでRAIDドライブに表示できます。

次に、作成したコアを通常起動するディスクにインストールします。

cp dcore.img /boot/grub/i386-pc
grub-bios-setup -d /boot/grub/i386-pc -c dcore.img /dev/sda

2.0より前のバージョンのGRUBの場合、マニュアルのようにgrub-bios-setupコマンドは引き続きgrub-setupと呼ばれることがあります。

リブート。メニューが表示される前に（場合によっては表示されません）、Welcome to GRUB!に続いてデバッグメッセージの数ページが表示されます。

Answer 3

2番目の質問に答えるために、2.02でパッチされた raid1に関連するバグ があります。

このバグが2.02〜beta1（バグが報告されたバージョン）より前に存在していたかどうかがわからない場合でも、役立つことを願っています。

edit：また、これを投稿した直後に疑問が浮かびました：RAID1はソフトウェアまたはハードウェアRAIDですか？