MD（RAID1）+ LVMのルートでのブートエラー：udevイベントのタイミング
Ubuntu Server 13.10（x64）の新規インストールで、md + lvmにあるルートボリュームからの起動に問題があります。私は今のところ解決策を考えてきましたが、何が起こっているのか、そしてどのようなより良い解決策があるのかについてもっと理解したいと思います。
このマシンの目的はXenを実験することであるため（商用VMホスティング）をよりよく理解するため）、マシンは私が手に入れなければならない部品、具体的にはQ6600 + AsusP5QLから組み立てられますPro、1 TBおよび500GB SATAディスク（500 GBディスクはまだ他の場所で使用されていますが、後で追加されます。）
1TBディスクには3つのパーティションがあります。sda1は500GBディスクのsdb1と同じサイズ、sda2はスワップ、残りはsda3です。 md0は、sda1 + sdb1で構成されるRAID1ボリューム[1]であり、LVMで使用可能な1つのPVです。
UbuntuはこのVG（vg_mir）の2つのLV（dom0_rootとdom0_homes）にインストールされ、/ bootはdom0_rootにあります。
特定の問題は、ディスクが初期化された直後に、次のメッセージで現れます。
kernel: [ 3.003506] md: bind<sda1>
kernel: [ 3.007705] md/raid1:md0: active with 1 out of 1 mirrors
kernel: [ 3.007768] md0: detected capacity change from 0 to 499972440064
kernel: [ 3.047284] md0: unknown partition table
kernel: [ 3.124709] device-mapper: table: 252:0: linear: dm-linear: Device lookup failed
kernel: [ 3.124759] device-mapper: ioctl: error adding target to table
kernel: [ 3.125156] device-mapper: table: 252:1: linear: dm-linear: Device lookup failed
kernel: [ 3.125196] device-mapper: ioctl: error adding target to table
一時停止した後、それはあきらめてinitramfsシェルにドロップします。コマンドlvm vgchange -ayを発行すると、LVMが正常に初期化され、/ dev/mapperが期待どおりに入力され、システムは^ Dの後に正常に起動します。
/ etcに/lib/udev/rules.d/85-lvm2.rulesのコピーを作成し、次に示すようにsleep 1を挿入します。
SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
RUN+="watershed sh -c 'sleep 1; /sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
（そしてinitramfsを再構築する）システムは支援なしで起動するようになりましたが、これはかなりひどい解決策です。さまざまなバグトラッカーやブログ投稿で説明されているように、rootwait=、lvmwait=、およびscsi_mod.scan=syncカーネルパラメーターをいじってみましたが、どれもうまくいきませんでした。いくつかのページは、evmsが問題であることを示唆していますが、それはインストールされていないようです。他の人は無関係なブロックデバイスでタイムアウトを提案し、私はDVDドライブを無効にすることさえしました。
Mdとlvmの間にある種の競合状態があり、md0の準備が整う前にlvmがudevによって呼び出されているようです。それらのカーネル引数は遅延を挿入するようです 後 lvmが実行されているため、vgchangeがすでに実行されている（そして失敗している）ためにLVの準備ができていないため、待機の量は役に立ちません。
それは私が問題を掘り下げた限りです。誰かがより良い解決策を提案したり、問題をさらに見つけるためにドリルインする方法を提案したりできますか？
[1]現時点では、sdb1が欠落しているため、Ubuntuは劣化したボリュームでの起動を好まないため、このRAIDボリュームは1つのデバイスでRAID1になるように手動で構成されます。
明らかに同じタイプのハードウェアと13.10x64の新規インストールで、同じ問題が発生しました。経験が浅いので、カーネルモジュールが見つからないなどの可能性を追求するために数日を費やしましたが、レポートを読んだ後、initramfsbusyboxプロンプトでのvgchange-ayによってシステムが起動可能になることがわかりました。私はあなたが投稿した1秒の遅延回避策をまだ試していません（私はそうします）が、関連しているかもしれない次のDebianバグレポートにも注意します：
私は同じ問題を抱えていて、検索した後、 この解決策 が私のために働いていることがわかりました。すべての/dev/md/*デバイスの名前を/dev/md*の/etc/mdadm/mdadm.confデバイスに変更し、update-initramfs -uを実行してinitramfsを更新する必要がありました。