UUIDおよび/ dev / disk / by-idによる救助

最近、新しいサーバーでXenをピックアップし、非常に興味深い問題に遭遇しました-読み込み時に、すべてがBIOSでハードコーディングされているにもかかわらず、sdaとsdbが2本のネジからランダムに選択されました。 したがって、サーバーが時間の経過とともにロードされていることがわかりました。 そして、私は、この問題をどのように解決するかを考え始めました:)すべてではなく、ディスクの1つが暗号化されていれば、すべては難しくありませんでした:)

そのため、状況の簡単な説明から始めます。

Xen upおよび2つのIDE HDDを備えたサーバーがありました：160 Gb —システムおよび400 Gb — Xenゲストドメインを備えた暗号化ディスク。 システムドライブマスター、ドメイン-スレーブ、すべてが完全に機能しました。 しかし、ある日、奴隷はあなたがもうそのように生きることができないと決め、静かに死んだ:)。 気にしないことに決め、新しい400 Gb SATAドライブがそれに取って代わりました。 BIOSでは、誰が誰であるか、つまり、どのドライブが最初で、どのドライブが2番目であるかが厳密に記述されており、ロードを続行することが決定されました。

GRUB画面が表示され、3秒間ハングしてダウンロードが完了しました。 彼らが言うように、真実は遠くない、彼らは言う、音楽は長い間演奏しなかった、フライヤーは長い間踊らなかった、なぜならinitrdイメージを読み込んだ後、システムはルートセクションを見つけることができないという言葉でその「ファイ」を私に言ったから お互いを見て（Xenを意味する）、私はそれが私に見えたと判断し、3つの魔法のボタンを押した後、システムは明らかにヒントを理解したので、リブートしました。 BIOSを再確認すると、私は何も台無しにしなかったことがわかり、再試行することになりました。 「 こんにちは、つまり、私のルートパーティションがどこにあるのか知りたいですか？」 -システムは私に言った。 メッセージ出力をスクロールすると、IDEドライブがsdbになり、SATAがsdaになったことに驚きました。 このおとぎ話の中の何かが正しくありません。 小さなパンはキツネを食べて考え、私は考えて決めました、もしあなたがそう決めたら、それは問題ではありません、今私たちはあなたが望むようにそれをします。 繰り返しますが、3つのボタンを読み込み、GRUBメニューに移動すると、sdbが編集され、ボタンbとダウンロードプロセスが開始されます。 私は椅子に身を乗り出しましたが、システムは再び「私はどこにいるのですか？」と尋ねたので、長くは続きませんでしたが、答えは「誰ですか？」、プロセスを見て、今回、ディスクはすでに正常に検出されており、ルートパーティションがsdbにあることをGRUBに何も通知しませんでした。 すべてを吐き出し、 3つのボタンをもう一度押しても、すべてをそのままにして、 「ああ、奇跡！」システムが正常に起動しました。 :)

空の星とおとめ座の星座の不適切な配置にすべてを帰することで落ち着かせることができるように思えますが、再起動を繰り返すと正気であることがわかりましたが、システムは既知のアルゴリズムに基づいていました（ただし、それはただ/ dev / rand）、今日家のボスであり、誰が皿を洗う必要があるかが決定されました:)

長い間UUIDを使用できるという事実は知っていましたが、1つありましたが、暗号化されたデータとゲストドメインの接続と起動を自動化する2、3のスクリプトの形式で、それらはcryptsetup createを使用して初期化されたときに、デバイスへのハードポインターを使用しました（ / dev / sdb1）のようなもの。 私たちは何かをエレガントでできるだけ早く考えなければなりませんでした:)

ダウンロードの問題はすぐに解決され、UUIDを称賛しました。 menu.lstに属するセクションとセクションの確認は、GRUBとfstabで修正されました。

これは次のように行われます。

＃tune2fs -l / dev / sda3 | grep -i uuid



ファイルシステムUUID：269f023a-bf30-4a6e-a866-6c414dec0ef6



menu.lst内：

タイトルXen 3.2-1-amd64 / Debian GNU / Linux、カーネル2.6.26-2-xen-amd64

ルート（hd0.0）

カーネル/xen-3.2-1-amd64.gz

module /vmlinuz-2.6.26-2-xen-amd64 root = UUID = 269f023a-bf30-4a6e-a866-6c414dec0ef6 ro console = tty0

モジュール/initrd.img-2.6.26-2-xen-amd64



およびfstabの一部：

UUID = 269f023a-bf30-4a6e-a866-6c414dec0ef6 / ext3エラー= remount-ro 0 1



そして、ここでスワップセクションに関して疑問が生じました。 多くは、UUIDセクションをスワップに割り当てる方法を知りません（デフォルトでは、インストーラーはUUIDセクションなしで作成します）。 これを行うには、最初に無効にして単純に再作成します。

＃スワップオフ

＃mkswap / dev / gde_swap

＃vol_id / dev / gde_swap | grep UUID

ID_FS_UUID = c52042d0-8527-48bd-812c-d51000059098

ID_FS_UUID_ENC = c52042d0-8527-48bd-812c-d51000059098

ここからUUIDを取得し、fstabに書き込みます。



しかし、暗号化されたネジはどうですか？ UUIDはそこに表示されません：（Debianのircチャンネル（irc.debian.org）に行き、そこにアドバイスを求めなければなりませんでした:)だから彼らは/ dev / disk / by-id / :)について教えてくれました

そこをちらっと見たところ、私が見つけたもので、結局はcryptsetupも、さらに快適に存在するのに十分であることがわかりました。それは、デバイスへの望ましいリンクでした：scsi-SATA_ST3400633AS_9NF0BZ3B-part1。 スクリプトの編集は迅速かつ簡単で、その後真実の瞬間が訪れました-コントロールショットのリブート:)



皆を称賛し、念のために、セント・パトリックも（スラヴォスにこんにちは;））すべてがバタンと鳴りました:)



だから、彼らが言うように、忍耐と仕事はすべてを粉砕します:)そして最も重要なことは、恥ずかしがらずに知っている人に尋ねてください:)



PS：irc.debian.orgの友好的な人々に感謝します。



UPD：ジャンパーですべてが大丈夫です:)ダブルチェック、これは私にも最初に起こったことです:)