| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
 Re: [Xen-users] xl create unable to connect to console, 4.4.1-rc1 build from source
 
 | On 07/25/2014 02:10 AM, Ian Campbell
      wrote:
 
      Here's my full _paths.h:If you pass --libdir= then since this changes the install dir for these
tools it ought to be changing the path where other bits of the toolstack
try to exec them as well.
The code in libxl which launches xenconsole is
tools/libxl/libxl.c:libxl_console_exec():
    char *p = libxl__sprintf(gc, "%s/xenconsole", libxl__private_bindir_path());
and tools/libxl/libxl_paths.c:libxl__private_bindir_path() is just:
        const char *libxl__private_bindir_path(void)
        {
            return PRIVATE_BINDIR;
        }
and tools/libxl/_paths.h has
        #define PRIVATE_BINDIR "/usr/local/lib/xen/bin"
tools/xenconsole/Makefile installs the client into PRIVATE_BINDIR too.
The _paths.h one is autogenerated based (supposedly) on ./configure's
libdir. Can you check what you see there? 
 #define SBINDIR "/usr/local/sbin"
 #define BINDIR "/usr/local/bin"
 #define LIBEXEC "/usr/local/lib/xen/bin"
 #define LIBDIR "/usr/lib64"
 #define SHAREDIR "/usr/local/share"
 #define PRIVATE_BINDIR "/usr/lib64/xen/bin"
 #define XENFIRMWAREDIR "/usr/local/lib/xen/boot"
 #define XEN_CONFIG_DIR "/etc/xen"
 #define XEN_SCRIPT_DIR "/etc/xen/scripts"
 #define XEN_LOCK_DIR "/var/lock"
 #define XEN_RUN_DIR "/var/run/xen"
 #define XEN_PAGING_DIR "/var/lib/xen/xenpaging"
 
 So, PRIVATE_BINDIR is set correctly for libdir=/usr/lib64, so I'm
    not sure why xl is still looking for it in /usr/lib.  I mis-spoke
    previously when I said I hadn't passed any parameters to .configure
    the first time, I used /usr/lib.  So, it may be possible that I
    didn't clean/uninstall the previous installation correctly.  I just
    used make uninstall, but I also believe I was running the hypervisor
    when I did the uninstall which I could see being a problem...
 
 
 
      In my install attempts they are installed in
${prefix}/lib64/python/site-packages, independent from --libdir=. The
target dir is provided by the system python. Maybe the used target dir
is not in systems python search path? If so, that would be a bug in that
python installation. I'm not sure how to determine the system's Python search path (echo
    $PYTHONPATH doesn't show a path, not sure if that's it).  I do have
    Python libs in /usr/lib64/python2.7/site-packages, and pygrub was
    looking there, but the Xen Python libs weren't installed there
    during the build process.  I'll try make rpmball and see what I can
    determine from the output.
 
 My guess is I'm experiencing issues with previous installs not being
    uninstalled properly and causing problems.  There are still a lot of
    xen related files in /usr/lib, which I think should have been
    removed with make uninstall.  I will try to clean the other
    installations I did and use only --libdir=/usr/lib64 and see if that
    helps.  I will keep you posted on my results, and thanks for the
    help.
 
 David
 
 
 | 
 _______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users 
 |