Dans les fstab, je sais que les /dev/sdxx, sont les moins recommandés.
Je crois que Pascal avait parlé de remplacer les UUID par les PARTUUID, cela dans un fil mais je ne trouve pas lequel.
J’aimerais bien les avis sur les choix/avantages/inconvénients de ceusses_qui_savent.
Sachant surtout que le fstab dont il est question est appelé à passer d’une machine à une autre via un DDext.
Merci.
Salut,
Les PARTUUID/PARTLABEL identifient les partitions GPT.
En revanche les UUID/LABEL identifient les filesystem.
Donc si tu reformates ta partition ton UUID change mais pas ton PARTUUID.
Dans ton cas, je te conseillerais d’utiliser /dev/sdx car c’est ta fstab que tu balades de disque en disque donc si tu ne veux pas y retoucher sans cesse…
Ce n’est que mon avis 
Oui, mais le problème, c’est que ce DDext est en sdbx sur une machine et en sdcx sur une autre
[quote=“ricardo”]Dans les fstab, je sais que les /dev/sdxx, sont les moins recommandés.
Je crois que Pascal avait parlé de remplacer les UUID par les PARTUUID, cela dans un fil mais je ne trouve pas lequel.
J’aimerais bien les avis sur les choix/avantages/inconvénients de ceusses_qui_savent.
Sachant surtout que le fstab dont il est question est appelé à passer d’une machine à une autre via un DDext.
Merci.[/quote]
Je sais pas si ça va t’aider, mais si tu comprends l’anglais c’est un bon article sur les UUID et PARTUUID :
https://bbs.archlinux.org/viewtopic.php?id=165051
Ah, j’avais compris que c’est la fstab que tu déplaçais.
Si tu déplace un disque utilises les UUID.
Si c’est un disque dont tu formates souvent les partitions, utilise les PARTUUID.
Partition : créer une nouvelle
[quote=“PascalHambourg”]Dans quels cas c’est utile, j’en avais listé quelques-uns plus haut dans ce fil.
https://www.debian-fr.org/message517702.html#p517702
[quote=“PascalHambourg”]L’UUID de partition (PARTUUID) est à l’origine (*) une spécificité de certains formats de table de partition comme GPT : chaque partition a un UUID “propre” qui permet de l’identifier indépendamment de son contenu. C’est totalement distinct de l’UUID “classique” lié au contenu (système de fichiers, swap…) de la partition. La même chose existe pour les labels de partition (PARTLABEL). Les versions suffisamment récentes du noyau Linux, udev/blkid et mount (donc fstab) savent gérer les UUID et labels de partitions. Cela présente des avantages, par exemple :
- si on “reformate” une partition, son UUID et son LABEL de contenu risquent de changer, mais pas son PARTUUID ni son PARTLABEL ;
- le noyau sait lire les PARTUUID et PARTLABEL, ce qui permet de monter directement la racine désignée par ce moyen sans initramfs, alors qu’un initramfs avec udev/blkid est obligatoire pour monter la racine identifiée par un UUID ou LABEL de contenu.
- si on clone le contenu d’une partition bloc à bloc, on peut encore distinguer la copie de l’original (qui auront les mêmes UUID et LABEL de contenu) par leur PARTUUID ou PARTLABEL.
- les partition sans contenu identifiable par un UUID ou un label, comme la partition BIOS boot, peuvent être identifiées par leur PARTUUID ou PARTLABEL.
(*) Les noyaux Linux suffisamment récents construisent aussi des PARTUUID synthétiques (mais pas de PARTLABEL) pour les partitions de disques au format MSDOS en se basant sur l’identifiant de disque contenu dans le MBR.[/quote]
Se passer d’initramfs implique de recompiler le noyau en incluant tous les pilotes nécessaires, je ne pense pas que cela te concerne.
Le cas du clonage de partition est relativement anecdotique, je pense.
Le cas de la partition sans contenu identifiable par un UUID, je l’ai mentionné pour être le plus complet possible mais en pratique je ne vois pas de cas concret où ce serait utile. La partition de type “BIOS Boot” que j’ai citée n’a pas besoin d’être référencée, elle n’est utilisée que par grub-install de façon implicite.
Le seul cas concret qui peut t’intéresser à mon avis, c’est le “reformatage” d’une partition contenant un système de fichiers ou un swap. Tu as vu l’exemple du swap lors de l’installation de la future Sid. Un autre exemple concret qui peut arriver, c’est la recréation d’un système de fichiers corrompu, suivie de la restauration du contenu à partir d’une sauvegarde. Si on ne spécifie pas explicitement l’ancien UUID lors de l’exécution de mkfs (ou mkswap pour une partition de swap), un nouvel UUID sera généré et il faudra mettre à jour toutes les références à la partition de type [mono]UUID=[/mono] notamment dans /etc/fstab.
Pour éviter cela, on peut remplacer les références de la forme [mono]UUID=[/mono] où est l’UUID du contenu (système de fichiers ou swap) par [mono]PARTUUID=[/mono] où est l’UUID unique de partition (à ne pas confondre avec l’UUID de type de partition), visible avec blkid ou gdisk.
Par contre je ne sais pas si update-grub sait manipuler les PARTUUID et comment il se comporte si la racine d’un système est référencée par son PARTUUID. Va-t-il reprendre cette référence dans le paramètre “root=” de la ligne de commande du noyau dans le fichier grub.cfg généré ? Même chose pour la partition /boot, le chargeur GRUB est-il capable de l’identifier par son PARTUUID ?[/quote]
Merci d’avoir retrouvé le fil, Belzébuth, et d’en avoir copié l’important concernant ma question.
On ne peut pas vraiment parler d’avantages ou inconvénients dans l’absolu. Ce qui est un avantage dans une situation peut devenir un inconvénient dans une autre situation.
Les différences entre UUID, LABEL, PARTUUID et PARTLABEL concernent la persistance et l’unicité.
Les (PART)UUID générés aléatoirement sont moins parlants mais plus uniques que les (PART)LABEL. Si tu as des installations sur plusieurs disques/machines, tu as peut-être donné les mêmes étiquettes aux partitions ou systèmes de fichiers (root, home, var, swap…). Tant que ces disques ne sont pas dans la même machine, tout va bien. Mais si un jour tu as besoin de brancher le disque d’une machine sur une autre machine pour dépanner, il y aura des conflits entre les étiquettes.
La persistance des UUID et PARTUUID n’est pas de même nature. Comme cela a été dit, l’UUID concerne le système de fichiers (le contenu) alors que le PARTUUID concerne la partition elle-même (le contenant). J’illustre la différence avec deux cas d’utilisation :
- Si je reformate la partition, l’UUID change mais pas le PARTUUID.
- Si je recrée la partition et y restaure une image de sauvegarde (clone), le PARTUUID change mais pas l’UUID.
Pas seulement. Depuis Jessie, les partitions d’un disque au format MSDOS ont aussi un PARTUUID synthétique construit à partir de l’identifiant du disque contenu dans le MBR et du numéro de la partition. C’est visible avec [mono]blkid[/mono] par exemple. Cependant, cet UUID synthétique est par nature moins persistant que celui d’une partition de disque au format GPT car il dépend du numéro de la partition. Or ce numéro est susceptible de changer notamment en cas d’ajout ou suppression d’une autre partition logique. Bref, si vous pouvez utilisez GPT au lieu de partitions logiques, ça a plein d’autres avantages.
Super précisions, comme d’habitude
Le premier paragraphe illustre bien la chose et chacun peut faire son choix selon ses besoins.
Je mets ce fil dans mon pense-bête.