search for: disklib

...http://syslinux.zytor.com/commit/9c8db7560e2dc83d1191bb2f90b4d4d0ae3d37d6 > Author: Michal Soltys <soltys at ziu.info> > AuthorDate: Wed, 13 Oct 2010 10:57:36 +0200 > Committer: Michal Soltys <soltys at ziu.info> > CommitDate: Wed, 13 Oct 2010 10:57:36 +0200 > > disklib: make CHS calculation match core/fs/diskio.c > > Signed-off-by: Michal Soltys <soltys at ziu.info> > I note that this code still: a) duplicates the code between read and write, and b) doesn't check for CHS overflow. This is particularly critical for write, obviously, since w...

Add detection code for "MS-DOS 3.30 through Windows 95 (A)" MBR to disklib. Signed-off-by: Gert Hulselmans <gerth at zytor.com> --- com32/gpllib/disk/mbrs.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/com32/gpllib/disk/mbrs.c b/com32/gpllib/disk/mbrs.c index 77e4180..37309e1 100644 --- a/com32/gpllib/disk/mbrs.c +++ b/com32/gpllib/d...

...ing it in the load() method. This is very early and in particular means that the only possible way to configure where we find the library is through environment variables and not through config parameters. Also it's not necessary as we don't call any functions from the library (such as VixDiskLib_InitEx) until config_complete. This change is neutral refactoring as currently we _do_ configure the location through an environment variable (LD_LIBRARY_PATH). --- plugins/vddk/vddk.c | 100 ++++++++++++++++++++++---------------------- 1 file changed, 51 insertions(+), 49 deletions(-) diff --gi...

Unfortunately this series doesn't work with the real VDDK library :-( I see: nbdkit: debug: vddk: config_complete nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 Then a little bit later during VDDK initialization it fails with: nbdkit: debug: VixDiskLib: Could not load default plugins from /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so: Cannot open library: libcrypto.so.1.0.2: cannot open shared object fil...

...RY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and that breaks lots of ordinary utilities on their system. (2) nbdkit vddk --run subcommand inherits the LD_LIBRARY_PATH environment variable from nbdkit, and common commands such as 'qemu-img' break, relying on complex workarounds like saving and restoring the original LD_LIBRAR...

...tp://syslinux.zytor.com/archives/2010-September/015342.html). Thanks, The following changes since commit 6f438cf6d03e45d875b510559246573954e43218: Arwin Vosselman (1): Fix missing option -s in libinstaller are available in the git repository at: git://github.com/pierre/syslinux.git disklib-fixes Pierre-Alexandre Meyer (2): gpllib: disk: make write functions actually work gpllib: disk: cap the number of sectors per write com32/gpllib/disk/write.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) -- Pierre-Alexandre Meyer http://pub.mouraf.org/blog

