Ubuntu Server 9.10 (karmic): xenner: depends on non-existent library

no change rebuild fixes this on lucid

also works for karmic

although in /etc/init.d/xenner i'm assuming

# rm -f \
       /var/log/netbackd.log \
       /var/log/blkbackd.log \
       /var/log/evtchnd.log \
       /var/log/xenstore.trace \

is meant to result in this
# rm -f \
# /var/log/netbackd.log \
# /var/log/blkbackd.log \
# /var/log/evtchnd.log \
# /var/log/xenstore.trace \

but the comment doesnt carry across multiple lines so this causes an error

this is quite old, heres a debdiff anyway

its gone from debian too, a candidate for archive removal? the debdiff will allow xenner to install and start, whether it works properly or not i don't know, its not seen changes since intrepid. i'll put it in my lucid ppa below if someone would like to comment on whether its a working package and worth fixing
https://launchpad.net/~sevenmachines/+archive/release+1

Since ubuntu decided to follow upstream and incorporate KVM virtualization by default the easiest way to run Xen domU images is by using Xenner. It is important that a working Xenner package continue to be available so that users are not forced to migrate to a full Xen dom0 kernel/initrd in order to run Xen domU images. Xen is still the current preferred cloud hypervisor used by ec2 and users like to test their images locally.

It would also be good if Xenner could be updated to 0.47. There have been a number of serious bugs fixed between 0.41 and 0.47.

xenner 0.47 seems ok. aside from a minor change in GNUmakefile from sh to bash to allow building

I just checked an F12 machine to see where fedora was on this:
# yum list xen xenner
Available Packages
xen.x86_64 3.4.1-5.fc12 fedora
xenner.x86_64 0.47-3.fc12 fedora

So fedora is runnng xen-3.4 and xenner-0.47. I don't know whether xenner-0.47 depends on xen-3.4. Something that would need investigated.

you should probably open up a new bug for an update request for xenner so someone can look at that separately.
meanwhile i'll see about getting 0.41 at least up and running. fixing 0.41 means that the patch can maybe be SRU'd into karmic (hopefully) as well as lucid. i'll upload a karmic version to the ppa below if you're interested in trying it out
https://launchpad.net/~sevenmachines/+archive/release/+packages

I'll try out a new package if you get it built to your ppa.

Also, opened a new bug requesting an update of Xenner to 0.47:

https://bugs.launchpad.net/ubuntu/+source/xenner/+bug/496745

Ok I upgrade xenner using the ppa package but it did not go so well:

Log started: 2009-12-14 18:37:34
(Reading database ... 132481 files and directories currently installed.)
Preparing to replace xenner 0.41-1ubuntu5 (using .../xenner_0.41-1ubuntu5.1~sevenmachines1_amd64.deb) ...
 * Stopping xenner xenner [fail]
/etc/init.d/xenner: line 123: /var/log/netbackd.log: No such file or directory
invoke-rc.d: initscript xenner, action "stop" failed.
dpkg: warning: old pre-removal script returned error exit status 127
dpkg - trying script from the new package instead ...
 * Stopping xenner xenner start-stop-daemon: warning: failed to kill 16431: No such process
                                                                         [fail]
/etc/init.d/xenner: line 123: /var/log/netbackd.log: No such file or directory
invoke-rc.d: initscript xenner, action "stop" failed.
dpkg: error processing /var/cache/apt/archives/xenner_0.41-1ubuntu5.1~sevenmachines1_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 127
update-rc.d: warning: /etc/init.d/xenner missing LSB keyword 'default-stop'

update-rc.d: warning: xenner start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (2 3 4 5 6)
update-rc.d: warning: xenner stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (none)
 * Starting xenner xenner [ OK ] * Starting evtchnd evtchnd
 * Starting xensored xenstored [ OK ]
 * Starting xenconsoled xenconsoled [ OK ]
 * Starting xen block devices xenblkbackd /usr/sbin/blkbackd: error while loading shared libraries: libxenctrl.so: cannot open shared object file: No such file or directory
                                                                         [fail]
 * Starting xen netblock netbackd /usr/sbin/netbackd: error while loading shared libraries: libxenctrl.so: cannot open shared object file: No such file or directory
                                                                         [fail]
Errors were encountered while processing:
 /var/cache/apt/archives/xenner_0.41-1ubuntu5.1~sevenmachines1_amd64.deb
Log ended: 2009-12-14 18:37:36

$ sudo apt-file search libxenctrl.so
libxen3: /usr/lib/libxenctrl.so.3.2
libxen3: /usr/lib/libxenctrl.so.3.2.0
libxen3-dev: /usr/lib/libxenctrl.so
xenner: /usr/lib/xenner/libxenctrl.so.3.0
xenner: /usr/lib/xenner/libxenctrl.so.3.0.0

So this missing shared lib is in libxen3-dev which is not a dependency listed for xenner.

thats not a bug in the new package, its a problem with the old one. the old initscript is broken so uninstallation fails on trying to stop the daemon in the dpkg pre-removal script. in this particular case its ok to remove the prerm script before upgrading
$rm /var/lib/dpkg/info/xenner.prerm

