On 07/08/2010 02:06 PM, Daniel Hokka Zakrisson wrote: > Roderick A. Anderson wrote: >> On 07/08/2010 11:16 AM, Daniel Hokka Zakrisson wrote: >>> Edward Capriolo wrote: >>>> On Wed, Jul 7, 2010 at 6:58 PM, Roderick A. Anderson >>>> <raanders@cyber-office.net> wrote: >>>>> On 07/07/2010 02:49 PM, Roderick A. Anderson wrote: >>>>>> >>>>>> On 07/07/2010 01:14 PM, Daniel Hokka Zakrisson wrote: >>>>>>> >>>>>>> Roderick A. Anderson wrote: >>>>>>>> >>>>>>>> On 07/06/2010 08:25 PM, Daniel Hokka Zakrisson wrote: >>>>>>>>> >>>>>>>>> Roderick A. Anderson wrote: >>>>>> >>>>>> <snip/> >>>>>> >>>>>>> The source RPMs are available from the repository, >>>>>>> http://rpm.hozac.com/dhozac/centos/5/vserver/SRPMS/ and spec files etc >>>>>>> from http://src.hozac.com/viewvc/rpms/ (requires IPv6). >>>>>> >>>>>> OK something new to get into. IPv6. I've been able to avoid it so far. :-) >>>>>> >>>>>> I am getting an error from your repo. PkgKey 44 doesn't exist? >>>>> >>>>> Duh! >>>>> >>>>> yum clean all >>>>> yum clean metadata >>>>> >>>>> >>>>> Rod >>>>> -- >>>>>> >>>>>> That ring a bell for you or anyone else. I'm sure Google will have some >>>>>> input when I get to it. >>>>>> >>>>>> >>>>>> Rod >>>>> >>>>> >>>> >>>> So the challenge with redhat/centos is the way kernel patches are >>>> backported. It is very intensive to applying the myriad backported >>>> patches as well as the vserver patches and be able to deal with the >>>> conflicts. >>> >>> It's not really that hard, just time-consuming to do for every single >>> release. That is why I gave up and created a vanilla kernel instead. >> >> Is that how you created those on your repo? I got lazy and just did an >> update of util-vserver*. The kernel I'm runnning (from your RPM) is >> 2.6.22.19-vs2.3.0.34.1 (March 2008.) > > Yes. It's a vanilla kernel with the vserver patch. > >> I see a 2.6.27.39-7.vs2.3.0.36.7.9 (November 2009) in the repo but yum >> doesn't see/recognize/use it. Can you clue-stick me? Should even be >> trying to it? > > I disabled this after identifying some issues with it. I haven't had > time to fix them all, though I should restart with 2.6.32 or 33 soonish. > Most of the issues are not in the kernel itself, but with everything > around it. mkinitrd sometimes needs to know about new module names, and > sometimes module-init-tools needs an update. However, when I get some > round 'tuits, that is on the list of things to tackle... Thanks. I was thinking it was not-ready-for-prime-time. :-) I had succeeded in build a vanilla kernel with the LV patch but wasn't sure that was the correct thing to do. Beside, kernel-wise, I was up-to-date. It was the utils I was behind on. I am in the process of building a yum repo mirror for CentOS and will expand it to include Linux-Vserver soon-ish. I too suffer from a shortage of TUITs (type: round.) Rod -- > >> Rod >> -- >>> For RHEL though, your issue is more that it is based on 2.6.18, which >>> would mean an ancient Linux-VServer patch, or, trying to backport a >>> new patch to an ancient kernel, neither of which is really feasible. >>> >>>> For fc12 I took the approach of applying vserver patch first and then >>>> removing anything that conflicted with it.. >>> >>> Have you validated the correctness of that? Patches are quite often >>> interdependent... >>> >>>> http://www.jointhegrid.com/fc12-vserver-repo/ >>>> >>>> fc12 does not backport many patches (30 or so) only 2 conflicted. with >>>> Cent/RHEL you are probably going to get thousands of conflicts. I >>>> would use RPM to build and deploy the kernel but trying to match patch >>>> for patch is impossible (IMHO) >>> >> >