1 votes

Comment puis-je copier une partition d'une image sur une partition d'un disque physique ?

J'avais enfin une clé usb bootable fonctionnelle avec une installation de Windows 7 prête à l'emploi, quand j'ai réalisé qu'une fois la sélection de la langue apparue, le clavier et le trackpad de mon Macbook Pro ne fonctionnaient plus et je n'avais aucun moyen de procéder à l'installation réellement.

J'ai décidé de mettre en place un Windows 7 x64 sous VirtualBox, installer les pilotes de clavier et de trackpad du package Logiciel de prise en charge de Bootcamp, et arrêter la VM.

J'ai utilisé VBoxManage internalcommands converttoraw ... pour convertir le disque virtuel en un .img. Pour ceux qui ne connaissent pas VirtualBox, cela crée une image complète du disque dur virtuel comme s'il s'agissait d'un disque dur physique, et cela fonctionne de la même manière.

J'ai utilisé fdisk pour afficher l'image :

sh-3.2# fdisk WINDOWS7.img 
Disk: WINDOWS7.img  geometry: 2610/255/63 [41943040 sectors]
Signature: 0xAA55
     Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
*1: 07    0  32  33 -   12 223  19 [      2048 -     204800] HPFS/QNX/AUX
2: 07   12 223  20 - 1023 254  63 [    206848 -   41734144] HPFS/QNX/AUX
3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused

J'ai ensuite utilisé ce qui suit dans une tentative de sauter la partition Réservée au Système et de simplement copier la partition de données Windows sur la tranche désignée de mon Macintosh HD :

sh-3.2# dd if=WINDOWS7.img of=/dev/disk0s4 skip=206848 bs=65535

Me laissant avec ce qui suit :

sh-3.2# fdisk /dev/disk0
Disk: /dev/disk0    geometry: 60821/255/63 [977105060 sectors]
Signature: 0xAA55
         Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] 
2: AC 1023 254  63 - 1023 254  63 [    409640 -  684395032] 
3: AB 1023 254  63 - 1023 254  63 [ 684804672 -    1269536] Darwin Boot 
4: 0B 1023 254  63 - 1023 254  63 [ 686074208 -  290768672] Win95 FAT-32

Cela semble correct, mais me laisse avec un disque non initialisable que je ne peux pas monter ni accéder avec l'utilitaire de disque, quand je clique sur monter, rien ne se passe, même si j'essaie mount -t ntfs /dev/disk0s4 /Volumes/Temp-Dir-Made-With-mkdir

utilitaire de disque

Quel pourrait être le problème ? Est-ce que je fais quelque chose de mal ? Est-ce impossible ?

La tranche 4 du disque0 n'hérite-t-elle pas du système de fichiers de la partition que j'ai écrite dessus ?

Merci d'avance pour tout éclaircissement !

Édition 1 :

@David C'est un MacbookPro11,3 ce qui devrait vous dire tout ce que vous avez besoin de savoir à ce sujet. En ce qui concerne Bootcamp, je l'ai téléchargé directement sous Windows depuis le Document de Support Apple suivant kbDL1720

@klanomath (Commentaire 1)Vrai, mais c'est une bonne information à connaître ! Par curiosité, pourquoi 65535 est une mauvaise taille de bloc ? Je pensais que la spécification de la taille du bloc avait seulement à voir avec le nombre de blocs qui étaient traités et envoyés vers le disque/image à la fois, permettant essentiellement de DD plus rapidement avec plus de RAM (avec la loi des rendements décroissants entrant en jeu à un certain moment bien sûr.) Suis-je complètement dans l'erreur concernant le paramètre bs= ?

@user3439894 J'y ai pensé, je ne devrais pas avoir besoin du MBR si j'utilise un chargeur de démarrage différent, mais j'ai négligé de partitionner la Réserve Système. Le problème ici est que j'ai déjà 4 partitions sur le disque dur... J'oublie quelle est la partition 0 (je ne suis pas devant mon mac), la partition 1 est Mac, la partition 2 est la partition de récupération Mac, et la partition 3 est celle que j'ai faite pour Windows. Peut-être que je fais fausse route... Bootcamp est devenu un vrai cauchemar, cela aurait été bien si cela avait simplement pris mon image et fait le travail pour moi, mais je digresse.

