CentOS - Aug 2010 - can i config/build/boot a new kernel on centos 5.5 with LVM?

(disclaimer:  i'll be a bit vague about some of this since i don't
have a test system to try to reproduce it until later today or this
weekend.)

  during a RHEL SA course i was teaching this week, i was using both
centos 5.5 and RHEL 6.0 beta 2 and, as a fun exercise, i was showing
how to "git" checkout the kernel source tree, configure it, build,
install and boot to a new kernel.  sadly, at no time did that
exercise actually work, so i just want to ask a general question --
should i, with a standard install of centos 5.5 with all of the
required development packages, be able to checkout the kernel source,
and build and boot a new kernel?

  upon reflection, the issues might have to do with the fact that LVM
was in use and perhaps the initrd didn't have LVM support built in
but, again, i can't check that until later today at the earliest.

  so, here's the hypothetical scenario i'm going to test later:

  * gateway, 64-bit laptop, with 64-bit centos 5.5, fully updated
  * /boot is primary ext4 partition
  * / and /home are logical volumes in a single volume group
  * "git clone" latest kernel source
  * "make defconfig"
  * "make"
  * "make modules_install"
  * "make install"

is there any reason why the above shouldn't work?  (and instead of
"make defconfig", i can copy the /boot/config file for the stock
kernel and "make oldconfig".  i'll almost certainly try both just
to
cover all the possibilities.)

  so ... should this theoretically work?  is there a web page that
actually walks through the process?  because we were having all kinds
of grief just installing the kernel or booting and failing to find the
root device (which is why i suspect something LVM-related.)

  i'm open to suggestions.  thanks.

rday

p.s.  obviuosly, i'd love to hear that someone else has already done
this and it worked just fine.

-- 

=======================================================================Robert P.
J. Day                               Waterloo, Ontario, CANADA

        Top-notch, inexpensive online Linux/OSS/kernel courses
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

On Friday 20 August 2010, Robert P. J. Day wrote:
>   (disclaimer:  i'll be a bit vague about some of this since i
don't
> have a test system to try to reproduce it until later today or this
> weekend.)
>
>   during a RHEL SA course i was teaching this week, i was using both
> centos 5.5 and RHEL 6.0 beta 2 and, as a fun exercise, i was showing
> how to "git" checkout the kernel source tree, configure it,
build,
> install and boot to a new kernel.
Rolling your own kernel is really considered a last resort on CentOS/RHEL. It 
seems like a strange exercise to select for an RHEL SA course (IMHO). If you 
really want/need to do this then reading through 
http://wiki.centos.org/HowTos/Custom_Kernel may be a good idea.
> sadly, at no time did that 
> exercise actually work, so i just want to ask a general question --
> should i, with a standard install of centos 5.5 with all of the
> required development packages, be able to checkout the kernel source,
> and build and boot a new kernel?
If done properly, yes. However it's not like just any git-checked-out 
kernel+config will make you happy.
>   upon reflection, the issues might have to do with the fact that LVM
> was in use and perhaps the initrd didn't have LVM support built in
> but, again, i can't check that until later today at the earliest.
...

LVM will be automatically added to the initrd by mkinitrd (assuming the kernel 
it tries to use has the required modules).

/Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.centos.org/pipermail/centos/attachments/20100820/72233175/attachment-0002.sig>