Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

Pages : 1

#1 Le 17/03/2019, à 05:28

qolepam

dd semble ne pas tout effacer

bonjour,

Après avoir inséré une clé usb(/dev/sdb)à réparer donc à effacer complètement,j'effectue en ligne de commande dans le terminal:

dd  if=/dev/zero of=/dev/sdb bs=8192

j'ai pris bs=8192 pour aller + vite

la commande fdisk /dev/sdb,après l'option p,me fournit l'information que le début du secteur commence à 8192 et finit au dernier secteur de la clé:

>fdisk /dev/sdb

Bienvenue dans fdisk (util-linux 2.27.1).
Les modifications resteront en mémoire jusqu'à écriture.
Soyez prudent avant d'utiliser la commande d'écriture.


Commande (m pour l'aide) : p
Disque /dev/sdb : 29,7 GiB, 31914983424 octets, 62333952 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
Type d'étiquette de disque : dos
Identifiant de disque : xxxxxxxxx

Périphérique Amorçage Début      Fin          Secteurs     Taille   Id Type
/dev/sdb1      *                8192       62333951 62325760  29,7G  7 HPFS/NTFS/exFAT


1)Pourquoi le secteur ne commence-t-il pas à 0 puisque normalement j'ai mis des 0 binaires partout avec dd?
2)Que faut-il comme commande linux pour que le secteur de la clé usb ,rempli de 0 binaires,commence à 0(et non à 8192)(c'est-à-dire supprimer le secteur d'amorçage)?


merci de votre aide

Dernière modification par Nuliel (Le 17/03/2019, à 09:28)

Hors ligne

#2 Le 17/03/2019, à 09:27

Nuliel

Re : dd semble ne pas tout effacer

Taille de secteurs physiques = 512 octets . Donc il faut mettre bs=512, pas plus.

Et pense aux balises code pour la lisibilité

Edit: testdisk peut aussi rechercher les partitions qui ont été supprimées, mais un

sudo fdisk -l /dev/sdb

permettra de seulement s'intéresser au MBR

Dernière modification par Nuliel (Le 17/03/2019, à 09:35)

[ poster un retour de commande ] [ poster une photo ]

Hors ligne

#3 Le 17/03/2019, à 10:13

diesel

Re : dd semble ne pas tout effacer

Essaye ça

sudo umount /dev/sdb1 ; sudo mkfs.vfat -I /dev/sdb

après avoir vérifié que ta clé USB est bien sur /dev/sdb.

Amicalement.

Jean-Marie

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

#4 Le 17/03/2019, à 13:58

jamesbad000

Re : dd semble ne pas tout effacer

Bonjour,
Visiblement tout le monde répond à coté du sujet smile

qolepam a écrit :

le début du secteur commence à 8192 et finit au dernier secteur de la clé:

C'est plutôt le début de la partition qui est au secteur 8192...

@qolepam Après le coup de dd que tu as fait, il ne devrait même plus y avoir de table de partition.
Donc soit la commande dd à foiré, soit tu as effacé autre chose suite à une manip de déconnexion /reconnexion qui à entrainée une permutation des nom de devices
Il faut reprendre méthodiquement.
Avec la clef  connectée donne le retour de

sudo lsblk -o size,name,fstype,label,mountpoint
sudo ls -l /dev/disk/by-id

Dernière modification par jamesbad000 (Le 17/03/2019, à 13:59)

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#5 Le 17/03/2019, à 16:42

qolepam

Re : dd semble ne pas tout effacer

mon disque usb défectueux est sdb

sudo lsblk -o size,name,fstype,label,mountpoint

  SIZE NAME           FSTYPE   LABEL   MOUNTPOINT
169,4M loop1          squashfs         /snap/gimp/110
 35,3M loop13         squashfs         /snap/gtk-common-themes/1198
218,1M loop11         squashfs         /snap/gimp/130
 29,7G sdb                             
 29,7G └─sdb1                          
 53,7M loop8          squashfs         /snap/core18/782
 53,7M loop6          squashfs         /snap/core18/731
   91M loop4          squashfs         /snap/core/6405
 1024M sr0                             
