Building RPM Kernel with a patch -- how to add?
The only other thing I can think of is I commented out two lines toward the end of the spec file that gathered the debuginfo stuff. I have my build environment set to not build the debuginfo packages so I get an error if I do not comment those lines out. You may have to uncomment them.
Are you building this kernel to go on the same machine you are building it on? If so why not just skip the RPM build altogether and just do a "make install"?
Are you building this kernel to go on the same machine you are building it on? If so why not just skip the RPM build altogether and just do a "make install"?
Void Main wrote:The only other thing I can think of is I commented out two lines toward the end of the spec file that gathered the debuginfo stuff. I have my build environment set to not build the debuginfo packages so I get an error if I do not comment those lines out. You may have to uncomment them. Also, my spec files are for the 741 and 760 kernels, not the 766.
Are you building this kernel to go on the same machine you are building it on? If so why not just skip the RPM build altogether and just do a "make install"?
Ok so I'll backup a step and see if the files differ in some way that is killing things.
as for the "why make an rpm"
I have one system with everything that I am using as my development system. another box for a firewall that I will strip down for the final live firewall config.
I want to have the kernal build so that I can make an rpm for a target firewall box. this time it's an AMD K6 another time a customer may have an old PIII and so on, I want to tweak the package for the system.
and also to know how to build the thing...
back when I started it took a while to build but it did not seem this complex, but then that was like 8 years back...
.... time to see if the stuff you just posted has a "Smoking Gun"

No Kiddin!!!Void Main wrote:I actually changed part of what I posted as you were posting apparently. Ignore the part where I said my spec file was not for 766 because it is. Duh!

I was looking back and saw the post had changed "Under my fingers" while I was typing!!

and figured that you must have seen that... I was 90% sure we had already covered that 766 part before.....
so back to
the debug thing?
and any other details.... I'll go back and try and trace back some stuff...
What is the actual error message that you get when it dies? If it helps, here is my rpm-tmp file from the last build I did:
http://voidmain.is-a-geek.net/files/mis ... -tmp.20810
Also you know that the RPM you are building will end up in redhat/RPMS/i686 if you are building for i686, etc right?
http://voidmain.is-a-geek.net/files/mis ... -tmp.20810
Also you know that the RPM you are building will end up in redhat/RPMS/i686 if you are building for i686, etc right?
yes the rpm will go in the right folder; got thatVoid Main wrote:What is the actual error message that you get when it dies? If it helps, here is my rpm-tmp file from the last build I did:
http://voidmain.is-a-geek.net/files/mis ... -tmp.20810
Also you know that the RPM you are building will end up in redhat/RPMS/i686 if you are building for i686, etc right?

