MATERIEL : [Pas résolu] Clefs USB bootables ... ou pas

Support Debian
#1

Bonjour

Je suis confronté à un mystère déconcertant.

Je dispose de deux clef USB matériellement identiques (à l’exception de la couleur du boitier :smiley: ) sur lesquelles j’ai installé sur l’unique partition d’icelles une minidistribution debian via debootstrap, amorcée par grub.

Les deux clefs fonctionnent via qemu.
Par contre une seule est reconnue bootable par le bios de l’ordinateur avec lequel je les essaie en direct.

Le contenu binaire est le même (dd de la bootable à la non bootable).

Je suis tout ouie quant à une explication ou une suggestion de manipulation.

Quelques infos :

[code]lsusb :

Bus 001 Device 003: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 001 Device 004: ID 058f:6387 Alcor Micro Corp. Flash Drive
[/code]

[code]Partitionnement

Disque /dev/sdc : 2062 Mo, 2062548992 octets
8 têtes, 7 secteurs/piste, 71936 cylindres, total 4028416 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x588ea623

Périphérique Amorce Début Fin Blocs Id Système
/dev/sdc1 496 4028415 2013960 83 Linux
[/code]
L’ordinateur de test est un Dell Vostro 1720.

Cordialement

Dominique

#2

Salut miko !

[moderation]Les règles d’usage du forum (que tu peux relire ici) demandent que le titre de chaque demande d’aide soit préfixé par le domaine sur lequel elle porte en majuscules, pour faciliter le repérage des sujets pour ceux qui apportent leur aide.[/moderation]

Par exemple dans ton cas : [mono]MATÉRIEL : Clefs USB bootables… ou pas[/mono].

#3

[quote=“miko”]…Le contenu binaire est le même (dd de la bootable à la non bootable).…[/quote]Oui mais le contenu de la clef ou de la ou des partition contenues ?

Si les deux clefs ont exactement la même taille, et pour être certain que le contenu des clefs soit identique,
en supposant que le fichier de périphérique de la clef qui fonctionne est [mono]/dev/sdc[/mono]
et que celui de la clef qui ne fonctionne pas est [mono]/dev/sdd[/mono] (au passage, tu notera que ces noms de fichiers se terminent par une lettre et pas un chiffre)

Il faut dé-[mono]mount[/mono]er toutes les partitions de ces deux clefs (au cas ou un [mono]mount[/mono]age automatique aurait été fait par le système)
Depuis le compte [mono]root[/mono] :

umount /dev/sdc* umount /dev/sdd*
Ensuite seulement tu pourra copier le contenu binaire de l’une sur l’autre avec [mono]dd[/mono] :

dd if=/dev/sdc of=/dev/sdd bs=4M syncN’oublie pas d’attendre que la dernière commande ([mono]sync[/mono]) soit bien terminée avant de déconnecter physiquement les clef du connecteur USB de ta machine.

#4

Rebonjour

J’ai recopié le périphérique entier et non seulement la partition.

Cordialement

Dominique

#5

Alors je ne vois pas du tout ce qu’il a pu se passer.

Ceci dit, s’il y a eu copie d’une clef sur l’autre, il n’y a pas encore eu de comparaison entre les contenus lisibles des deux clef.

dd if=/dev/sdc of=contenuSdc bs=4M sync dd if=/dev/sdd of=contenuSdd bs=4M sync diff -a contenuSdc contenuSdd
Si la dernière commande ([mono]diff[/mono]) ne retourne rien, c’est que le contenu binaire des deux fichiers ([mono]contenuSdc[/mono] et [mono]contenuSdd[/mono]) est identique

#6

Bonjour

[quote=“MicP”]Ceci dit, s’il y a eu copie d’une clef sur l’autre, il n’y a pas encore eu de comparaison entre les contenus lisibles des deux clef.
[/quote]

Je n’ai effectivement pas vérifié la copie (sur une clef USB de 2 GiO, c’est long)
Toutefois le fait que la clef non bootable fonctionne avec qemu m’incite fortement à penser que son contenu n’est pas corrompu.

Je vais lancer la comparaison.

Cordialement

Dominique.

#7

