ドライブ/パーティション番号がまだ使用されているのはなぜですか？

多くの場合、特にブートローダーをいじくり回しているときは、数値のドライブ番号とパーティション番号が使用されているのがわかります。たとえば、/boot/grub/grub.cfg私が見るところではset root='hd0,gpt2'、私のUEFIブートエントリはドライブ/パーティション番号を参照することが多く、ブートローダーが関係するほとんどすべての状況で発生するようです。

UUIDとPARTUUIDが用意されたので、この方法でパーティションをアドレス指定することは非常に不安定に思えます（ただし、ドライブが常に同じ順序でマウントされることは保証されていません。

したがって、私の質問は2つあります。

1. このアドレス指定スキームは、上記で説明したように不安定ですか？このスキームが予想よりもはるかに信頼性が高いことを意味する標準に何かが欠けていますか、またはこのアドレス指定スキームは、ドライブが単に順序を変えたり、マザーボードの異なるスロットに差し込んだりしますか？

2. 上記の質問に対する答えが「はい」の場合、なぜこのアドレッシングスキームが引き続き使用されるのですか？すべてにUUIDまたはPARTUUIDを使用すると、はるかに安定し、一貫したものになりませんか？

プレーンな番号付けスキームは、実際には最近のシステムでは使用されていません（「最近」はUbuntu 9以降であり、他のディストリビューションもその時代に適応した可能性があります）。
ルートパーティションがプレーンな番号付けスキームで設定されていることを確認するのは正しいことです。ただし、これはデフォルト設定またはフォールバック設定のみで、通常は次のような次のコマンドでオーバーライドされます。

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

これにより、ファイルシステムのUUIDに基づいてルートパーティションが選択されます。

実際には、通常の番号付けスキームは通常安定しています（ハードウェアの変更がない限り）。予測不可能な番号付けを確認した唯一の例は、先着順のサービスパターンに基づいて列挙されたIDEドライブとしてエミュレートされた多くのUSBドライブを備えたシステムです。これらのプロセスはいずれも本質的に混oticとしたものではないため、特定のシステムBIOSの実装に問題があると思います。

注：このコンテキストでの「ルートパーティション」は、ブート元のパーティションを意味し、「ルートaka。/ファイルシステム」を含むパーティションとは異なる場合があります。

厳密に言えば、UUIDはまったく対応していません。

アドレス指定は非常に簡単です：ドライブXセクターYを読み取る-またはそれ以外。メモリアドレスZを読み取る-または アドレス指定は簡単で高速であり、解釈の余地があまりなく、どこにでもあります。

UUIDはアドレス指定していません。代わりに、検索、検出、デバイスの表示を待機し、ファイルシステムを理解しています（★）。また、デバイスの数によっては、非常に長い時間がかかる場合があります。見つかったら、通常のアドレス指定に戻ります。

GRUBでは、これはsearch（★★）と呼ばれ、GRUBが既に翼を成長させている場合にのみ使用可能です（検索は、サポートするすべてのファイルシステムと同様にモジュールであるため、コアのロード後にのみ使用可能です）。Linuxでは（たとえば）findfs、findfsはシステム内のブロックデバイスを検索して、ファイルシステムまたはパーティションを探します。

すべてのブロックデバイスを通過し、スタンバイからウェイクアップし、データを読み取ります.UUIDが本来のように一意でない場合（dd事故などの後）、またはUUIDが変更された場合は結果が得られません- UUIDも構成エラーになりやすいです。

一般に、UUIDは優れています。もちろん、特にLinuxでドライブの順序がランダムであるために従来のアドレス指定が失敗する場合は、UUIDを使用可能な場合はどこでも使用する必要があります。しかし、複雑さは単純なアドレス指定の意図を超えていることを理解してください。そして、特にブートローダーの非常に初期の段階では、それはまだオプションではないかもしれません。対処が最初になり、成長する翼が後になります。

ブートローダーの場合、単に努力する必要はないかもしれません（すべてのブートローダーがGRUBなどの幅広いファイルシステムをサポートしているわけではありません）。場合hd0であることが保証されますが、ランダムなドライブの順序の問題を排除することができるかどうかの状況に起因する「我々がオフのブートディスクは」（BIOSが提供する）、およびので、他のパーティションの潜在的に巨大なリストの中を通過する必要がないかもしれませんUUIDを検索します。

