latest kernel? [General Linux]

From: Keith Keller on 15 Mar 2010 13:46

On 2010-03-15, Rahul <nospam(a)nospam.invalid> wrote:
>
> Thanks Moe! Usually I'm happy to let package-management systems do their
> thing without me interfering, but kernels are in a sense special. I was
> just wondering if it might be practical to do userspace-applications under
> yum but just use pristine kernel.org kernels. [I've also read some
> disparaging remarks on the kernel mailing list against using kernels
> compiled by distributors as opposed to pristine kernels. Not sure how
> relevant this is.]
>
> I guess I need to read more!

Specifically, you need to know more about which kernel features you
require, and whether those features have changed from the userland
software your distro provides to the mainline kernel. This doesn't
happen often for modules that are already fairly stable, but if you are
relying on a more experimental kernel module it could change fairly
rapidly through various kernel versions.

There are cans of worms in either direction. If you have many systems
and build your own kernel for each of them, then every time there's a
security update you have to rebuild the kernel for each system. If you
are lucky and all your builds are the same, that's not a huge problem,
but if each build is customized you could be in for a lot of tedious
work. OTOH, if a security update is slow to propagate back to your
distro (because it has to be ported, for example), your box may be
vulnerable longer than it would had you followed the mainline kernel.

FWIW, Slackware is one of the few distros I know that does not modify
its kernel source locally. So following the mainline kernel there is
fantastically easy. :) Like Grant, I don't know precisely how far away
the RHEL kernels are from mainline, but their kernel is currently based
off of 2.6.18 and then patched, so it's probably not insignificant.

--keith

--
kkeller-usenet(a)wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

From: unruh on 15 Mar 2010 15:11

On 2010-03-15, Keith Keller <kkeller-usenet(a)wombat.san-francisco.ca.us> wrote:
> On 2010-03-15, Rahul <nospam(a)nospam.invalid> wrote:
>>
>> Thanks Moe! Usually I'm happy to let package-management systems do their
>> thing without me interfering, but kernels are in a sense special. I was
>> just wondering if it might be practical to do userspace-applications under
>> yum but just use pristine kernel.org kernels. [I've also read some
>> disparaging remarks on the kernel mailing list against using kernels
>> compiled by distributors as opposed to pristine kernels. Not sure how
>> relevant this is.]
>>
>> I guess I need to read more!
>
> Specifically, you need to know more about which kernel features you
> require, and whether those features have changed from the userland
> software your distro provides to the mainline kernel. This doesn't
> happen often for modules that are already fairly stable, but if you are
> relying on a more experimental kernel module it could change fairly
> rapidly through various kernel versions.
>
> There are cans of worms in either direction. If you have many systems
> and build your own kernel for each of them, then every time there's a
> security update you have to rebuild the kernel for each system. If you
> are lucky and all your builds are the same, that's not a huge problem,
> but if each build is customized you could be in for a lot of tedious
> work. OTOH, if a security update is slow to propagate back to your
> distro (because it has to be ported, for example), your box may be
> vulnerable longer than it would had you followed the mainline kernel.
>
> FWIW, Slackware is one of the few distros I know that does not modify
> its kernel source locally. So following the mainline kernel there is
> fantastically easy. :) Like Grant, I don't know precisely how far away
> the RHEL kernels are from mainline, but their kernel is currently based
> off of 2.6.18 and then patched, so it's probably not insignificant.

Often the distributions will port stuff from the MM kernels into their
kernels as well, plus adding modules, etc not included in the mainline
(Intel modules, sound card modules,...)

>
> --keith
>

From: Grant on 15 Mar 2010 16:32

On Mon, 15 Mar 2010 10:46:22 -0700, Keith Keller <kkeller-usenet(a)wombat.san-francisco.ca.us> wrote:

>On 2010-03-15, Rahul <nospam(a)nospam.invalid> wrote:
>>
>> Thanks Moe! Usually I'm happy to let package-management systems do their
>> thing without me interfering, but kernels are in a sense special. I was
>> just wondering if it might be practical to do userspace-applications under
>> yum but just use pristine kernel.org kernels. [I've also read some
>> disparaging remarks on the kernel mailing list against using kernels
>> compiled by distributors as opposed to pristine kernels. Not sure how
>> relevant this is.]
>>
>> I guess I need to read more!
>
>Specifically, you need to know more about which kernel features you
>require, and whether those features have changed from the userland
>software your distro provides to the mainline kernel. This doesn't
>happen often for modules that are already fairly stable, but if you are
>relying on a more experimental kernel module it could change fairly
>rapidly through various kernel versions.
>
>There are cans of worms in either direction. If you have many systems
>and build your own kernel for each of them, then every time there's a
>security update you have to rebuild the kernel for each system. If you
>are lucky and all your builds are the same, that's not a huge problem,
>but if each build is customized you could be in for a lot of tedious
>work.

