¿Averigua qué dispositivo / dev / root representa en Linux?

En Linux, hay un /dev/rootnodo de dispositivo. Este será el mismo dispositivo de bloque que otro nodo de dispositivo, como /dev/sdaX. ¿Cómo puedo resolver /dev/rootel nodo del dispositivo 'real' en esta situación, para poder mostrarle a un usuario un nombre de dispositivo sensible?

Por ejemplo, podría encontrarme con esta situación al analizar /proc/mounts.

Estoy buscando soluciones que funcionen desde un script de shell / python pero no C.

Analiza el root=parámetro desde /proc/cmdline.

En los sistemas que he visto, /dev/roothay un enlace simbólico al dispositivo real, por lo que readlink /dev/root(o readlink -f /dev/rootsi desea la ruta completa), lo hará.

Bueno, /dev/rootes solo un enlace simbólico al dispositivo real, por lo que puede usar readlink(2)para averiguar dónde apunta desde un programa, o readlink(1)hacer lo mismo desde un script de shell.

Tal vez me estoy perdiendo algo, pero ¿qué pasa con:

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

Esto probablemente debería actualizarse, porque mucha de la información aquí proporcionada es engañosa, y en realidad puede que nunca haya sido completamente correcta.

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

Para el punto / mount, solo le dicen que corresponde a / dev / root, que no es el dispositivo real que está buscando.

Por supuesto, puede mirar la línea de comando del kernel y ver en qué sistema de archivos raíz inicial se le indicó a Linux que arranque (parámetro raíz):

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

Sin embargo, esto no significa que lo que ve es el dispositivo raíz actual. Muchos sistemas Linux arrancan en sistemas de archivos raíz intermedios (como initramdisks e initramfs), que solo se utilizan para acceder al último.

Una cosa que esto señala es que la cosa en / proc / cmdline no es necesariamente la raíz del dispositivo final real en realidad.

Eso es de la gente de busybox, que supongo que saben de lo que están hablando cuando se trata de situaciones de arranque.

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

El segundo recurso útil que encontré es un hilo de Slackware muy antiguo sobre la cuestión de / dev / root, a partir de la edad de este hilo, podemos ver que todas las variantes siempre estuvieron presentes, pero creo que 'la mayoría' de las distribuciones usaban la simbólica método de enlace, pero ese era un simple interruptor de compilación del núcleo, podría hacer uno, o no hacer uno si entendía los carteles correctamente, es decir, cambiarlo de una manera, y readlink / dev / root informa el nombre real del dispositivo, cambiarlo el otro, y no lo hace.

Dado que el tema principal de ese hilo era cómo deshacerse de / dev / root, tuvieron que entender qué es realmente, qué lo hace, etc., lo que significa que tenían que entenderlo para deshacerse de él.

repugnante lo explicó bien:

/ dev / root es un dispositivo genérico que se puede usar en el fstab. También se puede usar 'rootfs'. Hacer esto ofrece alguna ventaja, ya que le permite ser menos específico. Lo que quiero decir es que, si la partición raíz está en una unidad externa, es posible que no siempre se muestre como el mismo dispositivo y montarla con éxito ya que requeriría cambiar la fstab para que coincida con el dispositivo correcto. Al usar / dev / root, siempre coincidirá con cualquier dispositivo especificado en los parámetros de arranque del kernel de lilo o grub.

/ dev / root siempre ha estado presente como un punto de montaje virtual, incluso si nunca lo viste. También tiene rootfs (compárelo con los dispositivos virtuales especiales como proc y tmpfs que no tienen precedente / dev)

/ dev / root es un dispositivo virtual como 'proc' o / dev / tcp '. No hay un nodo de dispositivo en / dev para estas cosas, ya está en el kernel como dispositivo virtual.

Esto explica por qué no existe necesariamente un enlace simbólico. Me sorprende que nunca haya tocado este problema antes, dado que mantengo algunos programas que necesitan conocer esta información, pero más vale tarde que nunca.

Creo que algunas de las soluciones que se ofrecen aquí 'a menudo' funcionarán, y probablemente sean lo que haré, pero no son la verdadera solución real al problema, que, como señaló el autor de busybox, es significativamente más complicado de implementar de una manera muy De manera robusta.

[ACTUALIZACIÓN:} Después de obtener algunos datos de prueba de usuario, voy con el método de montaje, que parecía estar bien al menos en algunos casos. El / proc / cmdline no fue útil porque hay demasiadas variantes. En el primer ejemplo, ve el método anterior. Esto es cada vez menos común porque se desaconseja usarlo (la sintaxis original / dev / sdx [0-9]) porque esas rutas pueden cambiar dinámicamente (cambiar el orden del disco, insertar un disco nuevo, etc., y de repente / dev / sda1 se convierte en / dev / sdb1).

root=/dev/sda1
root=UUID=5a25cf4a-9772-40cd-b527-62848d4bdfda
root=LABEL=random string
root=PARTUUID=a2079bfb-02

VS el muy limpio y fácil de analizar:

mount
/dev/sda1 on / type ext4 (rw,noatime,data=ordered)

En el caso de cmdline, verá, la única variante que es la 'respuesta' correcta en teoría es la primera, en desuso, ya que no debe referir la raíz a un objetivo en movimiento como / dev / sdxy

Los dos siguientes requieren realizar la acción adicional de obtener el enlace simbólico de esa cadena en / dev / disk / by-uuid o / dev / disk / by-label

El último requiere, creo, usar parted -l para encontrar a qué apunta esa identificación parted.

Esas son solo las variantes que conozco y he visto, bien podría haber otras, como GPTID, por ejemplo.

Entonces la solución que estoy usando es esta:

primero, vea si / dev / root es un enlace simbólico. Si es así, verifique que no esté en / dev / disk / by-uuid o by-label, si es así, debe realizar un segundo paso de procesamiento para obtener la última ruta real. Depende de la herramienta que uses.

Si no tienes nada, ve a montar y mira cómo es eso. Como último caso alternativo, uno que no estoy usando porque los argumentos en su contra, ni siquiera siendo la partición o dispositivo en cuestión, son lo suficientemente buenos como para rechazar esa solución para mi programa. Mount no es una solución completamente robusta, y estoy seguro de que con suficientes muestras, sería fácil encontrar casos en los que no es correcto en absoluto, pero creo que estos dos casos cubren a 'la mayoría' de los usuarios, que es todo lo que necesitaba.

La solución más agradable, más limpia y más confiable hubiera sido que el núcleo siempre creara el enlace simbólico, lo que no habría perjudicado a nada ni a nadie, y lo llamaría bueno, pero no es así como funcionó en el mundo real. .

No considero ninguna de estas soluciones 'buenas o robustas', pero la opción de montaje parece satisfacer las 'suficientemente buenas', y si se requiere una solución realmente robusta, use las cosas que recomienda busybox.