Subject: Re: [vserver] Developer recommendations.
From: "Roderick A. Anderson" <raanders@cyber-office.net>
Date: Thu, 08 Jul 2010 15:14:15 -0700

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)
>>>
>>
>