I don't think it's that tedious work to stay up with latest -stable.
Two were recently released, 2.6.32.10 and 2.6.33.1.

So I'm updating four Slackware boxes, each with a unique custom config.

For 2.6.32.9 -> 2.6.32.10 the sequence is to rename source tree, revert
the 2.6.32.9 patch, apply the 2.6.32.10 patch, make, then I call a script
to perform the 'tedious' part of make install, copy files to /boot, edit
lilo.conf and offer to restart (while in su root mode).

For 2.6.33 -> 2.6.33.1 one skips the revert prior step.

I keep the kernel source under ~/linux, rather than /usr/src/linux, which
is where the distro kernel source lives. Custom kernels should have
unique names from the distro kernel so you don't accidentally remove
modules.

After updating the two releases, I have:
grant(a)pooh64:~/linux$ ls -l
total 4
drwxr-xr-x 23 grant wheel 800 2009-12-03 14:51 linux-2.6.32/
drwxr-xr-x 24 grant wheel 1728 2010-03-16 06:28 linux-2.6.32.10a/
drwxr-xr-x 23 grant wheel 800 2010-03-13 08:51 linux-2.6.33/
drwxr-xr-x 24 grant wheel 1760 2010-03-16 06:39 linux-2.6.33.1a/

These trees are hardlinked, so on-disk space is not as much as it looks.

The source directories with 'a' suffix are the actual trees used for
compiling the kernel, while the 2.6.32 and 2.6.33 directories are for
the main release source. Reason for this is a) I may skip several
stable releases and need to create one from scratch, or b) I may
use the main release as a basis for the next. I download each even
numbered main release. For all -stable versions and odd numbered
releases I only need to download the patches.

Occasionally I make patches for the kernel, that's when I use another
tree with 'b' suffix for a -> b patchset generation.

The kernel source tarballs and patches are kept on one machine, nfs
exported to the rest:

grant(a)deltree:~$ ls -l /home/common/linux/
total 80001
-rw-r--r-- 1 grant users 64424138 2009-12-03 16:24 linux-2.6.32.tar.bz2
-rw-r--r-- 1 grant users 523958 2010-01-29 10:24 patch-2.6.27.45.gz
-rw-r--r-- 1 grant users 343964 2010-03-16 03:13 patch-2.6.32.10.gz
-rw-r--r-- 1 grant users 276188 2010-02-24 02:43 patch-2.6.32.9.gz
-rw-r--r-- 1 grant users 51526 2010-03-16 03:14 patch-2.6.33.1.gz
-rw-r--r-- 1 grant users 10551136 2010-02-25 06:14 patch-2.6.33.bz2
-rw-r--r-- 1 grant users 5663642 2010-03-09 07:28 patch-2.6.34-rc1.bz2

So the command sequence to update from 2.6.32.9 to 2.6.32.10 was:

ssh into target box (I use PuTTY from windoze)
$ cd linux
$ ls -l
$ mv linux-2.6.32.9a linux-2.6.32.10a
$ cd linux-2.6.32.10a
$ zcat /home/common/linux/patch-2.6.32.9.gz |patch -p1 -R
$ zcat /home/common/linux/patch-2.6.32.10.gz |patch -p1
$ make
$ bk # my build scripts -> buildkernel*
ask for root password
make install -> hooks /sbin/installkernel to:
copy versioned bzImage, .config and System.map to /boot
edit lilo.conf (manually)
offer to reboot
- - -
It's not much to do, as one reuses the .config from previous version
there's no mucking about with make *config.

grant(a)pooh64:~$ ls -lrt /boot/
....
-rw-r--r-- 1 root root 41662 2010-03-16 06:28 config-2.6.32.10a
-rw-r--r-- 1 root root 2975888 2010-03-16 06:28 bzImage-2.6.32.10a
-rw-r--r-- 1 root root 1485515 2010-03-16 06:28 System.map-2.6.32.10a
-rw-r--r-- 1 root root 46626 2010-03-16 06:39 config-2.6.33.1a
-rw-r--r-- 1 root root 3016304 2010-03-16 06:39 bzImage-2.6.33.1a
-rw-r--r-- 1 root root 1480056 2010-03-16 06:39 System.map-2.6.33.1a
-rw------- 1 root root 22016 2010-03-16 06:40 map

