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...
> 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)
>>
>
-- Daniel Hokka ZakrissonReceived on Thu Jul 8 22:07:15 2010