找出Linux中/ dev / root代表什么设备？

在linux上，有一个/dev/root设备节点。这将是与另一个设备节点相同的块设备，例如/dev/sdaX。/dev/root在这种情况下，如何解析为“真实”设备节点，以便向用户显示明智的设备名称？

例如，我在解析时可能会遇到这种情况/proc/mounts。

我正在寻找可以在shell / python脚本而不是C上运行的解决方案。

root=从中解析参数/proc/cmdline。

在我看过的系统上，/dev/root是到实际设备的符号链接，因此readlink /dev/root（或者，readlink -f /dev/root如果您需要完整路径）将执行此操作。

好吧，/dev/root这只是指向实际设备的符号链接，因此您可以使用readlink(2)它从程序中找出它的指向，或者readlink(1)从Shell脚本执行相同的操作。

也许我缺少了一些东西，但是呢：

mount|grep ' / '|cut -d' ' -f 1

这可能应该进行更新，因为此处提供的许多信息都具有误导性，并且实际上可能从未完全正确。

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

对于/挂载点，系统只会告诉您它对应于/ dev / root，它不是您要查找的真实设备。

当然，您可以查看内核命令行，并查看指示Linux在哪个初始根文件系统上引导（根参数）：

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

但是，这并不意味着您看到的是当前的根设备。许多Linux系统在中间根文件系统（例如initramdisks和initramfs）上启动，这些文件系统仅用于访问最后一个。

指出的一件事是/ proc / cmdline中的事情不一定是实际存在的最终设备根目录。

那是来自busybox的人，我认为他们知道启动情况时他们在说什么。

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

我发现的第二个有用资源是关于/ dev / root问题的非常老的Slackware线程，从该线程的年代开始，我们可以看到所有变体始终存在，但是我相信“大多数”发行版都使用了符号link方法，但是那是一个简单的内核编译开关，如果我正确地理解了发布者，它可以制作一个，也可以不制作，即以一种方式进行切换，然后readlink / dev / root报告真实的设备名称，然后进行切换另一个，但事实并非如此。

由于该线程的主要主题是如何摆脱/ dev / root，因此他们必须深入了解它的真正含义，产生原因等等，这意味着，他们必须了解它才能摆脱它。

gnashly很好地解释了这一点：

/ dev / root是可以在fstab中使用的通用设备。也可以使用“ rootfs”。这样做提供了一些优势，因为它可以使您不那么具体。我的意思是，如果根分区位于外部驱动器上，则它可能并不总是显示为同一设备并成功地将其挂载为/，因此需要更改fstab以匹配正确的设备。通过使用/ dev / root，它将始终匹配lilo或grub在内核引导参数中指定的任何设备。

/ dev / root始终作为虚拟安装点存在，即使您从未见过。rootfs也是如此（将其与不带/ dev的特殊虚拟设备（例如proc和tmpfs进行比较））

/ dev / root是一个虚拟设备，例如“ proc”或/ dev / tcp。/ dev中没有用于这些操作的设备节点-它已经作为虚拟设备存在于内核中。

这解释了为什么符号链接不一定存在的原因。令我惊讶的是，由于我维护了一些需要了解此信息的程序，但我从来没有遇到过这个问题，但是迟到总比没有好。

我相信这里提供的某些解决方案将“经常”起作用，并且可能是我会做的，但是它们并不是解决问题的真正方法，正如busybox作者指出的那样，在非常非常大的范围内实现起来要复杂得多。健壮的方式。

[更新：}在获得一些用户测试数据之后，我将使用mount方法，至少在某些情况下似乎可以。/ proc / cmdline没什么用，因为有太多的变体。在第一个示例中，您看到了旧方法。这种情况越来越少了，因为强烈建议不要使用它（原始的/ dev / sdx [0-9]类型语法），因为这些路径可以动态更改（交换磁盘顺序，插入新磁盘等，然后突然/ 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的情况下，您会看到，理论上正确的“答案”的唯一变体是第一个已弃用的变量，因为您不应将root引用到诸如/ dev / sdxy的移动目标

接下来的两个需要执行进一步的操作，以从/ dev / disk / by-uuid或/ dev / disk / by-label中的字符串获取符号链接。

最后一个要求我相信使用parted -l来查找parted id指向的内容。

那只是我所知道和看到的变体，可能还有其他变体，例如GPTID。

所以我正在使用的解决方案是这样的：

首先，查看/ dev / root是否为符号链接。如果是，请验证它是否不是/ dev / disk / by-uuid或按标签，如果不是，则必须执行第二步处理以获取最后的真实路径。取决于您使用的工具。

如果您什么都没有，请去安装，看看情况如何。作为最后一个备用案例，我没有使用它，因为针对它的参数甚至不一定是实际的分区或设备，足以让我拒绝程序的解决方案。mount并不是一个完全可靠的解决方案，而且我相信如果有足够的样本，很容易找到根本不正确的情况，但是我相信这两种情况都涵盖了“大多数”用户，这是我所需要的。

最好，最干净，最可靠的解决方案是让内核始终建立符号链接，这不会伤害任何东西或任何人，并称其为好，但这在现实世界中并非如此。。

我认为这些解决方案都不是“好的或健壮的”解决方案，但是mount选项似乎可以满足“足够好”的要求，如果需要真正强大的解决方案，请使用busybox建议的功能。