Xen users - Oct 2013 - Install Xen 4.4-Unstable

Dear people with higher intelligence than me,

I''m trying to install xen 4.4-Unstable from source. I used this wiki 
page : http://wiki.xen.org/wiki/Compiling_Xen_From_Source.

Steps I took :

1) Check-out from git (master)
2) ./configure
3) make world
4) make install
5) /sbin/ldconifg
6) Reboot into xen

I''m currently running an up to date version of Fedora 19.

After rebooting I started with ''xen-dmesg'' under root, just to
see if I
had a working iommu right out of the box, however it appears I don''t 
even have xl:

[root@Hypervisor john]# xl dmesg
bash: xl: command not found

I backed out of root and ran the same thing, and got this result :

[john@Hypervisor ~]$ xl dmesg
xl: error while loading shared libraries: libxlutil.so.4.3: cannot open 
shared object file: No such file or directory

I''m certain I simply missed one step, but cannot for the life of me 
figure out what it is.
Thanks for your time and expertise,
- John


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

On 10/24/2013 08:24 PM, John Wargo wrote:
> Dear people with higher intelligence than me,
>
> I''m trying to install xen 4.4-Unstable from source. I used this
wiki
> page : http://wiki.xen.org/wiki/Compiling_Xen_From_Source.
>
> Steps I took :
>
> 1) Check-out from git (master)
> 2) ./configure
> 3) make world
> 4) make install
> 5) /sbin/ldconifg
> 6) Reboot into xen
>
> I''m currently running an up to date version of Fedora 19.
>
> After rebooting I started with ''xen-dmesg'' under root,
just to see if
> I had a working iommu right out of the box, however it appears I
don''t
> even have xl:
>
> [root@Hypervisor john]# xl dmesg
> bash: xl: command not found
>
> I backed out of root and ran the same thing, and got this result :
>
> [john@Hypervisor ~]$ xl dmesg
> xl: error while loading shared libraries: libxlutil.so.4.3: cannot 
> open shared object file: No such file or directory
>
> I''m certain I simply missed one step, but cannot for the life of
me
> figure out what it is.
> Thanks for your time and expertise,
> - John
Further testing shows this to be true for all package types. Regardless 
of if I''m installing xen 4.1, 4.2, 4.3-stable, 4.3-unstable, or 4.4, 
this happens every time, so now I know that I am indeed missing something.

Any suggestions?
-John


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

On Thu, Oct 24, 2013 at 08:24:06PM -0500, John Wargo
wrote:
> Dear people with higher intelligence than me,
> 
> I''m trying to install xen 4.4-Unstable from source. I used this
wiki
> page : http://wiki.xen.org/wiki/Compiling_Xen_From_Source.
> 
> Steps I took :
> 
> 1) Check-out from git (master)
> 2) ./configure
> 3) make world
> 4) make install
> 5) /sbin/ldconifg
> 6) Reboot into xen
> 
Just asking, do you have the necessary permission to run ''make
install''?
You need to be root.
> I''m currently running an up to date version of Fedora 19.
> 
Is there any special requirement that prevents you from using the
pre-package Xen in Fedora?
> After rebooting I started with ''xen-dmesg'' under root,
just to see
> if I had a working iommu right out of the box, however it appears I
> don''t even have xl:
> 
> [root@Hypervisor john]# xl dmesg
> bash: xl: command not found
> 
> I backed out of root and ran the same thing, and got this result :
> 
> [john@Hypervisor ~]$ xl dmesg
> xl: error while loading shared libraries: libxlutil.so.4.3: cannot
> open shared object file: No such file or directory
> 
What does "ldd `which xl`" (without quote) show?

Wei.
> I''m certain I simply missed one step, but cannot for the life of
me
> figure out what it is.
> Thanks for your time and expertise,
> - John
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users

