That would either require it be paravirtualized to run the newer
kernel (e.g. the same version as the host), which doesn't solve any of
his problems with SL6 kernel on SL5 userland, or fully virtualized
and he still runs a custom kernel in the VM.
Either way, virtualizing this doesn't solve the problem he's trying to
solve, unless I missed something.
[Did you mean chroot?]
- Rich
On Mon, Apr 16, 2012 at 6:48 AM, Oleg Sadov <[log in to unmask]> wrote:
> 15/04/2012 17:06 -0700, Konstantin Olchanski wrote:
>> On Sun, Apr 15, 2012 at 02:46:49PM -0500, Kevin K wrote:
>> > Depending on what special features you might use on your system
>> (virtualization, third party drivers), it might be possible to build a
>> kernel from kernel.org. I've tried this in the past but since the
>> latest kernel still didn't properly support the broken hardware I
>> didn't pursue it further.
>>
>>
>> Yes, what you say is possible. I run a few SL5 machines with a custom
>> built 2.6.34 kernel (the funny hardware requires non-default access
>> method to PCI config space).
>>
>> Last I remember, it was not too hard to build a vanilla linux kernel that
>> booted the SL5 userland. I do remember a few gotchas - some boot scripts expected
>> some drivers to be loadable modules (I had them compiled into the kernel),
>> autofs did not work because /dev/random broke (SL5 kernel uses the network
>> as source of randomness, but vanilla kernel does not, and there is no other
>> hardware present in the system). Took maybe half a day to sort this all out.
>> (I am not looking forward to repeat this with the 3.x kernels).
>>
>>
>> > On Apr 15, 2012, at 1:46 PM, Keith Lofstrom wrote:
>> >
>> > > I'm running S.L. 5.6 on a few machines, and have grown somewhat
>> > > dependent on it. However, there are features in the kernel
>> > > that comes with 6.2 (like USB3) which I would like to have.
>> > >
>> > > Is it possible to upgrade just the kernel and associated modules
>> > > and "miscellaneous"?
>> > >
>> > > I assume this is tricky, and fraught with dangers, and the usual
>> > > cautions (make backups, work on a copy of the disk, tweak yum
>> > > updates so they won't regress the 2.6.32 kernel, etc) apply.
>>
>>
>> I do not see any danger or special caution - if an SL6 kernel would boot
>> SL5 userland, it should run okey. But you will run into trouble with
>> userland stuff required to support the kernel - udev, mkinitrd, mdadm & co -
>> the SL5 stock tools might be too old for the recent kernels.
>>
>> That said, where I am, lack of support for new hardware is the main reason
>> we move from SL3 to SL4 to SL5 to SL6.
>>
>> For new kernel features, you can run mongrel systems with mismatched
>> userland and kernels, but at some point the cost of diverging
>> from the mainstream becomes bigger than the cost of moving
>> all your apps to latest SL. (At which point effort of creating
>> and maintaining a mongrel system is wasted; while the effort
>> of moving apps to latest SL is mostly in understanding your apps
>> and in keeping *them* up to date, which you should do anyway,
>> regardless).
>
> The most simple solution for this problem -- using virtualized SL5
> installation on SL6 host.
>
>> K.O.
>>
>>
>>
>> > >
>> > > For now, I just want to know whether this is worthy of further
>> > > consideration, or instead I should set aside a few weeks to
>> > > upgrade everything then rebuild a lot of poorly written custom
>> > > apps.
>> > >
>> > > Keith
>> > >
>> > > --
>> > > Keith Lofstrom [log in to unmask] Voice (503)-520-1993
>> > > KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
>> > > Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
>>
|