i'd just add that the initscript and dpkg scripts probably need a closer look in general, that would be part of upgrading the package though and not a minimal bug fix for this version

The dependency on libxen3-dev needs to be added to xenner in order to get the missing libxenctrl.so shared lib installed. And this needs to be part of the bug fix. The package is broken otherwise.

i've tested it on karmic without any problems, the rebuild corrects the library dependencies to work with the correct dynamic versions and not libxenctrl.so itself. without libxen3-dev installed there isnt any libxenctrl.so errors. have you tested the new package and are still getting them?

Yes, I just retested and I'm getting the exact same errors on the libxenctrl.so shared library.

Your PPA says package was updated 3 hours ago. Is that ok?

are you sure the ppa version installed properly?
$ apt-show-versions xenner
xenner 0.41-1ubuntu5.1~sevenmachines1

i can reproduce the problem with xenner 0.41-1ubuntu5 from karmic main on a vanilla karmic install, and xenner 0.41-1ubuntu5.1~sevenmachines1 works as it should with no errors. so if you're using the same package i'm not sure whats going wrong.

$ sudo apt-show-versions -a xenner
xenner 0.41-1ubuntu5 install ok installed
xenner 0.41-1ubuntu5 karmic us.archive.ubuntu.com
xenner 0.41-1ubuntu5.1~sevenmachines1 karmic ppa.launchpad.net
xenner/karmic upgradeable from 0.41-1ubuntu5 to 0.41-1ubuntu5.1~sevenmachines1

It keeps trying to perform the upgrade:
$ sudo apt-get upgrade xenner
...
The following packages will be upgraded:
    xenner
...

but fails with the same libxenctrl.so shared library error as I posted above.

its still the old package. remember, you need to
$rm /var/lib/dpkg/info/xenner.prerm

before upgrading.

the reason your still getting the errors is that the initscript is failing while trying to remove the old package. this causes the upgrade to fail and the old version of xenner to restart, showing you the same library errors

Ok, that got it. I missed that first manual step.

$ sudo apt-show-versions -a xenner
xenner 0.41-1ubuntu5.1~sevenmachines1 install ok installed
xenner 0.41-1ubuntu5 karmic us.archive.ubuntu.com
xenner 0.41-1ubuntu5.1~sevenmachines1 karmic ppa.launchpad.net
xenner/karmic uptodate 0.41-1ubuntu5.1~sevenmachines1

good stuff, if you want to test it out for a bit and see if theres any major problems that would be great. if it seems working enough i'll subscribe a motu and see about getting it into karmic

There appears to be some type of apparmor profile issue between libvirt and xenner. Xenner is expected to be a valid emulator callable by libvirt.

Here's what I see even after unloading apparmor:

+ apparmor_status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode :
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

+ virsh start Ubuntu-domU-x86-1
Connecting to uri: qemu:///system
error: Failed to start domain Ubuntu-domU-x86-1
error: internal error unable to start guest: libvir: error : cannot execute binary /usr/bin/xenner: Permission denied

+ tail /var/log/kern.log
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.595329] type=1505 audit(1260901134.725:32): operation="profile_load" pid=13204 name=libvirt-74367128-9bd6-3264-3833-f661c47b464e
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.598647] device vnet0 entered promiscuous mode
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.599664] br0: port 2(vnet0) entering learning state
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.600812] type=1503 audit(1260901134.735:33): operation="exec" pid=13208 parent=13207 profile="libvirt-74367128-9bd6-3264-3833-f661c47b464e" requested_mask="x::" denied_mask="x::" fsuid=0 ouid=0 name="/usr/bin/xenner"
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.644365] br0: port 2(vnet0) entering disabled state
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.683450] device vnet0 left promiscuous mode
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.683454] br0: port 2(vnet0) entering disabled state
Dec 15 13:18:54 grp-01-23-02 kernel: [ 5147.828181] type=1505 audit(1260901134.957:34): operation="profile_remove" pid=13210 name=libvirt-74367128-9bd6-3264-3833-f661c47b464e namespace=default

Even with apparmor unloaded the kernel still loads a profile, denies access and then removes the profile. Maybe this is some type of apparmor bug or a kernel bug. Or maybe there needs to be an apparmor profile setting in the xenner package.

CORRECTION: Here's what I see even after disabling apparmor:

This package is pretty old now so i can't be sure how useful it is, however the attached debdiff should at least get it up and running

xenner (0.41-1ubuntu6) lucid; urgency=low

  * rebuild to refresh libxenctrl.so dependency (LP: #496654)
  * debian/xenner.init: comment out the arguments to the removed rm -f call

working on it

This bug was fixed in the package xenner - 0.41-1ubuntu6

---------------
xenner (0.41-1ubuntu6) lucid; urgency=low

  * rebuild to refresh libxenctrl.so dependency (LP: #496654)
  * debian/xenner.init: comment out the arguments to the removed rm -f call
 -- Niall Creech <email address hidden> Fri, 12 Feb 2010 13:34:06 +0000