web-dev-qa-db-ja.com

Ubuntu：起動時にmdデバイスはどのように組み立てられますか？

Ubuntuの起動時にmdデバイスはどのように組み立てられますか？ /etc/mdadm/mdadm.confは本当にここで関連する要素ですか？

私のmdadm.confは正常です。レスキューCD環境にいるときに確認しました。 mdadm -A --scanを実行すると、必要に応じてデバイス名を見つけて割り当てます。 mdadm.confにはAUTO -allが含まれており、配列の組み立てからすべての自動化を排除します。

私がする必要があるのは、ブート時にmdadm.confで概説されているようにmdデバイスを自動アセンブルできるようにすること、またはアセンブル時に0.9アレイのsuper-minor値を尊重し、 1.2配列のname（どうやら<hostname>:<super-minor>）であり、mdadm.confなしで正しいことを行います。私はどのパズルのピースが欠けていますか？

次の問題があります。 RAID1を備えた2つのmdデバイス（md0およびmd1）とRAID6を備えた1つ（md2）があります。 必要なデバイス名でそれらを参照しています。 md0にはメタデータバージョン0.9があり、他の2つにはバージョン1.2があります。 md0は/にマップされ、他の2つはbootingには関係ありません。

ブートドライブはGPTパーティションです。その上に接着剤「BIOSブートパーティション」（sda1）があります。 grub-install --no-floppy /dev/sdaは成功を報告します。

  • md0 == sda3 + sdb3
  • md1 == sda2 + sdb2
  • md2 == sdc + sdd + sde + sdf + sdg + sdh
  • sda1およびsdb1は、それぞれ「BIOSブートパーティション」です

GRUB2は/boot/grub/devicemapに満足しています。私はそれを提供し、part_gpt、raid、mdraid09およびext2をモジュールに追加してGRUB2にプリロードしました。

まだレスキュー環境にルートボリュームが残っているので、すべてをマウントしてからchrootedしました。

mkdir /target
mount /dev/md0 /target
mount -o bind /dev /target/dev
mount -o bind /dev/pts /target/dev/pts
mount -o bind /sys /target/sys
mount -o bind /proc /target/proc
chroot /target /bin/bash

そこから、super-minorのmd0をリセットし（メタデータ0.9を使用）、md1とmd2のnameをリセットします。また、mdadm --detail ...を使用して動作することを確認しました。それ以外に/etc/default/grubを調整し、update-grubとgrub-install --no-floppy /dev/sdaとgrub-install --no-floppy /dev/sdbも実行しました。

その後、起動すると、ルートファイルシステムをマウントできなかったため、常にinitramfsレスキューシェルに移動しました。 /proc/mdstatを確認した後の理由は、それぞれのmdデバイスがアセンブルも実行もされていないためです。他の2つの（メタデータバージョン1.2）ドライブは、125..127の範囲のどこかにデバイス番号を受け取ることは言うまでもありません。

注： GRUB2がブートディスクから起動します。したがって、少なくとも、正しく埋め込まれています。問題は、最初のrootfsから適切なルートファイルシステムへの移行です。

linuxubuntugrub2mdadminitrd
8
0xC0000022L

基本的な起動プロセス

グラブ

  1. Grubは、MBRからディスク、md、ファイルシステムなどのコードを読み取ります。
  2. Grubは/ bootパーティションを見つけて、残りの部分を読み取ります。構成と、構成が指定するすべてのモジュールには、ロードが必要です。
  3. Grubは、通常、カーネルとinitramfsをメモリにロードしてカーネルを実行するように指示するconfigの指示に従います。

フォールバックモードがあり、Grubが実際にファイルシステムを読み取ることができない場合に備えて—ブートレコードにそのすべてのコードを埋め込むための十分なスペースがないか、またはファイルシステムまたはその下のレイヤーを認識していないためです。この場合、GRUBはセクターのリストを埋め込み、それらからコードを読み取ります。これはmuch堅牢性が低く、回避するのが最も良い方法です。カーネルとそのようなinitramfs（わからない）。

カーネル

その後、カーネルが制御を取り、基本的なハードウェアの初期化を行います。この段階はかなり早いです。次に、カーネルはinitramfsをtmpfsに解凍し、そのtmpfsで/initを探します。次に、それが実行されます（通常の意味では、カーネルはこの時点でフル稼働しています）/init。ちなみに、これは昔ながらのシェルスクリプトです。

Initramfs

mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-3.8-trunk-AMD64 | cpio -idmvのようなことを行うことにより、initramfsを手動で抽出できます。

Initramfsは、すべてのドライバのロード、udevの起動、ルートファイルシステムの検索を担当します。これは失敗しているステップです。ルートファイルシステムが見つからないため、エラーが発生します。

Initramfsが完了すると、ルートファイルシステムがマウントされ、制御が/ sbin/initに渡されます。

システム起動

この時点で、あなたのinitが引き継ぎます— Ubuntuは現在upstartを使用していると思います。

壊れたもの

何が壊れているのかは完全にはわかりませんが（一部、告白します。これは、UbuntuよりもDebianでの動作がよく似ているためですが、似ていますが）、いくつかの提案があります。

  • Initramfsには、独自のmdadm.confのコピーがあります。修正するには、update-initramfs -uを実行する必要があるだけかもしれません。
  • ブートメッセージを確認します。エラーの可能性があります。 'quiet'と 'splash'を取り除き、カーネルラインに 'verbose'を追加して、実際にそれらを確認します。
  • 使用するストレージによっては、rootdelayパラメータの設定が必要になる場合があります。
  • シェルプロンプトにダンプすると、コマンドは多くありませんが、mdadmはあります。何が問題だったかを理解してみてください。問題を修正すると、ブートを続行できます。
17
derobert

さて、私はただ一つのピースが欠けていたことがわかりました。 initrd画像はmdadm.confをいじった後に更新されていませんでした。

それで私は何をしましたか？

Ubuntu ServerのインストールCDのレスキューシステムを起動しました。インストーラー環境からシェルを実行することを選択し、ルートファイルシステムを使用することをしないことを選択しました。次に（#が前に付いたコメント）：

cat /proc/mdstat
# It showed me md125, md126 and md127
# Stop those:
mdadm -S /dev/md125
mdadm -S /dev/md126
mdadm -S /dev/md127
# Assemble the root volume (meta-data version 0.9)
mdadm -Av --update=super-minor --run /dev/md0 /dev/sda3 /dev/sdb3
# Assemble the other two arrays, updating the names (meta-data version 1.2)
mdadm -Av --update=name --run /dev/md1 /dev/sda2 /dev/sdb2
mdadm -Av --update=name --run /dev/md2 /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh
# Check the outcome:
cat /proc/mdstat
# See preferred minor and names:
mdadm --detail /dev/md0
mdadm --detail /dev/md1
mdadm --detail /dev/md2
# All is fine, so proceed ...
# Create directory for the chroot:
mkdir /target
# Mount root volume on it
mount /dev/md0 /target
mount -o bind /dev /target/dev
mount -o bind /proc /target/proc
mount -o bind /sys /target/sys
mount -o bind /dev/pts /target/dev/pts
# Now chroot into it:
chroot /target /bin/bash
# Fix up the GRUB device map to match what 'mdadm --detail' gives as UUID:
nano /boot/grub/devicemap

ナノ

nanoを使用しているのは、vimが文字どおりダム端末のために頭痛の種となったためです。使用できます Ctrl+x 終了する（保存するように求められます、 Ctrl+k 現在の行をカットするには、 Ctrl+u カットラインを貼り付けるには、 Ctrl+o バッファを保存します。

これは複雑に聞こえますが、bashワンライナー（長いものでも）でも実行できます。

for i in /dev/disk/by-id/md-uuid-*; do DEV=$(readlink $i); echo "(${DEV##*/}) $i"; done|sort|tee /boot/grub/devicemap

これは、mdデバイスとそのUUIDのcurrent名を使用し、GRUB2の閲覧用にdevicemapを作成します。したがって、上記が正しく行われたと仮定すると、正しいデバイス名がすでにあるはずです。

これより先：

# Edit the grub config
nano /etc/default/grub

それが含まれていることを確認してください：

GRUB_PRELOAD_MODULES="part_gpt raid mdraid09 ext2"

/または/bootパーティションをメタデータバージョン1.2に構成している場合は、mdraid1xではなくmdraid09を使用してください。

さらに：

# Update the initrd images
update-initramfs -c -k all

この上のステップはミッシングリンクでした。これにより、mdadm.confが起動時に有効になるようです。

# Install GRUB2 on the two drives eligible for booting, just to be sure
grub-install --no-floppy /dev/sda
grub-install --no-floppy /dev/sdb
# Make the latest config take effect
update-grub

その後、chrootを終了して再起動します。

2
0xC0000022L