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

[ppr-kut]

Yes, that is of course an option and is probably also what I will do. However, copying to a separate server is not something we do on a regular basis but rather as a last resort. I wanted to talk to the upstream developers first before going that way.

[Hubbitus]

Guys, it is known and already fixed bug in wget - https://savannah.gnu.org/bugs/index.php?22537 . So, it is not related nor to phpBB forum nor vbox mount.
In wget 1.12.1 all should work properly.

[ppr-kut]

ah, cool
All is good then

[jpatton]

Uff... I'm having one of those moments where I feel like I'm missing something completely obvious, but my own troubleshooting is going nowhere. I'm having trouble with the compile. I used svn checkout to get the headers (I'm using PUEL). I'm running Fedora 12 (x86_64) with VBox 3.1.4; gcc 4.4.3; and fuse, fuse-devel, and fuse-libs 2.8.1. I should have all of the essential build tools. VBox kernel module has been built for the current kernel.

Code: Select all   Expand viewCollapse view

[root@ svn_vbox]# uname -r
2.6.31.12-174.2.22.fc12.x86_64
[root@ svn_vbox]# ls
iprt  Makefile.kmk  VBox  vdbuild.sh  vdfuse-v60.c
[root@ svn_vbox]# ./vdbuild.sh . vdfuse-v60.c
vdfuse-v60.c: In function ‘VD_read’:
vdfuse-v60.c:558: warning: implicit declaration of function ‘VBOX_SUCCESS’
/tmp/ccd3Rdvj.o: In function `VD_read':
vdfuse-v60.c:(.text+0x12c9): undefined reference to `VBOX_SUCCESS'
/tmp/ccd3Rdvj.o: In function `VD_write':
vdfuse-v60.c:(.text+0x151a): undefined reference to `VBOX_SUCCESS'
collect2: ld returned 1 exit status
strip: 'vdfuse-v60': No such file
Compile Failed!

Because I'm that daring (i.e. don't have a clue what I'm doing , I'm not a C/C++/Java guy), I've tried changing vdfuse-v60.c to use VINF_SUCCESS since that's the only other *_SUCCESS "thing" I could find in VBox/ or iprt/, but that didn't help.

[h2o]

It seems like the vbox in trunk removed the VBOX_SUCCESS macro; try replacing VBOX_SUCCESS with RT_SUCCESS.

[jpatton]

It seems like the vbox in trunk removed the VBOX_SUCCESS macro; try replacing VBOX_SUCCESS with RT_SUCCESS.

Heh, so I wasn't so far off looking around for SUCCESS in the VBox code. Should've looked harder, I guess! Compiled ok now, thanks!

[h2o]

It seems like the vbox in trunk removed the VBOX_SUCCESS macro; try replacing VBOX_SUCCESS with RT_SUCCESS.

Because of the change in the trunk source code (the removal of the VBOX_SUCCESS macro), vdfuse-v70, which includes the minor fix, is released.

[jpatton]

Well, it looks like I spoke too soon. The compile goes fine, but now I get seg faults when I try to run it.

Code: Select all   Expand viewCollapse view

[root@ svn_vbox]# ./vdfuse-v70 -r -a -v -f /virtual/WinXp.vdi /virtual/WinVista
disktype is VDI
Segmentation fault

And the reason why I haven't posted this sooner is that I can't find a core dump anywhere. At first it was an issue with abrt intercepting, realizing that vdfuse isn't part of a known package, then tossing away the dump since it had no idea what to do with it. I've since stopped the abrt service, but still no core file to be found. The only hint I get in messages log is:

Code: Select all   Expand viewCollapse view

Feb 24 13:59:42 kernel: vdfuse-v70[32401]: segfault at 605018 ip 0000000000401911 sp 00007fffca9636f0 error 6 in vdfuse-v70[400000+4000]

Any ideas?

[h2o]

thats rather strange, recompile vdfuse after adding the -ggdb option into vdbuild, turn on core dumps by running 'ulimit -c unlimited' in your shell, then run the program and get a core dump. Use gdb to get a backtrace; that will be very helpful.

[jpatton]

Alright, I'm really confused now. Let's see if I can put what I did step-by-step.
1. I added -ggdb to line 54 in vdbuild.sh (or .txt or whatever) and recompiled
2. I ran (after fixing to get core dumps):

Code: Select all   Expand viewCollapse view

[root@ svn_vbox]# ./vdfuse-v70 -v -r -a -f /virtual/WinXp.vdi /virtual/WinVista3
disktype is VDI
Segmentation fault (core dumped)

3. I ran "gdb vdfuse-70" and once it started, did/got the following:

Code: Select all   Expand viewCollapse view

(gdb) run -d -v -r -a -f /virtual/WinXp.vdi /virtual/WinVista3
Starting program: /home/jpatton/svn_vbox/vdfuse-v70 -d -v -r -a -f /virtual/WinXp.vdi /virtual/WinVista3
[Thread debugging using libthread_db enabled]
disktype is VDI
Partition       Size           Offset
=========       ====           ======

Partition1      1048576        375807541248


