Sortie de la commande ( fdisk -l )

Support Debian
#8

La commande fdisk affiche les informations trouvées dans la table de partitionnement du ou des disques,

C’est le système d’exploitation qui va ensuite décider, en fonction des programmes installés,
et en fonction de ce pourquoi elles auraient été formatées, de ce qui sera fait du contenu de ces partitions.

Sur ton disque, la partition accessible par le fichier de périphérique /dev/sdb2
a été formatée de façon à pouvoir être utilisée par LVM (gestionnaire de volumes logiques)
mais c’est la seule information que l’on puisse trouver dans la table de partitionnement du disque /dev/sdb concernant cette partition.

Les « disques » accessibles par les fichiers de périphériques

/dev/mapper/vg-lv--boot
/dev/mapper/vg-lv--home
/dev/mapper/vg-lv--swap

sont ensuite virtuellements créés par LVM en utilisant le contenu de la partition /dev/sdb2

Ce que le programme LVM fait du contenu de la partition /dev/sdb2
n’est pas indiqué dans la table de partitionnement du disque /dev/sdb

Si tu prends ce disque et que tu le connectes sur une machine sur laquelle le paquetage lvm2 n’a pas été installé alors les disques virtuels LVM ne pourront pas être créés, visibles et accessibles

#9

alors là un grand merci car tu as anticipé ma prochaine question qui était : pourquoi ce ssd est invisible si je le branche sur mon portable habituel tout en fonctionnant très bien sur le portable où il était branché lors de l’installation debian11 → testing . Enfin si j’ai bien saisi le sens de ta phrase . Et donc je vais installer le paquetage lvm2 sur mon LDLC habituel .

vérification

mm@Xfce:~$ apt policy lvm2
lvm2:
  Installé : (aucun)
  Candidat : 2.03.11-2.1
 Table de version :
     2.03.11-2.1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages

ouf ! je pensais avoir flingué en partie mon ssd !!

#10

Voilà :slight_smile:
Et donc, une fois le paquetage lvm2 installé sur cet autre machine,
ces disques virtuels sont vus par LVM et leur contenu est accessible.

#11

voilà qui est fait ; je testerai plus tard . Du coup lorsque je vais le passer en debian 12 je vais garder mon partionnement type LVM et non pas tout formater comme je le prévoyais de prime abord car je pensais l’avoir raté . Caramba !

merci pour toutes ces explications .

** ces disques virtuels : je n’avais pas vraiment porté attention à l’importance de l’adjectif

#12

D’ailleurs, puisqu’il s’agit de LVM (Logical Volume Manager)
j’aurais peut-être plutôt dû dire : disques logiques (par opposition à physiques)

#13

Non, c’était parfaitement clair la première fois.

Elles sont strictement identiques en ce qui concerne /dev/sdb. La différence, c’est que la première affiche les informations et la table de partition de tous les périphériques blocs alors que la seconde n’affiche que celles de /dev/sdb. Le fait que les volumes logiques affichés à la suite soient stockés sur /dev/sdb n’est qu’une coïncidence dont fdisk n’a pas connaissance et qui ne le concerne pas. C’est un éditeur de table de partition, il ne s’intéresse donc qu’au contenu des tables de partition et pas à l’imbrication des périphériques blocs les uns dans les autres contrairement à lsblk.

Ce ne sont pas des disques virtuels. Ils sont aussi réels qu’une partition.

Non plus. Ce sont des volumes logiques.

#14

effectivement et le découpage visuel que je faisais était trompeur . En reprenant le manuel je pense avoir compris le pourquoi de cet affichage différent :

  • commande n°1 = pas de disque spécifié et dans le manuel je suis donc à ce niveau :
Si aucun périphérique n'est fourni, ceux mentionnés dans /proc/par‐
              titions (si ce fichier existe) sont utilisés.

Or la liste qui se trouve dans ce fichier correspond exactement , à un élément près ( cf ps ) , à la sortie de la commande fdisk -l l’ordre de présentation compris . Les liens vg-lv— étant remplacés dans cette liste par leurs cibles dm-x

  • commande n°2 = disque spécifié et alors
Afficher les tables de partitions des périphériques indiqués  puis  quit‐
              ter