>________________________________
> From: John Wargo <wargo.john25@gmail.com>
>To: Xen Users <xen-users@lists.xen.org> 
>Sent: Friday, 25 October 2013, 2:57
>Subject: Re: [Xen-users] Install Xen 4.4-Unstable
> 
>
>
>On 10/24/2013 08:24 PM, John Wargo wrote:
>
>Dear people with higher intelligence than me,
>
>I''m trying to install xen 4.4-Unstable from source. I used this
      wiki page : 
>http://wiki.xen.org/wiki/Compiling_Xen_From_Source.
>
>Steps I took :
>
>1) Check-out from git (master)
>2) ./configure
>3) make world
>4) make install
>5) /sbin/ldconifg
>6) Reboot into xen
>
>I''m currently running an up to date version of Fedora 19.
>
>After rebooting I started with ''xen-dmesg'' under root,
just to see
      if I had a working iommu right out of the box, however it appears
      I don''t even have xl:
>
>[root@Hypervisor john]# xl dmesg
>bash: xl: command not found
>
>I backed out of root and ran the same thing, and got this result :
>
>[john@Hypervisor ~]$ xl dmesg
>xl: error while loading shared libraries: libxlutil.so.4.3: cannot
      open shared object file: No such file or directory
>
>I''m certain I simply missed one step, but cannot for the life of
      me figure out what it is.
>Thanks for your time and expertise,
>- John
>Further testing shows this to be true for all package types.
    Regardless of if I''m installing xen 4.1, 4.2, 4.3-stable,
    4.3-unstable, or 4.4, this happens every time, so now I know that I
    am indeed missing something.
>
>Any suggestions?
>
>
I would double check the wiki sections marked"Library Installation
Directory" & "Python Prefix and Module Layout" to see if they
apply to your situation.







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

On 10/25/2013 03:12 AM, Wei Liu wrote:
> On Thu, Oct 24, 2013 at 08:24:06PM -0500, John Wargo wrote:
>> Dear people with higher intelligence than me,
>>
>> I''m trying to install xen 4.4-Unstable from source. I used
this wiki
>> page : http://wiki.xen.org/wiki/Compiling_Xen_From_Source.
>>
>> Steps I took :
>>
>> 1) Check-out from git (master)
>> 2) ./configure
>> 3) make world
>> 4) make install
>> 5) /sbin/ldconifg
>> 6) Reboot into xen
>>
> Just asking, do you have the necessary permission to run ''make
install''?
> You need to be root.
>
>> I''m currently running an up to date version of Fedora 19.
>>
> Is there any special requirement that prevents you from using the
> pre-package Xen in Fedora?
>
>> After rebooting I started with ''xen-dmesg'' under
root, just to see
>> if I had a working iommu right out of the box, however it appears I
>> don''t even have xl:
>>
>> [root@Hypervisor john]# xl dmesg
>> bash: xl: command not found
>>
>> I backed out of root and ran the same thing, and got this result :
>>
>> [john@Hypervisor ~]$ xl dmesg
>> xl: error while loading shared libraries: libxlutil.so.4.3: cannot
>> open shared object file: No such file or directory
>>
> What does "ldd `which xl`" (without quote) show?
>
> Wei.
>
>> I''m certain I simply missed one step, but cannot for the life
of me
>> figure out what it is.
>> Thanks for your time and expertise,
>> - John
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org
>> http://lists.xen.org/xen-users
Wei,
> Just asking, do you have the necessary permission to run ''make
install''?
> You need to be root.
Yes, I made sure to run all of those under root (via ''sudo
su'')
> Is there any special requirement that prevents you from using the
> pre-package Xen in Fedora?
Yes, it has some issues with AMD-Vi and IOMMU, as well as some VGA 
passthrough issues that supposedly can be handled in 4.4.
> What does "ldd `which xl`" (without quote) show?
> Wei.
[john@Hypervisor ~]$ ldd `which xl`
         linux-vdso.so.1 =>  (0x00007fff9f4f8000)
         libxlutil.so.4.3 => not found
         libxenlight.so.4.3 => not found
         libxenctrl.so.4.3 => not found
         libyajl.so.2 => /lib64/libyajl.so.2 (0x00007f9dc4758000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9dc4538000)
         libc.so.6 => /lib64/libc.so.6 (0x00007f9dc4170000)
         /lib64/ld-linux-x86-64.so.2 (0x00007f9dc4990000)

