Salut Skami et tout ceux ayant participé à cette discussion,

Connaissant un peu le sujet j'ai voulu y répondre avant (mais le
weekend-end de pâques ayant été chargé... ;)) En tout cas la démarche
décrite par Loïc est la bonne !!

Je me permet simplement de compléter cette discution par un petit
"addon" qui pourrait éventuellement servir...

> > La partition ne commence par au début du fichier. Il faut d'abord
> > repérer l'offset de début de la partition concernée (fdisk -ul DISK.img,
> > champ Start)
> >
> > Ensuite multiplier ce nombre par 512 (nombre de blocks), et enfin monter
> > l'image en loopback, en précisant l'offset trouvé:
> >
> >
> > mount -o loop,offset=xxx DISK.img /mnt
> 
> Ça marche !!

Impeccable :)

A mon tour d'exposer par une petite "étude de cas" de ce type de montage
(et les limitations que j'ai pu constater)...

J'ai un fichier 'WinXP-SP2.img' contenant une image que j'utilise
régulièrement sous qemu...

Effectivement le point intéressant est le : sudo fdisk -lu WinXP-SP2.img
(le -u étant effectivement l'Option utile pour donner les tailles -les
unités- en secteurs plutôt qu'en cylindres)

...
Disque WinXP-SP2.img: 0 Mo, 0 octets
...
Unités = secteurs de 1 * 512 = 512 octets
...
  Périphérique Amorce  Début        Fin      Blocs     Id  Système
WinXP-SP2.img1   *          63     7168895     3584416+   7  HPFS/NTFS
WinXP-SP2.img2         7168896     8176895      504000    5  Etendue
WinXP-SP2.img5         7168959     8176895      503968+   b  W95 FAT32
...

Il se trouve que dans la plupart des cas effectivement 1secteur =
512octets (mais sur une image -un disque non physique- mieux vaut
vérifier cette valeur).

La première partition (de type ntfs) commence donc effectivement à 63
secteurs après le début soit à 63*512 (32256) octets.
La deuxième partition (de type vfat) commence à 7168959 secteurs soit
7168959*512 octets.

Ce qui est pratique en shell c'est de lui laisser faire les
multiplications (secteur*nb_octet_par_secteur)...

On peut donc monter chacune des partitions de la manière suivante :

sudo mount -t ntfs -o loop,offset=$((63*512)) WinXP-SP2.img /mnt/disk1/

et

sudo mount -t vfat -o loop,offset=$((7168959*512))
WinXP-SP2.img /mnt/disk2/

(bon je vous l'accorde cela évite juste de sortir une calculette ou
d'ouvrir un calc.. et le copié/collé des valeurs...)

> Merci à Loic et à tous pour vos réponses: je vais pouvoir travailler 
> efficacement - car pour travailler efficacement sous Windows, il faut 
> l'éteindre et le monter sous Linux :-p

Effectivement !
J'ai noté la même limitation à savoir qu'une modification du système de
fichiers NTFS sur le point de montage lorsque windows (sous Qemu) est
lancé, pose des problèmes (visibilité des fichiers / corruption du
ntfs ...) sous windows...
Même constat sur la partition en vfat (que j'avais crée dans ce but mais
sans plus de succès).

Donc difficile d'avoir un partage synchronisé efficace entre le hôte et
la machine émulée (sans avoir recours à un montage réseau par exemple).

Par contre si l'on crée un répertoire nommé par exemple 'directory' au
même niveau que l'image et que l'on lance qemu avec l'option '-fda
fat:floppy:rw:directory' cela permet d'avoir un bon emplacement
d'échange entre la machine hôte et la machine émulée.

Voila pour ce petit complément et mon retour d'expérience à ce sujet.

Bonne émulation :-)

@+
Vincent




 Diffusez cette liste aupres de vos relations :-)
            Linux Azur : http://linux-azur.org
       Vous etes responsable de vos propos.
*** Pas de message SMS, HTML ni de PJ SVP ***

Répondre à