et c’est bien ce qui apparaît en sortie .

J’espère que ça se tient .

Merci pour les réponses qui m’ont permis de mettre les différentes briques aux bons endroits . Enfin je pense .

ps de rectification :

  • dans la liste ci-dessus il y a juste un sr0 qui n’apparaît pas en sortie de la commande fdisk -l .
  • " sr0, scd0 etc are assigned by the kernel, to devices that are recognised as CD/DVD drives." selon duckduckgo
#15

Oui, /dev/sr0 est un lecteur de CD/DVD/blu-ray.

#16

j’avais laissé cette explication de côté car je ne comprenais pas son lien avec mon faux-problème du moment . Pas sûr mais je pense mieux voir ce que ça signifie :

mais c’est la seule information que l’on puisse trouver dans la table de partitionnement du disque /dev/sdb concernant cette partition.

donne une indication sur la réponse à fdisk -l /dev/sdb

sont ensuite virtuellements créés par LVM en utilisant le contenu de la partition /dev/sdb2

il s’agit d’une autre phase qui a lieu lors de l’utilisation du ssd formaté avec LVM mais qui n’est pas reliée au retour de commande fdisk -l . Cela signifie-t-il que ces disques , ou volumes ? , sont « volatils » =ils disparaissent à l’arrêt du ssd et sont recréés à chaque mise en route de ce disque ?

De plus il m’a fallu rechercher ce qu’étaient ces fameux /dev/mapper en question et trouver une réponse claire qui me donne au moins une vague petite , petite mais claire , idée sur ce qu’ils sont :

The Device Mapper is a kernel driver that provides a framework for volume management. It provides a generic way of creating mapped devices, which may be used as logical volumes.

Et donc si j’avais fait les choses normalement , i.e éplucher man fdisk -l jusqu’à comprendre en particulier ce que représentaient les dm-x du fichier partitions je n’aurais pas eu à poser la question sur le forum et je me serais privé de toutes ces explications et j’en serais probablement encore à me demander pourquoi je ne pouvais pas lire mon ssd avec mon portable habituel , ce qui est maintenant possible .

Donc : merci pour tous ces éclaircissements .

#17

Bonjour

Oui, dans les extraits ci-dessous, ce que la commande fdisk a affiché comme étant des « Disk » ou « Disque » sont en fait des liens symboliques vers des fichiers de périphérique qui permettent d’accéder à des Volumes logiques LVM

#18

bonjour ,

Après m’être rendu compte que vg-lv—home était en fait un lien , j’avais identifié sa cible grâce à :

mi@s125:/dev/mapper$ readlink vg-lv--home 
../dm-2

ce qui donnait du sens aux dm-x dans /proc/partitions . Mais je n’avais pas rapproché ce dm dans dm-2 de device mapper . Et donc il est bien de même nature qu’un périphérique « en dur » tel que sr0 par exemple . Donc si je comprends bien , un périphérique n’est pas obligatoirement un objet matériel qui se connecte avec des fils .

#19

En effet. Un « périphérique » de type bloc ou caractère est une abstraction du système d’exploitation qui peut représenter un objet physique comme un disque, un lecteur de CD ou de carte SD, un clavier, une souris, un écran, un port série, une imprimante… mais aussi un objet logique comme une partition, un ensemble RAID, un volume logique LVM, un volume chiffré, une console virtuelle (tty)…

Au sujet des volumes logiques LVM :

Oui et non. Ils sont créés suite à l’apparition du PV (volume physique) qui les contient (la partition de type LVM) mais ne sont pas supprimés automatiquement lorsque le PV disparaît suite à l’arrêt ou la déconnexion du disque. A première vue on pourrait croire le contraire car lsblk et lvs ne les affichent plus (probablement parce que le PV sous-jacent n’existe plus), mais les périphériques dm-* correspondants sont toujours présents dans /dev et /proc/partitions, les liens symboliques /dev/mapper/vg-lv et /dev/vg/lv sont toujours présents aussi, et on les voit bien avec dmsetup ls ou lsblk -s. Il faut donc les désactiver (avec vgchange ou lvchange) avant de déconnecter ou arrêter le périphérique sous-jacent.

J’apprécie et utilise souvent LVM pour mes installations, mais j’éviterais de l’utiliser sur un support amovible, à moins de faire en sorte que le support ne soit jamais arrêté ou déconnecté pendant qu’un OS est actif.

C’est clair ou c’est vague ?
Le device-mapper a été développé initialement pour LVM, mais il a ensuite été étendu à d’autres usages, comme le chiffrement de disque (dm-crypt). Il est même utilisé par kpartx pour créer les périphériques correspondant aux partitions d’un autre périphérique. Dans son utilisation basique, le principe est similaire à la gestion des fichiers éventuellement fragmentés : chaque périphérique dm-* est construit à partir d’un ou plusieurs blocs de tailles diverses situés sur un ou plusieurs périphériques de toute nature (disque, partition, ensemble RAID, autre périphérique créé par le device-mapper…) et apparaît comme la concaténation de tous ces blocs.

LVM est une surcouche qui gère les méta-données contenues dans les volumes physiques décrivant les différents volumes logiques.

Un volume logique LVM est accessible par trois chemins :

  • /dev/dm-* est le nom canonique du périphérique créé par le device-mapper. Inconvénient, son nom est variable car les numéros sont attribués dans l’ordre de création qui n’est pas forcément constant. Et puis ce n’est pas très parlant.
  • /dev/mapper/vg-lv est généralement un lien symbolique créé par le device-mapper pour tout périphérique qu’il crée et pointant vers le nom canonique. Les « - » dans les noms de VG et LV sont doublés pour ne pas les confondre avec le « - » qui sépare le VG et le LV. C’est cette forme qui est inscrite dans /etc/fstab lorsqu’on fait une installation avec LVM, et aussi passée par GRUB à la ligne de commande du noyau pour identifier la racine car c’est cette forme qui permet à l’initramfs de savoir qu’il s’agit d’un volume logique ou chiffré et de l’activer.
  • /dev/vg/lv est généralement un lien symbolique créé par LVM pointant aussi vers le nom canonique.

Dans certains systèmes, l’un des deux derniers peut aussi être un fichier spécial de périphérique avec les mêmes numéros majeur et mineur (voir ls -l) que celui du nom canonique.

Un dernier mot concernant la comparaison entre les partitions et les volumes logiques LVM. Conceptuellement, ils ne sont pas fondamentalement différents et servent à gérer le découpage des disques. La structure des partitions est décrite dans une table de partition située sur chaque disque, la structure des volumes logiques est décrite dans les méta-données situées dans chaque volume physique LVM. Une différence majeure est que la création des périphériques représentant les partitions est automatique et gérée entièrement par le noyau alors que la création des périphériques représentant les volumes logiques est gérée en partie en espace utilisateur par LVM, le device-mapper et udev. Mais comme je l’ai écrit plus haut, la création des périphériques de partitions peut aussi être gérée via le device-mapper par kpartx. Cela peut servir dans le cas des partitions sur un périphérique que le noyau ne considère par comme partitionnable, ou d’un format de table de partition exotique inconnu du noyau.

1 J'aime
#20

donc la connexion de ce ssd à mon portable habituel n’est pas une bonne idée , car pour le retirer en toute sécurité comme il est dit , je n’arrête pas le debian du portable et me contente de démonter le volume ou de l’éjecter selon ce qui est disponible . Pour communiquer et échanger je m’en tiendrai donc au protocole ssh ou mieux , à ssh associé à mc commander , car il est alors connecté à un autre portable dont l’OS n’est jamais amorcé . Ça devrait aller , non ?

A priori ce ssd n’a pas subi de dégâts , il m’a tout l’air de très bien fonctionner . Mais promis , je ne recommence pas .

#21

Je me méfie des supports amovibles qui contiennent plusieurs « volumes » au sens large (partitions, systèmes de fichiers) car le gestionnaire de fichiers ne montre que les volumes et pas le support lui-même, et quand on demande à en démonter ou éjecter un on ne sait jamais trop ce qui va se passer : est-ce que cela va démonter seulement ce volume ? ou bien tous les volumes pour pouvoir éjecter le support en sécurité ?