-John

On 10/25/2013 04:16 AM, Ian Murray wrote:
>
>
>
>
>
>
>> ________________________________
>> From: John Wargo <wargo.john25@gmail.com>
>> To: Xen Users <xen-users@lists.xen.org>
>> Sent: Friday, 25 October 2013, 2:57
>> Subject: Re: [Xen-users] Install Xen 4.4-Unstable
>>
>>
>>
>> On 10/24/2013 08:24 PM, John Wargo wrote:
>>
>> Dear people with higher intelligence than me,
>>
>> I''m trying to install xen 4.4-Unstable from source. I used
this
>        wiki page :
>> http://wiki.xen.org/wiki/Compiling_Xen_From_Source.
>>
>> Steps I took :
>>
>> 1) Check-out from git (master)
>> 2) ./configure
>> 3) make world
>> 4) make install
>> 5) /sbin/ldconifg
>> 6) Reboot into xen
>>
>> I''m currently running an up to date version of Fedora 19.
>>
>> After rebooting I started with ''xen-dmesg'' under
root, just to see
>        if I had a working iommu right out of the box, however it appears
>        I don''t even have xl:
>> [root@Hypervisor john]# xl dmesg
>> bash: xl: command not found
>>
>> I backed out of root and ran the same thing, and got this result :
>>
>> [john@Hypervisor ~]$ xl dmesg
>> xl: error while loading shared libraries: libxlutil.so.4.3: cannot
>        open shared object file: No such file or directory
>> I''m certain I simply missed one step, but cannot for the life
of
>        me figure out what it is.
>> Thanks for your time and expertise,
>> - John
>> Further testing shows this to be true for all package types.
>      Regardless of if I''m installing xen 4.1, 4.2, 4.3-stable,
>      4.3-unstable, or 4.4, this happens every time, so now I know that I
>      am indeed missing something.
>> Any suggestions?
>>
>>
> I would double check the wiki sections marked"Library Installation
Directory" & "Python Prefix and Module Layout" to see if they
apply to your situation.
>
>
>
>
>
>
>
>
>>
>> -John
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org
>> http://lists.xen.org/xen-users
>>
>>
Ian,

After checking the "Phython Prefix Section", I deemed it unapplicable
as
I was having a different issue, and it was aimed at debian.

If there is any reason to try it anyway, let me know,
-John

On Fri, 2013-10-25 at 05:35 -0500, John Wargo wrote:
> > What does "ldd `which xl`" (without quote) show?
> [john@Hypervisor ~]$ ldd `which xl`
>          linux-vdso.so.1 =>  (0x00007fff9f4f8000)
>          libxlutil.so.4.3 => not found
>          libxenlight.so.4.3 => not found
>          libxenctrl.so.4.3 => not found
Was this after having run /sbin/ldconfig (as root). If yes then what
does e.g. "find / -name libxlutil.so.4.3" show?

Also, what is the output of "which xl"? 

Ian.

On 10/25/2013 05:45 AM, Ian Campbell wrote:
> On Fri, 2013-10-25 at 05:35 -0500, John Wargo wrote:
>>> What does "ldd `which xl`" (without quote) show?
>> [john@Hypervisor ~]$ ldd `which xl`
>>           linux-vdso.so.1 =>  (0x00007fff9f4f8000)
>>           libxlutil.so.4.3 => not found
>>           libxenlight.so.4.3 => not found
>>           libxenctrl.so.4.3 => not found
> Was this after having run /sbin/ldconfig (as root). If yes then what
> does e.g. "find / -name libxlutil.so.4.3" show?
>
> Also, what is the output of "which xl"?
>
> Ian.
>
Ian,

