Partitionnement Debian

Support Debian
#1

Bonjour à tous !

Est ce que quelqu’un pourrait m’expliquer ce comportement sous debian 8.7 :
Lors de l’install, j’ai crée mes VG/lvm de cette facon :
Fichier fstab :

/dev/mapper/VG_System-lv_root / ext4 errors=remount-ro 0 1
/boot was on /dev/sda1 during installation
UUID=316442b3-4923-4d60-8f5c-59e4d84fe2b4 /boot ext2 defaults 0 2
/dev/mapper/VG_Appli-lv_home /home ext4 defaults 0 2
/dev/mapper/VG_System-lv_opt /opt ext4 defaults 0 2
/dev/mapper/VG_System-lv_usr /usr ext4 defaults 0 2
/dev/mapper/VG_System-lv_var /var ext4 defaults 0 2
swap was on /dev/sda2 during installation
UUID=f3ba92bb-bf8b-4b1a-ac3a-5010ff5754ae none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

De sorte que mon VG_System contienne des lvm nommés respectivement lv_root, lv_usr, etc… et mappé sur leurs partitions resptives /, /usr etc…

Mais lorsque que je fais un df -h j’obtiens ceci :

> Sys. de fichiers             Taille Utilisé Dispo Uti% Monté sur
/dev/dm-0                      9,1G    248M  8,4G   3% /
udev                            10M       0   10M   0% /dev
tmpfs                          403M    5,9M  397M   2% /run
/dev/dm-1                      4,5G    828M  3,5G  20% /usr
tmpfs                         1006M       0 1006M   0% /dev/shm
tmpfs                          5,0M       0  5,0M   0% /run/lock
tmpfs                         1006M       0 1006M   0% /sys/fs/cgroup
/dev/sda1                      230M     33M  186M  15% /boot
/dev/mapper/VG_Appli-lv_home   9,1G     22M  8,6G   1% /home
/dev/mapper/VG_System-lv_opt   4,5G    9,4M  4,3G   1% /opt
/dev/mapper/VG_System-lv_var   3,7G    253M  3,2G   8% /var

et le dmsetup info me remonte bien les noms correct…

root@template-debian:/# dmsetup ls
VG_System-lv_opt (254:4)
VG_System-lv_root (254:0)
VG_Appli-lv_home (254:2)
VG_System-lv_usr (254:1)
VG_System-lv_var (254:3)

Ma question : d’ou viennent ces dm-0 et dm-01 alors qu’ils correspondent au lv_root et lv_usr (et que les autres lv_opt, lv_var) sont bien nommés?

Y a t il un moyen de les renommer?

Je précise mon propos également car le plus surprenant c’est que le lvm du /root est correctement nommé dans le grub (pas de trace du /usr)

echo 'Chargement de Linux 3.16.0-4-amd64…'
linux /vmlinuz-3.16.0-4-amd64 root=/dev/mapper/VG_System-lv_root ro single
echo ‘Chargement du disque mémoire initial…’

Par contre effectivement dans le mtab et le /proc/mounts les disques sont référencés sous le nom /dev/dem-0 et 1
Ce que je ne comprends pas du coup c’est que les autres LV apparaissent bien…

Du coup ou est fait la correspondance entre le UUID et le /dev/dm-0… et savez vous si il y a possibilité de le renommer / d’enlever ce mapping?

Merci d’avance et bonne journée :slight_smile:

#2

Tu veux dire montés sur leurs points de montages respectifs.

/dev/dm-* sont les vrais noms (noms “canoniques”) de périphérique des volumes logiques créés par le device-mapper. On peut les voir par exemple avec

dmsetup ls -o blkdevname ls -l /dev/dm-* cat /proc/partitions

On peut voir avec ls -l ou readlink que /dev/mapper/VG-LV et /dev/VG/LV sont des liens symboliques qui pointent vers /dev/dm-*.

La différence entre les systèmes de fichiers / et /usr et les autres, c’est qu’ils sont montés par l’initramfs (racine initiale dont le rôle est de monter la racine) alors que les autres sont montés par l’init du système final (sysvinit ou systemd).

Le script /init de l’initramfs appelle la fonction resolve_device() de /usr/share/initramfs-tools/scripts/functions qui

  • transforme la valeur de la variable root de la ligne de commande du noyau lorsqu’elle est de la forme UUID=“uuid” ou LABEL=“label” en nom de périphérique /dev/disk/by-uuid/“uuid” ou /dev/disk/by-label/“label”
  • “canonicalise” le nom de périphérique avec readlink -f lorsque c’est un lien symbolique, ce qui transforme par exemple /dev/disk/by-uuid/“uuid” en /dev/sdXN ou/dev/mapper/VG/LV en /dev/dm-N

