Re: [Xen-users] xl create unable to connect to console, 4.4.1-rc1 build from source

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-07-24 at 16:25 -0600, David A. Van Arnem wrote:

> Just as a followup (with solution!) --
> 
> I ran into the problem again on a subsequent build of Xen, and you were 
> correct in your assumption that xl was looking for xenconsole in the 
> wrong place, which was easily determined with strace.  Xl was looking 
> for it in /usr/lib/xen/bin, but it had installed to /usr/lib64/xen/bin 
> (I used --libdir=/usr/lib64 as a ./configure parameter this time, last 
> time I used no parameters so I assume it was placed in something like 
> /usr/local/lib/bin).  Creating a symbolic link 
> /usr/lib/xen/bin/xenconsole -> /usr/lib64/xen/bin/xenconsole solved the 
> problem.

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?

As an experiment I did:
        ./configure --libdir=/foo/bar
        make -C tools/libxl _paths.h
and as expected I see:
        #define PRIVATE_BINDIR "/foo/bar/xen/bin"
        
that was with Xen unstable though.

I know Olaf (CCd) was improving autoconf vs. libdir etc behaviour at one
point but I thought that was all in and I don't see anything since 4.4
which looks related.

> I also ran into a similar problem with pygrub; the python tools were 
> installed to /usr/local/lib64/python2.7/site-packages... even with 
> --libdir=/usr/lib64.  When I tried to start up the guest using pygrub, I 
> got an error about it not finding the bootloader and the reason is as 
> documented here: 
> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source#Python_Prefix_and_Module_Layout.
>  
> I couldn't determine a fix for Fedora with configure options, so I 
> created symbolic links in /usr/lib64/python2.7/site-packages to point to 
> the /usr/local/lib64/python2.7/site-packages versions and was able to 
> start up the guest.

I thought that the Python prefix issue was Debian/Ubuntu specific, so
I'm not sure what to suggest for Fedora. Perhaps someone on list has an
idea.

Are you using --prefix=/usr as well as --libdir=/usr/lib64? I think
Python might install into the site dir under $prefix, which despite
containing "lib" in the string isn't controlled by libdir (the subtree
under $prefix is part of the Python build configuration AIUI).

Ian.

> Even though my problem is solved for now, is there a way to install the 
> Python tools directly to the libdir?  Is there a way to tell xl to look 
> for xenconsole in the libdir?  Appending the locations to PATH didn't 
> seem to fix the problem, and only symbolic links worked.
> 



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users