[quote]…2 GiO, c’est long…[/quote]C’est pour ça que j’utilise plutôt un disque dur dans un boîtier USB pour tester et utiliser les images ISO live ou d’installation,
Mais tu pourrais commencer par vérifier par une comparaison de fichier plus petit (ici, 4Mio):

dd if=/dev/sdc of=contenuSdc bs=4M count=1 sync dd if=/dev/sdd of=contenuSdd bs=4M count=1 sync diff -a contenuSdc contenuSddSi les 4 premiers Mio sont identiques, passe à la comparaison du contenu intégral.

#8

Dans cette situation, une comparaison de sommes md5 ne serait-elle pas beaucoup plus rapide ?

#9

Tout-à fait, [mono]md5sum[/mono] serait effectivement tout aussi efficace pour déterminer si les fichiers sont identiques ou pas.

Mais pour le problème de la lenteur dans la récupération des fichiers, comme il faudra quand même lire chaque fichier pour pouvoir en calculer la somme MD5…

======
J’avais pensé à la commande [mono]diff[/mono] car elle nous donnera la différence constatée, et avec cette différence, on pourra peut-être comprendre ce qui s’est passé.

#10

Bonjour,

J’ai vérifié que les contenus sont rigoureusement identiques.
J’ai aussi vérifié que lsusb -v me donne les mêmes informations pour les deux clefs.

Pour information :

  • [mono]cmp -l[/mono] est mieux adapté à la comparaison de fichiers binaires que [mono]diff[/mono] qui est orienté comparaison de fichiers textuels (et création de patches)
  • [mono]md5sum[/mono] et consort n’est utile que lorsque l’on ne dispose pas de l’original pour comparaison : il n’est pas plus rapide puisqu’il faut bien lire les deux clefs dans tous les cas.

Cordialement

Dominique

#11

Merci beaucoup pour l’information au sujet de la commande [mono]cmp[/mono],
Comme quoi, (vu le nom de la commande), je/on va souvent chercher ailleurs ce qu’on a sous le nez, et c’est aussi pour ça que j’adore Linux :slightly_smiling:.

=====
Étant donné que leur comportement diffère, il faut bien que quelque chose différencie ces deux clefs.
Leur contenu binaire (récupéré avec [mono]dd[/mono]) est vraiment le plus bas niveau d’accès que je connaisse avec Linux.
Avant, j’utilisais l’int 13h et toutes ses fonction, ce qui m’a permis de découvrir pas mal de choses,
mais ça, c’était avant…

Ici, on a affaire à un canal de communication USB, dont le protocole est un standard, et ne devrait (théoriquement) pas être “polluable”,
mais les mystères du BIOS et de l’UEFI sont impénétrables (“législativement” parlant).

Il y a aussi l’intermédiaire situé entre le connecteur USB et les puces mémoires (qui est lui aussi impénétrable même si on peut parfois avoir accès à certains datasheets).

======
Histoire d’innocenter la machine hôte, as-tu pu tester la clef USB (qui ne veut pas booter) sur une ou plusieurs autres machines ?

======
Si c’est bien la clef qui cause problème (ce que je pense), j’aimerai bien avoir un de ces analyseurs de protocole USB pour trouver ce qui cloche.

En tout cas, tiens nous au courant si tu trouve les raisons de cette différence de comportement (et surtout comment tu t’y es pris pour le découvrir).

======
Pourrais-tu me transmettre les références exacte de cette clef, je vais m’en offrir une ou deux (suivant le prix) rien que pour satisfaire ma curiosité.

#12

Mais encore ?

#13

Bonjour,

[quote=“MicP”]
Si c’est bien la clef qui cause problème (ce que je pense)[/quote]

Je pense effectivement que la clef a un souci matériel, mais j’ignore comment le détecter…

[quote=“MicP”]
Pourrais-tu me transmettre les références exacte de cette clef, je vais m’en offrir une ou deux (suivant le prix) rien que pour satisfaire ma curiosité.[/quote]

Il s’agit de clefs promotionnelles, offertes vierges : il y a juste une sérigraphie sur le capot.
Je n’ai aucune information quant au modèle exact, à l’exception de la réponse lsusb (que j’hésite à poster ici en totalité). Sa taille est de 2GO.

