Re: [Xen-users] Wrong version of xen-utils after building xen from source causes xen to exit with error

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 14/09/16 15:40, Brett Stahlman wrote:
> On Wed, Sep 14, 2016 at 5:32 AM, George Dunlap <george.dunlap@xxxxxxxxxx> 
> wrote:
>> On Thu, Sep 8, 2016 at 8:43 PM, Brett Stahlman <brettstahlman@xxxxxxxxx> 
>> wrote:
>>> ** Update **
>>> Following recommendations on a page dealing with the installation of
>>> multiple versions of Xen side-by-side, I re-ran configure like this...
>>>
>>> configure --prefix=/home/bstahlman/install/xen \
>>> --sysconfdir=/home/bstahlman/install/xen/etc \
>>> --enable-rpath
>>>
>>> ...and was then able to run xl by specifying the path to the sbin/xl
>>> under the directory specified with --prefix.
>>>
>>> Aside: I also had to add this line to /etc/fstab...
>>>
>>> none /proc/xen xenfs defaults 0 0
>>>
>>> ...and I have to start the xencommons service manually like so:
>>>
>>> sudo ~/install/xen/etc/init.d/xencommons start
>>>
>>> But now I'm able to run xen-create-image to create an ubuntu guest:
>>> sudo xen-create-image --hostname ubuntu-test --dhcp --dir
>>> ~/xen/images/ --size=4G --role=udev
>>>
>>> (Note that I had to use the script installed by package manager, as I
>>> don't see a version of xen-create-image under my custom install
>>> directory). Strangely, xen-create-image gives what looks like an
>>> error...
>>>
>>> ERROR: Can't find version 4.8 of xen utils, bailing out!
>>>
>>> ...but the command appears to work, and I'm able to start the guest by
>>> running xl on the resulting config file:
>>> sudo ./install/xen/sbin/xl create /etc/xen/ubuntu-test.cfg -c
>>>
>>> The problem occurs when I attempt to create an HVM guest:
>>> $ sudo ~/install/xen/sbin/xl create ~/cfg/xen/xl-ubuntu-hvmloader.cfg -c
>>> Parsing config from /home/bstahlman/cfg/xen/xl-ubuntu-hvmloader.cfg
>>> libxl: error: libxl_create.c:562:libxl__domain_make: domain creation
>>> fail: Invalid argument
>>> libxl: error: libxl_create.c:904:initiate_domain_create: cannot make 
>>> domain: -3
>>>
>>> I initially assumed the error must be due to the options in the config
>>> file (pasted at the end), but when I ran the xl create command in gdb,
>>> I discovered that the option parsing was successful: the error occurs
>>> because the ioctl() call in the following function returns -1:
>>
>> ioctl returns -1 on failure and then sets the global variable 'errno'.
>> If you see above, libxl itself gives you the appropriate
>> interpretation of errno -- "Invalid argument".
>>
>> Given that your config file doesn't seem to have anything strange in
>> it, I would suspect that you're still having some sort of issue where
>> you're running the wrong set of tools (or perhaps the wrong library)
>> for the Xen version that you're running.
>>
>> As an aside, another useful trick if you want to build from source is
>> to use "make debball".  That will create a .deb package you can
>> install and remove easily.  The key thing is this debball is NOT A
>> COMPLETE PACKAGE -- you still need to run ldconfig and everything
>> manually, just as you would if you'd run "make install".  It's just a
>> lot easier to remove and/or update than "make install", since dpkg
>> keeps track of all the files for you.
> 
> Hmm... I never ran ldconfig after the `make install', so perhaps that
> could have been the issue?

Potentially; but normally if that's the issue then running the resulting
binary will give you linking errors.

If you had previously built the full Debian package with Xen 4.8, it's
*possible* that you had the old libraries in your ld.so.cache, so that
stuff worked even without running ldconfig.

You could try running "ldd /path/to/your/new/xl" to verify which version
of the library you're actually using when running it.

> Just yesterday, I was able to build the package obtained with `apt-get
> source' using the following command:
> 
> sudo dpkg-buildpackage -us -uc
> 
> But this is a bit tedious because each time I want to tweak a file
> (e.g., to put in some debug printf's), I have to run the debian
> "quilt" utility to make a patch. I would prefer to just modify source
> and rebuild. Wasn't aware of the "debball" target. Also, didn't
> realize it was necessary to run ldconfig after installing a package
> with dpkg. What's the standard way to run ldconfig in this case? If I
> built package without using configure to change default paths, which
> directory(s) need to be passed to ldconfig (or are the defaults
> sufficient)?

Fully-functional packages do the ldconfig for you (along with dependency
tracking, starting system services, &c).  The output of
dpkg-buildpackage will be a fully-functional package with all those bits
handled already.

The reason the "debball" makefile target is called that is because it's
essentially just a tarball which uses dpkg for file-tracking, not a
fully functional package.  We don't want to be burdened with doing all
the work of maintaining a package -- our downstreams (Debian, Fedora,
&c) are doing a good job of that and there's no need to duplicate their
work.  We just want an easy way to install and remove the files while
doing development, hence "debball" (and the corresponding "rpmball").

> When I built with dkpg-buildpackage, I got a handful of .debs: e.g.,
> xen-hypervisor, xenstore, xen-utils, xen-system. Would it be best to
> run `dpkg -i' on these files individually, or drop them all in a
> directory and run dpkg on that? (I haven't used dpkg standalone much,
> and want to be sure the dependencies are handled properly.)

dpkg will handle dependencies in the sense that it will refuse to
install something if there are dependencies that aren't there.  So
normally installing xen-*.deb is the best thing.

But the output of "make debball" has *no* dependency tracking -- it is
the exact equivalent of "tar xfz [blah]", but easier to remove.  :-)

 -George

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