それがあなたがhd0,gpt2望むものであると言う設定に十分自信があり、そうでなければならない場合、そうでなければありえない場合、そのように使用しても何も悪いことはありません。場合によっては、単純で単純なアドレス指定がうまく機能することもあります。

（★）以前にここでLABELについて説明しました ...

ラベルには一般的な標準はありません。すべて手作業で作成されています。たとえば、util-linuxのスーパーブロック形式のこの実装を参照してください。明日、新しいファイルシステムを考案した場合、たとえラベルが付いていても、サポートが追加されるまで表示されません。

...それはUUIDでもほぼ同じです。

（★★）実際には、GRUB searchには--hintオプションがあり、...ソースコードを確認していないため、マニュアルにも記載されていませんが、このようなオプションは両方の長所を提供する意味があります。ヒントは最初にそのパーティションsearchをチェックするように指示する必要があり、UUIDが期待どおりに一致する場合、最小限の労力でデバイスを識別し、一致しない場合は、何とか動作を続けるために完全な検索にフォールバックします。

それに加えて、以前に見つかったUUIDはキャッシュされる傾向があるため、すべてのデバイスを何度も何度も通過する必要はありません-あなたが探しているUUIDが実際にどこかに存在していれば、これもうまく機能しますそもそもキャッシュに入れてください。

また、ラベルを忘れないでください。それらはUUIDほどユニークではありませんが、より有益であり、fstabを人間が読めるようにします。デスクトップ、または小さな会社の場合、つまり、数個から数十個のドライブを管理している場合は、UUIDよりラベルを好むかもしれません。

あなたの質問に対する @frostschutzの優れた答えを熟考し、「クラシック」デバイスリンクアドレッシングを好む可能性が高いシナリオの1つは、VMのセットアップです。Ubunzima 04.18イメージをカスタマイズするとします。2つのディスクを持つ（スローアウェイ）VMを作成します。1つは（スローアウェイ）システムドライブで、2つ目はマウントしてカスタマイズします。おそらく、新しいディスクで新しいgrubを取得したい場合は、UEFIブートパーティションもマウントします。下のターゲットパーティションのマウントポイントを選択したと仮定すると/mnt、目的のマウントテーブルは次のようになります。

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

したがって、既存のプロバイダー提供のクラウド対応イメージから2つの同一のドライブを作成し、それらを新しいVMに接続して起動します。当然、

• 私たちの想像上のUbunzima 04.18も例外ではない、最新のOSディストリビューションはすべて、UUIDという名前のマウントに依存しています。
• 同じイメージからロールアウトされたすべてのハードドライブは、同じUUIDを持ちます。UUIDは一意であるため、何が問題になる可能性がありますか？

あなたはすでにこれがすべて進んでいるところを見ています。

このfrankencontraptionが初めてブートしたときsda9、EFIブートパーティションとして選択されましたが、Linux sdb1はルートFSとして再マウントすることを決定しました。

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

そして、私のロールアウトスクリプトはそのために非常に準備が整っていなかったので、フランケンビルド中にログで文句を言う単一のツールなしで、最終的には起動できない画像があります！

もちろん、ログにマウントテーブルを印刷しました。そしてもちろんの混乱アップ途中でランダムの間としたデバイスが搭載された順序で（8）プリントマウントをマウントするので、それは私がそれをすぐに見つけていなかった驚くべきことではなかったので、見つけるのは非常に困難です。そして、同じスクリプト（異なるイメージのディスクを使用）が以前は15歳のGlenfiddichと同じくらいスムーズに機能していたと想像してください。問題を解明しようとしてログに髪¹を引っ張ったのに何時間かかったと思いますか？

デスクトップPCからルーターに埋め込まれたLinux、Androidスマートフォン、クラウドデータセンターまで、どんな状況にも適した厳格なルールはありません。SOの答えは客観的であると想定されており、私の経験や好みはもちろんそうではありません。そのため、パーティションを識別するさまざまな方法の中から選択するときに、論理的な推論の例を示します。

