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


17

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

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

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


ты здесь проверил? linux-diag.sourceforge.net/Sysfsutils.html Рекомендует способ запрашивать ядро ​​о подключенных устройствах всех видов, не уверен, если это то, что вы ищете!

Ответы:


14

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


Вау, молниеносные реакции :-)

1
Это намного безопаснее, чем разыменование символической ссылки. +1 :)
Тим Пост

1
Это работает на трех дистрибутивах (fc14, rhel5, ubuntu 11.04), которые я рассмотрел, с небольшим предостережением о том, что для обработки аргументов типа root = UUID = type требуется дополнительный шаг.
КДТ

Меня интересует, почему это безопаснее, чем решение readlink, кто-нибудь может уточнить?
opello

readlink не всегда работает, я работаю над этой проблемой прямо сейчас и нашел пользователя, система которого не показывает результатов: readlink / dev / root - который вызвал сбой в программе, над которой я работаю, поэтому я и пришел к этой теме. Правильный тест - сначала выполнить readlink / dev / root, затем, если он равен null, найти его в / proc / cmdline, но синтаксический анализ / proc / cmdline не так прост, как лучшее решение, поэтому я продолжу искать.
Lizardx

12

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


Или просто ls -l /dev/root- короче набрать :)
rozcietrzewiacz

@jankes, но тогда вы должны проанализировать вывод ls(он попросил что-то использовать в сценарии).
CJM

Ах, извини - упустил это из виду.
rozcietrzewiacz

Нет - на моей машине RHEL5 это определенно не символическая ссылка, хотя на машине FC14 или Ubuntu 11.04 это так.
КДТ

1
Не работает на archlinux.
g33kz0r

7

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


Нет, не работает на archlinux
g33kz0r

Также не в Debian, openSUSE, CentOS (неполный список) :(
pevik

Добавьте Ubuntu в список.
Lizardx

2

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

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

2

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

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.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.