it passes the "BUILD" stage so the file you just posted is not the one where it dies.
I am at the stage where the modules and the kernel boot files are done
it tries to add the gpg sig to the loadable modules
then it exits the BuildKernel() function and then dies.
leaves all the files but never makes the .rpm for installing.
I think it has all the files made but just never grabs them and builds the rpm.
I am going to copy the files I have and re-install the sources from the src rpm and test that *IT* builds correctly from the start....
for all I kinow there may even be an error in the files or some early chnages we made....
so I'll start at quare one and just try and build a kernel w/o any edits and see where that goes.
if that works then I can try some chnages and repeat untill I have it working.
"If you eliminate the imposible then what ever remains however improbable is the truth"
Void Main wrote:But it shouldn't just exit without giving an error message indicating what the problem is. It would be nice to see about the last 50-100 lines of the output from your rpmbuild command.
what I posted before:
and it was running along nice ----
it got to the modules build and ran them.
then I saw an error message about "no job control" ??
when I looked at the tmp file that was refered to it ends like this:
Code:
BuildKernel
###
### install
###
%{null}
exit 0
the line "%{null}" is where it died.
the % I think is the "Job COntrol" command to bring a process to the foreground. that line is where something was missing or was wrong with the spec file or the related chnages.
in a while here I bet I'll get it, I am runing a build straight from the source and if that works then I'll know some chnage I made did it and I can step into chnages one at a time and get it to work.
I must have hosed it somewhere and not know where I shot my self in the foot.
I see now. My tmp script ends just like yours except it doesn't have that %{null} line. I don't see that in the spec file, is it in yours? Other than that I am wondering what your ~/.rpmmacros files looks like. I am wondering if you have a "null" where there should be a "nil". Have you modified any other RPM files in /etc/rpm or /usr/lib/rpm?
that may be it....
I am checking ....
here:
www.linuxquestions.org has a how-to much like yours.
from there they said to put this into .rpmmacros
are you saying that is wrong?
should be %{nil} ??
I am checking ....
here:
www.linuxquestions.org has a how-to much like yours.
from there they said to put this into .rpmmacros
Code: Select all
%debug_package %{null}
should be %{nil} ??
Yes, I don't know where their HOWTO is but it is wrong if they say to use "null". Here's my .rpmmacros file:
However, this doesn't get used when I build the kernel as root. I just use the defaults for root. I have globally turned off the debug packages by adding this to my /etc/rpm/macros file:
The above line obviously effects all users including root.
EDIT: I found that linuxquestions article:
http://www.linuxquestions.org/questions ... &artid=170
They say adding the "%debug_package %{null}" may give a bad exit status for some people. That's because the line is wrong.
Code: Select all
%packager Void Main
%distribution Void Main RPMS
%vendor voidmain.is-a-geek.net
%_signature gpg
%_gpg_name Void Main
%_topdir /home/voidmain/redhat
%_tmppath /var/tmp
%_rpmtopdir %{_topdir}
%_builddir %{_rpmtopdir}/BUILD
%_buildhost voidmain.is-a-geek.net
%_rpmdir %{_rpmtopdir}/RPMS
%_sourcedir %{_rpmtopdir}/SOURCES
%_srcrpmdir %{_rpmtopdir}/SRPMS
%_specdir %{_rpmtopdir}/SPECS
%_menudir /usr/lib/menu
%_iconsdir /usr/share/icons
%_miconsdir /usr/share/icons/mini
%_liconsdir /usr/share/icons/large
%debug_package %{nil}
Code: Select all
%debug_package %{nil}
EDIT: I found that linuxquestions article:
http://www.linuxquestions.org/questions ... &artid=170
They say adding the "%debug_package %{null}" may give a bad exit status for some people. That's because the line is wrong.
thanks, now I have a *MUCH BETTER* working understanding of the build process with rpmbuild.
a lot of it is out there but having someone to kind of "Tap on the shoulder and ask a question" helps when you get stuck!
and it's always the little things like null Vs. nil that can really kill you eh?
funny to me in a way: I have always found null to follow the UNIX / Linux use as it comes from the C background; nil is a term I always think of for the Pascal folks ... and the teacher I had that did Pascal and C classes was a Pascal biggot who felt very uncomfortable with handling pointers and addresses in a high level language; Even though he also taught x86 assemby classes and was *DAMM GOOD* at that!
thanks again!
Now I *HOPE* I can finish w/o more issues....
a lot of it is out there but having someone to kind of "Tap on the shoulder and ask a question" helps when you get stuck!
and it's always the little things like null Vs. nil that can really kill you eh?
funny to me in a way: I have always found null to follow the UNIX / Linux use as it comes from the C background; nil is a term I always think of for the Pascal folks ... and the teacher I had that did Pascal and C classes was a Pascal biggot who felt very uncomfortable with handling pointers and addresses in a high level language; Even though he also taught x86 assemby classes and was *DAMM GOOD* at that!
thanks again!
Now I *HOPE* I can finish w/o more issues....

You are right about the null vs nil. I actually learned Pascal before I learned C way back when. In fact I used to be pretty good with TP/BP. I'm still (after more than 15 years of it) not as confident with C as I ever was with Pascal. "nil" is also still used in some databases and I suspect this is why it was used. Probably related to Berkeley DB somehow or another (RPM uses Berkeley DB).