Linux で /dev/root が表すデバイスが何であるかをご覧ください。

Question 1

root=でパラメータを解析します/proc/cmdline。

Answer

root=でパラメータを解析します/proc/cmdline。

Question 2

ここで提供される情報の多くは誤解を招く可能性があり、実際には完全に正確ではない可能性があるため、おそらく更新する必要があります。

https://bootlin.com/blog/find-root-device/

/マウントポイントは/dev/rootに相当することを知らせるだけで、探している実際のデバイスではありません。

もちろん、カーネルコマンドラインを見て、どの初期のルートファイルシステムがLinuxを起動するように指示されているかを調べることができます（rootパラメータ）。

$ cat /proc/cmdline mem=512M console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait

しかし、これが現在ルートされているデバイスを見ているわけではありません。多くのLinuxシステムは、最後のルートファイルシステムにアクセスするためだけに使用されるinitramdisksやinitramfsなどの中間ルートファイルシステムから起動します。

ここで指摘する1つのことは、/ proc / cmdlineの内容が実際に存在する実際の最終デバイスルートである必要はないことです。

これはBusyboxの従業員が送ったもので、ブート状況で彼らが何を言っているのかを知っていると思います。

https://www.linuxquestions.org/questions/slackware-14/slackware-current-dev-root-688189/page2.html

私が見つけた2番目の便利なリソースは、/dev/root問題に関する非常に古いSlackwareスレッドでした。そのスレッドが出た時点から、すべてのバリエーションが常に存在していることがわかりますが、「ほとんどの」ディストリビューションは両方ともシンボリックリンク方式を使用していると思います。しかし、それは単純なカーネルコンパイルスイッチであり、ポスターを正しく理解すると、1つを作成したり作成したりすることはできません。つまり、一方向に切り替えます。 readlink /dev/root 実際のデバイス名を報告し、別のデバイス名に切り替えますが、そうではありません。

このスレッドの主なトピックは/dev/rootを削除する方法なので、実際に何か、コンポーネントなどを理解する必要があります。つまり、削除するにはこれを理解する必要があるという意味です。

これを悪く説明すると次のようになります。

/dev/root は fstab で使用できる汎用デバイスです。「rootfs」も使用できます。これにより、あまり具体的に指定できないため、いくつかの利点があります。つまり、ルートパーティションが外部ドライブにある場合は常に同じデバイスとして表示されない可能性があり、正常にマウントするには、正しいデバイスと一致するようにfstabを変更する必要があります。 / dev / rootを使用すると、liloまたはgrubのカーネルブートパラメータで指定されたすべてのデバイスと常に一致します。

/dev/root は表示されなくても常に仮想マウントポイントとして存在します。 rootfsの場合も同様です（前に/devを持たないprocやtmpfsなどの特殊な仮想デバイスと比較）。

/dev/root は、「proc」や「/dev/tcp」などの仮想デバイスです。 / devにはこれらのデバイスノードはありません。すでにカーネルに仮想デバイスとして存在します。

これはシンボリックリンクが必ずしも存在しない理由を説明します。驚くべきことに、私はこの情報を知る必要があるいくつかのプログラムを維持しているので、以前はこの問題に遭遇したことはありませんが、やらないより遅い方が良いです。

私はここに提供されているソリューションのいくつかが「通常」動作し、おそらく私がやると思いますが、問題に対する実際のソリューションではなく、busyboxの作者が指摘したように、非常に複雑な状況で実装する方が複雑です。。堅牢な方法。

[Update:} 一部のユーザーテストデータを取得したら、マウント方法を使用する予定ですが、少なくとも場合によっては問題ないようです。 /proc/cmdlineはバリアントが多すぎるので役に立ちません。最初の例では、以前のアプローチを見ることができます。これらのパスは動的に変更（ディスク順序の交換、新しいディスクの挿入など）され、突然/ dev / sda1に変更される可能性があるため、使用（元の/ dev / sdx [0-9]タイプの構文）を使用しないことをお勧めします。 /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のようなモバイルターゲットにrootを参照してはいけません。

次の 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つのケースが「ほとんどの」ユーザーに適用されると信じており、これが私が必要とするすべてです。

最もよく、最もきれいで最も信頼できる解決策は、カーネルが常にシンボリックリンクを作成することです。。

私はこれがすべて「良いか強力な」ソリューションだとは思わないが、マウントオプションは「十分に良い」要件を満たしているようで、本当に強力なソリューションが必要な場合はbusyboxが推奨するものを使用してください。

Answer