Salut à tous.
J’ai un disque dur en lvm, j’ai créer un “volume groupe” et dedans plusieurs “logical volume”.
Dans /etc/fstab, comment ma ligne doit-être ?
Dans mon fstab :
/dev/mapper/centre-Programmes /media/Programmes ext4 defaults 0 2
Donc ta première proposition.
michel@debg53sw:~$ udisksctl info -b /dev/dm-2 | grep /dev/
Device: /dev/dm-2
PreferredDevice: /dev/vg2x128/lv2x128
Symlinks: /dev/disk/by-id/dm-name-vg2x128-lv2x128
/dev/disk/by-id/dm-uuid-LVM-aPDERyR0T0oT4OezW1HfRt8PlB9cdgwuAIOKHhhiMOblTy3D0meYgggoxmR3gtJb
/dev/disk/by-uuid/e871a2ec-6534-4321-859c-620d1c576070
/dev/mapper/vg2x128-lv2x128
/dev/vg2x128/lv2x128
michel@debg53sw:~$
Les 6 autres sont tous des liens vers /dev/dm-2.
=======
Perso, dans le fichier /etc/fstab, je préfère utiliser l’UUID du système de fichiers :
e871a2ec-6534-4321-859c-620d1c576070
Les deux noms sont équivalents. Normalement /dev/$VG/$LV est le nom à utiliser mais /dev/mapper/$VG-$LV est le nom utilisé par l’installateur Debian parce qu’il permet à divers scripts de reconnaître que c’est un volume logique et de le gérer comme il convient. /dev/dm-* ne doit pas être utilisé car il n’est pas persistant.
À mon avis c’est du gâchis d’utiliser l’UUID comme identifiant persistant pour un volume logique alors que le nom de VG/LV est persistant en lui-même et plus parlant qu’un UUID. D’autre part, tous les contenus n’ont pas forcément d’UUID.
Je préférai l’UUID car il indiquait qu’un système de fichiers existe : Le VG et le LV peuvent très bien exister alors que ce volume logique a été re-formaté (ou ne l’a jamais été mais bon, indiquer un volume non formaté dans le fichier /etc/fstab…
).
Je trolle pas, j’indique simplement les motivations de mon choix,
car finalement, ce qui m’intéresse c’est ce qu’il y a dans le système de fichiers,
et si je le déplace, je n’ai rien à modifier, il suffit juste que je m’arrange pour que cet UUID ne soit utilisé que par une seule partition accessible à la machine,
donc, dès que j’en ai fait une copie, je modifie l’UUID de la partition source que je ne veux plus utiliser et tout va bien.
=======
Pas que par l’installateur : Quel que soit le lien utilisé pour le mountage, c’est toujours /dev/mapper/$VG-$LV qui sera retourné par la commande mount
Je n’ai pas compris ta logique concernant les UUID mais les goûts et les couleurs…
Concernant ce qu’affiche mount sans argument (ou df), cela provient de /etc/mtab qui est désormais un lien symbolique pointant vers /proc/mounts, pseudo-fichier contenant la liste des montages vue par le noyau). C’est lors du montage qu’est déterminé le nom qui sera visible.
Par défaut la commande mount classique du paquet source util-linux remplace le nom de périphérique fourni (ou l’UUID ou LABEL) par le nom “canonique”. Ainsi UUID=xxxx ou dev/disk/by-uuid/xxxx(lien symbolique) est transformé en /dev/sd$x$n s’il s’agit d’une partition simple. Dans le cas d’un volume logique LVM, visiblement mount choisit comme nom canonique la forme /dev/mapper/$vg-$lv bien que ce soit un lien symbolique, au lieu du véritable nom /dev/dm-$n. On peut voir ce processus en ajoutant l’option -v à la commande mount lors d’un montage manuel, ce qui affiche le nom de périphérique qui va effectivement être passé au noyau et sera visible dans /proc/mounts.
Pour éviter ce remplacement, on peut ajouter l’option -c à mount lors d’un montage manuel, et /proc/mounts contiendra le nom de périphérique d’origine.
La commande mount incluse dans busybox (utilisée par défaut dans l’initramfs et qui sert à monter la racine) a un comportement légèrement différent. Quand la racine, montée par l’initramfs, est un volume LVM, on peut voir qu’elle apparaît sous la forme canonique/dev/dm-$n et non /dev/mapper/$vg-$lv.
A noter que ce comportement a changé entre Wheezy et Jessie : dans Wheezy, lorsque la racine était identifiée par son UUID, ce dernier était affiché par mount ou df, ce qui n’était pas très pratique. Maintenant ils affichent le nom canonique du périphérique, mais avec l’excès inverse qui fait que si la racine est un volume logique son nom “convivial” n’apparaît plus. Comme ce n’est pas le comportement normal du mount de busybox, je soupçonne un readlink de s’être glissé par là…