Scripts are at http://bugs.id.au/bash/kernel/ but I must warn you that
they are overly complex, allowing for hosted builds for slow machines
and work for 2.4 series kernels :) I plan to update them, but other
stuff keeps me away. (Besides, they aint broke...)

I've been using this method for years, perhaps clunky but works well.

It's taken much longer to write this reply than update both releases
on the faster Core2Duo box, three other slow machines (~500MHz) are
still in the compile stage.

> OTOH, if a security update is slow to propagate back to your
>distro (because it has to be ported, for example), your box may be
>vulnerable longer than it would had you followed the mainline kernel.
>
>FWIW, Slackware is one of the few distros I know that does not modify
>its kernel source locally. So following the mainline kernel there is
>fantastically easy. :)

Yes, I describe one method above -- there's many ways to do this,
important thing is to automate the tedious bits ;)

Finally, there's a destructor script to remove old kernel files:
root(a)pooh64:~# /home/common/bin/rm-old-kernels

rm-old-kernels:
remove old kernel files not referenced by /etc/lilo.conf

Reading:
/etc/lilo.conf
/boot
/lib/modules

Process symlinks:
vmlinuz -> 2.6.29.6: okay

Kernel versions found:
/etc/lilo.conf /boot /lib/modules
2.6.29.6 2.6.29.6 2.6.29.6
- 2.6.32.10-rc1a 2.6.32.10-rc1a
2.6.32.10a 2.6.32.10a 2.6.32.10a
- 2.6.32.9a 2.6.32.9a
- 2.6.33.1-rc1a 2.6.33.1-rc1a
2.6.33.1a 2.6.33.1a 2.6.33.1a
- 2.6.33a 2.6.33a

Candidates for removal: 2.6.32.10-rc1a 2.6.32.10-rc1a
2.6.32.9a 2.6.32.9a
2.6.33.1-rc1a 2.6.33.1-rc1a
2.6.33a 2.6.33a

Removal: use all|y|n|q for all, yes, no or quit, default no:
rm -f /boot/*2.6.32.10-rc1a ? all
removed
rm -f /boot/*2.6.32.9a
rm -f /boot/*2.6.33.1-rc1a
rm -f /boot/*2.6.33a
rm -rf /lib/modules/2.6.32.10-rc1a
rm -rf /lib/modules/2.6.32.9a
rm -rf /lib/modules/2.6.33.1-rc1a
rm -rf /lib/modules/2.6.33a
Done!

Grant.

From: Grant on 15 Mar 2010 16:48

On Mon, 15 Mar 2010 19:11:16 GMT, unruh <unruh(a)wormhole.physics.ubc.ca> wrote:

....
>Often the distributions will port stuff from the MM kernels into their
>kernels as well, plus adding modules, etc not included in the mainline
>(Intel modules, sound card modules,...)

That's an outdated bit o' fluff :)

These days the kernel has the staging tree for drivers nearly ready
for prime time -- enabling wider testing.

Grant.

From: Keith Keller on 15 Mar 2010 23:36

On 2010-03-16, Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote:
>
> That's going to depend on how much your distribution is playing
> games with the kernel - it's another item to consider when choosing
> a distribution, but people rarely are aware of it, let alone think
> what's going on. I think it's been mentioned that you are using
> Red Hat, and _A_ solution to that is to grab the source rpm that
> corresponds to the kernel you are using. I don't have a listing
> handy, but this (from an old Fedora 11 listing) is representative:
>
> kernel-2.6.29.6-217.2.8.fc11.i586.rpm
> kernel-PAE-2.6.29.6-217.2.8.fc11.i686.rpm
> kernel-2.6.29.6-217.2.8.fc11.src.rpm

I take exception to this on two levels. First, Fedora is *supposed* to
be experimental. To expect its kernel sources to be pristine is a bit
much. Second, more applicable to RH, some of those patches are security
backports to the kernel they used at the time, under the basic idea that
as much should be ''stable'' as possible through the EL lines. So
simply looking at the number of patches is not a fair test. (Comparing
the first kernel, e.g., kernel-2.6.29.6-1.xxxxx, to 2.6.29.6, would be a
little fairer.)

On the other side of that, yes, RH still does patch their kernel, and
have in the past produced kernels that were not very high quality
compared to the main line. (But I haven't had any problems with CentOS
5 kernels, so perhaps this situation is improving, or perhaps I'm simply
not using it in a way that exposes the RH kernel's flaws.)

--keith

--
kkeller-usenet(a)wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information