Узнайте, какое устройство / dev / root представляет в Linux?

В linux есть /dev/rootузел устройства. Это будет то же самое блочное устройство, что и другое устройство, например /dev/sdaX. Как /dev/rootв этой ситуации я могу обратиться к «реальному» узлу устройства, чтобы я мог показать пользователю разумное имя устройства?

Например, я могу столкнуться с такой ситуацией при разборе /proc/mounts.

Я ищу решения, которые будут работать из сценария оболочки / Python, но не C.

Разобрать root=параметр из /proc/cmdline.

В системах, на которые я смотрел, /dev/rootесть символическая ссылка на реальное устройство, поэтому readlink /dev/root(или, readlink -f /dev/rootесли вам нужен полный путь), это будет сделано.

Ну, /dev/rootэто просто символическая ссылка на реальное устройство, так что вы можете использовать, readlink(2)чтобы узнать, куда оно указывает из программы, или readlink(1)сделать то же самое из сценария оболочки.

Может быть, я что-то упустил, но как насчет:

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

Это, вероятно, следует обновить, потому что большая часть информации, представленной здесь, вводит в заблуждение, и, возможно, фактически никогда не была полностью правильной.

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

Для точки / mount вам просто говорят, что она соответствует / dev / root, который не является реальным устройством, которое вы ищете.

Конечно, вы можете взглянуть на командную строку ядра и увидеть, на какой начальной корневой файловой системе Linux было поручено загрузиться (параметр root):

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

Однако это не означает, что вы видите текущее корневое устройство. Многие системы Linux загружаются на промежуточных корневых файловых системах (таких как initramdisks и initramfs), которые просто используются для доступа к финальной.

Одна вещь, на которую это указывает, заключалась в том, что вещь в / proc / cmdline не обязательно является действительным конечным корнем устройства, на котором фактически живут.

Это от занятых людей, которые, я полагаю, знают, о чем они говорят, когда дело доходит до загрузочных ситуаций.

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

Второй полезный ресурс, который я нашел, - это очень старая ветка Slackware по вопросу / dev / root. По возрасту этой ветки мы видим, что все варианты присутствовали всегда, но я считаю, что «большинство» дистрибутивов использовали символические метод link, но это был простой переключатель компиляции ядра, он мог сделать его или не сделать его, если бы я правильно понял плакаты, то есть переключить его одним способом, а readlink / dev / root сообщает реальное имя устройства, переключить его другой, и это не так.

Поскольку основной темой этого потока было то, как избавиться от / dev / root, они должны были понять, что это такое на самом деле, что делает его и т. Д., А значит, им нужно было понять это, чтобы избавиться от него.

скрежетно объяснил это хорошо

/ dev / root - это общее устройство, которое можно использовать в fstab. Можно также использовать «rootfs». Это дает некоторое преимущество, поскольку позволяет вам быть менее конкретным. Я имею в виду, что если корневой раздел находится на внешнем диске, он может не всегда отображаться как одно и то же устройство, и его успешное монтирование может потребоваться, если / потребуется изменить fstab для соответствия нужному устройству. Используя / dev / root, он всегда будет соответствовать любому устройству, указанному в параметрах загрузки ядра из lilo или grub.

/ dev / root всегда присутствовал как виртуальная точка монтирования, даже если вы ее никогда не видели. Также есть rootfs (сравните это со специальными виртуальными устройствами, такими как proc и tmpfs, у которых нет предшествующих / dev)

/ dev / root - это виртуальное устройство, такое как 'proc' или / dev / tcp '. Для этих вещей в / dev нет узла устройства - он уже находится в ядре как виртуальное устройство.

Это объясняет, почему символическая ссылка не обязательно существует. Я удивлен, что никогда раньше не сталкивался с этой проблемой, учитывая, что я поддерживаю некоторые программы, которые должны знать эту информацию, но лучше поздно, чем никогда.

Я полагаю, что некоторые из предлагаемых здесь решений будут «часто» работать, и, вероятно, я это сделаю, но они не являются истинным истинным решением проблемы, которое, как отметил автор busybox, значительно сложнее реализовать в очень надежная манера

[ОБНОВЛЕНИЕ:} После получения некоторых пользовательских тестовых данных, я собираюсь использовать метод монтирования, который, по крайней мере, подходит для некоторых случаев. / 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 или by-label, если это так, вам нужно сделать второй шаг обработки, чтобы получить последний реальный путь. Зависит от инструмента, который вы используете.

Если у тебя ничего нет, тогда иди на гору и посмотри как это. В качестве последнего резервного варианта я не использую, потому что аргументы, приведенные против него, не обязательно являются фактическим разделом или устройством, о котором идет речь, достаточно хороши, чтобы я отклонил это решение для моей программы. mount - не совсем надежное решение, и я уверен, что при наличии достаточного количества примеров было бы легко найти случаи, когда это совсем не так, но я считаю, что эти два случая охватывают «большинство» пользователей, и это все, что мне было нужно.

Самым хорошим, чистым и самым надежным решением для ядра было бы просто всегда создавать символическую ссылку, которая не повредила бы ничему или кому-либо, и называла бы это хорошим, но в реальном мире это не так. ,

Я не считаю ни одно из них «хорошими или надежными» решениями, но опция монтирования, по-видимому, удовлетворяет «достаточно хорошим», и, если требуется действительно надежное решение, используйте материал, рекомендованный busybox.