Here are the commands you requested (I have run /sbin/ldconfig), and I 
think that they''ll prove useful:

[root@Hypervisor /]# find -name "libxlutil*"
./home/john/Documents/Virtualization/xen/tools/libxl/libxlutil.so.4.3.0
./home/john/Documents/Virtualization/xen/tools/libxl/libxlutil.a
./home/john/Documents/Virtualization/xen/tools/libxl/libxlutil.h
./home/john/Documents/Virtualization/xen/tools/libxl/libxlutil.so
./home/john/Documents/Virtualization/xen/tools/libxl/libxlutil.so.4.3
./home/john/Documents/Virtualization/xen/dist/install/usr/local/lib/libxlutil.so.4.3.0
./home/john/Documents/Virtualization/xen/dist/install/usr/local/lib/libxlutil.a
./home/john/Documents/Virtualization/xen/dist/install/usr/local/lib/libxlutil.so
./home/john/Documents/Virtualization/xen/dist/install/usr/local/lib/libxlutil.so.4.3
./home/john/Documents/Virtualization/xen/dist/install/usr/lib64/libxlutil.so.4.3.0
./home/john/Documents/Virtualization/xen/dist/install/usr/lib64/libxlutil.a
./home/john/Documents/Virtualization/xen/dist/install/usr/lib64/libxlutil.so
./home/john/Documents/Virtualization/xen/dist/install/usr/lib64/libxlutil.so.4.3
./usr/lib64/libxlutil.a
./usr/lib64/libxlutil.so
./usr/lib64/libxlutil.so.4.3
./usr/lib64/libxlutil.so.4.3.0
./usr/local/lib/libxlutil.a
./usr/local/lib/libxlutil.so
./usr/local/lib/libxlutil.so.4.3
./usr/local/lib/libxlutil.so.4.3.0
[root@Hypervisor /]# which xl
/usr/bin/which: no xl in (/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin)

Thanks for your help thus far,
-John

On Fri, 2013-10-25 at 20:49 -0500, John Wargo wrote:
> [root@Hypervisor /]# find -name "libxlutil*"
> ./usr/lib64/libxlutil.a
> ./usr/lib64/libxlutil.so
> ./usr/lib64/libxlutil.so.4.3
> ./usr/lib64/libxlutil.so.4.3.0
> ./usr/local/lib/libxlutil.a
> ./usr/local/lib/libxlutil.so
> ./usr/local/lib/libxlutil.so.4.3
> ./usr/local/lib/libxlutil.so.4.3.0
You appear to have two parallel installations of Xen here, one with
prefix=/usr and one with prefix=/usr/local. Have you tried invoking
configure with a variety of options at some point?

Having two installs could be causing all sorts of confusion, and will
certainly trip you up in the future. You should clean one of them up
("make uninstall" in a tree ./configure''d however you did it
initially
would be a good start).
> [root@Hypervisor /]# which xl
> /usr/bin/which: no xl in (/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin)
This suggests that the installation in prefix=/usr is somehow incomplete
(or else xl would be in /usr/sbin/xl) so that is probably the one to get
rid of.

If you are going to use prefix=/usr/local (which is a good idea to keep
installed from source stuff separate to package managed stuff) then it
seems like your distro requires you to add /usr/local/{sbin,bin} to your
$PATH manually.

However this result also conflicts with the log you posted previously
for the output of "ldd `which xl`" where obviously an xl must have
been
found. Do you have only a single system you are experimenting with or
could that result have been a different one? Maybe you just forgot to
amend your $PATH in this case?

Ian.

