Hello David,
Yes, you can go one more step backwards, and use cluster-1.02.00.
But you must also apply two patches : see
http://www.redhat.com/archives/cluster-devel/2006-June/msg00162.html
These two patches are due to changes in libsysfs.
For me it worked like a charm.
Regards,
Rami Rosen
On 3/21/07, David Shwatrz <dshwatrz@gmail.com>
wrote:> Hello all,
>
> I had tried to build Red Hat Cluster (http://sourceware.org/cluster/)
> against
> a Xen tree in order to deploy a cluster with Xen VMs.
>
> Under the ftp repository,
> ftp://sources.redhat.com/pub/cluster/releases,
> there are some releases.
>
> I started by trying to build the latest, which is: cluster-2.00.00.tar.gz.
>
> I ran :
> ./configure --kernel_src=/work/src/xen-3.0.4_1-src/linux-2.6.16.33-xen
>
> I get the following error :
> /work/src/cluster-2.00.00/gnbd-kernel/src/gnbd.c: In function
> ''gnbd_init'':
> /work/src/cluster- 2.00.00/gnbd-kernel/src/gnbd.c:888: error:
''struct
> request''
> has no member named ''cmd_type''
>
> It turns out that the struct request in
>
> /work/src/xen-3.0.4_1-src/linux-2.6.16.33-xen/include/linux
> is missing
> a member named ''cmd_type'' ; this member DOES exists
in linux kernel
> 2.6.20 for example.
>
> After probing a bit, I discovered that the problem is that this redhat
> cluster
> version is for kernel 2.6.20 (and higher) , and Xen
> (also unstable version, as far as I know) still does not work with this
> version.
> see the following thread:
>
> https://www.redhat.com/archives/linux-cluster/2007-March/msg00175.html
>
> So I went a step back and tried cluster-1.03.00.
>
> (If you wonder why I skipped cluster-1.04 version, which does exists
> in that repository: the reason is simple ; If you will look at that
> thread
> mentioned above you will find out that also cluster-1.04 is intended
for
> use with 2.6.20.)
>
> after "make install" I got:
> /work/src/cluster-1.03.00/gfs-kernel/src/nolock/main.c: In function
> ''nolock_plock_get'':
> /work/src/cluster-1.03.00/gfs-kernel/src/nolock/main.c:250:
> error: too many arguments to function ''posix_test_lock''
>
> It turned out that the posix_test_lock() prototype in the linux kernel
that
> Xen
> uses is:
> struct file_lock *posix_test_lock(struct file *, struct file_lock *);
>
> while the call to posix_test_lock() in gfs-kernel/src/nolock/main.c is with
> three
> parameters.
>
> What should I do ? should I go again one step back
> (until reaching a
> stop point for this recursion) ?
>
> Any ideas ?
>
> DS
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel