Después de investigar con expertos en esta materia, programadores de deferentes ramas y profesores dimos con la respuesta al dilema y la compartimos en este post.
Solución:
analizar el root= parámetro de /proc/cmdline.
En los sistemas que he mirado, /dev/root es un enlace simbólico al dispositivo real, por lo que readlink /dev/root (o readlink -f /dev/root si quieres 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 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 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 final.
Una cosa que esto señala es que la cosa 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 lo hace.
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.
Gashly 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 montarlo con éxito como requiere 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 o grub.
/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 /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 kernel 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 saber 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 yo haré, pero no son las soluciones reales. true solución al problema, que como señaló el autor de busybox, es significativamente más complicado de implementar de una manera muy robusta.
[UPDATE:} After getting some user test data, I’m going with the mount method, which seemed to be ok for some cases at least. The /proc/cmdline was not useful because there are too many variants. In the first example, you see the old method. This is less and less common because it’s strongly discouraged to use it (the original /dev/sdx[0-9] tipo de sintaxis) 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 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 ese string 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 habría sido que el núcleo siempre hiciera el enlace simbólico, lo que no habría perjudicado a nada ni a nadie, y lo hubiera llamado 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.
Recuerda que tienes la capacidad de añadir una tasación certera .