Bugs dans la doc Oracle VirtualBox User Manual -- v 6.1.32

Bonjour,

c'est dans le pdf de la 6.1.32 (dans /usr/lib/virtualbox) et ça se passe au chapitre 5.11 pages 105 et 106 puis, plus détaillé, au chapitre 8.46 en pages 242 et suivantes.
J'ai perdu un temps dément avec juste cette bricole idiote :
Pièce jointe 615108

Le signe "=" en rouge fait que ce qui est saisi n'est pas analysé ou je ne sais quoi, bref, en remplaçant par une espace, hop !, ça fonctionne.
Alors méfiance avec les deux "=" en bleu clair, je n'ai pas testé...

Autre chose :
Pièce jointe 615109
Pas moyen de faire fonctionner la dernière ligne,

Code:

---

mount: /mnt: mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/loop0, page de code ou programme auxiliaire manquant, ou autre erreur.

---

Avec ça on est bien renseigné...

Chez moi ça fait une erreur de segmentation (mais version 6.1.26) et apparemment c'est expérimental. Ils auraient pu accepter le du vdi plutôt que de devoir renseigner l'UUID.
Une fois la commande effectuée, essayes de monter le fichier vhdd qui est sensé représenter la partition à plat dans un périphérique loopback (avec losetup ou kpartx), tu devrais ensuite pouvoir monter la partition depuis le dev/loopX.

Citation:

---

Envoyé par chrtophe

Chez moi ça fait une erreur de segmentation (mais version 6.1.26) et apparemment c'est expérimental. Ils auraient pu accepter le chemin ? du vdi plutôt que de devoir renseigner l'UUID.

---

Si tu pensais à chemin, path, ça fonctionne, j'ai testé

Code:

---

1 2 3

vboximg-mount options: [ { -i | --image } <specifier> ] VirtualBox disk base image or snapshot, specified by UUID or path

---

Citation:

---

Envoyé par chrtophe

Une fois la commande effectuée, essayes de monter le fichier vhdd qui est sensé représenter la partition à plat dans un périphérique loopback (avec losetup ou kpartx), tu devrais ensuite pouvoir monter la partition depuis le dev/loopX.

---

Je n'ai pas encore compris comment il fallait faire. J'ai essayé

Code:

---

mount -o loop ...

---

mais je me suis fait jeter. On verra ça demain.

Citation:

---

Je n'ai pas encore compris comment il fallait faire.

---

Code:

---

losetup -a

---

pour lister les devices loopback, il faut prendre un numéro non affecté.
exemple avec un /dev/loop0 dispo :

Code:

---

losetup /dev/loop0 vhdd

---

A ce stade, le fichier image brut vhdd est accessible comme un disque via /dev/loop0
puis :

Code:

---

kpartx -av /dev/loop0

---

Ceci va rendre automatiquement dispo toutes les partitions contenues dans /dev/loop0 dans un "sous-device" loopback
avec fdisk -l, tu pourras voir les partitions pour trouver celle à monter par exemple :

Code:

---

mount /dev/loop0p1 point_de_montage

---

Ensuite pour démonter proprement :

Code:

---

1 2 3 4

umount /dev/loop0p1 kpartx -d /dev/loop0 losetup -d /dev/loop0

---

et enfin la commande virtualbox inverse de vboximg-mount

Je répète : pas pu tester

Mais tu as une autre méthode, que j'ai déjà testé : j'avais oublié : avec les qemu-utils (paquet à installer) - du coup plus natif virtualbox
Une fois le paquet instalé:

Code:

---

modprobe nbd

---

puis :

Code:

---

qemu-nbd -c /dev/nbd1 fichier.vdi

---

Tu pourras ensuite monter la partition directement comme par exemple:

Code:

---

mount /dev/nbd1p1 /mnt

---

nbd ressemble au fonctionnement des loopback

Et attention aux comportement si il y a des clichés.

Bonjour,

réponses rapides :

Citation:

---

Envoyé par chrtophe

Code:

---

losetup -a

---

---

OK merci, m'en vais tester tout ça dans la journée...

Citation:

---

Envoyé par chrtophe

et enfin la commande virtualbox inverse de vboximg-mount