Detaching after fork from child process 8487.
FUSE library version: 2.8.1
nullpath_ok: 0
[New Thread 0x7ffff5a7b710 (LWP 8488)]
[New Thread 0x7ffff5058710 (LWP 8489)]
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56
INIT: 7.12
flags=0x0000007b
max_readahead=0x00020000
   INIT: 7.12
   flags=0x00000011
   max_readahead=0x00020000
   max_write=0x00020000
   unique: 1, success, outsize: 40

And in /virtual/WinVista3 I have:

Code: Select all   Expand viewCollapse view

[root@ virtual]# ll /virtual/WinVista3/
total 700G
dr-xr-xr-- 1 jpatton jpatton      0 2009-09-30 15:41 .
drwxr-xr-x 9 jpatton vboxusers 4.0K 2010-02-25 14:48 ..
-r--r--r-- 1 jpatton jpatton   350G 2009-09-30 15:41 EntireDisk
-r--r--r-- 1 jpatton jpatton   350G 2009-09-30 15:41 Partition1

Which is what I want, right?
4. Now, the reason why I have WinVista3/ is because in trying to figure out gdb, I did more-or-less the same steps above, but when I killed gdb (Ctrl-C), it left these in my /virtual/ directory:

Code: Select all   Expand viewCollapse view

[root@ virtual]# ll
ls: cannot access WinVista2: Transport endpoint is not connected
ls: cannot access WinVista: Transport endpoint is not connected
...
d?????????  ? ?       ?                ?                ? WinVista
d?????????  ? ?       ?                ?                ? WinVista2
dr-xr-xr--  1 jpatton jpatton          0 2009-09-30 15:41 WinVista3

Which I think is FUSE being upset.

I haven't tried doing the loopback with the copy of vdfuse running inside gdb (I'm kind of afraid to). Hate to be a pain, h2o, and I really appreciate your help... I'll wait to see what you would like for me to do next.

Edit to add: If I try to use WinVista or WinVista2 as mountpoints now, it says permission denied in gdb. I can't rmdir/rm -rf them either, it gives the same "Transport endpoint is not connected" error.

Another edit: I can umount them to get control back. Also, info keeps flowing in gdb, I think just in response to ls commands in /virtual.

[h2o]

I can't really tell the source of the problem from that information. Run gdb on the core dump (gdb <path to vdfuse> <path to core dump>) and type bt to get a backtrace, it would be extremely helpful if you could do that, thanks!

[jpatton]

Cut out a bunch of garbage about reading/loading symbols. I think this what you want:

Code: Select all   Expand viewCollapse view

Core was generated by `./vdfuse-v70 -d -v -r -a -f /virtual/WinXp.vdi /virtual/WinVista'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000401911 in fwrite () at iofwrite.c:37
37      {

That's it, as far as I can tell.

Edit, oops, forgot a step. Here's some more:

Code: Select all   Expand viewCollapse view

(gdb) bt
#0  0x0000000000401911 in fwrite () at iofwrite.c:37
#1  0x00000000004014ae in fwrite () at iofwrite.c:37
#2  0x0000003f8121eb1d in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>,
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=<value optimized out>) at libc-start.c:226
#3  0x0000000000400fa9 in fwrite () at iofwrite.c:37
#4  0x00007fff4f3cdf58 in ?? ()
#5  0x000000000000001c in ?? ()
#6  0x0000000000000008 in ?? ()
#7  0x00007fff4f3cfd3f in ?? ()
#8  0x00007fff4f3cfd4c in ?? ()
#9  0x00007fff4f3cfd4f in ?? ()
#10 0x00007fff4f3cfd52 in ?? ()
#11 0x00007fff4f3cfd55 in ?? ()
#12 0x00007fff4f3cfd58 in ?? ()
#13 0x00007fff4f3cfd5b in ?? ()
#14 0x00007fff4f3cfd6e in ?? ()
#15 0x0000000000000000 in ?? ()

[h2o]

hmm it seems like you built an optimized version of vdfuse, can you please redo the backtracing steps on a vdfuse compiled with the flags "-ggdb -O0" ? Thanks! And also, what system are you on, and what version of vbox are you using?

[h2o]

New release! Get it on the howto page at viewtopic.php?f=7&t=17574

Since I can't seem to find a way to access the machine data from C, I wrote a python wrapper for vdfuse called vdautomount which uses the virtualbox python api to get information about snapshots in order to mount disks with snapshots. Enjoy!

[nordlichtHH]

Hi

I try to compile this tool on Fedora 13 x64

I always get following error:

Code: Select all   Expand viewCollapse view

# ./vdbuild.sh vbox/include/ vdfuse.c
/usr/bin/ld: /tmp/ccJ1yKvw.o: undefined reference to symbol 'VDOpen'
/usr/bin/ld: note: 'VDOpen' is defined in DSO /usr/lib/virtualbox/VBoxDDU.so so try adding it to the linker command line
/usr/lib/virtualbox/VBoxDDU.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
strip: 'vdfuse': No such file
Compile Failed!


What is wrong?
I installed the libs and devel files, and downloaded the includes via svn.



Thank you
Chris