0voto

klanomath Points 63400

La commande appropriée pour dd une partie d'un fichier brut vers une partition dans votre cas est :

dd if=WINDOWS7.img of=/dev/disk0s4 skip=206848 bs=512 count=41527296

Le bs dans la commande dd peut être interprété comme une taille de bloc artificielle de l'entrée et de la sortie du "fichier". Pour des raisons historiques et techniques, la taille de bloc par défaut de dd est de 512 octets.

La raison d'utiliser 512 (ou un multiple/diviseur entier approprié) comme bs est la taille de bloc de votre image et de la partition disk0s4 - qui est soit 512 ou 4096.

La taille de bloc (logique) de disk0 peut être calculée (même sans savoir si fdisk fonctionne avec 512 ou 4096 octets en interne) : 977105060 * 512 = 500 Go ou 977105060 * 4096 = 4 To. Un SSD de 4 To n'existe pas encore pour les MacBook Pro, donc la taille de bloc doit être de 512 octets. Il en va de même pour votre fichier img.

Maintenant, vous pouvez prendre en compte des raisons de vitesse : plus le bs est grand, plus l'image sera copiée rapidement.

Par conséquent, une commande dd valide dans votre cas pourrait être :

dd if=WINDOWS7.img of=/dev/disk0s4 skip=X bs=2 count=Y

Étant donné que bs est de 2 octets seulement, vous devez modifier skip (saute X blocs à bs de if) et count (Y blocs à bs sont "écrits"). Étant donné que skip est de 206848*512, X est de 206848*512/2 et count est de 41527296*512, Y est de 41527296*512/2 et la commande ci-dessus est :

dd if=WINDOWS7.img of=/dev/disk0s4 skip=52953088 bs=2 count=10630987776

Un test rapide révèle :

dd if=/dev/zero of=~/Desktop/output.file bs=1 count=1048576
1048576 octets transférés en 1.593527 sec (658022 octets/sec)
dd if=/dev/zero of=~/Desktop/output.file bs=2 count=524288
1048576 octets transférés en 0.800444 sec (1309993 octets/sec)
dd if=/dev/zero of=~/Desktop/output.file bs=4 count=262144
1048576 octets transférés en 0.384188 sec (2729331 octets/sec)
dd if=/dev/zero of=~/Desktop/output.file bs=1024 count=1024
1048576 octets transférés en 0.001932 sec (542700705 octets/sec)

Plus le bs est grand, plus rapide la commande dd est exécutée.

PS : Le plus grand bs fonctionnel pour vous est 1048576 (le plus grand commun diviseur) car 105906176(=taille de saut en octets)/1048576=101 (et 21261975552(=taille du décompte en octets)/1048576=20277). 101 est premier !


Jusqu'à présent, toutes les valeurs de bs sont des multiples de 2. Si bs est impair, cela peut entrer en conflit avec les tailles de bloc de if/of. Au moins dans votre cas, if et of ont des tailles d'octets pairs car ils sont des multiples de 512.

Maintenant, il devrait être évident pourquoi l'utilisation de bs=65535 échoue : les numéros de bloc de saut et de comptage sont déterminés par bs et non par la taille de bloc naturelle de votre image ou partition. Une commande appropriée pourrait être

dd if=WINDOWS7.img of=/dev/disk0s4 skip=1616.024... bs=65535 count=324436.950...

Au moins pour moi, cela échoue car 1616.024... est une valeur numérique illégale. On peut donc supposer que tous les nombres doivent être des valeurs entières !

Un bs de 65535 fonctionne uniquement si la taille totale de if/of et des limites de saut ou de recherche sont multiples de 65535 octets.

Si votre commande dd ne contient aucune partie de saut/recherche/comptage, vous pouvez utiliser des tailles de bs arbitraires cependant.


Même si la commande dd au début de la réponse fonctionnera, vous ne pourrez probablement pas démarrer sur la partition Windows To Go (ou Windows Installer Prêt-À-Partir ?). Le MBR de disk0 ne contiendra pas l'entrée de démarrage nécessaire.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X