---

Il n'y en a pas, c'est un bête umount de ce qu'on peut trouver dans la liste sortie par mount.

Citation:

---

Envoyé par chrtophe

Mais tu as une autre méthode, que j'ai déjà testée : j'avais oublié : avec les qemu-utils (paquet à installer)

---

Oui, je la connais et l'utilise par ailleurs, et si je patauge avec vboximg-mount (qui m'a l'air bien tordu...), je me rabattrai sur qemu.

Citation:

---

Envoyé par chrtophe

Et attention aux comportement si il y a des clichés.

---

Je n'en ai pas.

Merci pour tout, je te tiens au courant.

Bonjour,

ce matin il pleut, c'est un temps à trifouiller dans les machines, j'ai attaqué par une reconfiguration du noyau par ajout de modules (il me manquait le support du device-mapper) et après reboot, en avant (FGHIJK.vdi est un vieux disque virtuel provenant de la virtualisation d'une vieille machine win2k, avec 3 partitions principales et 1 étendue contenant 3 autres secondaires, on le voit bien avec fdisl -l /dev/loop0) !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

$ cd / $ vboximg-mount --image /media/root/GreyPassport/FGHIJK.vdi /mnt/mp $ ls /mnt/mp/ FGHIJK.vdi vhdd vol0 vol1 vol2 vol3 vol4 vol5 $ losetup -l # retourne rien, vide, = ok $ losetup /dev/loop0 /mnt/mp/vhdd $ losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 0 1 /mnt/mp/vhdd 0 512 $ losetup -a /dev/loop0: [0044]:5 (/mnt/mp/vhdd) $ kpartx -av /dev/loop0 add map loop0p1 (254:0): 0 8193087 linear 7:0 63 add map loop0p2 (254:1): 0 102398310 linear 7:0 8193150 add map loop0p3 (254:2): 0 51199155 linear 7:0 110591460 add map loop0p4 (254:3): 0 2 linear 7:0 161790615 add map loop0p5 (254:4): 0 20482812 linear 7:0 161790678 add map loop0p6 (254:5): 0 14329917 linear 7:0 182273553 add map loop0p7 (254:6): 0 13108977 linear 7:0 196603533

---

ça semble tout bon, je crée 7 points de montage /mnt/pdm1...7 et continue les explications de chrtophe :

Citation:

---

Envoyé par chrtophe

... Ceci va rendre automatiquement dispo toutes les partitions contenues dans /dev/loop0 dans un "sous-device" loopback
avec fdisk -l, tu pourras voir les partitions pour trouver celle à monter par exemple :

Code:

---

mount /dev/loop0p1 point_de_montage

---

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

$ fdisk -l /dev/loop0 Disque /dev/loop0 : 100 GiB, 107374182400 octets, 209715200 secteurs ... Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/loop0p1 63 8193149 8193087 3,9G 7 HPFS/NTFS/exFAT /dev/loop0p2 8193150 110591459 102398310 48,8G 7 HPFS/NTFS/exFAT /dev/loop0p3 110591460 161790614 51199155 24,4G 7 HPFS/NTFS/exFAT /dev/loop0p4 161790615 209712509 47921895 22,9G f Étendue W95 (LBA) /dev/loop0p5 161790678 182273489 20482812 9,8G 7 HPFS/NTFS/exFAT /dev/loop0p6 182273553 196603469 14329917 6,8G 7 HPFS/NTFS/exFAT /dev/loop0p7 196603533 209712509 13108977 6,3G 7 HPFS/NTFS/exFAT $ mount /dev/loop0p1 /mnt/pdm1 mount: /mnt/pdm1: le périphérique spécial /dev/loop0p1 n'existe pas.

---

Aïe ! Pour essayer de comprendre,

Code:

---

1 2 3

$ mount /dev/lo<TAB> log loop1 loop3 loop5 loop7 loop0 loop2 loop4 loop6 loop-control

---

et effectivement, il n'y a pas grand chose à monter sous le nom loop0pX...
Pour y voir clair,

Code:

---

1 2 3 4 5 6 7 8 9 10

$ mount ... /dev/sdd1 on /media/root/GreyPassport type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) vboximg-mount on /mnt/mp type fuse.vboximg-mount (rw,nosuid,nodev,relatime,user_id=0,group_id=0) /dev/mapper/loop0p1 on /media/root/SWAP type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,uhelper=udisks2) /dev/mapper/loop0p2 on /media/root/Films_n_Zik type fuseblk (mêmes infos que ci-dessus) /dev/mapper/loop0p3 on /media/root/Backups type fuseblk (idem) /dev/mapper/loop0p5 on /media/root/Save type fuseblk (...) /dev/mapper/loop0p6 on /media/root/Temp_Divers type fuseblk () /dev/mapper/loop0p7 on /media/root/Distribs type fuseblk ()

