# 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:** 12\
**Page:** 2

<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, 3:27 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/21 "2023-01-08T15:27:57Z")

</div>

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

Je me méfie des supports amovibles qui contiennent plusieurs «&nbsp;volumes&nbsp;» 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é ?

> [@zao](#):
>
> il est alors connecté à un autre portable dont l’OS n’est jamais amorcé . Ça devrait aller , non ?

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

---

<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 9, 2023, 6:36 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/22 "2023-01-09T06:36:27Z")

</div>

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

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 :

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

---

<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 9, 2023, 10:38 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/23 "2023-01-09T10:38:45Z")

</div>

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 :

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

```nohighlight
sudo umount -v /dev/mapper/vg*

```

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

```nohighlight
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é :

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

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

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

---

<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 9, 2023, 11:42 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/24 "2023-01-09T11:42:01Z")

</div>

> [@anon29980398](#):
>
> Voilà comment je procède avant de déconnecter un disque dur USB  
> dans lequel il y a une système LVM.

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 «&nbsp;plasticité&nbsp;» 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 ) .

---

<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 9, 2023, 7:23 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/25 "2023-01-09T19:23:01Z")

</div>

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

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

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

Il faut tester. Il se peut que «&nbsp;éjecter&nbsp;» 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.

> [@zao](#):
>
> LVM , plutôt réservé aux gros brasseurs de To

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.

> [@anon29980398](#):
>
> /dev/mapper/vg-lv–boot

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

---

<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 9, 2023, 9:34 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/26 "2023-01-09T21:34:38Z")

</div>

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

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 «&nbsp;normales&nbsp;» , 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](https://unix.stackexchange.com/questions/35508/eject-usb-drives-eject-command) 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 .

---

<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 9, 2023, 9:34 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/27 "2023-01-09T21:34:52Z")

</div>

> [@PascalHambourg](#):
>
> …
> 
> > [@anon29980398](#):
> >
> > /dev/mapper/vg-lv–boot
> 
> Pourquoi un volume logique séparé pour /boot ?

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](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681) de [**zao**](https://www.debian-fr.org/u/zao) :

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

---

<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 9, 2023, 9:42 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/28 "2023-01-09T21:42:11Z")

</div>

> [@anon29980398](#):
>
> 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](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681) de [**zao**](https://www.debian-fr.org/u/zao)

vient probablement du tuto dont je me suis servi , et que j’ai peut-être mal interprété d’ailleurs , ça c’est dans mes cordes , donc ? en ce qui me concerne . Si c’était à refaire je ne prévoirais pas ce volume car il me semble avoir lu que c’était nécessaire uniquement pour des distributions plus anciennes et qu’actuellement on pouvait s’en passer . Ceci sous toutes réserves bien sûr .

---

<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 9, 2023, 9:52 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/29 "2023-01-09T21:52:57Z")

</div>

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

Les tests que j’avais fait en utilisant l’option contextuelle `Éjecter` (après avoir démonté les systèmes de fichiers des volumes logiques et tous les autres systèmes de fichiers existants sur ce même disque) n’ont pas fonctionné tant que les volumes logiques étaient encore actifs,

 ![Capture d’écran_2023-01-09_22-55-12](https://www.debian-fr.org/uploads/default/original/2X/e/ec73f8cded9a73bf2d2d955a174b065c261f1dbe.png)

c’est pour ça que j’ai proposé d’utiliser la ligne de commande suivante  
pour désactiver les volumes logiques :

```plaintext
sudo vgchange -van vg

```

ce qui a permis ensuite de pouvoir utiliser l’option contextuelle `Éjecter`

---

<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 9, 2023, 10:21 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/30 "2023-01-09T22:21:28Z")

</div>

> [@zao](#):
>
> Si c’était à refaire je ne prévoirais pas ce volume car il me semble avoir lu que c’était nécessaire uniquement pour des distributions plus anciennes

Ce qui était nécessaire, c’était de mettre /boot dans une _partition_ classique hors de LVM quand le chargeur d’amorçage ne supportait pas LVM. Mais ça n’a jamais eu aucun intérêt de séparer /boot de la racine si c’est pour le mettre aussi dans un volume logique.

---

<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 9, 2023, 10:23 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/31 "2023-01-09T22:23:58Z")

</div>

> [@PascalHambourg](#):
>
> Ce qui était nécessaire, c’était de mettre /boot dans une _partition_ classique hors de LVM quand le chargeur d’amorçage ne supportait pas LVM.

oui et j’en sais quelque chose car lors de mon 1er essai j’avais oublié de créer une partition FAT 32 pour grub-efi .

voilà , j’ai retrouvé la citation en question du 22 juillet 2021 par @PascalHambourg :

> La partition système EFI est nécessaire pour l’amorçage UEFI.  
> La partition /boot séparée n’est plus indispensable avec GRUB 2, c’est un reste du temps où les chargeurs d’amorçage (LILO, GRUB 1) ne savaient pas lire LVM.

et depuis j’ai un peu mélangé tout ça .

---

<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 9, 2023, 10:26 UTC](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681/32 "2023-01-09T22:26:42Z")

</div>

C’est encore autre chose, la partition EFI montée sur /boot/efi. Rien à voir avec /boot.

[Page précédente](https://www.debian-fr.org/t/sortie-de-la-commande-fdisk-l/87681.md?page=1)