et utilise la commande mount incluse dans busybox ou klibc-utils. Celle-ci passe le nom de périphérique, ici /dev/dm-N, tel quel à l’appel système de montage du noyau.

L’avantage de “canonicaliser” est de remplacer les noms de périphériques dérivés de l’UUID, assez peu lisibles et très longs, par leur nom canonique du style /dev/sda1.
L’inconvénient est que cela remplace les noms de périphériques explicites du device-mapper par leur nom canonique du style /dev/dm0.

De son côté, l’init du système final utilise la commande mount normale du paquet source util-linux. Celle-ci

  • lit directement la désignation de périphérique figurant dans /etc/fstab et convertit lui-même les formes UUID=, LABEL=, PARTUUID=, PARTLABEL=
  • “canonicalise” le nom de périphérique
  • lorsqu’il s’agit d’un volume créé par le device-mapper comme un volume logique LVM, remplace le nom canonique par la forme /dev/mapper/“nom”
  • passe le nom de périphérique résultant à l’appel système de montage du noyau
#3

Merci pour cette réponse claire :slight_smile:

Je comprends mieux du coup la volonté de canoniser les fs / et /usr par contre ce qui me parait incohérent c’est de laisser la possibilité de créer des LV nommés par l’utilisateur sur ces FS si c’est pour ne pas en tenir contre par la suite…

Savez vous du coup si il y a des moyens de les renommer / s’affranchir de ce mapping? Je conçois que cette volonté de nommage de ma part peut paraitre superflue mais il s’agit d’environnement d’entreprise ou tous nos Unix / Linux doivent avoir le même partitionnement pour des questions de lisibilité / facilité d’administration :slight_smile:

Merci d’avance bonne journée :slight_smile:

#4

Je ne comprends pas cette remarque. Le système tient compte des noms des LV puisque c’est ainsi qu’ils sont définis dans /etc/fstab. C’est juste dans la sortie de df ou mount qu’ils n’apparaissent pas. A part l’aspect visuel, je ne vois pas où est le problème.

Tu veux dire que l’initramfs monte / et /usr sans les canonicaliser s’il s’agit de volumes du device-mapper ?
Il faut forcer l’inclusion de la commande mount standard (d’util-linux) dans l’initramfs, ou modifier le code des scripts de l’initramfs pour ne pas convertir les noms de périphériques commençant par “/dev/mapper”.

Voir comment réaliser ces actions dans la documentation du paquet initramfs-tools.

#5

C’est justement bien ca mon soucis, le but en tant qu’admin sys est de fournir des environnements “parlants” et exploitables aux personnes chargés de l’exploitation. Sur ce sujet en particulier, nous avons principalement un environnement Redhat / Centos et nous integrons en ce moment du Debian, il faut donc que la sortie d’un df -h soit la même que sur nos autres environnements. D’où ma volonté de renommer ces FS / LV. :slight_smile:

Je vais regarder du coté des initramfs.

#6

J’ose espérer que les personnes chargées de l’exploitation d’un serveur ne sont pas des incapables et peuvent comprendre qu’un même périphérique peut être désigné par plusieurs noms/chemins et que le nom utilisé ou affiché peut varier en fonction des commandes. L’important est de pouvoir facilement retrouver la correspondance entre ces noms.

#7

On est bien d’accord dessus mais quoi qu’il en soit, si on peut uniformiser au maximum, pourquoi s’en priver? :slight_smile:

#8

Parce que ça restera de la bidouille causant une déviation par rapport à un système Debian standard, et qu’on ne sait pas trop ce qui pourra se passer en cas de mise à jour ultérieure du paquet initramfs-tools.
Bref, bien peser les avantages et inconvénients avant de faire ça sur des serveurs de production.

#9

Pour l’instant ce ne sont pas des serveurs de production, j’en suis justement au stade de création d’un template pour VMWare.

Celui ci sera bien sur testé et re testé avant de déployer des serveurs à partir de celui ci :slight_smile:

Je suis en train de chercher des infos sur l’initramfs.

#10

Regarde la page de manuel initramfs-tools (8).
Pour l’inclusion de /bin/mount : créer un hook script contenant une commande copy_exec. Attention : cela risque de faire grossir l’initramfs à cause de l’inclusion des dépendances.

Pour la modification de la canonicalisation, voir directement dans le script /usr/share/initramfs-tools/scripts/local qui appelle la fonction resolve_device() ou /usr/share/initramfs-tools/scripts/functions qui la contient.