copier une carte SD avec dd ne copie pas exactement
J'essaie de faire une copie de ma carte SD pour pouvoir la déplacer sur ma carte SD de 64 Go. Je l'ai fait avec la carte SD d'un Raspberry Pi, aucun problème là-bas.
La carte SD est composée de deux partitions: BOOT (fat32) et linux (ext4)
J'ai essayé de créer une image de la carte SD entière en utilisant:
Sudo dd of=Images/orangepi.img if=/dev/sdd bs=1M status=progress
Et le remettre sur une carte SD:
Sudo dd if=Images/orangepi.img of=/dev/sdd bs=1M status=progress
Je ne pouvais pas monter l'image car elle était composée de 2 partitions. J'ai donc imagé BOOT et linux séparément à l'aide de:
Sudo dd of=linux.img if=/dev/sdd2 bs=1M status=progress
Sudo dd of=BOOT.img if=/dev/sdd1 bs=1M status=progress
Comme vous pouvez le voir sur la capture d'écran que j'ai ajoutée, l'image créée (à droite) à partir de la carte SD ne correspond pas à celle de la carte SD (à gauche).
Ma question est la suivante: Pourquoi cela se produit-il et comment puis-je créer une image correcte de ma carte SD?.
Le dossier personnel de ma carte SD a un dossier appelé "Musique" contenant des dossiers avec des fichiers mp3.
Mon image a un x-font.ttf avec le nom "Music". Les dossiers semblent se transformer en fichiers aléatoires lors de la création d'une image.
La carte SD est un disque de travail Ubuntu pour mon ordinateur orangepi et fonctionne actuellement.
**Sudo apt install dcfldd
lsblk**
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
└─sda2 8:2 0 465.8G 0 part /media/Shared
sdb 8:16 0 238.5G 0 disk
├─sdb1 8:17 0 500M 0 part
├─sdb2 8:18 0 116.8G 0 part
├─sdb3 8:19 0 117.3G 0 part /
├─sdb4 8:20 0 1K 0 part
└─sdb5 8:21 0 3.9G 0 part [SWAP]
sdc 8:32 1 7.5G 0 disk
├─sdc1 8:33 1 64M 0 part /media/fhfs/BOOT
└─sdc2 8:34 1 7.4G 0 part /media/fhfs/linux
sdg 8:96 0 465.8G 0 disk
└─sdg1 8:97 0 465.8G 0 part /media/fhfs/0c91eeb6-7199-47b6-a603-04432a091fdc
sr0 11:0 1 1024M 0 rom
**ls -lha /dev | grep sd**
brw-rw---- 1 root disk 8, 0 Oct 18 14:54 sda
brw-rw---- 1 root disk 8, 2 Oct 18 14:54 sda2
brw-rw---- 1 root disk 8, 16 Oct 18 14:54 sdb
brw-rw---- 1 root disk 8, 17 Oct 18 14:54 sdb1
brw-rw---- 1 root disk 8, 18 Oct 18 14:54 sdb2
brw-rw---- 1 root disk 8, 19 Oct 18 14:54 sdb3
brw-rw---- 1 root disk 8, 20 Oct 18 14:54 sdb4
brw-rw---- 1 root disk 8, 21 Oct 18 14:54 sdb5
brw-rw---- 1 root disk 8, 32 Oct 20 18:11 sdc
brw-rw---- 1 root disk 8, 33 Oct 20 18:11 sdc1
brw-rw---- 1 root disk 8, 34 Oct 20 18:11 sdc2
brw-rw---- 1 root disk 8, 48 Oct 18 14:54 sdd
brw-rw---- 1 root disk 8, 64 Oct 18 14:54 sde
brw-rw---- 1 root disk 8, 80 Oct 18 14:54 sdf
brw-rw---- 1 root disk 8, 96 Oct 18 14:54 sdg
brw-rw---- 1 root disk 8, 97 Oct 18 14:54 sdg1
**Sudo dcfldd if=/dev/sdc2 of=linuxdcfl.img hash=md5,sha1 hashlog=hashlog.txt**
242944 blocks (7592Mb) written.
243056+1 records in
243056+1 records out
**Sudo dcfldd if=/dev/sdc2 vf=linuxdcfl.img verifylog=verify.log**
0 - 0: Mismatch
Total: Mismatch
J'ai essayé dcfldd et j'ai obtenu une disparité, pas de journal des erreurs difficile. verify.log est vide. hashlog a juste les sommes sha et md5.
dd a une longue histoire de création de bits exacts pour les doubles de bits. diff peut être utilisé pour le prouver assez facilement
Remarque: vous ne mentionnez pas la version d'Ubuntu que vous utilisez. La seule raison qui fait la différence est que l'utilisation du commutateur d'état a changé.
Ubuntu 14.04 Extrait de man dd
status=WHICH
WHICH info to suppress outputting to stderr; 'noxfer' suppresses
transfer stats, 'none' suppresses all
Ubuntu 16.04 extrait de man dd
status=LEVEL
The LEVEL of information to print to stderr; 'none' suppresses everything but error messages, 'noxfer' suppresses
the final transfer statistics, 'progress' shows periodic transfer statistics
Tout cela mis à part, la seule chose à laquelle je peux penser qui ferait en sorte que votre fichier image ait un motif de bits différent de celui de votre source est soit:
Erreur utilisateur:
A) Tentative d'imagerie d'une partition montée (une très mauvaise idée)
B) Echec de sync en laissant des données dans la mémoire tampon du noyau.
ou
Échec matériel:
C) Une zone défaillante sur le disque où vous avez stocké l'image. Cela implique une défaillance imminente du lecteur (j'espère que vous avez des sauvegardes, sinon, hop!)
D) Une connexion douteuse offrant une mauvaise connectivité au périphérique multimédia source ou cible
Il serait sage de vérifiez l’état intelligent du lecteur sur lequel vous avez stocké l’image.
Le fait que dcfldd ait également entraîné une discordance me laisse penser que vous avez un câble défaillant ou un support de stockage défaillant (sur le support d'entrée ou le support de sortie).
Ceci est un commentaire sur la fragilité des puces SD/microSD.
J'ai utilisé le commentaire ci-dessus à propos de badblocks pour tester 2 nouvelles puces microSD de 512 Go. Vu leur taille, je suis allé avec un lecteur de carte USB 3.0 sur un port USB 3.0. Les frites sont devenues chaudes vraiment chaudes. J'ai ensuite fait un repère en utilisant Disks pour confirmer leur vitesse, en utilisant mon test standard de 1000 échantillons (plutôt que le standard 100), toujours sur lecteur USB 3.0/port 3.0. 1 a réussi, l'autre à environ 600 échantillons et la vitesse d'écriture est passée de ~ 90 Mo/s à moins de 20 Mo/s. Cette vitesse d’écriture n’a pas diminué, je pense donc avoir "gravé" ^ la puce en raison de la puissance disponible sur un port USB 3.0.
Puisque badblocks est un processus intensif et complet d’écriture/lecture qui prend beaucoup de temps, je vous suggérerais d’utiliser un lecteur de carte USB 2.0 ou, de préférence, un lecteur de carte USB 3.0. un port USB 2.0, afin de minimiser la possibilité de graver une puce volumineuse (coûteuse). Cela prendra plus de temps, mais alors quoi. Je recommanderais alors d’utiliser le standard 100 échantillons à comparer (lecteur USB 3.0/port USB 3.0). ).
J'ai malheureusement utilisé un certain nombre de puces microSD plus petites de 128 Go pour déterminer la procédure ci-dessus. La plupart d'entre eux sont revenus sous RMA pour avoir échoué à mes tests. Ces puces ne sont tout simplement pas aussi robustes que les clés USB 3.0, c’est donc une mise en garde.
^ Par ailleurs, si vous utilisez un lecteur de carte USB 3.0/un port USB 3.0 et que votre puce prend beaucoup plus de temps qu'une autre, de la même taille, il se peut qu'elle soit déjà "brûlé".
La carte SD peut avoir des blocs défectueux.
'Sudo badblocks -s -w/dev/sd #' sur la carte SD de destination pour exécuter un test de modèle en mode écriture. Faites très attention au fichier/dev/sd #. 'badblocks -w' est DESTRUCTIF! Vous voudrez peut-être vérifier/dev/sd # avec 'ls -l/dev/disk/by-id /' pour vous assurer que vous disposez du bon périphérique de bloc.
Je lance ceci sur tous mes nouveaux périphériques de stockage et tous les mauvais suspects. Un disque dur 1 TB SATA prend environ 24 heures pour effectuer un passage des quatre modèles de -w. Une carte SD sera beaucoup plus rapide. J'ai trouvé de mauvaises clés USB, cartes SD, disques durs et même quelques mauvais lecteurs de cartes micro-SD USB de cette façon.
Si des numéros de bloc défectueux apparaissent, vous pouvez essayer de RMA le périphérique s'il est toujours sous garantie.
Les dates et les tailles de fichier .xsession-errors sont complètement différentes entre les deux listes de fichiers de votre image. "Dd" ne pourra pas le faire sans brouiller tout le système de fichiers au-delà de la simple reconnaissance.
Vous ne devez pas utiliser dd sur des systèmes de fichiers montés. C’est un peu difficile à éviter lorsque la plupart des systèmes montent automatiquement dès que vous branchez une carte SD.
Utilisez 'df' et 'dmesg' pour trouver le/dev/sd_ # de votre carte SD. Avertissement: Il peut y en avoir plusieurs pour cette carte SD si vous avez plusieurs partitions.
Sudo umount /dev/sd_#
pour démonter la carte SD, mais elle sera toujours connectée et non éjectée.
Exécutez à nouveau 'df' pour vérifier qu'il a été démonté.
Vous pouvez maintenant "dd" lire ou écrire sur la carte SD dans son ensemble (première paire de "dd" de l’affiche originale).
Dites au système d’éjecter la carte SD. [Dans Ubuntu 16.04, cliquez avec le bouton droit de la souris sur la carte SD et sélectionnez "Éjecter le lecteur parent". Ils devraient vraiment ajouter les options "mount" et "unmount"] Si vous ne trouvez pas une option d'éjection, exécutez "sync" et attendez que l'invite revienne pour vider les tampons d'écriture avant de retirer la carte SD.
Oui, vous pouvez monter des partitions dans une image en utilisant kpartx
Sudo apt install kpartx
cd Images
Sudo kpartx -a orangepi.img
Il créera des périphériques sous/dev/mapper et les périphériques doivent être détectés par Nautilus pour permettre le montage de leurs partitions respectives.
Pour supprimer le périphérique sous/dev/mapper, après avoir démonté la partition,
cd Images
Sudo kpartx -d orangepi.img
En ce qui concerne la raison pour laquelle la partition diffère dans votre cas, je n’ai aucune idée de ce que vous avez fait pour aboutir à ce résultat. Cela aurait dû être pareil.
J'évite toujours de faire dd sur des partitions individuelles. Sauf pour exactement le même support de stockage, même taille, même numéro de modèle ...
On dirait que vous avez créé une partition plus grande sur la nouvelle carte et dérangé quelque chose avec les inodes.
Vous avez dit que vous ne pouviez pas monter l'image, mais cela fonctionne-t-il comme prévu sur la carte SD de destination? Cela devrait...
Je suppose que vous essayez de passer à une plus grande carte. Ma façon préférée est dd toute la carte. Ensuite, démarrez sur un ordinateur ou branchez-le à un autre ordinateur, chargez Gparted, réduisez la partition d’un couple, puis reprenez sa taille maximale. Il va récupérer le nouvel espace libre et ne prend que 2-3 minutes.