[Xen-devel] Guidance needed

[Richard Bowser <bowser.richard@xxxxxxxxx>]

I am something of a newcomer to xen, and interested in creating a how-to on building xen from sources.  On July 1st I started trying to build the (old) "Xen 3.4.0 plus kernel combined source distribution tarball".  I have two Linux environments available to me:  My personal development system runs Ubuntu 9.04.  I also have a Fedora Core 10 system available at school.  I have fresh, new (combined) xen-3.4.0 directories on both systems.  All build attempts still abend on both systems, for various reasons.  It is now mid August.

This is NOT a request for technical help in using xen.  (I have repeatedly written the xen-users list asking for help, and have received no helpful suggestions.  But that is only WHY I want to develop a how-to.  It doesn't matter here.)  I have just uncovered something appropriate here:  I have a Ubuntu 9.04 problem - an oddity which could be in the xen source, in Ubuntu's Python 2.6.2 script handling, or in Ubuntu 9.04 linux.  Please help me decide where to report this problem.  I must remark that since xen 3.4.1 is already out, in one sense my problem is moot.  Only in Ubuntu 9.04 there still is a 100% reproducible failure in trying to build the combined 3.4.0 tarball (no longer offered on the xen.org download page), but if left uncorrected, the identical bug is likely to appear in the next stable release of a combined tarball.

Here's the issue:  In the function untar() within ketchup, builds under Ubuntu 9.04 uniformly fail - all the while results flagged as errors actually SUCCEED before the script abends.  Ketchup dies.  Under FC10, builds blithely sail past this point with no problem, though subsequently failing for reasons still under investigation and irrelevant here.

An abnormal termination of ketchup displays these lines of text on std error:
mv: cannot move `linux-2.6.18/..' to `../..': Device or resource busy
rmdir: failed to remove `linux-2.6.18': Directory not empty
ketchup: Unpacking failed: 
256

The ketchup untar function holds this code:
    err = os.system("mv linux*/* linux*/.[^.]* ..; rmdir linux*")
    if err:
        error("ketchup: Unpacking failed: ", err)
        sys.exit(-1)

I believe the printed 256 above is the hex value passed as "err".

This is my point of failure.  I edited my local ketchup script forcing an exit just prior to executing the offending code.  A test of "make world" revealed ketchup had been running in the directory xen-3.4.0/linux-2.6.18/ketchup-tmp, where there was yet another linux-2.2.6, holding untared binaries just derived from linux-2.6.18.tar.bz2.  The forced exit left the suspect code unexecuted.  Manual execution of "mv linux*/* linux*/.[^.]* .." did successfully transfer all file contents from ketchup-tmp/linux-2.6.18 to ../.. (which is also named linux-2.6.18).  Subsequent manual execution of "rmdir linux*" did indeed successfully remove it from ketchup-tmp.

In confusion, I retested by sending my existing test xen-3.4.0 directory to the trash and untaring a fresh copy in its place (with ketchup unedited.)
I experienced an identical failure.  Close observation of my new but failing build directory (xen-3.4.0/linux-2.6.18) showed that:

1) it had all the contents that had been unpacked by ketchup in os.system("bzcat %s | tar -xf -" % tarfile)    - i.e., the move HAD WORKED
2) xen-3.4.0/linux-2.6.18 sill had a subdir ketchup-tmp, which was EMPTY    - i.e., the rmdir also HAD WORKED

Folks, when a system fails on an error - but actually works, something is WONKY, big time.

As a result of going this far, I now know some important details to include in my how-to.  Yet I feel this logical foible does need fixing, even if I don't quite know just who its "proud owner" might be.  If anyone knowledgeable in building xen from sources cares to do so, please email me directly.  I have several how-to issues I'd like to discuss.  If this list is an appropriate venue for discussing a how-to in progress, please tell me so.

I hope to contribute material of value here, and disrupt nobody.  Thanks for reading through all this!

-Rich B.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel