Xen devel - Jun 2013 - Test Day instructions: specific list of files to be removed?

In the Test Day instructions, it is said:
>Remove any old versions of Xen toolstack and userspace binaries (including
qemu).
Is there a Wiki (or other) page somewhere which gives the tester a
checklist of things to remove?  I''ve seen a couple
distribution-specific lists that people have assembled on the Web, but
they are meant as distribution-specific scripts primarily.

I mean a short document which might give a slightly higher level
checklist.  Maybe something like:

All files containing "xen" in the binary directories, modules
directories, library directories
All files containing "qemu" in the ..
All files beginning with ...

Does something like that exist somewhere, so that a tester could go
down a checklist to remove old files (particularly if they are from a
prepackaged Xen install, not a similar RC install) and be relatively
sure they got them all?

I know this is not a big deal to folks who are used to doing this, but
for someone new to the test day process, this could be helpful.

Thanks,

Russ

On Fri, 2013-06-14 at 23:53 -0400, Russ Pavlicek wrote:
> In the Test Day instructions, it is said:
> 
> >Remove any old versions of Xen toolstack and userspace binaries
(including qemu).
> 
> Is there a Wiki (or other) page somewhere which gives the tester a
> checklist of things to remove?
If they previously installed from distro packages then they should
remove (purge in Debian terms to really get rid of them) whatever
packages they installed. That package list will be distro specific.

I they previously installed from source then running "make uninstall"
from that previous source tree would be a good start. This rule isn''t
terribly well maintained but it ought to catch the most obvious stuff I
think.

You could also run "make install DESTDIR=/tmp/to-be-removed" on the
old
tree, then you could look at all the relative paths there and remove
from the filesystem.

Probably the most important things to remove are anything
in /usr/bin , /usr/sbin or /usr/lib with "xen" or "xl" in
the name
especially, if the previous version was installed in /usr while the
newer ones go to /usr/local, since the newer ones won''t then overwrite
the old ones.

Also looking through /etc (especially /etc/xen and /etc/init.d/*xen*)
would be wise. Likewise /boot.
>   I''ve seen a couple
> distribution-specific lists that people have assembled on the Web, but
> they are meant as distribution-specific scripts primarily.
> 
> I mean a short document which might give a slightly higher level
> checklist.  Maybe something like:
> 
> All files containing "xen" in the binary directories, modules
> directories, library directories
> All files containing "qemu" in the ..
> All files beginning with ...
> 
> Does something like that exist somewhere, so that a tester could go
> down a checklist to remove old files (particularly if they are from a
> prepackaged Xen install, not a similar RC install) and be relatively
> sure they got them all?
Unfortunately not. It will vary a bit from system to system (distro,
which dev packages you have installed etc).

Installing to /usr/local by default will simplify this somewhat since
there will typically be less other stuff under /usr/local to sift
through.

I suppose we could encourage people to use "./configure
--prefix=/opt/xentestday-20130622" but that is not a commonly used
config so it will have its own issues.

> I know this is not a big deal to folks who are used to doing this, but
> for someone new to the test day process, this could be helpful.
The goal is really just to avoid issues with running the old toolstack
(or linking the new libraries) when you think you are running the new.
Most of the time the new ones would overwrite to old so it''s not all
that critical to get it right, as long as we on #xentest keep in mind
the possibility that an obscure bug (e.g. an unexplainable xl segfault)
might be down to picking up old versions of things.

Ian.

 
>>  I know this is not a big deal to folks who are used to doing this, but
>>  for someone new to the test day process, this could be helpful.
> 
> The goal is really just to avoid issues with running the old toolstack
> (or linking the new libraries) when you think you are running the new.
> Most of the time the new ones would overwrite to old so it''s not
all
> that critical to get it right, as long as we on #xentest keep in mind
> the possibility that an obscure bug (e.g. an unexplainable xl segfault)
> might be down to picking up old versions of things.

I just tried 4.3RC4 over the top of a working 4.22 yesterday and I had all sorts
of problems of "permission denied" and "internal error" when
doing basic stuff like xl destroy and xl list. A little googling told me that
this was likely down to mixed versions and sure enough I ended up with at least
two xl''s and various other stuff duplicated. The only time I have used
an option on configure is for lib/lib64 and never anything on this system,
AFAIR.

Unfortunately, I had to get it back in a working state as this machine is
unattented Mon-Fri so pretty much took it back to 4.22 with without much
investigation. Obviously by then I had some cleaning up still to do and AFAIR it
looks like the path differences were along the lines of /usr/ vs /usr/local/  .
As I said before I have never done anything specifically in the past around this
so presumably the defaults have changed unless I am doing something wrong or
missing something.

Am Montag 17 Juni 2013, 11:36:51 schrieb Ian Murray:
> 
> >>  I know this is not a big deal to folks who are used to doing
this, but
> >>  for someone new to the test day process, this could be helpful.
> > 
> > The goal is really just to avoid issues with running the old toolstack
> > (or linking the new libraries) when you think you are running the new.
> > Most of the time the new ones would overwrite to old so it''s
not all
> > that critical to get it right, as long as we on #xentest keep in mind
> > the possibility that an obscure bug (e.g. an unexplainable xl
segfault)
> > might be down to picking up old versions of things.
> 
> 
> I just tried 4.3RC4 over the top of a working 4.22 yesterday and I had all
sorts of problems of "permission denied" and "internal
error" when doing basic stuff like xl destroy and xl list. A little
googling told me that this was likely down to mixed versions and sure enough I
ended up with at least two xl''s and various other stuff duplicated. The
only time I have used an option on configure is for lib/lib64 and never anything
on this system, AFAIR.
> 
> Unfortunately, I had to get it back in a working state as this machine is
unattented Mon-Fri so pretty much took it back to 4.22 with without much
investigation. Obviously by then I had some cleaning up still to do and AFAIR it
looks like the path differences were along the lines of /usr/ vs /usr/local/  .
As I said before I have never done anything specifically in the past around this
so presumably the defaults have changed unless I am doing something wrong or
missing something.
I had the same problem until I found the hint in the wiki to remove all stuff
before installing from source.

It would be good if the build environment would support the flag
-Wl,-rpath=DIR for the linker. So everybody could have installed multiple xen
versions in different directories beside the original version from the
distribution.
For the native xen libraries and tools this could be done via an addition
in $(XEN)/config/Tools.mk.in:
APPEND_LDFLAGS      := -Wl,-rpath=$(prefix)/lib64
More problematic seem to be additional tools like qemu as these currently
dont support this flag.
And I don''t know how command pathes are handled via fork/exec calls and
in
scripts.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html