Pourquoi mes clés USB identiques sont-elles différentes d'un octet?

15

J'ai deux clés USB identiques ( TrekStor 16 Go ) préparées comme suit avec l' image c't bankix .

  1. Préparation avec GParted :

    • Supprimé la partition existante
    • Création d'une nouvelle table de partition DOS
    • Formatage du stick avec FAT32, partition principale

  2. Chargement de l'image sur le stick via usb-creator-kde.

J'ai donc fait la même procédure pour les deux bâtons, mais l'un démarre et l'autre plante avec un message d'erreur:

(initramfs) mount: mounting /dev/loop0 on //filesystem.squashfs failed: No such device
Can not mount /dev/loop0 (/cdrom/casper/filesystem.squashfs) on //filesystem.squashfs

Ensuite, j'ai essayé de les comparer via sudo cmp /dev/sdb /dev/sdc. Cela s'est traduit par:

/dev/sdb /dev/sdc differ: byte 441, line 5

Qu'est-ce qui ne va pas ici, et comment puis-je le réparer?

live-usb troubleshooting étudiant
la source
Vous pouvez essayer de copier celui qui fonctionne sur l'autre à l'aide de dd et voir si cela aide. Ou vous pouvez simplement utiliser sfdisk pour copier la table de partition à partir de la bonne, et y aller.
Angelo
Il vous indique immédiatement quel est le problème - filesystem.squashfs n'est pas valide pour une raison quelconque, ou bien vous avez mal configuré le processus de démarrage. C'est un fichier image - compressé - c'est tout votre système de fichiers racine. Mais ... vos initramfs pensent qu'il est situé sur /cdrom. Et il essaie apparemment de se monter sur lui-même? C'est une chose initramfs - je parie que c'est bien. Peut-être que vous avez les deux sticks branchés sur l'ordinateur en même temps? Ou vous avez peut-être des paramètres en double qui auraient dû être uniques lors de la configuration. Éloignez-vous des créateurs de systèmes en direct - ils sont des problèmes.
mikeserv

Réponses:

30

Bien que je ne sais pas pourquoi on plante (mauvais bâton? L' image corrompue?), Le suspect habituel pour les différences dans les systèmes de fichiers « identique » créés, qu'ils soient ISO9660 ou autrement, est l' horodatage , par exemple pour le temps de création. Ou une étiquette de système de fichiers par défaut aléatoire . Si vous voulez des données identiques sur les deux, ddla bonne image sur l'autre bâton et vérifiez leurs sommes de contrôle (md5sum ou autre; tout fera l'affaire).

Oh, et l'hypothèse du titre de votre question ne tient pas. Ce n'est pas seulement un octet qui diffère. cmpvous indique uniquement le premier qui est différent, puis quitte.

Jens
la source
22

Selon toute vraisemblance, ils ne diffèrent pas d'un seul octet. Ce n'est que le premier octet différent. Exécutez cmp -l dev/sdb /dev/sdcpour répertorier toutes les différences.

Les 512 premiers octets de la clé sont son secteur de démarrage . Le décalage 441 (440 si vous commencez à numéroter à 0) est l'emplacement de la signature de disque qui est censé identifier le disque de manière unique (pour les avantages de Windows - je ne me souviens pas avoir vu Linux prendre soin). Il faut s'attendre à ce qu'ils diffèrent. Ce sont les fichiers sur la clé qui sont censés être identiques, pas les étiquettes de disque (ou les horodatages des fichiers, soit dit en passant).

Vérifiez que le bâton qui se bloque a le contenu de fichier correct. Il peut être physiquement endommagé.

Gilles 'SO- arrête d'être méchant'
la source