Re: Still learning! (kernel help)

Disclaimer -- I use Debian.. and this may be more wordy than it has to
be.

I think I am conflicted about this issue (Compiling a non-distro
available kernel on an enterprise level distro) .. and won't say much
more about my personal conflict other than the purpose of CentOS is
scalability and enterprise scalability/package management. It may not be
the best thing out there for say laptops (why LVM a typical laptop?)..
but on single or multiple servers its strengths are enterprise level
flexibility.. if everything is kept up-to-date via binary packages on
all servers under your scope it would be easy to maintain as all the
software installed came from the same source.. can be transitioned
easily from server to server and so on.

That being said, there is a huge transition in-between 2.6.9 and 2.6.14
so when using a 2.6.9 be very indepth with your gui config and look over
every possible option that an old config may have nulled out, Typically
if you use a source package for this newer kernel it will work well
since it provides a config suitable for your distro. Importing an old
config should be fine, however if your distro uses an initrd you must
consider using it and not statically compiling in all the things you
think you want for a few different reasons. I can only say this based on
what Debian does when installing a packaged kernel, not really how
CentOS handles it, but they are going to be really close.

Mainly initrd's are not evil space mongering slowdowns, and are
incredibly useful. A distros packaged kernel will typically use an
initrd and a smart mkinitrd script to set up a minimal initrd to init
all your detected hardware. Including intelligent scripts for
initilalizing lvm/evms/raid setups, specific chipset drivers for
IDE/SCSI,etc.., and loading the file system module for your / mount.

Basically when you install the packaged kernel. It custom tunes an
initrd to your system, making the package work across multiple
motherboards from the same package. In debian they segregate x86 into
386, k7(-smp), and 686(-smp) which helps narrow down the different
packaged kernels that work with the stable distribution, they all have
the same modules available, however the processor and a few
other .config params are changed to optimize the kernel against the
target processor, simplifying many sysadmins jobs. I personally
maintain a small inter-company debian repository for some Via C3 tuned
kernels, our main routers are Via PD1000's which we have 5 of throughout
several offices of the company, they are slow to compile on however
quick enough and low power so we use them everywhere. Without a feed for
a stable kernel package that makes a specific initrd for each of the
servers (some differently configured) it would take more effort than I
want to offer to maintain seperate trees on all those unique hosts. I
also maintain a Geode tuned kernel package from 2.6.14 sources with a
very minimal set of modules for some embedded wireless routers, still
using an initrd to help load up some modules. This option also allows
me to load modules before the rootfs is mounted with specific parameters
if those need changed (mainly SquashFS/UnionFS).

Think that should be just enough beating around the bush? :) I don't
know how RPM packaging of a kernel works, only dpkg but if you are going
to go through the effort to compile 2.6.14 (from SRPM's I assume) you
should do it using a smart config (from the SRPM) that CentOS would
prefer, one configured not only to your processor but to the "enterprise
level" distribution you are using. Since debian 2.6.14 is in the
"unstable" dist, I backport it as well as udev and module-init-tools to
stable whenever I have to use it (which I rarely have to) and try to
compile and maintain the source package located on a machine I want to
be in charge of packaging kernels and extra packages I am going to use
in our infrastructure. I for the most part using the configs that the
distributions kernel package maintainers prefer. Bringing a working
config up from scratch isn't difficult, however I often run into systems
"Speed Racer Configed by Leet Haxors" and the ex-maintainers never kept
the kernel tree, threw away the configs and left out this one tiny
little module that could have been usefull. Instead of a bandaid
solution, getting the right tree, assuming the config, compiling all the
modules and installing just this one little .ko file
into /lib/modules/.../kernel/driver/somewhere/ where future admins will
never know what I did. I typically scrap the running kernel and install
an up-to-date kernel that the distro will have no problems with.
Cleaning out all non-distro related kernel poopies along the way.
Offering a lot of flexibility and a straight forward maintenance
solution to the admins.

This is a biased view from a person who has made a lot of mistakes along
the way :)

Let me know if this helps or makes you insane.

Shane

On Mon, 2006-01-02 at 13:09 -0900, Arthur Corliss wrote:
> On Mon, 2 Jan 2006, Damien Hull wrote:
>
> > It sounds like I should skip "make oldconfig" and just copy the kernel
> > config from /boot.
> >
> > I'm going to look at distcc before I do any kernel building. If I can
> > get it to work I should be able to compile a kernel before I get to old.
>
> FYI: if you're running a 2.6 kernel and you've configured support for it in
> there you can get the *currently* running kernel's config parameters from
> /proc/config.gz, which may be necessary if you haven't backed up your last
> kernel config into /boot|whatever.
>
> In either case you still need to run "make oldconfig" if you're migrating to a
> newer kernel. The whole point of this is just to import *your* settings along
> with setting (supposedly) sane defaults for new features along with their
> internal dependencies on other kernel features. That said, if you're just
> making changes in a previously configured kernel tree (such as if you want to
> enable new hardware support, etc.) you don't need to do this.
>
> Assuming you have a valid build environment building a kernel is a *lot*
> simpler than some of you may think. This may have been already discussed (and
> if so, I apologise) but let's go through a quick kernel compile using the pure
> kernel sources downloaded from kernel.org:
>
> 1) Start from a clean, unconfigured source tree and configure it
> for your architecture (assuming you've installed and symlinked it
> as /usr/src/linux):
>
> cd /usr/src/linux
> make mrproper
> make include/linux/version.h
> make include/asm # make symlinks on 2.4 source trees
> make include/linux/autoconf.h
>
> 2) Import your previous kernel config:
>
> gzip -dc /proc/config.gz > .config # or cp /boot/config-whatever \
> # ./.config
> yes "" | make oldconfig # You don't need the 'yes "" |' on 2.4 trees
>
> 3) Configure your kernel, review import for correctness, etc.:
>
> make {config|menuconfig|xconfig}
>
> 4) Make & install your kernel:
>
> make # make bzImage on 2.4 kernels
> # make modules on 2.4 kernels
> # make backups of previous /boot files, configure bootloader to
> # load those for backups
> cp System.map /boot/
> cp arch/i386/boot/bzImage /boot/vmlinuz
> cp .config /boot/vmlinux/current-config
> make modules_install
>
> 5) Recover disk space (optional):
>
> make clean
>
> The above scenario does not anticipate initrds, etc., just straight kernel
> loads via the bootloader.
>
> At this point, if you are just make alterations to your current config all you
> need to do are steps 3-5. Go through the entire bit if you're starting with a
> new kernel source tree.
>
> Things can be more entertaining when you run a 64 bit kernel with 32 bit
> userland, in which case you need to manually set the ARCH and CROSS_COMPILE
> make variables.
>
> Again: I haven't been watching this thread closely, so I apologise if I've
> just reiterated what others have posted. It just seemed that since the thread
> is continuing there's still some confusion. What I've described here is
> roughly what I do for my own distro and it works reliably. Though the 2.6
> kernel has seen enough radical changes that one can no longer blindly believe
> that a simple make oldconfig and compile will produce a working kernel. You
> *must* review what's configured to make sure it'll work. Oh, and don't mix
> I2O & Fusion MPT drivers. :-P
>
> --Arthur Corliss
> Bolverk's Lair -- http://arthur.corlissfamily.org/
> Digital Mages -- http://www.digitalmages.com/
> "Live Free or Die, the Only Way to Live" -- NH State Motto
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Jan 2 16:02:54 2006