RH7.1 -> 2.4.12
Chris.
within a RedHat framework; newly concerned with things like RPM
manageability, I'm somewhat paranoid. Any pointers or affirmations
would be greatly appreciated.
I needed functionality from the newer 2.4.x kernel (specifically, USB
support for my Clie), but RedHat only has 2.4.3-12 on their updates
site. So I downloaded and installed kernel-source-2.4.3-12.i386.rpm
and then downloaded and untar'd linux-2.4.12.tar.gz from ftp.us.kernel.org
(this was unpacked in /root to avoid confusion). I then copied
/usr/src/linux-2.4/configs/kernel-2.4.3-i686.config to /root/linux/.config
and ran `make config` which used .config for its defaults. I ran through
the config hitting 'enter' for pretty much everything, hoping the kernel
would be built more or less the way RedHat did so, with any additional
features being set to reasonably sane defaults.
I ran the usual litany of 'make clean / dep / bzImage / modules /
modules_install ', going back both to comment out CONFIG_SCSI_CPQFCTS=m
(apparently Alan Cox is aware of the 'brokeness' of this piece, and I'll never
need it), and also to edit drivers/parport/ieee1284_ops.c in accordance with
other instructions, to eliminate two hard errors that caused the build process
to fail. (Should a 'production' kernel have errors of this nature?)
Having built the kernel, I copied cp arch/i386/boot/bzImage to vmlinuz-2.4.12
in /boot and /boot_backup (different drives), built an initrd (I'm using
dev_md in RAID1 for everything but the pair of /boot partitions), edited
/etc/lilo.conf to create a new 'linux' image (renaming the default image
'linux-redhat') and ran `lilo`.
Hopefully, I have a system that isn't too "broken" as far as maintaining it
with RPM once RedHat catches up with the kernel tree.
Thoughts?
Thanks in advance!
Michael Lee Yohe
> within a RedHat framework; newly concerned with things like RPM
> manageability, I'm somewhat paranoid. Any pointers or affirmations
> would be greatly appreciated.
>
> I needed functionality from the newer 2.4.x kernel (specifically, USB
> support for my Clie), but RedHat only has 2.4.3-12 on their updates
> site. So I downloaded and installed kernel-source-2.4.3-12.i386.rpm
You can always opt to go for the Rawhide version of the kernel -
available in source RPM. There is often a much-more recent version of
the kernel available for you to tinker with. Mind you, after installing
a Red Hat source RPM-based kernel, do a make mrproper, and then copy the
.config file for the default configuration you wish to support.
--
Michael Lee Yohe (myohe+...@redhat.com)
Software Developer, Engineering Services
Red Hat, Inc.
QUIPd 0.20: (427 of 530)
-> We seek peace, knowing that peace is the climate of freedom.
-> - Dwight D. Eisenhower
Dave Brown
> Wondering if I did this right. I'm relatively new to doing things
> within a RedHat framework; newly concerned with things like RPM
> manageability, I'm somewhat paranoid. Any pointers or affirmations
> would be greatly appreciated.
>
> I needed functionality from the newer 2.4.x kernel (specifically, USB
> support for my Clie), but RedHat only has 2.4.3-12 on their updates
> site. So I downloaded and installed kernel-source-2.4.3-12.i386.rpm
> and then downloaded and untar'd linux-2.4.12.tar.gz from ftp.us.kernel.org
> (this was unpacked in /root to avoid confusion). I then copied
> /usr/src/linux-2.4/configs/kernel-2.4.3-i686.config to /root/linux/.config
> and ran `make config` which used .config for its defaults. I ran through
> the config hitting 'enter' for pretty much everything, hoping the kernel
> would be built more or less the way RedHat did so, with any additional
> features being set to reasonably sane defaults.
> Thoughts?
You didn't need to do all this in /root. Normally, when you extract a
package from www.kernel.org, you'd do it in /usr/src, making sure that
you'd removed any symlink "linux" first; (kernel.org kernel trees are
built in a "linux" directory). After extraction, rename "linux" to
"linux-2.4.12", and then recreate the symlink "linux" to it. No problem
keeping more than one kernel source tree around--if you have the disk
space.
Note, however, that rpm doesn't know that this is installed, so you
won't be able to upgrade kernel-source package and have it deal with
your 2.4.12 tree--rpm only knows about your 2.4.3 tree.
Try to keep your paranoia under control... it's only a game. :)
--
Dave Brown Austin, TX
Leonard Evens
> Wondering if I did this right. I'm relatively new to doing things
> within a RedHat framework; newly concerned with things like RPM
> manageability, I'm somewhat paranoid. Any pointers or affirmations
> would be greatly appreciated.
As Michael Yohe pointed out, you could always get the rpm package
in rawhide.redhat.com (where you have to do some searching to find it).
The last time I looked, they had 2.4.9 there. That would be easier than
making your own kernel.
If you get a kernel from kernel.org, you should consider getting and
applying an ac patch. These are going to be the most "RedHat
like", since Alan Cox works for RedHat. These can be found at
kernel.org in the appropriate place under people/alan.
But when I used the approved procedure for applying the patch,
I found that I had to rename the directory linux.vanilla because that
is what he had in the patch.
--
Leonard Evens l...@math.northwestern.edu 847-491-5537
Dept. of Mathematics, Northwestern Univ., Evanston, IL 60208
Wayne Pollock
can use the config files that RH used. These can be found in the
old /usr/src/linux directory (which you should've renamed before
installing the new kernel source), in the subdirectory "configs".
I have details directions to build a kernel (2.4.9) on a RH system at:
http://www.hcc.cc.fl.us/pollock/Unix/KernelRebuild.htm
(This is a new "HOW-TO" document since I didn't like the old one
much. Feedback is welcome, as I'm trying to improve the document.)
Hope this helps!
-Wayne
Leonard Evens
wrote:
> If you install the new kernel without wiping out the old one, you can
> use the config files that RH used. These can be found in the old
> /usr/src/linux directory (which you should've renamed before installing
> the new kernel source), in the subdirectory "configs".
>
> I have details directions to build a kernel (2.4.9) on a RH system at:
> http://www.hcc.cc.fl.us/pollock/Unix/KernelRebuild.htm
> (This is a new "HOW-TO" document since I didn't like the old one much.
> Feedback is welcome, as I'm trying to improve the document.)
This looks like it would be helpful.
But I do have one question. What about the kernel headers? If you use
RedHat packages, you first install the package kernel-headers. This
installs the file kernel.h-dist-no and links it to kernel.h. That file
says it is created at boot, but it isn't. Just what is its function,
and is it necessary? The rest of kernel-headers is the /usr/include/asm
and /usr/include/linux trees. These are also in the tree created by the
kernel-source package, so they presumably are not needed to create
a new kernel via RedHat procedures, and if you get your source from
kernel.org, they wouldn't be used. So exactly what are they for,
and if one creates a new kernel using source from kernel.org, should
one reconstruct those trees using what is included with the tar file
and which were used to compile the kernel?
Wayne
>
> In article <3BCBE6DD...@acm.org>, "Wayne Pollock" <pol...@acm.org>
> wrote:
>
> > If you install the new kernel without wiping out the old one, you can
> > use the config files that RH used. These can be found in the old
> > /usr/src/linux directory (which you should've renamed before installing
> > the new kernel source), in the subdirectory "configs".
> >
> > I have details directions to build a kernel (2.4.9) on a RH system at:
> > http://www.hcc.cc.fl.us/pollock/Unix/KernelRebuild.htm
> > (This is a new "HOW-TO" document since I didn't like the old one much.
> > Feedback is welcome, as I'm trying to improve the document.)
>
> This looks like it would be helpful.
>
> But I do have one question. What about the kernel headers? If you use
> RedHat packages, you first install the package kernel-headers. This
> installs the file kernel.h-dist-no and links it to kernel.h. That file
> says it is created at boot, but it isn't. Just what is its function,
> and is it necessary? The rest of kernel-headers is the /usr/include/asm
> and /usr/include/linux trees. These are also in the tree created by the
> kernel-source package, so they presumably are not needed to create
> a new kernel via RedHat procedures, and if you get your source from
> kernel.org, they wouldn't be used. So exactly what are they for,
> and if one creates a new kernel using source from kernel.org, should
> one reconstruct those trees using what is included with the tar file
> and which were used to compile the kernel?
AFAIK:
The kernel header files are not used to build the kernel, the
kernel uses the copies of the files in /usr/src/linux. The
"asm" and "linux" directories in /usr/include are for kernel
related software, stuff like "ps" comand for example. When
building such programs the definition of kernel data structutes
(such as the process table) are needed.
As for the kernel.h file that Red Hat copies to /boot, it appears
different than /usr/include/linux/kernel.h (linked to
/usr/src/linux/include//linux/kernel.h).
If someone knows better, please let me know!
-Wayne
Michael Lee Yohe
> kernel uses the copies of the files in /usr/src/linux. The
> "asm" and "linux" directories in /usr/include are for kernel
> related software, stuff like "ps" comand for example. When
> building such programs the definition of kernel data structutes
> (such as the process table) are needed.
This is not correct - each kernel release must be properly paired with
the latest headers. Even if the source code references something like:
#include <linux/proc_fs.h>
... the -I parameter for GCC could substitute an include path so that
the kernel headers that come with the kernel are used instead of the
older stock headers (which is what actually happens when you use a new
kernel). To check out what's going on, look at the ".depend" file after
a "make dep".
--
Michael Lee Yohe (myohe+...@redhat.com)
Software Developer, Engineering Services
Red Hat, Inc.
QUIPd 0.20: (223 of 531)
-> They've managed to keep their unemployment low although their
-> overall unemployment is high.
-> - Bill Clinton, discussing taxes and employment
Wayne Pollock
>
> > The kernel header files are not used to build the kernel, the
> > kernel uses the copies of the files in /usr/src/linux. The
> > "asm" and "linux" directories in /usr/include are for kernel
> > related software, stuff like "ps" comand for example. When
> > building such programs the definition of kernel data structutes
> > (such as the process table) are needed.
>
> This is not correct - each kernel release must be properly paired with
> the latest headers. Even if the source code references something like:
>
> #include <linux/proc_fs.h>
>
> ... the -I parameter for GCC could substitute an include path so that
> the kernel headers that come with the kernel are used instead of the
> older stock headers (which is what actually happens when you use a new
> kernel). To check out what's going on, look at the ".depend" file after
> a "make dep".
>
Actually that's what I was trying to say. The kernel makefiles
do use "-I" to use the /usr/src/linux/include/* files, and will
thus ignore older /usr/include/linux/* files. but if you
later rebuild "ps", it does need to current files. The best
idea is to either copy or link the header files that came with
the kernel you're using into the /usr/include directory. That way
everyone is happily using the same (latest) kernel related header
files.
Sorry for the confusion!
-Wayne