On Sat, Jul 2, 2011 at 2:40 PM, Teck Choon Giam <[log in to unmask]> wrote:
> On Sat, Jul 2, 2011 at 2:24 PM, Steven Haigh <[log in to unmask]> wrote:
>> On 2/07/2011 12:26 PM, Teck Choon Giam wrote:
>>>>
>>>> Name: kernel-%{pkg_name}
>>>> Version: %{kvmajor}
>>>> Release: %{pkg_release}%{?revision}%{?localrel}
>>>>
>>>> Your package name is kernel-xen.
>>>> Your version is 2.6.32
>>>> Your release is 1%{?revision}%{?localrel}
>>>
>>> You need to fix many issues in your spec file.  One of them is the
>>> %{version} and %{release} as from your spec file you seems to have
>>> confusion and from that confusion you will have issues with packaging
>>> your kernel package module.  Personally I will not include arch in
>>> that and why you do so?  I mean %define KRELEASE
>>> %{pkg_name}-%{version}-%{release}.%{_target_cpu} ... why use
>>> %{_target_cpu} here?
>>
>> Thanks for the pointers on this. I went through everything with a fine tooth
>> comb and I've managed to get a kernel RPM to build, install correctly, and
>> I'm just about to reboot and test it (once the backup is complete!)
>
> Glad that you have overcome those issues... ... I hope that isn't
> going to end like that... you lack of -devel package as well for your
> own kernel package.  Imagine if you need to compile other module(s)
> and without the source/devel package... you will have issues... ...
>
>> Hopefully, I should have a working SL6 Xen Dom0 kernel built from 2.6.32.41
>> & Xen 4.1.1 available for testing (x86_64 only at this stage)
>
> Oh... you mean you need those?  Err... ... I have both x86_32 and
> x86_64 repo for them all (xen-kernel, xen-4.0 and xen-4.1)... ... if
> you really need them let me know... however I think it is a very good
> exercise to do own packaging to suit own needs.
>

A few things for your information:

1. Your kernel rpm includes firmware which will break others (I guess
or assume) as it overwrites the whole /lib/firmware/whatever or files
within the folder (which I wonder stock kernel depends on
kernel-firmware package and yet your kernel replaced it)... ... please
test your kernel rpm with yum --nogpgcheck localinstall yourkernel.rpm
then try to remove it aka yum remove yourkernel to see whether does
yum complain anything... ...

2. Your kernel rpm installed modules size is large due to you didn't
strip it... hint: please use make INSTALL_MOD_STRIP=1 ...
modules_install... ... see stock kernel.spec for reference or grep -B
5 -A 5 MOD_STRIP Makefile in any kernel source tree :p

grep -A 5 -B 5 MOD_STRIP ./Makefile

MODLIB	= $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
export MODLIB

#
#  INSTALL_MOD_STRIP, if defined, will cause modules to be
#  stripped after they are installed.  If INSTALL_MOD_STRIP is '1', then
#  the default option --strip-debug will be used.  Otherwise,
#  INSTALL_MOD_STRIP will used as the options to the strip command.

ifdef INSTALL_MOD_STRIP
ifeq ($(INSTALL_MOD_STRIP),1)
mod_strip_cmd = $(STRIP) --strip-debug
else
mod_strip_cmd = $(STRIP) $(INSTALL_MOD_STRIP)
endif # INSTALL_MOD_STRIP=1
else
mod_strip_cmd = true
endif # INSTALL_MOD_STRIP
export mod_strip_cmd


ifeq ($(KBUILD_EXTMOD),)
core-y		+= kernel/ mm/ fs/ ipc/ security/ crypto/ block/

So about the initial reply about kernel version... see Makefile about the line:

MODLIB	= $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)

That is why I replied about make ... ... KERNELRELEASE=%{yourwhateverversion}

There are many things to learn from the Makefile itself... ... :)

Hope this helps and somewhat useful... ...

Thanks.

Kindest regards,
Giam Teck Choon