Pourquoi fstab utilise-t-il l'UUID au lieu du nom du système de fichiers réel?

Par exemple, ceci est la première ligne de mon /etc/fstab:

UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a    /    ext4    errors=remount-ro    0    1

Et voici la sortie de la df -hcommande (rapportant l'espace disque libre):

honey@bunny:~$ df -T

Filesystem     Type     1K-blocks    Used Available Use% Mounted on
/dev/vda       ext4      30832636 4884200  24359188  17% /
none           tmpfs            4       0         4   0% /sys/fs/cgroup
udev           devtmpfs    498172      12    498160   1% /dev
tmpfs          tmpfs       101796     320    101476   1% /run
none           tmpfs         5120       0      5120   0% /run/lock
none           tmpfs       508972       0    508972   0% /run/shm
none           tmpfs       102400       0    102400   0% /run/user

Des deux, est-il correct de déduire que UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13areprésente /dev/vdaétant donné que la première colonne de fstabest <file system>?

Alors, ce serait bien si je modifiais /etc/fstabcela?

/dev/vda    /    ext4    errors=remount-ro    0    1

EDIT: Si oui (à la question ci-dessus), pourquoi la sudo blkidcommande affiche-t-elle un UUID différent pour /dev/vda?
```
$ sudo blkid

/dev/vda: LABEL="DOROOT" UUID="6f469437-4935-44c5-8ac6-53eb54a9af26" TYPE="ext4"
```
Qu'est-ce que j'oublie ici?

Réponse: je conclurais (3) à être un bug dans le cloud de mon hôte. Donc oui, l'UUID signalé par blkid(ou ls -l /dev/disk/by-uuid) devrait être le même que celui utilisé dans /etc/fstab.

— c'est moi
source

Vérifiez l'UUID avec la sudo blkidcommande.

— Avinash Raj

@AvinashRaj Hmm, bizarrement, la sudo blkidcommande génère un UUID différent pour /dev/vda. Cela ajoute à ma confusion. :) (Question mise à jour.)

— its_me