On 10/26/2013 01:51 AM, Ian Campbell wrote:
> On Fri, 2013-10-25 at 20:49 -0500, John Wargo wrote:
>
>> [root@Hypervisor /]# find -name "libxlutil*"
>> ./usr/lib64/libxlutil.a
>> ./usr/lib64/libxlutil.so
>> ./usr/lib64/libxlutil.so.4.3
>> ./usr/lib64/libxlutil.so.4.3.0
>> ./usr/local/lib/libxlutil.a
>> ./usr/local/lib/libxlutil.so
>> ./usr/local/lib/libxlutil.so.4.3
>> ./usr/local/lib/libxlutil.so.4.3.0
> You appear to have two parallel installations of Xen here, one with
> prefix=/usr and one with prefix=/usr/local. Have you tried invoking
> configure with a variety of options at some point?
>
> Having two installs could be causing all sorts of confusion, and will
> certainly trip you up in the future. You should clean one of them up
> ("make uninstall" in a tree ./configure''d however you
did it initially
> would be a good start).
>
>> [root@Hypervisor /]# which xl
>> /usr/bin/which: no xl in
(/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin)
> This suggests that the installation in prefix=/usr is somehow incomplete
> (or else xl would be in /usr/sbin/xl) so that is probably the one to get
> rid of.
>
> If you are going to use prefix=/usr/local (which is a good idea to keep
> installed from source stuff separate to package managed stuff) then it
> seems like your distro requires you to add /usr/local/{sbin,bin} to your
> $PATH manually.
>
> However this result also conflicts with the log you posted previously
> for the output of "ldd `which xl`" where obviously an xl must
have been
> found. Do you have only a single system you are experimenting with or
> could that result have been a different one? Maybe you just forgot to
> amend your $PATH in this case?
>
> Ian.
>
Ian,

Sorry for the confusion, I have tried with a variety of configuration 
options, and the "ldd `which xl`" came from before that.
My plan is to clean up all of the installs, then just have it installed 
to /usr/local/bin (or sbin if necessary). I will post here when I am 
done, and if it doesn''t work, then I''ll post the correct ldd,
which, and
find.

Again, sorry for your confusion,
-John

On 10/26/2013 01:51 AM, Ian Campbell wrote:
> On Fri, 2013-10-25 at 20:49 -0500, John Wargo wrote:
>
>> [root@Hypervisor /]# find -name "libxlutil*"
>> ./usr/lib64/libxlutil.a
>> ./usr/lib64/libxlutil.so
>> ./usr/lib64/libxlutil.so.4.3
>> ./usr/lib64/libxlutil.so.4.3.0
>> ./usr/local/lib/libxlutil.a
>> ./usr/local/lib/libxlutil.so
>> ./usr/local/lib/libxlutil.so.4.3
>> ./usr/local/lib/libxlutil.so.4.3.0
> You appear to have two parallel installations of Xen here, one with
> prefix=/usr and one with prefix=/usr/local. Have you tried invoking
> configure with a variety of options at some point?
>
> Having two installs could be causing all sorts of confusion, and will
> certainly trip you up in the future. You should clean one of them up
> ("make uninstall" in a tree ./configure''d however you
did it initially
> would be a good start).
>
>> [root@Hypervisor /]# which xl
>> /usr/bin/which: no xl in
(/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin)
> This suggests that the installation in prefix=/usr is somehow incomplete
> (or else xl would be in /usr/sbin/xl) so that is probably the one to get
> rid of.
>
> If you are going to use prefix=/usr/local (which is a good idea to keep
> installed from source stuff separate to package managed stuff) then it
> seems like your distro requires you to add /usr/local/{sbin,bin} to your
> $PATH manually.
>
> However this result also conflicts with the log you posted previously
> for the output of "ldd `which xl`" where obviously an xl must
have been
> found. Do you have only a single system you are experimenting with or
> could that result have been a different one? Maybe you just forgot to
> amend your $PATH in this case?
>
> Ian.
>
Ian,

After removing both installs, then installing xen to /usr/local, I added 
/usr/local/sbin to my path, and it all works great now.

Thanks for your time,
-John