Si tu veux dire que c’est l’OS installé sur le SSD externe qui tourne, oui, ça devrait aller.

#22

j’ai souvent rencontré cette situation sous la forme /dev/sdbx et /dev/sdby . Donc , suite à ta remarque , je pense résoudre le problème de cette façon :

mm@Xfce:/media/mm$ ls
0a7c2a40-ca56-494b-b9ed-f9b14214ea51  3277c06d-5daa-4cbf-ba66-fdd15a82a570
mm@Xfce:/media/mm$ sudo umount 0a7c2a40-ca56-494b-b9ed-f9b14214ea51 3277c06d-5daa-4cbf-ba66-fdd15a82a570 
[sudo] Mot de passe de mm : 
mm@Xfce:/media/mm$ ls
mm@Xfce:/media/mm$

notes :

  • sans sudo ça fonctionne aussi mais j’ai une fenêtre pop-up qui s’ouvre , qui m’agace , et qui me dit :

impossible d’ouvrir le répertoire 0a… ou 32… ( ça varie selon les essais ) , permission non accordée

malgré tout le media est bien démonté : vérification comme ci-dessus = aucun retour de la commande ls . Et encore il faut que le mot de passe de sudo ait été entré , sinon sudo ou pas le pop-up est là . Idem en root .

  • la commande ls n’affiche elle aussi que les volumes , mais aucune information sur le support lui-même , pour autant est-elle insuffisante comme contrôle ?

  • je viens de vérifier par la commande fdisk -l après démontage ( comme ci-dessus ), le support et les volumes apparaissent encore . Il faut que je fasse clic droit → éjecter et là tout disparaît et alors seulement la DEL de contrôle M/A du ssd s’éteint . Donc , malgré tout est-ce que la meilleure manière de procéder n’est pas :

  1. clic doit → démonter chaque volume
  2. clic droit → éjecter et vérifier que la DEL est bien éteinte
  3. ou un panaché : ligne de commande + éjecter
#23

Bonjour

Voilà comment je procède avant de déconnecter un disque dur USB
dans lequel il y a une système LVM.

Dans l’exemple suivant, j’ai utilisé les références de ton système LVM :

/dev/mapper/vg-lv--root
/dev/mapper/vg-lv--boot
/dev/mapper/vg-lv--home
/dev/mapper/vg-lv--swap

Démonter les systèmes de fichiers qui sont dans les volumes logiques
et qui seraient encore montés :

sudo umount -v /dev/mapper/vg*

Au cas où, désactiver aussi le swap
qui est dans le volume logique :

sudo swapoff -v /dev/mapper/vg-lv--swap

Vérifier qu’aucun des systèmes de fichiers
contenus dans le groupe de volume nommé vg
ne soit encore monté :

grep ^/dev/mapper/vg /etc/mtab

si aucun système de fichiers qui serait contenu dans un des volumes logiques
qui serait contenu dans le groupe de volume nommé vg n’est monté,
alors la ligne de commande ci-dessus ne retournera rien .

Désactiver tous les volumes logiques
qui sont contenus dans le groupe de volume nommé vg :

sudo vgchange -van vg

Au cas où, démonter aussi tous les systèmes de fichiers
des partitions du disque dur USB concerné
qui seraient encore montés :

sudo umount -v /dev/sdb[1-9]*

Voilà, en fonction des messages retournés par ces lignes de commandes,
tu peux maintenant déconnecter physiquement le disque dur USB
en toute quiétude.

Quand ce disque USB sera reconnecté à la machine,
les volumes logiques qui avaient été désactivés seront automatiquement activés.

#24

bonjour ,

au fur et à mesure que je reçois des informations sur le système LVM je m’aperçois qu’il n’est pas vraiment simple à utiliser et que sa manipulation est réservée à des personnes qui savent ce qu’elles font .

Le mien de système est sur un ssd que j’ai réservé à différents tests que je ne veux pas effectuer sur mon portable habituel afin de le préserver des conséquences éventuelles d’une erreur de manipulation . Surtout lorsque je débutais avec debian . Je lui ai gardé cette fonction et l’installation d’un debian/LVM faisait partie de ces tests .

Il est évident que je ne suis pas vraiment l’utilisateur type concerné par LVM , plutôt réservé aux gros brasseurs de To il me semble . En tant qu’utilisateur de base avec des exigences en terme de volume ou de « plasticité » du système peu élevées , LVM est une sorte de luxe que je voulais tester et je ne le regrette pas car j’ai appris un tas de trucs rien que dans cette file . A terme je repasserai en partitionnement normal pour la suite = test de mon portable pour une compatibilité avec bookworm en mars , puis avec le futur debian 12 . Je serai plus à l’aise et n’aurai pas à me soucier des exigences particulières dues à LVM . Mais peut-être qu’un jour je lui trouverai une utilité et au moins je l’aurai essayé avant .

En tout cas merci pour ces renseignements qui résument les bonnes pratiques à avoir au cas où je veuille utiliser puis déconnecter mon ssd/LVM de mon portable habituel . Les trouver sur internet n’est pas toujours évident , sans même parler de la pertinence des résultats obtenus ici ou là .

ps : j’ai oublié de préciser que ma réponse à @PascalHambourg concernait la déconnexion d’un disque sans système LVM ( comme le ssd autonome et nomade que j’ai utilisé pour réaliser les tests mentionnés ci-dessus ) .

#25

Ça dépend où on regarde.
/media/$USER ne contient que les points de montage temporaires créés dynamiquement pour les systèmes de fichiers montés pour l’utilisateur $USER par udisks2, généralement à la demande du gestionnaire de fichiers de l’environnement de bureau. Les lecteurs de CD/DVD et autres volumes figurant dans /etc/fstab avec les options user,noauto sont montés sur les points de montage normalement permanents spécifiés dans /etc/fstab.
Pour voir ce qui est monté où et comment, il vaut mieux regarder dans le pseudo-fichier /proc/mounts.
Les supports de stockage sont dans /dev, comme tous les périphériques.

Il faut tester. Il se peut que « éjecter » démonte proprement tous les volume montés du même support de stockage avant de l’arrêter/éjecter. Mais dans le doute, on démonte d’abord.

Non, pas forcément. On peut bénéficier de ses fonctionnalités sans avoir de gros volumes de stockage. Au contraire, il permet une gestion fine de l’espace disque quand ce dernier est limité. Exemple : je veux séparer /home, /tmp, /var, /var/log, /var/cache… bref tout ce qui bouge beaucoup et peut grossir rapidement mais l’espace disque est contraint et je ne sais pas trop combien allouer à chaque partie. Avec des partitions, si j’estime mal les besoins à long terme je risque de me retrouver avec une partition pleine qu’il sera difficile d’agrandir. Avec LVM, je commence avec des tailles minimales en laissant de l’espace libre et je pourrai agrandir les volumes au fur et à mesure des besoins.

Pourquoi un volume logique séparé pour /boot ?

#26

pour info ( ne concerne pas LVM ) :

  • l’éjection avec la souris fait disparaître du répertoire /dev le support /dev/sdb , les différents volumes sdbx et éteint la DEL du ssd ( partitions « normales » , pas de volumes logiques )
  • l’éjection par ligne de commande sudo eject /dev/sdb fait disparaître les volumes /dev/sdbx du répertoire /dev mais laisse /dev/sdb/ et n’éteint pas la DEL . J’ai dû ajouter sudo udisksctl power-off -b /dev/sdb pour cela

et aussi , pris ici pour l’ éjection d’une clef USB :

  • By ejecting the device, you effectively disable any further access to the device. Only a reset of the USB subsystem (e.g. a reboot) will reload the device. Otherwise, you must physically disconnect the USB device and reconnect it in order to access it again.
  • Before ejecting, this command will unmount all volumes on the device that were mounted.
  • If volumes are in use, this command will fail as with unmount, except that some volumes might be unmounted and some volumes might remain mounted.

Donc si ce texte est correct , la fonction éjecter prend tout en charge dans le cas d’une clef USB , et donc pour mon ssd sans volumes logiques . Mais bon , pour plus de sûreté autant démonter les partitions sdbx d’abord .

#27

Je n’en sais rien, c’est juste un des volumes logiques
dont j’ai relevé la présence dans l’extrait ci-dessous du message #1 de zao :