Découvrez quel périphérique / dev / root représente sous Linux?

Sous Linux, il existe un /dev/rootnœud de périphérique. Ce sera le même périphérique de bloc qu'un autre nœud de périphérique, comme /dev/sdaX. Comment puis-je résoudre /dev/rootle nœud de périphérique «réel» dans cette situation, afin que je puisse montrer à un utilisateur un nom de périphérique raisonnable?

Par exemple, je pourrais rencontrer cette situation lors de l'analyse /proc/mounts.

Je cherche des solutions qui fonctionneraient à partir d'un script shell / python mais pas C.

Analyser le root=paramètre de /proc/cmdline.

Sur les systèmes que j'ai examinés, il /dev/rooty a un lien symbolique vers le vrai périphérique, donc readlink /dev/root(ou readlink -f /dev/rootsi vous voulez le chemin complet) le fera.

Eh bien, /dev/rootc'est juste un lien symbolique vers le vrai périphérique, vous pouvez donc l'utiliser readlink(2)pour savoir où il pointe à partir d'un programme, ou readlink(1)pour faire la même chose à partir d'un script shell.

Peut-être que je manque quelque chose, mais qu'en est-il:

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

Cela devrait probablement être mis à jour, car une grande partie des informations fournies ici sont trompeuses et n'ont peut-être jamais été complètement correctes.

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

Pour le point de montage /, on vous dit juste qu'il correspond à / dev / root, qui n'est pas le vrai périphérique que vous recherchez.

Bien sûr, vous pouvez regarder la ligne de commande du noyau et voir sur quel système de fichiers racine initial Linux a été chargé de démarrer (paramètre racine):

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

Cependant, cela ne signifie pas que ce que vous voyez est le périphérique racine actuel. De nombreux systèmes Linux démarrent sur des systèmes de fichiers racine intermédiaires (comme initramdisks et initramfs), qui sont juste utilisés pour accéder au dernier.

Une chose que cela souligne, c'est que la chose dans / proc / cmdline n'est pas nécessairement la racine réelle du périphérique final réellement en vie.

Cela vient des gens occupés, qui je suppose savent de quoi ils parlent quand il s'agit de situations de démarrage.

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

La deuxième ressource utile que j'ai trouvée est un très vieux fil de discussion Slackware sur la question de / dev / root, depuis l'âge de ce fil, nous pouvons voir que toutes les variantes étaient toujours présentes, mais je crois que `` la plupart '' des distributions utilisaient le symbolique méthode de lien, mais c'était un simple commutateur de compilation du noyau, il pouvait en faire un, ou pas si je comprenais bien les affiches, c'est-à-dire le basculer dans un sens, et readlink / dev / root rapporte le nom réel du périphérique, le changer l'autre, et ce n'est pas le cas.

Comme le sujet principal de ce fil était comment se débarrasser de / dev / root, ils devaient entrer dans ce qu'il était réellement, ce qui le rend, etc., ce qui signifie qu'ils devaient le comprendre pour s'en débarrasser.

grincheusement expliqué bien:

/ dev / root est un périphérique générique qui peut être utilisé dans le fstab. On peut également utiliser «rootfs». Faire cela offre un certain avantage en ce qu'il vous permet d'être moins spécifique. Ce que je veux dire, c'est que si la partition racine se trouve sur un disque externe, elle peut ne pas toujours apparaître comme le même périphérique et la monter avec succès car / nécessiterait de changer le fstab pour correspondre au périphérique correct. En utilisant / dev / root, il correspondra toujours au périphérique spécifié dans les paramètres de démarrage du noyau de lilo ou grub.

/ dev / root a toujours été présent en tant que point de montage virtuel, même si vous ne l'avez jamais vu. Il en va de même pour rootfs (comparez cela aux périphériques virtuels spéciaux comme proc et tmpfs qui n'ont pas de dev / dev)

/ dev / root est un périphérique virtuel comme 'proc' ou / dev / tcp '. Il n'y a pas de nœud de périphérique dans / dev pour ces choses - il est déjà dans le noyau en tant que périphérique virtuel.

Cela explique pourquoi un lien symbolique n'existe pas nécessairement. Je suis surpris de n'avoir jamais rencontré ce problème auparavant, étant donné que je maintiens certains programmes qui ont besoin de connaître ces informations, mais mieux vaut tard que jamais.

Je crois que certaines des solutions proposées ici fonctionneront «souvent», et sont probablement ce que je ferai, mais elles ne sont pas la vraie vraie solution au problème qui, comme l'a noté l'auteur de busybox, est beaucoup plus compliqué à mettre en œuvre dans un contexte très manière robuste.

[MISE À JOUR:} Après avoir obtenu des données de test utilisateur, je vais avec la méthode de montage, qui semblait être correcte dans certains cas au moins. La ligne de commande / proc / n'était pas utile car il existe trop de variantes. Dans le premier exemple, vous voyez l'ancienne méthode. C'est de moins en moins courant car il est fortement déconseillé de l'utiliser (la syntaxe de type / dev / sdx [0-9] d'origine) car ces chemins peuvent changer dynamiquement (permuter l'ordre des disques, insérer un nouveau disque, etc., et soudainement / dev / sda1 devient / dev / sdb1).

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

VS le très propre et facile à analyser:

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

Dans le cas de cmdline, vous verrez, la seule variante qui est la bonne «réponse» en théorie est la première, déconseillée, car vous ne devez pas référencer root à une cible en mouvement comme / dev / sdxy

Les deux suivants nécessitent d'effectuer l'action supplémentaire consistant à obtenir le lien symbolique de cette chaîne dans / dev / disk / by-uuid ou / dev / disk / by-label

Le dernier nécessite, je crois, d'utiliser parted -l pour trouver ce vers quoi cet id parted pointe.

Ce ne sont que les variantes que je connais et que j'ai vues, il pourrait bien y en avoir d'autres, comme GPTID, par exemple.

La solution que j'utilise est donc la suivante:

tout d'abord, voyez si / dev / root est un lien symbolique. Si c'est le cas, vérifiez que ce n'est pas dans / dev / disk / by-uuid ou by-label, si c'est le cas, vous devez effectuer une deuxième étape de traitement pour obtenir le dernier vrai chemin. Cela dépend de l'outil que vous utilisez.

Si vous n'avez rien, allez à la monture et voyez comment c'est. Comme dernier cas de secours, celui que je n'utilise pas parce que les arguments avancés contre lui ne sont même pas nécessairement la partition ou le périphérique en question sont assez bons pour que je rejette cette solution pour mon programme. Le montage n'est pas une solution entièrement robuste, et je suis sûr qu'avec suffisamment d'échantillons, il serait facile de trouver des cas où cela ne va pas du tout, mais je pense que ces deux cas couvrent `` la plupart '' des utilisateurs, c'est tout ce dont j'avais besoin.

La solution la plus agréable, la plus propre et la plus fiable aurait été pour le noyau de toujours créer le lien symbolique, ce qui n'aurait blessé personne ni personne, et de l'appeler bon, mais ce n'est pas ainsi que cela a fonctionné dans le monde réel. .

Je ne considère aucune d'entre elles comme des solutions `` bonnes ou robustes '', mais l'option de montage semble satisfaire les `` assez bonnes '', et si la solution vraiment robuste est requise, utilisez les éléments recommandés par busybox.