Analysieren Sie root= Parameter aus /proc/cmdline .
Auf den Systemen, die ich mir angesehen habe, /dev/root ist ein symbolischer Link zum echten Gerät, also readlink /dev/root (oder readlink -f /dev/root wenn Sie den vollständigen Pfad wollen), wird es tun.
Dies sollte wahrscheinlich aktualisiert werden, da viele der hier gegebenen Informationen irreführend sind und möglicherweise nie umfassend korrekt waren.
https://bootlin.com/blog/find-root-device/
Für den Einhängepunkt / wird Ihnen nur gesagt, dass er /dev/root entspricht, was nicht das eigentliche Gerät ist, nach dem Sie suchen.
Natürlich können Sie sich die Kernel-Befehlszeile ansehen und sehen, auf welchem anfänglichen Root-Dateisystem Linux angewiesen wurde zu booten (Root-Parameter):
$ cat /proc/cmdline mem=512M console=ttyS2,115200n8root=/dev/mmcblk0p2 rw rootwait
Dies bedeutet jedoch nicht, dass das, was Sie sehen, das aktuelle Root-Gerät ist. Viele Linux-Systeme booten auf Zwischen-Root-Dateisystemen (wie initramdisks und initramfs), die nur für den Zugriff auf Finalone verwendet werden.
Eine Sache, auf die dies hinweist, war, dass das Ding in /proc/cmdline nicht unbedingt das eigentliche letzte Geräte-Root ist, auf dem tatsächlich gelebt wird.
Das ist von den busybox-Leuten, von denen ich annehme, dass sie wissen, wovon sie sprechen, wenn es um Boot-Situationen geht.
https://www.linuxquestions.org/questions/slackware-14/slackware-current-dev-root-688189/page2.html
Die zweite nützliche Ressource, die ich gefunden habe, ist ein sehr alter Slackware-Thread über die Frage nach /dev/root. Aus dem Alter dieses Threads können wir sehen, dass alle Varianten immer vorhanden waren, aber ich glaube, die „meisten“ Distributionen verwendeten das Symbolische link-Methode, aber das war ein einfacher Kernel-Kompilierungsschalter, er könnte einen machen oder auch keinen machen, wenn ich die Poster richtig verstanden habe, das heißt, es in eine Richtung umschalten, und readlink /dev/root meldet den tatsächlichen Gerätenamen, umschalten der andere, und das tut es nicht.
Da das Hauptthema dieses Threads war, wie man /dev/root loswird, mussten sie sich damit befassen, was es eigentlich ist, was es ausmacht usw., was bedeutet, dass sie es verstehen mussten, um es loszuwerden.
knurrend hat es gut erklärt:
/dev/root ist ein generisches Gerät, das in der fstab verwendet werden kann. Man kann auch 'rootfs' verwenden. Dies bietet einige Vorteile, da Sie weniger spezifisch sein können. Was ich meine ist, wenn sich die Root-Partition auf einem externen Laufwerk befindet, wird sie möglicherweise nicht immer als dasselbe Gerät angezeigt, und ein erfolgreiches Mounten als / würde eine Änderung der fstab erfordern, um dem richtigen Gerät zu entsprechen. Durch die Verwendung von /dev/root passt es immer zu dem Gerät, das in den Kernel-Boot-Parametern von lilo oder grub angegeben ist.
/dev/root war schon immer ein virtueller Einhängepunkt, auch wenn Sie ihn nie gesehen haben. Ebenso rootfs (vergleichen Sie dies mit den speziellen virtuellen Geräten wie proc und tmpfs, die kein vorangestelltes /dev haben)
/dev/root ist ein virtuelles Gerät wie 'proc' oder /dev/tcp'. Für diese Dinge gibt es den Nodevice-Knoten in /dev - er ist bereits als virtuelles Gerät im Kernel enthalten.
Dies erklärt, warum ein symbolischer Link nicht notwendigerweise existiert. Ich bin überrascht, dass ich noch nie auf dieses Problem gestoßen bin, da ich einige Programme betreue, die diese Informationen benötigen, aber besser spät als nie.
Ich glaube, dass einige der hier angebotenen Lösungen "oft" funktionieren werden und wahrscheinlich das sind, was ich tun werde, aber sie sind nicht die eigentliche wahre Lösung des Problems, das, wie der Autor von busybox feststellte, sehr viel komplizierter zu implementieren ist robuste Weise.
[UPDATE:} Nachdem ich einige Benutzertestdaten erhalten habe, gehe ich mit der Mount-Methode, die zumindest für einige Fälle in Ordnung zu sein schien. Die /proc/cmdline war nicht sinnvoll, da es zu viele Varianten gibt. Im ersten Beispiel sehen Sie die alte Methode. Dies kommt immer seltener vor, da dringend davon abgeraten wird, es zu verwenden (die ursprüngliche /dev/sdx[0-9]-Typsyntax), da sich diese Pfade dynamisch ändern können (Festplattenreihenfolge tauschen, neue Festplatte einfügen usw. und plötzlich /dev/ sda1 wird zu /dev/sdb1).
root=/dev/sda1
root=UUID=5a25cf4a-9772-40cd-b527-62848d4bdfda
root=LABEL=random string
root=PARTUUID=a2079bfb-02
VS sehr sauber und einfach zu analysieren:
mount
/dev/sda1 on / type ext4 (rw,noatime,data=ordered)
Im Fall von cmdline werden Sie sehen, dass die einzige Variante, die theoretisch die richtige 'Antwort' ist, die erste, veraltete ist, da Sie root nicht auf ein sich bewegendes Ziel wie /dev/sdxy verweisen sollten
Die nächsten beiden erfordern die weitere Aktion, den symbolischen Link von dieser Zeichenfolge entweder in /dev/disk/by-uuid oder /dev/disk/by-label
zu erhaltenDer letzte erfordert, glaube ich, die Verwendung von parted -l, um herauszufinden, worauf diese parted id zeigt.
Das sind nur die Varianten, die ich kenne und gesehen habe, es könnte durchaus noch andere geben, wie zum Beispiel GPTID.
Also die Lösung, die ich verwende, ist diese:
Prüfen Sie zuerst, ob /dev/root ein symbolischer Link ist. Wenn dies der Fall ist, vergewissern Sie sich, dass es sich nicht um /dev/disk/by-uuid oder by-label handelt. Wenn dies der Fall ist, müssen Sie einen zweiten Verarbeitungsschritt ausführen, um den letzten echten Pfad zu erhalten. Hängt vom verwendeten Tool ab.
Wenn Sie nichts haben, dann gehen Sie zum Reittier und sehen Sie, wie das ist. Als letzten Fallback verwende ich keinen Fall, weil die Argumente dagegen, dass es sich nicht unbedingt um die eigentliche Partition oder das fragliche Gerät handelt, gut genug sind, um diese Lösung für mein Programm abzulehnen. mount ist keine vollständig robuste Lösung, und ich bin mir sicher, dass es bei genügend Beispielen leicht wäre, Fälle zu finden, in denen es überhaupt nicht richtig ist, aber ich glaube, diese beiden Fälle decken die „meisten“ Benutzer ab, was alles ist, was ich brauchte.
Die schönste, sauberste und zuverlässigste Lösung wäre gewesen, wenn der Kernel einfach immer den symbolischen Link erstellt hätte, der nichts und niemandem geschadet hätte, und es als gut bezeichnet hätte, aber so hat es in der realen Welt nicht funktioniert.
Ich betrachte keine dieser Lösungen als 'gute oder robuste' Lösungen, aber die Mount-Option scheint die 'gut genug' zu befriedigen, und wenn eine wirklich robuste Lösung erforderlich ist, verwenden Sie das von busybox empfohlene Zeug.