...rary. Setting this > always causes problems because VDDK comes bundled with broken > replacements for system libraries, such as libcrypto.so and > libstdc++.so. Two problems this causes which we have seen in the real > world: > > (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and > that breaks lots of ordinary utilities on their system. > > (2) nbdkit vddk --run subcommand inherits the LD_LIBRARY_PATH > environment variable from nbdkit, and common commands such as > 'qemu-img' break, relying on complex workarounds like saving and > re...

Add detection code for "FreeDOS (eXtended FDisk)" MBR to disklib. Signed-off-by: Gert Hulselmans <gerth at zytor.com> --- com32/gpllib/disk/mbrs.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/com32/gpllib/disk/mbrs.c b/com32/gpllib/disk/mbrs.c index 37309e1..6150fcf 100644 --- a/com32/gpllib/disk/mbrs.c +++ b/com32/gpllib/d...

>From the earlier patches - that simple fix for indexes not counting non-data partitions in gpt and mbr cases. Patches don't touch any other parts of the code at this stage - bigger stuff later for disklib as we agreed - but this is potentially useful right now. Michal Soltys (1): chain.c: fix public index value in mbr and gpt iterators

On 2/17/20 12:17 PM, Richard W.M. Jones wrote: > Unfortunately this series doesn't work with the real VDDK library :-( > > I see: > > nbdkit: debug: vddk: config_complete > nbdkit: debug: dlopen shim prefix set to /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64 > > Then a little bit later during VDDK initialization it fails with: > > nbdkit: debug: VixDiskLib: Could not load default plugins from /home/rjones/tmp/vddk-6.7.3/vmware-vix-disklib-distrib/lib64/libdiskLibPlugin.so: Cannot open library: libcrypto.so.1.0.2: cannot o...

...h/use the VMs. To that end, I've been trying to launch the VMs via the VMware VIX API by UNC path (not mapped drive). The trouble is that when accessed via UNC path, it seems that VIX can't properly determine that the fileserver supports large files and refuses to open the VM. VIX Error: DISKLIB-SPARSE: "\\VMWAREFS.org.net\images\windows_7_ultimate_x64_en\Windows_7_x64-000003.vmdk" : failed to open (36872): Underlying file system does not support files that large. DISKLIB-LINK : "\\VMWAREFS.org.net\images\\windows_7_ultimate_x64_en\Windows_7_x64-000003.vmdk" : failed t...

I couldn't get this to work in the end. This is the latest non-working version. This email documents what doesn't work for the permanent record. The central problem is that VDDK InitEx() appears to dlopen() various of its own plugins. Although I wasn't able to capture exactly what dlopen() command it is running, the plugins cannot be loaded because they rely on the recompiled

...d I was wondering: would it be acceptable to change it from "replace existing chain.c32" to "provide alternative altchain.c32" ? The rationale for such request: - chaindev resides in its own directory under com32, so there're no conflicts possible - the dependency on disklib is trivial to solve - just move disklib.{c,h} (which is de-facto used only by chain, and consists of functions moved outside original chain.c) to the chaindev subdir; any further swaps (e.g. towards core disk functions) / backporting would be a trivial matter too - the code would be...

...RY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and that breaks lots of ordinary utilities on their system. (2) nbdkit vddk --run subcommand inherits the LD_LIBRARY_PATH environment variable from nbdkit, and common commands such as 'qemu-img' break, relying on complex workarounds like saving and restoring the original LD_LIBRAR...

...RY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and that breaks lots of ordinary utilities on their system. (2) nbdkit vddk --run subcommand inherits the LD_LIBRARY_PATH environment variable from nbdkit, and common commands such as 'qemu-img' break, relying on complex workarounds like saving and restoring the original LD_LIBRAR...

...couple of implicit questions here: (1) Can VDDK (actually, VMware server) handle two connections to the same disk image, both open for reading and with different flags? The answer to that is yes. Running these two sets of commands in parallel works fine for me: $ LD_LIBRARY_PATH=vddk/vmware-vix-disklib-distrib/lib64 \ ./nbdkit vddk file="[datastore1] Fedora 28/Fedora 28.vmdk" \ libdir=vddk/vmware-vix-disklib-distrib \ server=vmware user=root password=- \ thumbprint=xx vm=moref=3 \ -fv -r -p 10809 single-link=true & $...

As I've spent really too long today investigating this, I want to document this in a public email, even though there's nothing really that interesting here. One thing you find from search for VDD 6.7 / VixDiskLib_QueryAllocatedBlocks issues with Google is that we must be one of the very few users out there. And the other thing is that it's quite broken. All testing was done using two baremetal servers connected back to back through a gigabit ethernet switch. I used upstream qemu and nbdkit from git a...

On Fri, Apr 12, 2019 at 03:52:58PM +0200, Martin Kletzander wrote: > On Thu, Apr 11, 2019 at 06:55:55PM +0100, Richard W.M. Jones wrote: > >This seems to be a bug in VDDK, possibly connected with the fact that > >we fork after initializing VDDK but before doing the > >VixDiskLib_ConnectEx. I suspect it's something to do with the PID > >changing. > > > >It would be fair to deduct 2 minutes from all timings below. > > > > Is the PID changed because you want to exec from the parent (where > the init is done), but all the other calls are d...

Differences from v4: Patch 1 is simplified: I realized that since we already use -rdynamic for nbdkit (after all, we WANT our dlopen()d plugins to be able to call our nbdkit_* exports), it is only a matter of adding dlopen to the set of symbols that we export. With that done, there is no separate shared library needed; our dlopen shim is now part of nbdkit proper, and we don't have to tweak

--- configure.ac | 5 +++++ plugins/vddk/vddk.c | 4 ++++ 2 files changed, 9 insertions(+) diff --git a/configure.ac b/configure.ac index d71f06e4..57626a76 100644 --- a/configure.ac +++ b/configure.ac @@ -321,6 +321,11 @@ AC_SEARCH_LIBS([dlsym], [dl dld], [ ]) LIBS="$old_LIBS" +old_LIBS="$LIBS" +LIBS="$LIBS -ldl" +AC_CHECK_FUNCS([dlmopen])