Analyser le root= paramètre de /proc/cmdline .
Sur les systèmes que j'ai examinés, /dev/root est un lien symbolique vers le périphérique réel, donc readlink /dev/root (ou readlink -f /dev/root si vous voulez le chemin complet), le fera.
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é invité à démarrer (paramètre racine) :
$ cat /proc/cmdline mem=512M console=ttyS2,115200n8root=/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 ne sont utilisés que pour accéder au dernier.
Une chose que cela souligne est que la chose dans /proc/cmdline n'est pas nécessairement la racine réelle du périphérique final sur laquelle vit réellement.
Cela vient des personnes occupées, qui, je suppose, savent de quoi elles parlent lorsqu'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 Slackware sur la question de /dev/root, depuis l'âge de ce fil, on peut voir que toutes les variantes étaient toujours présentes, mais je crois que "la plupart" des distributions utilisaient le symbolique link méthode, mais c'était un simple commutateur de compilation du noyau, il pouvait en faire un, ou ne pas en faire un si j'avais bien compris les affiches, c'est-à-dire le changer dans un sens, et readlink /dev/root indique le vrai nom du périphérique, changez-le l'autre, et ce n'est pas le cas.
Étant donné que le sujet principal de ce fil était de savoir comment se débarrasser de /dev/root, ils devaient comprendre ce qu'il est réellement, ce qui le rend, etc., ce qui signifie qu'ils devaient le comprendre pour s'en débarrasser.
gnashly l'a bien expliqué :
/dev/root est un périphérique générique qui peut être utilisé dans le fstab. On peut aussi utiliser 'rootfs'. Faire cela offre certains avantages en ce sens qu'il vous permet d'être moins précis. Ce que je veux dire, c'est que si la partition racine est sur un lecteur externe, elle peut ne pas toujours apparaître comme le même périphérique et le monter avec succès en tant que / nécessiterait de changer le fstab pour qu'il corresponde au bon périphérique. En utilisant /dev/root, il correspondra toujours au périphérique spécifié dans les paramètres de démarrage du noyau de lilo orgrub.
/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 préfixe /dev)
/dev/root est un périphérique virtuel comme 'proc' ou /dev/tcp'. Il y a un nœud nodevice dans /dev pour ces choses - il est déjà dans le noyau en tant que périphérique virtuel.
Ceci explique pourquoi un lien symbolique n'existe pas nécessairement. Je suis surpris de ne jamais avoir 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 solution au problème, qui, comme l'a noté l'auteur de la boîte occupée, est beaucoup plus compliquée à mettre en œuvre dans un très manière robuste.
[MISE À JOUR :} Après avoir obtenu des données de test utilisateur, j'utilise la méthode de montage, qui semblait convenir au moins dans certains cas. Le /proc/cmdline n'était pas utile car il y a 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 originale de type /dev/sdx[0-9]) car ces chemins peuvent changer dynamiquement (changer l'ordre des disques, insérer un nouveau disque, etc, et du coup /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, obsolète, car vous ne devez pas faire référence à root à une cible mouvante comme /dev/sdxy
Les deux suivants nécessitent de faire l'action supplémentaire d'obtenir le lien symbolique à partir 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 vers quoi pointe cet identifiant séparé.
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 :
d'abord, voyez si /dev/root est un lien symbolique. Si c'est le cas, vérifiez qu'il ne s'agit pas de /dev/disk/by-uuid ou de by-label, si c'est le cas, vous devez effectuer une deuxième étape de traitement pour obtenir le dernier chemin réel. Dépend de l'outil que vous utilisez.
Si vous n'avez rien, allez à monter et voyez comment c'est. Comme dernier cas de repli, celui que je n'utilise pas parce que les arguments avancés contre cela 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. mount 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ù ce n'est pas du tout correct, 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é que le noyau fasse toujours le lien symbolique, ce qui n'aurait fait de mal à personne ni à personne, et l'appellerait bon, mais ce n'est pas ainsi que cela fonctionnait dans le monde réel.
Je ne considère aucune de ces solutions comme "bonnes ou robustes", mais l'option de montage semble satisfaire le "assez bon", et si la solution vraiment robuste est requise, utilisez les éléments recommandés par busybox.