169,4M loop2          squashfs         /snap/gimp/113
 53,7M loop14         squashfs         /snap/core18/719
 34,6M loop0          squashfs         /snap/gtk-common-themes/818
 34,8M loop12         squashfs         /snap/gtk-common-themes/1122
195,2M loop9          squashfs         /snap/vlc/555
   91M loop10         squashfs         /snap/core/6350
  1,8T sda                             
473,9G ├─sda4         ext4             /home
 18,6G ├─sda2         ext4             /
  7,5G ├─sda3         swap             
  7,5G │ └─cryptswap1 swap             [SWAP]
  1,3T └─sda1         ntfs     Windows 
202,6M loop7          squashfs         /snap/vlc/768
202,3M loop5          squashfs         /snap/vlc/770
 91,1M loop3          squashfs         /snap/core/6531
sudo ls -l /dev/disk/by-id

total 0
lrwxrwxrwx 1 root root  9 mars  17 16:35 ata-PLDS_DVD-RW_DA8AESH_DX0L08424L1CB7205NTG -> ../../sr0
lrwxrwxrwx 1 root root  9 mars  17 16:35 ata-ST2000LX001-1RG174_WDZ88BSK -> ../../sda
lrwxrwxrwx 1 root root 10 mars  17 16:35 ata-ST2000LX001-1RG174_WDZ88BSK-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 mars  17 16:35 ata-ST2000LX001-1RG174_WDZ88BSK-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 mars  17 16:35 ata-ST2000LX001-1RG174_WDZ88BSK-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 mars  17 16:35 ata-ST2000LX001-1RG174_WDZ88BSK-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 mars  17 16:35 dm-name-cryptswap1 -> ../../dm-0
lrwxrwxrwx 1 root root 10 mars  17 16:35 dm-uuid-CRYPT-PLAIN-cryptswap1 -> ../../dm-0
lrwxrwxrwx 1 root root  9 mars  17 16:38 usb-DV12_DEVICE_V1.00-0:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 mars  17 16:38 usb-DV12_DEVICE_V1.00-0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 mars  17 16:35 wwn-0x5000c500ab2c7499 -> ../../sda
lrwxrwxrwx 1 root root 10 mars  17 16:35 wwn-0x5000c500ab2c7499-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 mars  17 16:35 wwn-0x5000c500ab2c7499-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 mars  17 16:35 wwn-0x5000c500ab2c7499-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 mars  17 16:35 wwn-0x5000c500ab2c7499-part4 -> ../../sda4

Dernière modification par qolepam (Le 17/03/2019, à 16:43)

Hors ligne

#6 Le 17/03/2019, à 17:15

diesel

Re : dd semble ne pas tout effacer

Ben..., je confirme

sudo umount /dev/sdb1 ; sudo mkfs.vfat -I /dev/sdb

Amicalement.

Jean-Marie

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

#7 Le 17/03/2019, à 17:17

jamesbad000

Re : dd semble ne pas tout effacer

qolepam a écrit :
dd  if=/dev/zero of=/dev/sdb bs=8192

En fait si tu as fais exactement ce qui apparait ci-dessus, il manque le sudo au début, et il y a du y avoir un message d'erreur.

donnes le retour de 

sudo dd  if=/dev/zero of=/dev/sdb bs=64K
sudo parted /dev/sdb unit s print
Naziel a écrit :

Taille de secteurs physiques = 512 octets . Donc il faut mettre bs=512, pas plus.

Au passage, je précise : que non.
4K est une bonne valeur par défaut qui améliore systématiquement les perf sur du matériel qui à moins de 20 ans. 64K est souvent un peu mieux.
Préciser un bs à 512 (voir moins) est utile seulement si on veux cibler une zone précise (effacer uniquement le MBR par ex)

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#8 Le 17/03/2019, à 22:39

qolepam

Re : dd semble ne pas tout effacer

sudo dd  if=/dev/zero of=/dev/sdb bs=64K

dd: erreur d'écriture dans '/dev/sdb': Aucun espace disponible sur le périphérique
486985+0 enregistrements lus
486984+0 enregistrements écrits
31914983424 bytes (32 GB, 30 GiB) copied, 5238,06 s, 6,1 MB/s
 sudo parted /dev/sdb unit s print 

Modèle: DV12  DEVICE V1.00 (scsi)
Disque /dev/sdb : 62333952s
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags: 

Numéro  Début  Fin        Taille     Type     Système de fichiers  Fanions
 1      8192s  62333951s  62325760s  primary                       démarrage

Hors ligne

#9 Le 17/03/2019, à 23:39

jamesbad000

Re : dd semble ne pas tout effacer

Original, l'écriture semble se passer normalement mais reste sans effet. Le plus probable est que la clef est morte.

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#10 Le 17/03/2019, à 23:58

qolepam

Re : dd semble ne pas tout effacer

pas moyen de réparer?

Hors ligne

#11 Le 18/03/2019, à 00:13

jamesbad000

Re : dd semble ne pas tout effacer

J'en doute. En tout cas je ne sais pas faire.

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#12 Le 18/03/2019, à 00:24

qolepam

Re : dd semble ne pas tout effacer

je suppose que l'indication que la clé est morte provient de:

dd: erreur d'écriture dans '/dev/sdb': Aucun espace disponible sur le périphérique

Est-ce cela?

Hors ligne

#13 Le 18/03/2019, à 00:38

jamesbad000

Re : dd semble ne pas tout effacer

Non, ça c'est normal car on n'a pas donné de limite à l'écriture. Donc linux rejette l'écriture lorsque dd essaie d'écrire au delà de la capacité de la clef.
La déduction viens simplement du constat que dd nous dis qu'il a écrit (donc a fonctionné normalement)

486984+0 enregistrements écrits

Et qu'en dépit de cela, la table de partition n'a pas été écrasée.
C'est assez inhabituel il est vrai. En général avec une clef hs on a un message d'erreur dès le départ, et l'opération s'arrête tout de suite indiquant que rien n'a été écrit.

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#14 Le 18/03/2019, à 00:44

qolepam

Re : dd semble ne pas tout effacer

où voit-on que la table de partition n'a pas été écrasée?

Hors ligne

#15 Le 18/03/2019, à 00:46

jamesbad000

Re : dd semble ne pas tout effacer

dans le résultat de parted 

Table de partitions : msdos

Et en plus il reste une partition définie 

Numéro  Début  Fin        Taille     Type     Système de fichiers  Fanions
 1      8192s  62333951s  62325760s  primary                       démarrage

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#16 Le 18/03/2019, à 00:50

qolepam

Re : dd semble ne pas tout effacer

la logique de dd ferait que la commande

sudo dd if=/dev/zero of=/dev/sdb bs=N    avec N nombre quelconque

écraserait toute partition en fait
Est-ce cela?

Hors ligne

#17 Le 18/03/2019, à 01:09

jamesbad000

Re : dd semble ne pas tout effacer

Plus précisément écraserait la totalité du périphérique de bloc indiqué (sdb représente un disque pas une partition. sdb1 représente l'unique partition définie sur sdb)
Et si à la place d'un périphérique de bloc on indique un fichier régulier (/home/Nomutilisateur/test) Il créera un fichier remplie de zéro qui grossira jusqu'à ce que le système de fichier soit plein.

Dernière modification par jamesbad000 (Le 18/03/2019, à 01:10)

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#18 Le 18/03/2019, à 01:15

jamesbad000

Re : dd semble ne pas tout effacer

un petit tuto qui peut aider à comprendre la différence entre disque, partitions, système de fichier https://doc.ubuntu-fr.org/partitions

L'espace et le temps sont les modes par lesquels nous pensons, et non les conditions dans lesquelles nous vivons. (Signé Albert)

Hors ligne

#19 Le 18/03/2019, à 12:55

qolepam

Re : dd semble ne pas tout effacer

merci bien!

Hors ligne

Pages : 1