Custom kernel RPM/SRPM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Thu, 2005-11-17 at 08:22 -0500, Jim Perrin wrote:
> Pardon me while I pull out Bryan J Smith's soap box for a minute (I'm
> SORRY... I couldn't resist. It's nothing personal Bryan..

No!  It's my soapbox and you can't play with it!  @-P

> just felt like some pre-coffee humor this morning) and preach about NOT
> REBUILDING your own enterprise kernel. I won't preach too much though,
> as you're on the right track with it. The best how-to that I'm aware
> of so far is currently here ->
> http://crab-lab.zool.ohiou.edu/kevin/kernel-compilation-tutorial-en/ 
> and details the basic steps you should take.

As Jim pointed out, at this point, it's better:

A)  to the "prep" (-bp)
B)  change what you want directly in the ./BUILD/kernel-* dir
C)  finish off the "build" (-bb)

You don't want to run arbitrary commands in any order.  I've seen the
SPEC files _differ_ in command order both before and after the prep.
You should also _avoid_ building on the "root" filesystem.  It's best to
stay in the chroot environment.

I've put up my own Blog on this:  
http://thebs413.blogspot.com/2005/10/kernel-26-on-fedora-based-systems.html

Select commentary ..

 "This addresses many issues, including:

  1. Include all components to complete a build
  2. Ensure exact steps to complete a build
  3. Avoid negative affects to files in the production system (chroot)
  4. Force documented changes with source, SPEC, etc...

  [ #4 is, of course, optional -- only if you modify the SPEC with
    your changes / patch files ]

  As of Red Hat Linux 7, I personally and professionally stopped
  building kernels from kernel-source[code] ... The exact order and
  requirements in not only building but even "prepping" the kernel
  source tree for 3rd party kernel modules is extremely important.
  But beyond that, the "mrproper" target can do some particularly
  nasty things to your systems' /usr/include and other directories.
  In the kernel.src.rpm build under the chroot, the 
  system's /usr/include and other directories are not touched, and
  they have their own, self-contained support.
  ...
  That will safely prep the kernel in the RPM chroot environment into
  a mode that is "ready to use" under
  /usr/src/redhat/BUILD/kernel-2.6*/linux-2.6*/, although you should
  consult the kernel-2.6.spec file to see what Makefile targets have
  and have not been run. You may wish to create a symbolic linke
  to /usr/src/linux-`uname -r` but be careful when executing any
  Makefile targets in the unprotected, root filesystem of the
  system."

> /BJS flamesuit ON!

A flamesuit won't protect you from my thermonuclear blasts.  ;->


-- 
Bryan J. Smith   b.j.smith@xxxxxxxx   http://thebs413.blogspot.com
-------------------------------------------------------------------
For everything else *COUGH*commercials*COUGH* there's "ManningCard"



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux