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) >>> >> >Received on Thu Jul 8 23:15:03 2010