# Sortie de la commande ( fdisk -l )

**URL:** <https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681>\
**Category:** Support Debian\
**Created:** [Janvier 6, 2023, 4:19 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681 "2023-01-06T16:19:29Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 6, 2023, 4:19 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/1 "2023-01-06T16:19:29Z")

</div>

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 ?

```nohighlight
**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

```nohighlight
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]

```

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Janvier 6, 2023, 4:33 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/2 "2023-01-06T16:33:13Z")

</div>

Bonjour

> [@zao](#):
>
> ```plaintext
> mi@s125:~$ lsblk /dev/sdb
> …
> 
> ```

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

```plaintext
lsblk -l /dev/sdb

```

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 6, 2023, 4:38 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/3 "2023-01-06T16:38:53Z")

</div>

> [@anon29980398](#):
>
> Tu as oublié d’utiliser l’option **-l** dans la deuxième ligne de commande

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 :

```auto
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 .

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Janvier 6, 2023, 4:48 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/4 "2023-01-06T16:48:13Z")

</div>

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 :

```auto
       fdisk - Manipuler la table de partitions d'un disque

```

```nohighlight
       lsblk - Afficher les périphériques bloc

```

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 6, 2023, 4:54 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/5 "2023-01-06T16:54:07Z")

</div>

> [@anon29980398](#):
>
> La différence entre les deux commandes

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 :

```auto
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**?

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Janvier 6, 2023, 5:03 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/6 "2023-01-06T17:03:41Z")

</div>

> [@zao](#):
>
> …Pourquoi les sorties de **fdisk -l** et **fdisk -l /dev/sdb** ne sont pas les mêmes pour la partie **/dev/sdb**? …

entre les deux lignes de commande suivantes

```plaintext
fdisk -l

```

et

```plaintext
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 :

```plaintext
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:~# 

```

```plaintext
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:~# 

```

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 6, 2023, 5:12 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/7 "2023-01-06T17:12:07Z")

</div>

> [@anon29980398](#):
>
> Ce sont les mêmes informations qui seront retournées pour le disque accessible par le fichier de périphérique `/dev/sdb`

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 = ? ) .

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Janvier 6, 2023, 5:44 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/8 "2023-01-06T17:44:23Z")

</div>

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 «&nbsp;disques&nbsp;» accessibles par les fichiers de périphériques

```nohighlight
/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

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 6, 2023, 5:49 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/9 "2023-01-06T17:49:52Z")

</div>

> [@anon29980398](#):
>
> Si tu prends ce disque et que tu le connectes sur une machine sur laquelle lvm2 n’a pas été installé  
> alors les disques virtuels LVM ne pourront pas être créés, visibles et accessibles

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

```auto
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 !!

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Janvier 6, 2023, 5:53 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/10 "2023-01-06T17:53:52Z")

</div>

Voilà 🙂  
Et donc, une fois le paquetage **lvm2** installé sur cet autre machine,  
ces _disques virtuels_ sont vus par LVM et leur contenu est accessible.

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 6, 2023, 6:04 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/11 "2023-01-06T18:04:57Z")

</div>

> [@anon29980398](#):
>
> ces _disques virtuels_ sont vus par LVM et leur contenu est accessible.

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

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Janvier 6, 2023, 6:22 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/12 "2023-01-06T18:22:59Z")

</div>

D’ailleurs, puisqu’il s’agit de **LVM** ( **L** ogical **V** olume **M** anager)  
j’aurais peut-être plutôt dû dire : disques **logiques** (par opposition à _physiques_)

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Janvier 6, 2023, 8:14 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/13 "2023-01-06T20:14:58Z")

</div>

> [@zao](#):
>
> je suis vraiment le seul à me comprendre tellement je suis brumeux parfois

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

> [@zao](#):
>
> Pourquoi les sorties de **fdisk -l** et **fdisk -l /dev/sdb** ne sont pas les mêmes pour **/dev/sdb**?

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.

> [@anon29980398](#):
>
> ces _disques virtuels_ sont vus par LVM

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

> [@anon29980398](#):
>
> j’aurais peut-être plutôt dû dire : disques **logiques**

Non plus. Ce sont des volumes logiques.

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 6, 2023, 9:19 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/14 "2023-01-06T21:19:45Z")

</div>

> [@PascalHambourg](#):
>
> Elles sont strictement identiques en ce qui concerne /dev/sdb.

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 :

```plaintext
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

```plaintext
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

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Janvier 6, 2023, 10:10 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/15 "2023-01-06T22:10:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 8, 2023, 7:53 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/16 "2023-01-08T07:53:02Z")

</div>

> [@anon29980398](#):
>
> 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
> 
> ```auto
> /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`

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 «&nbsp;volatils&nbsp;» =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 .

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Janvier 8, 2023, 10:27 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/17 "2023-01-08T10:27:58Z")

</div>

Bonjour

> [@zao](#):
>
> … ces disques , ou volumes ? …

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

> [@zao](#):
>
> ```plaintext
> …
> Disk /dev/mapper/vg-lv--boot: 488 MiB, 511705088 bytes, 999424 sectors
> …
> 
> ```

> [@anon29980398](#):
>
> ```plaintext
> …
> Disque /dev/mapper/mongroupelvm-vol24G : 24 GiB, 25769803776 octets, 50331648 secteurs
> …
> 
> ```

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 8, 2023, 11:22 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/18 "2023-01-08T11:22:54Z")

</div>

bonjour ,

> [@anon29980398](#):
>
> sont en fait des liens symboliques vers des fichiers de périphériques qui permettent d’accéder à des **Volumes logiques LVM**

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

```plaintext
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 «&nbsp;en dur&nbsp;» 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 .

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Janvier 8, 2023, 1:19 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/19 "2023-01-08T13:19:12Z")

</div>

> [@zao](#):
>
> Donc si je comprends bien , un périphérique n’est pas obligatoirement un objet matériel qui se connecte avec des fils

En effet. Un «&nbsp;périphérique&nbsp;» 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 :

> [@zao](#):
>
> 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 ?

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.

> [@zao](#):
>
> 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 idée sur ce qu’ils sont

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 «&nbsp;-&nbsp;» dans les noms de VG et LV sont doublés pour ne pas les confondre avec le «&nbsp;-&nbsp;» 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.

---

<div class="post-metadata">

**Author:** ![zao](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/z/ce7236/32.png) [@zao](https://www.debian-fr.org/u/zao)\
**Post date:** [Janvier 8, 2023, 2:11 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/20 "2023-01-08T14:11:02Z")

</div>

> [@PascalHambourg](#):
>
> 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.

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 .

[Page suivante](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681.md?page=2)
