Discuss: Mount any VBox-compatible disk image on the host

[h2o]

The "" => "vdi" patch should be part of the file in the main howto page; can you fix that, Terry?

[burghj]

Unfortunately I still have no success with this vdfuse program.

Situtation as of today:
Linux Kernel 2.6.30
glibc 2.7
gcc 4.4.1
fuse 2.8.0
Vbox 3.04

The original vdfuse-v50.c from May 2009 kept producing the error message:
fuse: mount failed: Invalid argument

With the patch mentioned a few times here in the forum
- fuse_opt_add_arg (&fuseArgs, "");
+ fuse_opt_add_arg (&fuseArgs, "vdi");
this message disappeared.

Now, when I do
vdfuse -v -g -f /virtwin/Windows2000.vdi /mnt/vdi
I get (only?):

Partition Size Offset
========= ==== ======
Partition1 32256 22002591744

and any process which tries to access the mountpoint /mnt/vdi hangs forever.
Not interruptible, not killable, not even with kill -9

The numbers above look also very strange, the vdi-file has 14GB and contains a single primary NTFS partition with a Windows 2000.

JRO

[h2o]

Can you provide a backtrace of the program?

[burghj]

Hi h2o,

You are the program author of the vdfuse program, right?

Can you provide a backtrace of the program?

You mean a backtrace of vdfuse after startup?

An strace of the "other" programs show these usually hang in a "fstat".

Meanwhile I have also figured out how to use some of the example programs in the fuse distribution and they show the same behaviour, so it looks like I have a more general problem on the fuse side of things.

I have found another thread for it in the fuse mailing list, but no solution yet. I have just sent a followup there, let's see if the people there have an idea.

JRO

[h2o]

Try either:

building a debug version of vdfuse and running it with gdb, or

run strace -f vdfuse

Hopefully that should find the source of the problem.

[burghj]

Try either:
building a debug version of vdfuse and running it with gdb, or
run strace -f vdfuse

OK, will try both.
But I have not much time during the week for more experiments, so I think, there will be no interesting results before next weekend.

JRO

[burghj]

Try either:
building a debug version of vdfuse and running it with gdb, or
run strace -f vdfuse

OK, will try both.
But I have not much time during the week for more experiments, so I think, there will be no interesting results before next weekend.

JRO

So now I have a debug and a strace output from vdfuse. But I fear that it will not help much.

I think there are still two different issues:
The partition list looks strange as if the vdi file isn't read correctly.
Some deeper confusion happens in the fuse system.

I also got no response to my fuse questions in the fuse maling list.

JRO

[pasnox]

Hi,

I successfully built and user the fusedriver, homewhere, I see no way to deactivate the driver for a specific vdi file ?

If i use vdfuse -f XXX.vdi /mnt/vdi, then i can not cancel this process and need reboot to remove the EntireDisk / Partition1.
Please give me informations on how i could do it thanks.

[gixmi]

yes,I can't mount the vdi image.

[h2o]

Hi,

I successfully built and user the fusedriver, homewhere, I see no way to deactivate the driver for a specific vdi file ?

If i use vdfuse -f XXX.vdi /mnt/vdi, then i can not cancel this process and need reboot to remove the EntireDisk / Partition1.
Please give me informations on how i could do it thanks.

Try "killall vdfuse" or "fusermount -u <mountpoint>" as root.

[burghj]

I think there are still two different issues:
The partition list looks strange as if the vdi file isn't read correctly.
Some deeper confusion happens in the fuse system.

I also got no response to my fuse questions in the fuse maling list.

JRO

Meanwhile my questions on the fuse mailing-list got some attention, albeit no real solution yet.
But as a side effect of the tests recommended there, I found out that it has something to do with threading. The fuse hangs happen only in the default multi-threading mode. When I run the fuse code single-threaded everything works ok.
So as a workaround I have added the appropriate parameter (-s) to the internal fuse-mount parameters in vdfuse.c and can now fuse-mount my vdi as expected and everything looks as described. I can loop-mount my partition and see all my files in the virtual disk.
I don't know the real importance of the multi-threaded mode, but for the sole purpose of accessing some files in the virtual disk the single-threaded mode seems sufficient.

JRO

[h2o]

I think that the virtualbox disk library might not be thread-safe. We seem to have quite a few inportant patches posted on this forum so far, but none of them are put onto the main vdfuse page.

1. use "vdi" instead of an empty string for the mount parameter
2. use single threading, there's really no advantage in multi-threading

[cookiecaper]

This mounts with the patch suggested by jagdpanther on an up-to-date Arch Linux system (kernel 2.6.31), but it seems to be only read-only. The reason I needed this was so I could transfer data faster between the host and guest than one can do wth \\vboxsvr. At this rate, it's going to take more than 2 hours to transfer the extracted whole of several gigabyte 7z archive from a mounted network drive or about the same to extract it within the virtualized OS Itself. I'm hoping that the FUSE'd implementation would be faster than this, but it doesn't seem to mount correctly. I didn't run ./vdfuse with -r and /etc/mtab shows that the thing is mounted rw.

The actual error I get when I try to touch, cp, or rm a file is Operation Not Permitted or Permission Denied, though I am root. Perhaps it's a different problem? chmod doesn't help.

[penteki]

I wasn't able to use this mountig tool:
root@most:/tmp/vdimount# ./vdfuse-v50 -f hdd.vdi /tmp/vdimount/mnt
fuse: mount failed: Invalid argument
root@most:/tmp/vdimount# file hdd.vdi
hdd.vdi: data
root@most:/tmp/vdimount# file /tmp/vdimount/mnt
/tmp/vdimount/mnt: directory
root@most:/tmp/vdimount# ls -a mnt
. ..

[h2o]

We should seriously consider applying the patches to the vdfuse on the main howto page. It hasn't been updated for months, and people who could be successfully accessing their disks cannot unless they look at the discussion topic. If vdfuse is going to be stickied, then it better work.