I have a plain vanilla Centos source (not 100% sure where we got it from), but I can't seem to get a build that installs correctly.
I tried the method described at http://wiki.centos.org/HowTos/Custom_Kernel, but rpm doesn't like the output file, and even if I install it with -F, nothing seems to happen - no new kernel, now initrd, nothing.
When I tried following the directions in the README file that came with the source, I built the kernel just fine, but the instructions then go on to describe how to modify LILO to make the install work, and my boot loader is GRUB - not sure how to reconcile those two.
So, I built yet another kernel (rpm) following the guide at http://www.howtoforge.com/kernel_compilation_centos, and the rpm built just fine, but when I run mkinitrd, it complains that I don't have the ahci module in my kernel. The only reference I have found to ahci is in my boot setup, and it is already enabled, so, once again, I am stuck.
Anyone have any ideas here?
I'm running Centos 2.6.9-42.0.3ELsmp on a Dell Precision 390 (P4/HT 3GHz, 2Gb mem, ATI FireGL 4700, 160Gb SATA, ...
Thanks (again).
On 1/25/07, Mark Hull-Richter mhull-richter@datallegro.com wrote:
I have a plain vanilla Centos source (not 100% sure where we got it from), but I can't seem to get a build that installs correctly.
Welcome to the joy of building custom kernels.
I tried the method described at http://wiki.centos.org/HowTos/Custom_Kernel, but rpm doesn't like the output file, and even if I install it with -F, nothing seems to happen - no new kernel, now initrd, nothing.
Something in your build process has likely failed. Also, -F is to 'freshen' an existing package. This is something you most definitely DO NOT want to do with a kernel.
When I tried following the directions in the README file that came with the source, I built the kernel just fine, but the instructions then go on to describe how to modify LILO to make the install work, and my boot loader is GRUB - not sure how to reconcile those two.
Look at your /etc/grub.conf and add a stanza like the others, but with your kernel info. It should be pretty straight forward.
So, I built yet another kernel (rpm) following the guide at http://www.howtoforge.com/kernel_compilation_centos, and the rpm built just fine, but when I run mkinitrd, it complains that I don't have the ahci module in my kernel. The only reference I have found to ahci is in my boot setup, and it is already enabled, so, once again, I am stuck. Anyone have any ideas here?
Yes. Follow one guide at a time. This will keep you from dragging your problem around with you. Troubleshoot why your build failed the first time around.
I'm running Centos 2.6.9-42.0.3ELsmp on a Dell Precision 390 (P4/HT 3GHz, 2Gb mem, ATI FireGL 4700, 160Gb SATA, ...
Seems fairly common hardware. Are you sure you need to rebuild? Perhaps the centos wiki was not stern enough in discouraging custom builds for a plethora of reasons. What feature is it that you wish to enable in your custom kernel?
Mark Hull-Richter wrote:
I have a plain vanilla Centos source (not 100% sure where we got it from), but I can't seem to get a build that installs correctly.
I tried the method described at http://wiki.centos.org/HowTos/Custom_Kernel, but rpm doesn't like the output file, and even if I install it with -F, nothing seems to happen - no new kernel, now initrd, nothing.
My 30-second glance at it suggests it's not very good; the prep stage is quite wrong. For example, kernel-devel is a part of the output of the build process. You cannot install it before you have built your kernel.
I suggest you start with the src.rpm. rpm -i ... rpmbuild -bp ... <wherevr the spec went> Install whatever is says you need:-)
Here is a script that works for _at least some_ RHEL4 & FC3 kernels. I suggest you read it, understand it and adapt it to what you want. Then, maybe fix that wiki. #!/bin/bash set -xe rpmbuild=rpmbuild\ --define\ "_topdir${HOME}/redhat" rpm=rpm\ --define\ "_topdir${HOME}/redhat" if [ -n "$1" ] ; then K=$1 else K=$(dir -d1rt ~/Fedora/kernel*src.rpm ~/RH/FC3/updates/SRPMS/kernel*src.rpm | tail -1) fi DirName=$(rpm -qp --qf '%{name}-%{version}\n' ${K}) ${rpm} -i ${K} date=$(date "+%a %b %d %Y") sed -r <redhat/SPECS/kernel-2.6.spec >redhat/SPECS/kernel-2.6-dl.spec \ -e 's=FC>=dl=g' \ -e 's=FC2>=dl2=g' \ -e 's=FC3>=dl3=g' \ -e 's=%define builddoc 0=%define builddoc 1=' \ -e "s=%changelog=%changelog\n* ${date} John Summerfield summer@herakles.homelinux.org\n- autobuild for dl %{release}\n=" : : : : diff -u redhat/SPECS/kernel-2.6.spec redhat/SPECS/kernel-2.6-dl.spec || : ${rpmbuild} -bp --target i686 redhat/SPECS/kernel-2.6-dl.spec
echo Fixing configs ( set -x cd $(find ~/redhat -type d -name ${DirName})/lin* ls -la for f in configs/*.config do : make -s mrproper sed < $f >.config \ -e 's+# CONFIG_NTFS_FS is not set+CONFIG_NTFS_FS=m\nCONFIG_NTFS_DEBUG=n\nCONFIG_NTFS_RW=y+'
grep -q 'CONFIG_NTFS_FS is not set' .config && exit grep -4 NTFS .config # make -s oldconfig cp -bvp .config ~/redhat/SOURCES/$(basename $f) head -9 $f .config ~/redhat/SOURCES/$(basename $f) mv -b .config $f done )
echo Fixed configs
BO="-ba" for arch in i686 do : ${rpmbuild} ${BO} --clean --target ${arch} redhat/SPECS/kernel-2.6-dl.spec BO="-bb --rmsource" done
In my case, I'm building a brace of kernels with NTFS support. the resultant kernals install on nahant/FC3 just fine.
My 30-second glance at it suggests it's not very good; the prep stage is quite wrong. For example, kernel-devel is a part of the output of the build process. You cannot install it before you have built your kernel.
That was mostly to pull in the other prerequisites to make sure folks have everything. It was easier to tell them to install 1 package than list the 15 or so which are needed. If you would like to spell out the dependencies individually, you're welcome to modify the wiki (or at least pass changes along, as it may still be restricted to a core group.. I'm not sure).
And you can most certainly install the ones from the distro before you build your own. I simply took the lazy way out in the documentation. I'm not really a fan of people rebuilding the kernel anyway. This thread is a prime example of why.
1. There was no need specified for why a custom kernel was needed. If such a need was spelled out, it's possible that much better help could be provided, or it could even be added to the centosplus kernel.
2. No build log or error of any kind was shown to help troubleshoot. And rather than figuring out what went wrong, the user moved to a drastically different set of instructions, which use a drastically different kernel. Doing so without proper understanding could (and likely would) lead to problems down the road. (The install with --nodeps on the howtoforge listing is a nice touch)
3. The user in question seems to have not done homework regarding centos and XFS, and will be modifying the 2.6.9 xfs code instead of using the much nicer xfs code backported by ex-SGI folks specifically for centos.
4. There are many considerations in building a custom kernel for centos, such as the audit libs, utmp compatability, current system compatability (as demonstrated by the lvm troubles) and so on.
</rant> Not at all a dig at you John, so don't take it that way. Interesting script you have there.
Jim Perrin wrote:
My 30-second glance at it suggests it's not very good; the prep stage is quite wrong. For example, kernel-devel is a part of the output of the build process. You cannot install it before you have built your kernel.
That was mostly to pull in the other prerequisites to make sure folks have everything. It was easier to tell them to install 1 package than
If they're not listed in the kernel spec, then the kernel spec's broken.
If they're not listed in the kernel spec, then the kernel spec's broken.
Not necessarily. Installing the kernel doesn't require you to have the build dependencies installed or else you'd need gcc, some parts of qt, and some portions of Xorg just to install the kernel, when they're only really required to build or run make xconfig. Installing the src.rpm doesn't require the build deps to be installed either, and won't allow for installation if the build is being done in a sane manner as an unprivileged user. Now if they're not listed as a buildrequires, then the spec would be broken. For the tutorial, I'd rather have all deps required to build installed at the outset, as people tend to not read error messages (yes, I'm a bit jaded and cynical at times).
So you can either spell out the dozen+ build dependencies, or you can install the package that pulls them all in. Like I said before, I took the shortcut :-P
-
Jim Perrin -
John Summerfield -
Mark Hull-Richter