Cordialement

Dominique.

#14

Bonjour,

Mais encore ?[/quote]

Sur le Dell Vostro 1720, pour permettre un amorçage, le périphérique doit être reconnu comme amorçable par le bios.
L’une des clefs est bien reconnue et permet l’amorçage via grub. L’autre n’est pas reconnue, et ne propose pas grub.

Je ne comprends pas bien quelle autre information vous donner.

Cordialement

Dominique.

#15

Salut !

Si c’est possible, connectes tes deux clés sur ta machine.
Ensuite, dis nous ce que renvoie cette commande (passée en mode administrateur) :

# fdisk -l s’il te plaît.

#16

Bonjour,

[quote=“tizef”]
Ensuite, dis nous ce que renvoie cette commande (passée en mode administrateur) :

Je ne peux plus effectuer la comparaison parce j’ai fait évoluer le contenu de la clef bootable.
Toutefois la réponse figure pour l’une des clefs dans mon premier messages.
Et les clefs étant binairement identiques, fdisk devrait montrer la même chose dans les deux cas (je suis à peu près certain de l’avoir vérifié plusieurs fois, sans pouvoir exposer une preuve).

Cordialement

Dominique.

#17

[quote=“miko”]…
Toutefois la réponse figure pour l’une des clefs dans mon premier messages.[/quote]Dans ce premier message, je vois que cette clé n’a pas le drapeau “boot”.
Je suppose que celle que tu appelles “clé bootable” l’a, elle.

[quote=“miko”]Et les clefs étant binairement identiques, fdisk devrait montrer la même chose dans les deux cas…[/quote]Justement, même si tu as fait évoluer le contenu de cette clé, vérifie avec fdisk -l si elle a le drapeau “boot” (l’astérisque, après /dev/sdx * …/…).

Dans ton premier post, le drapeau n’est pas là :

Périphérique Amorce Début Fin Blocs Id Système /dev/sdc1 496 4028415 2013960 83 LinuxDevrait être :

Périphérique Amorce Début Fin Blocs Id Système /dev/sdc1 * 496 4028415 2013960 83 Linux

La différence entre tes deux clés ne tient peut-être qu’à ça. Sans certitude, mais c’est une piste à vérifier (même après changement du contenu).

#18

Si la partition d’une des clef a le drapeau boot activé et l’autre pas,
alors le contenu binaire des fichiers obtenus avec [mono]dd[/mono] en utilisant le fichier de périphérique associé à la clef (pas celui de la partition contenue) serait différent.

La/les table(s) des partitions (MBR ou GPT) et le drapeau boot (boot flag) de la partition sont donc inclus dans ces fichiers binaires.

Mais comme :[quote=“miko 24 Sep 2014 13:13 (4ème message)”]…J’ai recopié le périphérique entier et non seulement la partition.…[/quote]

[quote=“MicP 24 Sep 2014 13:16 (5ème message)”]…

dd if=/dev/sdc of=contenuSdc bs=4M sync dd if=/dev/sdd of=contenuSdd bs=4M sync diff -a contenuSdc contenuSdd
…[/quote][quote=“miko 25 Sep 2014 07:33 (10ème message)”]…J’ai vérifié que les contenus sont rigoureusement identiques.…[/quote]

#19

Si l’une est boutable et pas l’autre c’est qu’elles sont différentes.
Si elles sont matériellement identiques et que tu as fait un dd de l’une entière (et pas seulement la partition) sur l’autre, elles devraient être rigoureusement identiques.

Donc l’une d’entre elles, la seconde, est foireuse. Pas la peine de tourner autour du pot je pense

#20

On est tout-à fait d’accord sur le fait que le contenu retourné par [mono]dd[/mono] est identique.

Mais “tourner autour du pot” permettra peut-être de comprendre à quel niveau se trouve cette différence.

C’est dans ce but que je demandai à miko :[quote=“message du 25 Sep 2014 09:15”]…as-tu pu tester la clef USB (qui ne veut pas booter) sur une ou plusieurs autres machines ?…[/quote]