多くの場合、特にブートローダーをいじくり回すと、ドライブ番号とパーティション番号が使用されていることがわかります。たとえば、私の/boot/grub/grub.cfg set root='hd0,gpt2'が表示されます 、私のUEFIブートエントリはドライブ/パーティション番号を参照することが多く、ブートローダーが関係するほとんどすべてのコンテキストで発生するようです。
UUIDとPARTUUIDができたので、この方法でパーティションをアドレス指定することは非常に不安定に見えます（afaik、ドライブが常に同じ順序でマウントされるとは限らない、ユーザーはmoboに接続されているドライブの順序を移動する可能性があります）
したがって、私の質問は2つあります。
-
このアドレス指定スキームは、上記で概説したように不安定ですか？このスキームが私が期待するよりもはるかに信頼できることを意味する標準に何かが欠けていますか、またはドライブが単に認識される結果として、このアドレス指定スキームは本当にシステムを起動できなくなりますか（少なくともブートエントリを修正するまで）別の順序ですか、それともマザーボードの別のスロットに接続しますか？
-
上記の質問に対する答えが「はい」の場合、なぜこのアドレス指定スキームが引き続き使用されるのですか？すべてにUUIDまたはPARTUUIDを使用する方がはるかに安定していて、一貫性がありませんか？
承認された回答：
プレーンな番号付けスキームは、最近のシステムでは実際には使用されていません（「最近」は、Ubuntu 9以降であり、他のディストリビューションもその時代に適応している可能性があります）。
ルートパーティションが設定されていることを確認するのは正しいです。プレーンな番号付けスキーム。ただし、これはデフォルトまたはフォールバック設定であり、通常、次のような次のコマンドで上書きされます。
search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a
これにより、ファイルシステムのUUIDに基づいてルートパーティションが選択されます。
実際には、プレーンな番号付けスキームは通常安定しています（ハードウェアの変更がない限り）。予測できない番号付けを観察した唯一の例は、先着順のパターンに基づいて列挙され、IDEドライブとしてエミュレートされた多くのUSBドライブを備えたシステムでした。これらのプロセスは本質的に混沌としているわけではないので、その特定のシステムのBIOS実装に問題があると思います。
関連：ソースシェルスクリプトへのパスを決定しますか？注：このコンテキストでの「ルートパーティション」とは、起動元のパーティションを意味し、「ルート別名」を含むパーティションとは異なる場合があります。 /ファイルシステム」。