Ce n'est pas un bon signe que la commande blkid affiche un UUID différent - veuillez vérifier l'UUID actuel avec `ls -l / dev / disk / by-uuid ''. Depuis sa vda, se pourrait-il que l'infrastructure de machine virtuelle sous-jacente ait changé quelque chose?

— liquidat

Ce @liquidat est la sortie que je suis: lrwxrwxrwx 1 root root 9 Jun 18 11:04 6f469437-4935-44c5-8ac6-53eb54a9af26 -> ../../vda. Quant à votre autre question, je vais contacter l'hébergeur à ce sujet.

— its_me

Je dirais que la machine peut ne pas redémarrer car l'entrée fstab est tout à fait erronée. Cela pourrait être un disque cloné ou quelque chose. Je suppose qu'il n'y a aucun autre appareil qui a l'UUID donné dans fstab?

— liquidat

Réponses:

L'avantage de l'utilisation de l'UUID est qu'il est indépendant du numéro de périphérique réel que le système d'exploitation donne à votre disque dur.

Imaginez que vous ajoutez un autre disque dur au système, et pour une raison quelconque, le système d'exploitation décide que votre ancien disque est maintenant à la sdbplace de sda.

Votre processus de démarrage serait foiré s'il fstabpointe vers le nom du périphérique. Mais dans le cas des UUID, ça va.

Des informations plus détaillées sur les UUID peuvent également être trouvées sur le blog "UUID et Linux: tout ce que vous devez savoir"

— liquidat
source

oui. même sans ajouter de nouveau disque, votre noyau peut décider d'échanger simplement deux des montages de développement de vos disques un jour. Voir wiki.archlinux.org/index.php/Persistent_block_device_naming

— Tommy

que se passe-t-il si je veux cloner l'image sur un autre disque, qui a un UUID différent?

— aloplop85

Il y a au moins une situation où les UUID sont moins utiles: si vous clonez un disque entier, puis redémarrez, vous pouvez obtenir le montage des partitions à partir de l'un ou l'autre disque, ou du mauvais disque.

— boot13

C'est vrai - vérifiez le billet de blog lié, il a même une section quand ne pas les utiliser.

— liquidation le

Si vous clonez le disque, vous devez modifier l'UUID sur le nouveau disque. tune2fs xfs_admin ou reiserfstune peuvent le faire en fonction de votre système de fichiers.

— steveayre

Dans ce cas, puis-je modifier / etc / fstab en ceci?

Vous pouvez et ce sera probablement correct, mais il serait probablement préférable de quitter l'UUID.

Les UUID sont des chaînes arbitraires utilisées pour identifier, dans ce cas, une partition sur un périphérique bloc; son stocké avec la partition elle-même, et peut être affecté à un autre si vous le souhaitez (sorte d'adresses MAC similaires).

L'avantage d'utiliser l'UUID est qu'il est indubitable, alors qu'il /dev/vdane l'est pas; il peut arriver qu'il finisse par être un lecteur différent au démarrage, bien que cela puisse être totalement théorique dans le contexte (par exemple, parce que vous n'avez qu'un seul lecteur d'un type particulier).

Un autre exemple plus subtil où l'utilisation du nom de périphérique peut causer un problème serait le passage récent de certains systèmes à l'utilisation de noms de périphériques réseau cohérents . Si cela se produisait comme une mise à niveau et que vous utilisiez un nom de périphérique codé en dur quelque part dans un script réseau, il se briserait. Un exemple parallèle de périphériques de bloc WRT peut être une mise à niveau du noyau ou udev qui modifie le schéma de dénomination.

Un des UUID est de rendre ce genre de choses possible et indolore. Ainsi, même si vous pouvez utiliser le nom du périphérique, cela n'a aucun avantage à moins que (par exemple) vous ayez un système dans lequel vous permutez différents lecteurs. En d'autres termes, si vous n'avez pas une bonne raison de le faire, restez avec l'UUID .

— boucle d'or
source

D'accord. Alors , ce qui explique les différents UUID pour /dev/vdadans /etc/fstabet rapporté par blkid? (Veuillez voir la question mise à jour si vous ne l'avez pas fait.)

— its_me

Plutôt que de demander dans une mise à jour, vous devriez poser cela comme une question distincte ("Pourquoi mon UUID de partition montée est-il différent de celui de fstab?").

— goldilocks

Vous pouvez le faire man fstabpour une lecture assez concise du contenu et de la sémantique du /etc/fstabfichier. Sur mon x86, un serveur Arch linux assez à jour, man fstabme donne ceci:

The second field ... describes  the mount point for the filesystem.

Donc, oui, /dev/vdaapparemment, c'est l'un des nombreux noms d'un appareil, tel quel UUID=050e1e34-39e6-4072-a03e-ae0bf90ba13a, étant donné que les deux noms semblent monter sur "/".

Si vous regardez dans le répertoire, /dev/disk/by-uuid/vous pouvez voir des liens symboliques qui pointent vers des choses comme /dev/sda1, /dev/sdb1sur mon serveur. Cela pourrait être une autre façon de vérifier votre hypothèse. /dev/diska des sous - répertoires by-id, by-path, by-uuidqui semblent tous être d' autres noms pour le même périphérique.

— Bruce Ediger
source

Dans ce cas, le problème (tel que mis à jour dans ma question) est que j'obtiens deux UUID différents pour /dev/vda! Veuillez revoir la question une fois de plus.

— its_me

Si j'ai répondu à la question d'origine, ce serait une bonne idée de la marquer comme «répondue» et d'écrire une nouvelle question, juste pour ne pas collecter des réponses non pertinentes, des réponses qui fonctionnent avec l'original et non la question modifiée.

— Bruce Ediger