root= を解析する /proc/cmdline からのパラメータ .
私が調べたシステムでは、/dev/root は実際のデバイスへのシンボリック リンクなので、readlink /dev/root (または readlink -f /dev/root フルパスが必要な場合)、それを行います。
ここに記載されている情報の多くは誤解を招くものであり、実際には完全に正しいものではない可能性があるため、これはおそらく更新する必要があります.
https://bootlin.com/blog/find-root-device/
<ブロック引用>/ マウント ポイントについては、探している実際のデバイスではない /dev/root に対応していることが示されます。
もちろん、カーネル コマンド ラインを見て、Linux が起動するように指示された初期ルート ファイルシステム (ルート パラメーター) を確認できます。
$ cat /proc/cmdline mem=512M console=ttyS2,115200n8root=/dev/mmcblk0p2 rw rootwait
ただし、これは、表示されているものが現在のルート デバイスであることを意味するものではありません。多くの Linux システムは、中間のルート ファイルシステム (initramdisks や initramfs など) で起動します。これらは、finalone にアクセスするためにのみ使用されます。
これが指摘していることの 1 つは、/proc/cmdline にあるものが、実際に実際に存在する実際の最終デバイス ルートであるとは限らないということです。
それは、ブート状況に関して彼らが何について話しているかを知っていると思います。
https://www.linuxquestions.org/questions/slackware-14/slackware-current-dev-root-688189/page2.html
私が見つけた 2 番目の有用なリソースは、/dev/root の問題に関する非常に古い Slackware スレッドです。このスレッドの時代から、すべてのバリアントが常に存在していたことがわかりますが、「ほとんどの」ディストリビューションはシンボリックを使用していたと思いますlink メソッドですが、これは単純なカーネル コンパイル スイッチでした。ポスターを正しく理解していれば、作成することも作成しないこともできます。
そのスレッドの主なトピックは /dev/root を取り除く方法だったので、彼らはそれが実際に何であるか、それを作るものなどを理解する必要がありました。つまり、それを取り除くために理解する必要がありました。
ぎこちなくうまく説明しました:
<ブロック引用>/dev/root は、fstab で使用できる汎用デバイスです。 「rootfs」も使用できます。これを行うと、特定性を低くすることができるという利点があります。つまり、ルート パーティションが外付けドライブにある場合、常に同じデバイスとして表示されるとは限らず、適切なデバイスと一致するように fstab を変更する必要があります。 /dev/root を使用すると、lilo orgrub のカーネル ブート パラメータで指定されたデバイスと常に一致します。
/dev/root は、見たことがない場合でも、常に仮想マウント ポイントとして存在していました。 rootfs も同様です (前に /dev がない proc や tmpfs などの特殊な仮想デバイスと比較してください)
/dev/root は、'proc' や /dev/tcp' のような仮想デバイスです。 /dev には、これらのデバイス ノードはありません。仮想デバイスとしてカーネルに既に存在します。
これは、シンボリック リンクが必ずしも存在しない理由を説明しています。この情報を知る必要があるいくつかのプログラムを維持していることを考えると、今までこの問題に遭遇したことがなかったことに驚いていますが、遅いよりはましです。
ここで提供される解決策のいくつかは「しばしば」機能し、おそらく私が行うことだと思いますが、それらは問題に対する実際の真の解決策ではありません。
[UPDATE:} いくつかのユーザー テスト データを取得した後、マウント メソッドを使用します。これは、少なくとも場合によっては問題ないように思われます。バリアントが多すぎるため、/proc/cmdline は役に立ちませんでした。最初の例では、古いメソッドが表示されます。これらのパスは動的に変更される可能性があるため (ディスクの順序を入れ替えたり、新しいディスクを挿入したりすると、突然 /dev/ sda1 は /dev/sdb1 になります)。
root=/dev/sda1
root=UUID=5a25cf4a-9772-40cd-b527-62848d4bdfda
root=LABEL=random string
root=PARTUUID=a2079bfb-02
VS 非常にクリーンで解析しやすい:
mount
/dev/sda1 on / type ext4 (rw,noatime,data=ordered)
cmdline の場合、/dev/sdxy のような移動するターゲットにルートを参照してはならないため、理論的に正しい「答え」である唯一のバリアントは非推奨の最初のものであることがわかります。
次の 2 つは、/dev/disk/by-uuid または /dev/disk/by-label のいずれかで、その文字列からシンボリック リンクを取得するというさらなるアクションを実行する必要があります
最後の例では、parted -l を使用して、その parted ID が指しているものを見つける必要があります。
これは私が知っていて見た亜種だけです。たとえば、GPTID のような他の亜種がある可能性があります。
そこで、私が使用しているソリューションは次のとおりです:
まず、/dev/root がシンボリック リンクかどうかを確認します。そうである場合は、/dev/disk/by-uuid または by-label ではないことを確認します。そうである場合は、最後の実際のパスを取得するために処理の 2 番目のステップを実行する必要があります。使用するツールによって異なります。
何も得られない場合は、マウントに移動して、それがどのようであるかを確認してください。最後の代替ケースとして、私が使用していないものは、それに対して与えられた引数が必ずしも問題の実際のパーティションまたはデバイスであるとは限らないため、プログラムのそのソリューションを拒否するのに十分です。 mount は完全に堅牢なソリューションではありません。十分なサンプルがあれば、まったく正しくないケースを簡単に見つけることができると確信していますが、これら 2 つのケースは「ほとんどの」ユーザーをカバーしていると思います。 /P>
最も素晴らしく、最もクリーンで、最も信頼できる解決策は、カーネルが常にシンボリック リンクを作成することでした。
私はこれらのいずれも「良いまたは堅牢な」解決策とは考えていませんが、マウント オプションは「十分に良い」を満たすように見えます。本当に堅牢な解決策が必要な場合は、busybox が推奨するものを使用してください。