Sortie de la commande ( fdisk -l )

Support Debian
#1

bonjour,

en voulant afficher les partitions de mon ssd autonome ( debian testing ) branché sur un portable ( W 10 ) j’ai d’abord utilisé la commande fdisk -l puis j’ai sélectionné le ssd fdisk -l /dev/sdb . Les deux sorties ne sont pas les mêmes : bien plus détaillée pour fdisk -l . Pourquoi ?

**1ère commande**
mi@s125:~$ sudo fdisk -l
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
...... tout ce qui concerne /dev/sda a été volontairement supprimé car inutile .......

Disk /dev/sdb: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: SU30            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 5888C869-74E4-4FBD-8E3F-E149C4E39AF7

Device      Start       End   Sectors   Size Type
/dev/sdb1   65535    262139    196605    96M EFI System
/dev/sdb2  262140 234418694 234156555 111.7G Linux LVM

Disk /dev/mapper/vg-lv--root: 27.94 GiB, 29997662208 bytes, 58589184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes

Disk /dev/mapper/vg-lv--boot: 488 MiB, 511705088 bytes, 999424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes

Disk /dev/mapper/vg-lv--home: 46.56 GiB, 49996103680 bytes, 97648640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes

Disk /dev/mapper/vg-lv--swap: 2.79 GiB, 2998927360 bytes, 5857280 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes


**2ème commande**
mi@s125:~$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: SU30            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: 5888C869-74E4-4FBD-8E3F-E149C4E39AF7

Device      Start       End   Sectors   Size Type
/dev/sdb1   65535    262139    196605    96M EFI System
/dev/sdb2  262140 234418694 234156555 111.7G Linux LVM

je rajoute ceci au cas où ce soit utile

mi@s125:~$ lsblk /dev/sdb
NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sdb               8:16   0 111.8G  0 disk 
├─sdb1            8:17   0    96M  0 part /boot/efi
└─sdb2            8:18   0 111.7G  0 part 
  ├─vg-lv--root 254:0    0  27.9G  0 lvm  /
  ├─vg-lv--boot 254:1    0   488M  0 lvm  
  ├─vg-lv--home 254:2    0  46.6G  0 lvm  /home
  └─vg-lv--swap 254:3    0   2.8G  0 lvm  [SWAP]
#2

Bonjour

Tu as oublié d’utiliser l’option -l dans la deuxième ligne de commande
Pour pouvoir comparer, il aurait fallut faire :

lsblk -l /dev/sdb
#3

non , je ne pense pas car il ne s’agit pas de lsblk qui est la 3ème commande donnée en supplément au cas où elle serait utile . Donc :

mi@s125:~$ sudo fdisk -l
mi@s125:~$ sudo fdisk -l /dev/sdb

note : j’ai rajouté une séparation identifiant le début de chaque commande en question .

#4

Ah oui, j’avais lu le texte et vu le manque de l’option,
mais je n’avais pas bien regardé le nom de la commande lsblk

La différence entre les deux commandes
se voit dans le descriptif de leur manuel :

       fdisk - Manipuler la table de partitions d'un disque

       lsblk - Afficher les périphériques bloc
#5

je suis vraiment le seul à me comprendre tellement je suis brumeux parfois …

donc les deux commandes qui ne donnent pas la même sortie sont :

mi@s125:~$ sudo fdisk -l
mi@s125:~$ sudo fdisk -l /dev/sdb

note : j’ai rajouté une séparation identifiant le début de chaque commande en question .

lsblk n’a été ajouté que comme 3ème commande différente si elle peut apporter un renseignement utile pour répondre à la question **Pourquoi les sorties de fdisk -l et fdisk -l /dev/sdb ne sont pas les mêmes pour /dev/sdb ?

#6

entre les deux lignes de commande suivantes

fdisk -l

et

fdisk -l /dev/sdb

Ce sont les mêmes informations qui seront retournées pour le même disque accessible par le fichier de périphérique /dev/sdb

Je n’ai qu’un seul disque dur,
alors voilà ce que ça donne :

root@deb116:~# fdisk -l
Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : Samsung SSD 870 
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x2c78134c

Périphérique Amorçage     Début        Fin   Secteurs Taille Id Type
/dev/sda1                  2048     206847     204800   100M  6 FAT16
/dev/sda2    *           206848  261089279  260882432 124,4G  7 HPFS/NTFS/exFAT
/dev/sda3             261089280  262303743    1214464   593M 27 TFS WinRE masquée
/dev/sda4             262303744 1953505279 1691201536 806,4G  5 Étendue
/dev/sda5             262305792  300050431   37744640    18G 83 Linux
/dev/sda6             300052480  350392319   50339840    24G 83 Linux
/dev/sda7             350394368  397199359   46804992  22,3G 83 Linux
/dev/sda8             397201408  494497791   97296384  46,4G 83 Linux
/dev/sda9             494499840  544839679   50339840    24G 83 Linux
/dev/sda10            607385600  620285951   12900352   6,2G 82 partition d'échange Linux / Solaris
/dev/sda11            620285954 1953505279 1333219326 635,7G 8e LVM Linux


Disque /dev/mapper/mongroupelvm-vol24G : 24 GiB, 25769803776 octets, 50331648 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/mapper/mongroupelvm-donneesLV : 300 GiB, 322122547200 octets, 629145600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
root@deb116:~# 

root@deb116:~# fdisk -l /dev/sda
Disque /dev/sda : 931,51 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : Samsung SSD 870 
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x2c78134c

Périphérique Amorçage     Début        Fin   Secteurs Taille Id Type
/dev/sda1                  2048     206847     204800   100M  6 FAT16
/dev/sda2    *           206848  261089279  260882432 124,4G  7 HPFS/NTFS/exFAT
/dev/sda3             261089280  262303743    1214464   593M 27 TFS WinRE masquée
/dev/sda4             262303744 1953505279 1691201536 806,4G  5 Étendue
/dev/sda5             262305792  300050431   37744640    18G 83 Linux
/dev/sda6             300052480  350392319   50339840    24G 83 Linux
/dev/sda7             350394368  397199359   46804992  22,3G 83 Linux
/dev/sda8             397201408  494497791   97296384  46,4G 83 Linux
/dev/sda9             494499840  544839679   50339840    24G 83 Linux
/dev/sda10            607385600  620285951   12900352   6,2G 82 partition d'échange Linux / Solaris
/dev/sda11            620285954 1953505279 1333219326 635,7G 8e LVM Linux
root@deb116:~#
#7

les sorties obtenues ne coïncident pourtant qu’en partie : la sortie de fdisk -l est bien plus détaillée que celle de fdisk -l /dev/sdb en ce qui concerne les partitions de ce disque /sdb . D’ailleurs gparted , curieusement , ne voit que sdb1 et sdb2 alors qu’habituellement il donne plus de détails lui aussi .

Peut-être ai-je fait une erreur lors du partitionnement car c’était mon 1er essai d’utilisation de LVM .

ps : je viens de voir que gparted donne bien tous les détails mais il faut double-cliquer sur /dev/sdb2 pour les obtenir dans une fenêtre de type pop-up ( terme français = ? ) .

#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 .