Analizar el root= parámetro de /proc/cmdline .
En los sistemas que he visto, /dev/root es un enlace simbólico al dispositivo real, por lo que readlink /dev/root (o readlink -f /dev/root si desea la ruta completa), lo hará.
Esto probablemente debería actualizarse, porque mucha de la información proporcionada aquí es engañosa y, en realidad, es posible que nunca haya sido completamente correcta.
https://bootlin.com/blog/buscar-dispositivo-raíz/
Para el punto de montaje /, solo se le dice que corresponde a/dev/root, que no es el dispositivo real que está buscando.
Por supuesto, puede consultar la línea de comandos 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 console=ttyS2,115200n8root=/dev/mmcblk0p2 rw rootwait
Sin embargo, esto no significa que lo que ve sea 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 lo que está en /proc/cmdline no es necesariamente la raíz real del dispositivo final en la que realmente vive.
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 subproceso de Slackware muy antiguo sobre la cuestión de /dev/root, a partir de la antigüedad de este subproceso, podemos ver que todas las variantes siempre estuvieron presentes, pero creo que 'la mayoría' de las distribuciones usaban el simbólico enlace, pero ese fue un simple cambio de compilación del kernel, podría hacer uno, o no hacer uno si entendí los carteles correctamente, es decir, cambiarlo de una manera, y readlink /dev/root informa el nombre real del dispositivo, cambiarlo el otro, y no.
Dado que el tema principal de ese hilo era cómo deshacerse de /dev/root, tenían que entrar en lo que realmente es, qué lo hace, etc., lo que significa que tenían que entenderlo para deshacerse de él.
rechinantemente lo explicó bien:
/dev/root es un dispositivo genérico que se puede usar en 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 como / requeriría cambiar el 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 orgrub.
/dev/root siempre ha estado presente como un punto de montaje virtual, incluso si nunca lo vio. Lo mismo ocurre con rootfs (compárelo con los dispositivos virtuales especiales como proc y tmpfs que no tienen un /dev anterior)
/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 núcleo como un dispositivo virtual.
Esto explica por qué no existe necesariamente un enlace simbólico. Me sorprende que nunca me haya topado con 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í funcionarán 'a menudo', y es probable que sea 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 manera robusta.
[ACTUALIZAR:} Después de obtener algunos datos de prueba del usuario, opté por 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, ves el método antiguo. Esto es cada vez menos común porque se desaconseja enfáticamente usarlo (la sintaxis de tipo /dev/sdx[0-9] original) porque esas rutas pueden cambiar dinámicamente (intercambiar el orden del disco, insertar un nuevo disco, 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á que la única variante que es la 'respuesta' correcta en teoría es la primera, obsoleta, ya que no debe hacer referencia a root 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.
Así que la solución que estoy usando es esta:
primero, vea si /dev/root es un enlace simbólico. Si es así, verifique que no sea para /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 utilices.
Si no tienes nada, entonces ve a montar y mira cómo es eso. Como último caso alternativo, uno que no estoy usando porque los argumentos dados en contra de que ni siquiera sean necesariamente la partición o el dispositivo real 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, dadas suficientes muestras, sería fácil encontrar casos en los que no sea del todo correcto, pero creo que estos dos casos cubren a 'la mayoría' de los usuarios, que es todo lo que necesitaba.
La mejor solución, la más limpia y la más confiable hubiera sido que el núcleo siempre hiciera el enlace simbólico, lo que no habría lastimado 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 como soluciones 'buenas o robustas', pero la opción de montaje parece satisfacer lo 'suficientemente bueno', y si se requiere una solución verdaderamente robusta, use las cosas que recomiende busybox.