- Création site Internet
- > Articles Techniques
- > Ubuntu, Debian, Linux
- > Gestion des disques sous Linux – mémo de commandes shell (Ubuntu & (...)
Gestion des disques sous Linux – mémo de commandes shell (Ubuntu & Debian)
mardi 27 décembre 2022, par
Une compilation de commandes shell Linux que j’utilise régulièrement pour la gestion de disques et partitions (Ubuntu/Debian).
Elle ne se veut ni exhaustive, ni pédagogique, mais sert de mémo technique basé sur mon expérience de terrain en développement et administration de systèmes Linux.
Cette pratique s’inscrit dans un usage quotidien de Linux depuis Debian Slink, pour le développement et la mise en production de projets web Laravel et de travaux en intelligence artificielle.
Elles sont regroupées par thématique :
Identifier disques et partitions disponibles sur l’ordinateur
Partitions chiffrées avec LUKS
Réparer une clé usb FAT32 en lecture seule sous Linux
Vérifier l’état SMART d’un disque
Monter / démonter une partition
Quand la table de partitions ne veut rien savoir
Analyse du journal ext4 avec debugfs
Récupération d’inodes supprimés
Analyse des performances disque
Recherche de malware au niveau boot (MBR / GPT)
Réinitialisation du code d’amorçage (MBR)
Monter un système de fichiers distant via SSH
Identifier disques et partitions disponibles sur l’ordinateur
Avant toute opération sur un disque ou une partition, il est utile de connaître leur disposition exacte et leurs caractéristiques.
Liste des disque physiques :
sudo lshw -class disk Informations détaillées sur les partitions :
sudo fdisk -l Liste des partitions, types et points de montage :
sudo blkid -o list -c /dev/nullou, plus lisible dans la plupart des cas :
lsblk -o NAME,SIZE,FSTYPE,TYPE,PTTYPE,LABEL,PARTLABEL,MOUNTPOINT,UUIDCes commandes permettent d’identifier précisément :
- les disques physiques
- les partitions
- leur type de système de fichiers
- leur point de montage
- leur UUID
Ces informations sont nécessaires pour cibler correctement un disque ou une partition dans les opérations suivantes.
Dans la suite, j’utiliserai les notations suivantes :
- /dev/sdX pour un disque
- /dev/sdXN pour une partition
où X est la lettre du disque et N le numéro de partition.
Exemple : /dev/sda1
Réparer un disque défectueux
Il existe de nombreuses approches face à un disque défectueux. Voici celles que j’utilise ponctuellement.
Trouver des secteurs défectueux sur un disque.
⚠️ Cette opération est très longue : la commande parcourt l’ensemble des secteurs du disque et écrit la liste des secteurs défectueux dans un fichier badsectors.txt.
sudo badblocks -v /dev/sdXN > badsectors.txt Marquer les secteurs erronés d’un disque afin qu’ils ne soient plus utilisés
Les secteurs défectueux sont alors exclus, ce qui limite les risques de corruption ou de perte de données.
NB : la partition doit être démontée au préalable via la commande :sudo umount /dev/sdXN
Le fichier badsectors.txt est le fichier généré par la commande badblocks.
sudo e2fsck -l badsectors.txt /dev/sdXNfsck est l’utilitaire de vérification des systèmes de fichiers sous Linux. e2fsck en est la version dédiée aux systèmes de fichiers de type ext2/ext3/ext4.
- Récupérer les informations du dernier contrôle fsck
sudo tune2fs -l /dev/sdXNPour extraire uniquement les informations liées à la fréquence d’analyse des disques et à l’historique des contrôles :
sudo tune2fs -l /dev/sdXN | grep -E "Last\ c|Max|Mount"Automatiser les contrôles
fsck peut être lancé manuellement, mais il est également possible de planifier des contrôles automatiques après un certain nombre de redémarrages.
La commande suivante force un contrôle fsck de la partition /dev/sdXN tous les 10 redémarrages :
sudo tune2fs -c 10 /dev/sdXN Une valeur de -1 désactive fsck et ses contrôles automatiques.
Une valeur de 1 force un contrôle à chaque démarrage.
Si la partition est montée via le fichier /etc/fstab, il convient également de vérifier la ligne correspondante à la partition. Un dernier champ positionné à 0 désactive le contrôle au démarrage.
Fdisk pour disques GPT
Les disques modernes utilisent souvent une table de partitions GPT, incompatible avec fdisk : on utilise alors gdisk pour manipuler correctement les partitions.
Installation de l’outil :
sudo apt-get update
sudo apt-get install gdiskFormatage d’un disque vierge
Création de la partition :
— Lancer l’outil de gestion des partitions :
sudo parted /dev/sdXDans parted, exécuter les commandes suivantes.
— Création de la table de partition GPT :
mklabel gpt— Création d’une partition primaire ext4 occupant l’ensemble du disque :
mkpart primary ext4 2048s 100%— Vérifier la table de partitions :
print— Quitter parted :
quit Création du système de fichier ext4 :
sudo mkfs.ext4 /dev/sdXN Attribution d’un label à la partition :
sudo e2label /dev/sdXN <nom>Partitions chiffrées avec LUKS
Lorsqu’un disque ou une partition est chiffré (par exemple pour des données sensibles), il n’apparaît pas comme un FS classique et nécessite une étape d’identification distincte.
Certaines partitions peuvent être chiffrées avec LUKS afin de protéger les données.
Voici comment identifier les volumes chiffrés actuellement présents sur le système :
sudo dmsetup ls --target cryptRéparer une clé usb FAT32 en lecture seule sous linux
Une clé USB montée en lecture seule empêche toute modification ou suppression de fichiers. Ce comportement est fréquent sur des supports FAT32 présentant des erreurs.
Ce cas se rencontre souvent lorsque le système de fichiers FAT32 devient incohérent après une suppression ou un retrait non propre de la clé USB.
Vérifier le type de système de fichiers et identifier la partition
Lister les périphériques FAT32 afin d’identifier la partition concernée :
lsblk -f |grep FAT32Ou, si l’identifiant est déjà connu :
lsblk -f /dev/sdXN Démonter la clé USB
La partition doit être démontée avant toute tentative de réparation :
sudo umount /dev/sdXN Lancer la réparation du système de fichiers FAT32
sudo dosfsck -w -r -l -a -v -t /dev/sdXNavec les paramètres suivants :
- -w : écrit les corrections sur le disque
- -r : interaction lors de la réparation
- -l : liste les fichiers présentant des erreurs
- -a : corrige automatiquement les erreurs
- -v : mode verbeux
- -t : marque les clusters défectueux dans la FAT
Une fois la réparation terminée, débrancher puis rebrancher physiquement la clé USB.
Voir l’espace disque utilisé
Espace utilisé / disponible par système de fichiers :
df -h Espace occupé par répertoire (taille) :
du -sh /chemin Afficher les points de montage :
findmntVérifier l’état SMART d’un disque
La plupart des disques supportent SMART : on peut obtenir les données d’état :
sudo smartctl -a /dev/sdX(Il faut installer : smartmontools)
Monter / démonter une partition
Monter une partition :
sudo mount /dev/sdXN /point/de/montage Démonter :
sudo umount /dev/sdXNDiagnostics bas niveau (quand ça commence à sentir mauvais)
Lire l’ensemble d’un disque sans le monter (détection de lenteurs ou d’erreurs E/S) :
sudo dd if=/dev/sdX of=/dev/null bs=1M status=progress Rechercher les erreurs disque côté noyau :
dmesg | grep -i -E "error|fail|ata|i/o"Inspection ext* sans montage
Afficher les métadonnées complètes d’un système de fichiers ext* :
sudo dumpe2fs /dev/sdXN | less Lister les superblocks disponibles :
sudo dumpe2fs /dev/sdXN | grep -i superblock Réparer un système de fichiers à partir d’un superblock alternatif :
sudo e2fsck -b 32768 /dev/sdXNLes systèmes de fichiers ext* disposent de superblocks alternatifs utilisables en cas de corruption.
FAT32 récalcitrant (cas désespérés)
Réparation automatique non interactive :
sudo dosfsck -a -w -v /dev/sdXN Réécriture du boot sector FAT :
sudo dosfsck -b /dev/sdXNQuand la table de partitions ne veut rien savoir
Forcer la relecture de la table de partitions :
sudo partprobe /dev/sdXsudo blockdev --rereadpt /dev/sdXRécupération de données (old school)
Attention la commande dd ne vérifie rien et n’avertit pas. Une erreur de périphérique (if= / of=) entraîne une perte de données immédiate et irréversible.
Copier un disque en ignorant les erreurs :
sudo dd if=/dev/sdX of=/dev/sdY conv=noerror,sync status=progress Variante plus robuste avec journal de récupération :
sudo ddrescue /dev/sdX /dev/sdY rescue.logForensic
Cloner un disque vers une image brute :
sudo dd if=/dev/sdX of=image.raw bs=4M status=progress Examiner une image disque sans la monter :
sudo file image.raw Associer une image disque à un périphérique loop :
sudo losetup -fP image.rawNote : un périphérique loop permet de traiter un fichier image comme un périphérique bloc.
Lister les périphériques loop actifs :
losetup -a Examiner les partitions détectées dans l’image :
lsblk /dev/loopX Lire un secteur précis (ex. MBR / GPT header) :
sudo dd if=/dev/sdX bs=512 count=1 | hexdump -C Lire un secteur à un offset donné :
sudo dd if=/dev/sdX bs=512 skip=2048 count=1 | hexdump -C Monter une partition d’image disque via offset :
sudo mount -o loop,ro,offset=1048576 image.raw /mnt/forensic(offset = début de partition en octets)
Monter en lecture seule (forensic safe) :
sudo mount -o ro,noload /dev/loopXpY /mnt/forensic Identifier le type de données présentes :
file image.raw Extraire les chaînes lisibles (recherche d’artefacts) :
strings image.raw | less Recherche ciblée (ex. mots-clés) :
strings image.raw | grep -i "password" Analyse et récupération de tables de partitions :
sudo testdisk image.raw Extraction de fichiers sans table de partitions :
sudo photorec image.rawAnalyse du header GPT (primaire / secondaire)
Cette analyse est utile lorsque la table de partitions GPT est corrompue ou incohérente, mais que le disque contient encore des données exploitables. L’objectif est de vérifier l’état du header GPT principal et de son backup, et de déterminer lequel peut servir de référence pour une restauration.
Lire le header GPT primaire (LBA 1) :
sudo dd if=/dev/sdX bs=512 skip=1 count=1 | hexdump -C Lire le header GPT secondaire (dernier secteur du disque) :
sudo dd if=/dev/sdX bs=512 skip=$(($(blockdev --getsz /dev/sdX)-1)) count=1 | hexdump -C Sauvegarder et comparer les deux headers :
sudo dd if=/dev/sdX bs=512 skip=1 count=1 of=gpt_primary.bin
sudo dd if=/dev/sdX bs=512 skip=$(($(blockdev --getsz /dev/sdX)-1)) count=1 of=gpt_backup.bin
cmp gpt_primary.bin gpt_backup.bin Inspecter les informations GPT lisibles :
sudo sgdisk -i 1 /dev/sdX Vérifier la cohérence globale de la table GPT :
sudo sgdisk -v /dev/sdXCarving manuel (extraction sans table de partitions ni système de fichiers)
Le carving manuel intervient lorsque la table de partitions et le système de fichiers sont irrécupérables. L’objectif est d’extraire directement des fichiers ou des données brutes à partir de signatures connues, sans s’appuyer sur aucune métadonnée.
Identifier le type général de données présentes dans une image disque :
file image.raw Rechercher des signatures de fichiers connues :
grep -a -b "JFIF" image.raw
grep -a -b "%PDF" image.raw Extraire un fichier à partir d’un offset connu :
dd if=image.raw of=fichier.bin bs=1 skip=OFFSET count=TAILLE Examiner le contenu extrait :
file fichier.bin
hexdump -C fichier.bin | lessAnalyse du journal ext4 avec debugfs
Cette analyse est utile lorsque des fichiers ont disparu récemment ou après un crash, mais que le système de fichiers ext4 est encore montable ou partiellement cohérent. L’objectif est d’examiner les structures internes (journal, inodes, blocs) afin d’identifier des données encore récupérables.
Ouvrir une partition ext4 avec debugfs (sans montage) :
sudo debugfs /dev/sdXNpuis dans debugfs les commandes d’analyse ci-dessous.
Afficher les informations générales du système de fichiers :
stats Examiner l’état du journal :
logdump Lister les inodes récemment modifiés (selon le journal) :
lsdel(Quitter debugfs avec quit)
Récupération d’inodes supprimés (ext4)
Cette méthode s’applique lorsque des fichiers ont été supprimés mais que leurs blocs n’ont pas encore été réutilisés. L’objectif est de restaurer directement les données à partir des inodes supprimés, sans passer par le nom de fichier original.
Un inode est la structure centrale d’un système de fichiers Linux (ext2/ext3/ext4). Il ne contient pas le nom du fichier, mais l’ensemble de ses métadonnées et les pointeurs vers les données.
Un inode contient notamment :
- le type (fichier, répertoire, lien, etc.)
- les permissions
- l’UID et le GID
- la taille
- les horodatages (atime, mtime, ctime, crtime selon le système de fichiers)
- les pointeurs vers les blocs de données :
— directs
— indirects
— double et triple indirects
Le nom du fichier n’est pas stocké dans l’inode, mais dans le répertoire. Un répertoire est une simple table associant un nom à un numéro d’inode : nom → inode
Conséquence :
- supprimer un fichier supprime le lien nom → inode
- l’inode peut encore exister
- les blocs de données peuvent rester intacts
Lister les inodes supprimés :
sudo debugfs /dev/sdXN
lsdel Examiner un inode supprimé :
stat <inode> Extraire le contenu d’un inode vers un fichier :
dump <inode> fichier_recupere.bin Analyser le fichier extrait :
file fichier_recupere.binAnalyse des performances disque (diagnostic bas niveau)
Cette analyse est utile pour identifier des lenteurs anormales, des timeouts E/S ou des comportements dégradés liés au matériel. L’objectif est de distinguer un problème logiciel d’un problème physique ou firmware.
Mesurer les performances brutes en lecture séquentielle :
sudo hdparm -tT /dev/sdX Tester la latence de lecture sans cache :
sudo dd if=/dev/sdX of=/dev/null bs=4K count=100000 iflag=direct status=progress Surveiller les erreurs E/S et timeouts :
dmesg | grep -i -E "i/o error|timeout|ata"Recherche de malware au niveau boot (MBR / GPT)
Cette vérification est pertinente en cas de comportement anormal persistant, y compris après réinstallation du système. L’objectif est d’identifier une modification du code d’amorçage (bootsector, MBR ou GPT).
Lire le secteur d’amorçage MBR (512 octets) :
sudo dd if=/dev/sdX bs=512 count=1 | hexdump -C Lire le header GPT primaire :
sudo dd if=/dev/sdX bs=512 skip=1 count=1 | hexdump -C Comparer avec un disque sain ou une sauvegarde :
cmp mbr_suspect.bin mbr_sain.bin Rechercher des chaînes suspectes :
strings mbr_suspect.binRéinitialisation du code d’amorçage (MBR)
Le MBR (Master Boot Record) correspond aux 512 premiers octets d’un disque en schéma de partition de type MBR.
Il contient le code d’amorçage primaire ainsi que la table de partitions. Une corruption ou une modification malveillante de ce code peut empêcher le démarrage du système ou persister malgré une réinstallation.
Cette opération consiste à neutraliser le code d’amorçage existant afin de repartir sur une base saine.
Écraser le code MBR (sans toucher aux partitions) :
sudo dd if=/dev/zero of=/dev/sdX bs=440 count=1 Supprimer complètement la table GPT et les métadonnées associées :
sudo sgdisk --zap-all /dev/sdX Réinstaller un chargeur d’amorçage légitime :
grub-install /dev/sdXEn cas de doute de compromission du boot secteur, l’idée est de supprimer le secteur d’amorçage douteux (MBR ou GPT selon le type), puis d’en réinstaller un propre avec grub.
Monter un système de fichiers distant via SSH (SSHFS)
Le montage via SSHFS permet d’accéder à un système de fichiers distant comme s’il était local, en s’appuyant uniquement sur une connexion SSH. C’est particulièrement utile pour l’analyse, la récupération de données ou l’accès ponctuel à des fichiers distants sans exposer de services supplémentaires.
Installer sshfs :
sudo apt-get install sshfs Monter un répertoire distant :
sshfs user@serveur:/chemin/distant /mnt/ssh Démonter proprement :
fusermount -u /mnt/ssh