• 理由がない場合はそのままにしておきます。UUIDは、ほとんどの最新のディストリビューションのデフォルトです。2番目のドライブを追加する場合は、それを試して決定します。知る必要さえないかもしれません。それでもシステムが起動し、新しいデバイスを表示してパーティションに分割できる場合は、デバイスをフォーマットしてfstabに追加します（UUID、LABEL、または/devリンクによって、同じ考慮事項が適用されます）。余分なドライブを差し込んだ後、システムが起動を拒否した場合にのみ問題が発生します（UEFI BIOSで起動順序を変更するのが最も簡単な方法です）。

  実際には、どのSATAコネクタが自分のデスクトップのどのドライブに接続するかをラベル付けするのが最速かつ最も簡単なソリューションかもしれませんが、システムの起動方法を変更し、非常に可能性の高い起動障害から回復することは、間違いなく最悪のタイムゴブラーです。しかし、あなたは余分なドライブに投げることはあなたの運の限界をテストして確認してください彼らの初期ブートドライブがすべてのように、GRUBによって見られることはありません非常に少なくとも、あなたを悩ませて立派な問題はないと思われる50人のプログラマのためにそれを管理する場合hd0と、としてのシステムsda。

• デスクトップまたは3台で自分のドライブとパーティションを管理するためのラベル、または小さな環境（その場所を「スタートアップオフィス」と面白く呼ぶソフトウェアエンジニアでいっぱいの家の居間）。誰かのマシンから物理ドライブを引き出す場合、ラベルを一貫して使用すれば、どこから来たのかがわかります。

  lsblk（8）は言うならばLABEL=bubba-boot、あなたはそれが呼ばれるマシンから引き出されている知っているババ。ほかに、ババ・ブートよりもはるかに簡単に私の舌の上にロール6864c4ea-f9b9-46db b875-4d7fc2981007、私の甘やかされて育った味に、実に作品Jawbreakerあります。ラベルが一意であることを確認することは今やあなたにシフトしますが、その見返りはラベルの意味です。

• /dev-同じイメージのスポーンである比較的短命で保守の少ないVMの大隊を指揮する場合のリンクベースの命名。すべてのUUIDがUUの約束を守るという週給に賭けることはありません。独自の物理サーバー上のVyper-HやKugel Cloudなど、すべての健全な VMサービスは、ブートドライブを呼び出してはならず、2番目で唯一の²です。一方、物理マシンでは、SATAケーブルを創造的に接続することで同じ配置を簡単に実現できます。sdesdc

  余談ですが、このシナリオでは、いわゆる「一貫性のある」イーサネットインターフェイスの命名と同じルートを使用します。VMでそれを無効にします。誤解しないでください。PCIスロット4に挿入したNICが、見ている間（または、NICがいる間も）に気まぐれに突然スロット5にジャンプしない限り、命名は一貫しています。恥はまったくありません）。残念ながら、「VMの大隊」環境では実際にそうなっています。この場合には、反直感的eth0であるよりより一貫enp0s4f6。VMプロバイダーは、常にPCIバス0のスロット4に仮想NIC番号1を配置することを約束しませんでした（そして、言及された3つのエンティティはいずれも物理的に実際ではありません）。通常はvirtioファミリーの同じドライバーモジュールを使用していることを考慮して、2番目のインターフェイスの前にある最初のインターフェイスに大きく依存します（最初のNICが常にない場合でもeth0、同じnote²が適用されます）。

  ---

¹もちろん、比Fig的に。このビジネスがあまりにも長い間残っていない場合、私は行ってきました。
²もしそうなら、私は真剣に彼らから叫び出して、プロバイダーやVMハイパーバイザーソフトウェアを変更することを検討します。

両方のスキームを混在させて、ほとんどのLinuxディストリビューションと一致させることができます。

結果は、ユースケースに応じて望ましい場合と望ましくない場合があります。たとえば、構成ファイルを変更せずに（仮想ハードウェアまたは実際のハードウェア）ドライブのホット交換が行われる場合、古いスキームを好む（さらにはudevスタイルの永続性ハッキングを無効にすることもできます）欲しかった。

2番目の質問（「なぜこのアドレッシングスキームが引き続き使用されるのか？」）への答えは、慣性です。はい、GPTパーティションディスクでUUIDのみを使用することは完全に可能です。の/dev/xxx名前の代わりにUUIDを使用できます/etc/fstab。そして、Discoverable Partitions Specificationが用意されたので、多くの場合、UUIDを指定する必要はありません。パーティションタイプでディスクをパーティション分割するだけで、パーティションが自動的に選択されます。私のマシンではroot=、カーネルコマンドラインにエントリがまったくありません。

ブートローダーについて言えば、GRUBは、マシンのブートストラップとはほとんど関係がないという意味で、最新のUEFI PCではほとんど不要です。現在、GRUBは単にカーネル選択プログラムとして機能します。このタスクには、systemd-bootなど、よりシンプルで優れた代替手段があります。