On Fri, 2009-01-30 at 11:14 +0530, Nitin Bhardwaj wrote: > On Fri, Jan 30, 2009 at 9:11 AM, Dave Miller <justd...@mozilla.com> > wrote: > > > > Nitin Bhardwaj wrote on 1/29/09 1:57 AM: > [....] > > > 4. Build the new kernel using rpmbuild command, which built two > RPMs > > > successfully: > > > kernel-2.6.18-92.el5.unionfs.rpm > > > kernel-devel-2.6.18-92.el5.unionfs.rpm > > > > Step 4 probably wiped out your patch. > > > > Yeah I suppose thats what was happening, I was not realizing it > earlier. > > So, following the instructions here: > http://wiki.centos.org/HowTos/Custom_Kernel, I did the following: > > 1. Added the patch ( unionfs-2.4_for_2.6.18-RHEL5.diff ) to > ~/rpmbuild/SOURCES, and referenced it in > ~/rpmbuild/SPECS/kernel-2.6.spec . > > 2.Turned off the KABI check and provided a new buildid in the > kernel-2.6.spec in ~/rpmbuild/SPECS > > 3. Build using rpmbuild -bb --target=`uname -m` --with baseonly > kernel-2.6.spec
Right, but I didn't seem to be able to disable the kabichk either on the command line or in the spec file itself, a bit odd. But, lets not forget that if you use these rpms later some time and you have another third party module on the machine that relies on this kabi function then it will break and you will probably have forgotten the kabi issue by then, caught!!! It's best to at least maintain the kabi in the RHEL kernel if possible. > > And bam ! I hit the same build error that Dave mentioned earlier last > year here: > http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2008-July/005893.html Right, but that was the point of the example patch to change the kernel configs that the kernel srpm copies and uses to configure the kernel? > > ----------------------------------------------------------- > + make ARCH=i386 nonint_oldconfig > CONFIG_UNION_FS > make[1]: *** [nonint_oldconfig] Error 5 > ----------------------------------------------------------- > > I used the same workaround Dave gave at that time, in the spec file: > > for configfile in *.config > do > echo "CONFIG_UNION_FS=m" >> $configfile > echo "CONFIG_UNION_FS_XATTR=y">> $configfile > echo "CONFIG_UNION_FS_DEBUG=y" >> $configfile > done > > and the build went fine. I haven't yet tried the new kernel and > module, but Erez mentioned in one of the messages about XATTR support > in unionfs thus: > > http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2008-May/005849.html > > >Andy, there's no xattr support in unionfs for 2.6.18 (the VFS was > lacking > >some vital support, I don't recommend it). So plz turn off > >CONFIG_UNION_FS_XATTR. > > However, Without the CONFIG_UNION_FS_XATTR=y insertion into spec file, > the build fails !! > > Hence I'm wondering whether will this workaround work ? And do we have > a solution to this issue already, which I may have missed ? Have to wait a while and see if I can build it I guess. Ian _______________________________________________ unionfs mailing list: http://unionfs.filesystems.org/ unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