---

Ha ha ! L'insertion de "mapper/" serait la solution ? Avec /dev/mapper/loop0pX c'est mieux mais c'est pas encore ça :

Code:

---

1 2 3 4

$ mount /dev/mapper/loop0p1 /mnt/pdm1 Mount is denied because the NTFS volume is already exclusively opened. The volume may be already mounted, or another software may use it which could be identified for example by the help of the 'fuser' command.

---

Et surtout, qu'est-ce que c'est que cette pagaille de dossiers créés dans /media/root pas par moi ?

Code:

---

1 2	$ ls /media/root/<TAB TAB> Backups/ Distribs/ Films_n_Zik/ GreyPassport/ Save/ SWAP/ Temp_Divers/

---

le dossier GreyPassport a été créé automatiquement à l'insertion du dd externe GreyPassport, qui stocke le fichier .vdi, ok. Mais les autres ?
Pris par le système de mountage depuis les noms des partoches qu'il a trouvés ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

$ ls /media/root/Backups/ Backups RECYCLER robocopy.exe save_C.bat save_D.bat save_E.bat SavesNTBackup 'System Volume Information' $ ls /media/root/Distribs/ 'Autres distribs' Epson OS_2k 'System Volume Information' w2ksp4_fr.exe 'Bouquins Inform' L_Streams RECYCLER 'w2k post sp4' $ ls /media/root/Films_n_Zik/ '_4_Fréquences CD-test' Bousquet Henri-Texier RECYCLER Zappa '_4_test files_WMA' BTO 'Livin Blues' 'Ronnie Earl' _5_Films Clapton 'Paul Desmond - Indian Summer.mp3' Sade.wav '_6_Films zique' 'Compil HN-D' 'Paul Desmond - Warm Valley.mp3' SRV-23-10-22 '_7_save compils maison' 'Coton eye joe.wma' 'Pink Floyd' 'System Volume Information' $ ls /media/root/Save/ 'Crumb by Philippe' RECYCLER 'System Volume Information' $ ls /media/root/SWAP/ $ (vide) $ ls /media/root/Temp_Divers/ $ (vide)

---

C'est bien ça. J'ai bien sous les yeux le contenu de mon disque virtuel, tout est accessible mais la chose ennuyeuse, c'est cet automatisme qui fait que les partoches sont montées là où le système décide, alors pour scripter ça, je crains que ça ne soit tendu, je préférais nettement avoir des points de montage contrôlés...

Des idées pour que le script ne perde pas ses repères ?

EDIT : le ménage

Citation:

---

Envoyé par chrtophe

Ensuite pour démonter proprement :

Code:

---

1 2 3

umount /dev/loop0p1 kpartx -d /dev/loop0 losetup -d /dev/loop0

---

---

Donc (rappel : loop0p4 n'existe pas, c'est la partition "étendue") :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

$ umount /dev/mapper/loop0p7 $ umount /dev/mapper/loop0p6 $ umount /dev/mapper/loop0p5 $ umount /dev/mapper/loop0p3 $ umount /dev/mapper/loop0p2 $ umount /dev/mapper/loop0p1 $ kpartx -d /dev/loop0 $ losetup -l $ (vide) $ losetup -a $ (vide) $ losetup -d /dev/loop0 losetup: /dev/loop0 : échec de détachement: Aucun périphérique ou adresse $ umount /mnt/mp $ ls /media/root/ GreyPassport $ umount /media/root/GreyPassport

---

Terminé !

Citation:

---

Des idées pour que le script ne perde pas ses repères ?

---

Désactiver l'automount. La façon de faire dépendra du window manager

Citation:

---

Envoyé par chrtophe

Désactiver l'automount. La façon de faire dépendra du window manager

---

Merci mais je n'ai pas le paquet automount installé ! Et d'ailleurs, je me demande comment le kernel se débrouille pour me monter les dd externes et autres clés usb que j'insère.

Tu utilises quel window manager ?

Citation:

---

Envoyé par chrtophe

Tu utilises quel window manager ?

---

OpenBox.

Dans pcmanfm, essayes de d'aller dans edition->preferences et décocher volume management

Bonjour,

et merci de t'être pris la tête avec mes tourments :

Citation:

---

Envoyé par chrtophe

Dans pcmanfm, essaye d'aller dans edition->preferences et décoche volume management

---

Pas trouvé "Volume Management", c'est de ça dont tu parles ? :
Pièce jointe 615351

Si "oui", j'avoue que je ne sais pas très bien quelle ligne décocher, probablement celle du milieu, mais à tous les coups ça va me désactiver la demande de lancement de pcmanfm lors de l'insertion d'un périph usb, ce qui est quand même bien utile, donc dommage de s'en passer.

Mais j'ai par ailleurs une bonne nouvelle : j'ai réussi à compiler et à faire fonctionner ce vieux vdfuse (qui trainait sur le web en 32bits) en 64bits et en plus il fonctionne mieux que le kpartx, qui m'a envoyé ça lors de la tentative de montage d'un fichier :

Code:

---

1 2	$ kpartx -a /dev/loop0 --> Error mounting /dev/dm-0 at /media/root/30m-fromdos: can't read superblock on /dev/mapper/loop0p1

---

alors que le fichier en question est bien monté avec mon vdfuse puis mount -o loop, voir ci-dessous.

Hélas, la commande umount est capricieuse :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

$ vdfuse -f data/virtualstuff/30_MEG.vdi /mnt/mp/ $ mount | grep '/mnt/mp' data/virtualstuff/30_MEG.vdi on /mnt/mp type fuse.vdfuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other) $ mount -o loop /mnt/mp/Partition1 /data/_share/4_VirtualTaf/src/part/Partition1 $ mount | grep Partition1 /mnt/mp/Partition1 on /data/_share/4_VirtualTaf/src/part/Partition1 type ext4 (rw,relatime) $ ls -lGg /data/_share/4_VirtualTaf/src/part/Partition1/ total 15 drwx------ 2 12288 2 nov. 2020 lost+found -rw-r--r-- 1 2397 14 mars 11:25 remarque_bullseye.txt $ umount /data/_share/4_VirtualTaf/src/part/Partition1; echo $? 0

---

Pièce jointe 615352

Code:

---

1 2 3 4 5 6 7 8

$ mount | grep Partition1 $ (vide) $ ls -lGg /data/_share/4_VirtualTaf/src/part/Partition1/ total 0 $ umount /mnt/mp/ $ (vide donc pas d'erreur) $ mount | grep '/mnt/mp' $ (vide donc bien démonté)

---

En résumé, il ne faut pas tenir compte du message d'erreur ! Ça se déglingue, chez Debian...

La preuve, les petites icônes sont plus grosses que les grandes :
Pièce jointe 615353
Je viens de vérifier, mes petites icônes sont bien en 16x16, :roll:

Bonsoir,

je reviens là-dessus après une longue absence pour cause de $§!/*@#~ de saleté de c0v1d, qui m'a rendu bien vaseux.
Là ça va mieux, merci, donc je me remets à l'établi, et je reprends là où j'avais lâché l'affaire, savoir, les caprices de la commande umount, qui me balance une fenêtre avec cette erreur non logguée dans les journaux /var/log/kern.log, messages, syslog, dmesg.
Pièce jointe 616141
En arrière-plan la commande cat /var/log/syslog | tail -10 qui montre bien que systemd me fait un caca nerveux : les 2 dernières lignes apparaissent lorsque je demande un umount, et "y" est le nom du dossier utilisé pour le point de montage.

Je ne comprends pas, car on dirait que le boulot est fait, la chose à démonter est bien démontée et je peux continuer à démonter son parent.

Mais je ne considère pas ça comme satisfaisant, ça fait désordre et je ne vois pas comment gérer ça dans un script, d'autant plus qu'avant de poster *ça* maintenant, j'ai bien vérifié dans la vieille machine 32bits la suite de commandes, et c'est strictement la même que dans la nouvelle machine 64bits, si je voulais faire du mauvais esprit je dirais que la seule différence entre les deux c'est que l'ancienne est vieille et si on y voit l'arrivée de systemd sur la pointe des pieds, cette bouze est loin d'y être opérationnelle.
Hélas, 9 ans plus tard elle s'est répandue comme une pandémie, elle est partout et j'ai une erreur non identifiée...

Que faire ? J'ai un peu googlé avec des mots comme [CODE]c problem[/c] mais maintenant, googler c'est un peu la loterie, alors si quelqu'un a une idée...

Bon, je réalise que ça pourrait faire l'objet d'un post à part entière, c'est vrai, mais c'est juste le post d'origine qui a un poil dérivé, alors c'est pas bien grave, pour le moment.

Bonsoir,

on s'est fait un brave sac de nœuds dans la tête, là où 2 lignes suffisaient... Source.
/x et /y sont les deux points de montage nécessaires, le premier pour l'image, le second pour la partition qu'on veut utiliser.

Code:

---

1 2	$ vboximg-mount -i /30_MEG.vdi -o allow_root /x/ $ mount /x/vol0 /y/ # Voir plus bas pour vol0

---

et ça s'utilise ainsi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

$ vboximg-mount -i /30_MEG.vdi -o allow_root /x/ $ ls -al /x/ total 9228 drwxr-xr-x 2 root root 0 1 janv. 1970 . drwxr-xr-x 27 root root 4096 31 mars 19:07 .. lr--r--r-- 1 root root 0 4 avril 16:16 30_MEG.vdi -> /30_MEG.vdi -rw-r--r-- 1 nobody nogroup 31457280 4 avril 19:05 vhdd -rw-rw-rw- 1 root root 31430144 1 janv. 1970 vol0 <------ VOL0 -- si plusieurs partitions, elles sont à la suite $ mount /x/vol0 /y/ $ ls -al /y/ total 20 drwxr-xr-x 3 root root 1024 14 mars 11:25 . drwxr-xr-x 27 root root 4096 31 mars 19:07 .. drwx------ 2 root root 12288 2 nov. 2020 lost+found -rw-r--r-- 1 root root 2397 14 mars 11:25 remarque_bullseye.txt

---

sans oublier

Code:

---

1 2	umount /y/ umount /x/

---

Allez, :resolu:

Bonjour,

Citation:

---

Envoyé par Jipété

on s'est fait un brave sac de nœuds dans la tête, là où 2 lignes suffisaient... Source.
/x et /y sont les deux points de montage nécessaires, le premier pour l'image, le second pour la partition qu'on veut utiliser.

---

C'était peut-être trop simple... :calim2:

le problème c'est que ce vboximg-mount n'a pas l'air très fiable...
Ce qui m'a mis la puce à l'oreille, c'est un post sur le forum vbox, https://forums.virtualbox.org/viewto...+mount#p470542, comme quoi les changements sur l'image montée ne seraient pas persistants...
Ça date de février 2020 et il n'y a aucune réponse !

Alors j'ai testé, et je confirme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

vboximg-mount -i /30_MEG.vdi --rw -o allow_root /x mount /x/vol0 /y ls /y/ lost+found remarque_bullseye.txt touch /y/test-file.txt ls /y/ lost+found remarque_bullseye.txt test-file.txt sync umount /y/ sync umount /x/ sync vboximg-mount -i /30_MEG.vdi --rw -o allow_root /x mount /x/vol0 /y ls /y/ lost+found remarque_bullseye.txt

---

et on constate l'absence du fichier "touch"é à la ligne 5, ce que je trouve navrant.

Citation:

---

Envoyé par Jipété

Allez, :resolu:

---

Bien obligé de décocher ça... :weird:

EDIT : j'ai posté chez vbox, plus qu'à surveiller le sujet...

Et le pire, c'est qu'avec le vieux vdfuse.c (qui traine sur des forums) adapté et recompilé pour du 64 bits par mes soins, ça fonctionne...

avec -o loop au mount de la ligne 4 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

vdfuse -f /30_MEG.vdi /x/ ls /x EntireDisk Partition1 mount -o loop /x/Partition1 /y ls /y lost+found remarque_bullseye.txt touch /y/testfile.txt ls /y lost+found remarque_bullseye.txt testfile.txt sync umount /y sync umount /x

---

sans -o loop (lignes 4 et 12) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

vdfuse -f /30_MEG.vdi /x/ ls /x EntireDisk Partition1 mount /x/Partition1 /y ls /y lost+found remarque_bullseye.txt testfile.txt touch /y/sansloop.txt sync umount /y/ umount /x/ vdfuse -f /30_MEG.vdi /x/ mount /x/Partition1 /y ls /y lost+found remarque_bullseye.txt sansloop.txt testfile.txt sync umount /y sync umount /x

---

Salut,

j'ai créé deux tickets chez VBox, un pour la non persistance des modifications apportées à une image (puisque ça a été confirmé par quelqu'un d'autre qui a repris mes tests suite au post dont j'ai parlé ici le 5 avril à 13 h 23) :
https://www.virtualbox.org/ticket/20896

et l'autre pour la documentation erronée :
https://www.virtualbox.org/ticket/20897

On verra bien...

Dans l'attente, je bricole avec mon vdfuse et/ou le couple nbd/qemu-nbd.
:coucou:

Bonjour,

Citation:

---

Envoyé par Jipété

j'ai créé deux tickets chez VBox, un pour la non persistance des modifications apportées à une image (puisque ça a été confirmé par quelqu'un d'autre qui a repris mes tests suite au post dont j'ai parlé ici le 5 avril à 13 h 23) :
https://www.virtualbox.org/ticket/20896

---

Les choses ont considérablement avancé !
Un, Oracle a confirmé le bug (yaisse ! Ça fait plaisir !) et
Deux, la solution (en cours de validation) devrait probablement être présente dans la 6.1.36, à surveiller.

Bonjour,

Citation:

---

Envoyé par Jipété

Deux, la solution (en cours de validation) devrait probablement être présente dans la 6.1.36, à surveiller.

---

C'est réglé avec la 6.1.36, ça fait plaisir !

(mais j'avoue humblement ne pas avoir vérifié si les corrections signalées en même temps ont été apportées au User Manual.)

Salut,

un autre bug avec vboximg-mount, c'est pourquoi je le poste à la suite.

Contexte : VBox 6.1.50
Outil : vboximg-mount
Localisation : UserManual.pdf, pages 242 (2x), 243 (2x), 244 (1x), 245 (2x).

Problème : l'aide et les exemples ont une erreur de typographie avec l'option --image, tout en bas de la page 243 par exemple : --image=<disk-image>.
En utilisant cette commande, l'outil ne trouve pas le fichier <disk-image> !
Il FAUT remplacer ce "=" par une espace, comme ça : --image <disk-image>.

Le problème est aussi présent avec l'option --vm, pages 242 (1x), 244 (1x), 245 (1x), 246 (1x).
Un test par copier-coller du pdf (sauf l'uuid, œuf corse) :

Code:

---

$ vboximg-mount --list --vm=6ca0dfc3-ef4f-4ec8-92ae-0b79d810d8a9

---

ne trouve rien, ne dit rien, rend le prompt...

Code:

---

1 2 3 4 5 6 7

$ vboximg-mount --list --vm 6ca0dfc3-ef4f-4ec8-92ae-0b79d810d8a9 ----------------------------------------------------------------- VM: MX UUID: 6ca0dfc3-ef4f-4ec8-92ae-0b79d810d8a9 Image: MXdisk.vdi UUID: ee97ae36-b780-4481-bda9-1e6126a2861f

---

Notez l'espace après --vm.
Je vais poster ça chez Oracle, stay tuned.
EDIT : https://www.virtualbox.org//ticket/22054