I needed more serial ports that the basic CentOS Version 4 system is built to use so I'm using the following kernel build instructions to build the new 2.6 kernel:
http://www.hylafax.org/content/Handbook:Basic_Server_Configuration:Modem-spe... fic_Guidance
I believe the procedure is correct but the kernel is not building.
I used the "kernel-2.6.9-34.EL.src.rpm file that I found on one of the CentOS mirrors.
Here are the problems that I've had so far.
1) The correct architecture to use. Does anyone know which architecture should be used for the Dell 2650 Dual Xeon processor? I thought the correct configuration file would have been "kernel-2.6.9-i686-smp.config". I've also tried "kernel-2.6.9-i586-smp.config" and run into the same problems.
2) When it built the rpm it was named "kernel-2.6.934.ELcustom-1.i386.rpm" but I would have expected it to be named "kernel-2.6.9-34.ELcustom-1.i386.rpm". Was it build using the correct name or might something be misconfigured.
3) When I entered the following command: "rpm -i /usr/src/redhat/RPMS/i386/kernel-2.6.934.ELcustom-1.i386.rpm"
I get the following error: "error: Failed dependencies: kernel >= 2.6.10 conflicts with lksctp-tools-1.0.2-6.4E.1.i386"
The "kernel >= 2.6.10" does not make sense but I was wondering if it had anything to do with the file being named kernel-2.6.934.... or is there some other problem I should be looking for?
Ideas anyone?
John Warren Network Operations Administrator
Prudent Rx Inc. 100 Corporate Pointe, Suite 395 Culver City, CA 90230
P: +1 (310)642-1700 x121 F: +1 (310)642-1701 e: jwarren@prudentrx.com
**Notice of Confidentiality** Please note that the information contained in this message may be privileged and confidential and protected from disclosure under the law, including the Health Insurance Portability and Accountability Act (HIPAA). If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited and may subject you to criminal or civil penalties. If you have received this communication in error, please notify the sender by replying to the message and delete the material from any computer.
Thank you,
Prudent Rx, Inc.
On 7/11/06, John Warren jwarren@prudentrx.com wrote:
I disagree with a fair amount of their method.
I believe the procedure is correct but the kernel is not building.
Because the procedure isn't really correct.
I used the "kernel-2.6.9-34.EL.src.rpm file that I found on one of the CentOS mirrors.
You should get the source from the most updated kernel so you're running code that doesn't have known holes. http://mirror.centos.org/centos-4/4/updates/SRPMS/
probably i686(smp) however newer xeons(EM64T) are also x86_64(smp) capable. Up to you to figure out which one you have and match your distro accordingly. Safe money says i686.
Sounds like you edited the '%define release' statement in the spec file.
yes, 934 is greater than 10, so this is to be expected :-P
Nope that's the money right there.
What you should do. (Rough steps, but close enough)
Prerequirement http://www.rpm.org/hintskinks/buildtree/ There are loads of people saying 'do not build as root'. There's good reason for this, so either create a user to build as or use your own, so long as you're not building as root.
1. Get the kernel source rpm from the url above. and make sure you have all the deps installed. 2. cd to buildroot/SPECS, and do 'rpmbuild -bp kernel.spec' This will create and patch the kernel tree. 3. Copy the buildroot/SOURCES/kernel-2.6.9-i686-smp.config to buildroot/BUILD/kernel/linux-version/.config 4. Configure your kernel how you see fit. make menuconfig etc. 5. Copy the .config back to buildroot/SOURCES/kernel-2.6.9-i686-smp.config 6. run rpmbuild --target=i686 -bs buildroot/SPECS/kernel.spec 7. run rpmbuild --rebuild --target=i686 buildroot/SRPMS/kernel-version.src.rpm
This will build a kernel of the same version and release with your new options. I'd recommend incrementing the release value defined in the line I mentioned earlier.
These are rough steps, but should point you in the right direction.
Useless in mailing lists. It's going to be distributed, it's going to be copied, archived, shared with others and referenced repeatedly... and all of that is before google gets to it.
<snip>
What you should do. (Rough steps, but close enough)
Prerequirement http://www.rpm.org/hintskinks/buildtree/
Done, I setup the user buildcentos and created the tree under that users home directory.
Done!
Done.
Here is where I'm having problems. The make menuconfig fails:
[buildcentos@quark linux-2.6.9]$ pwd /home/buildcentos/rpmbuild/BUILD/linux-2.6.9 [buildcentos@quark linux-2.6.9]$ ls -al total 72 drwxrwxr-x 2 buildcentos buildcentos 4096 Jul 19 17:15 . drwxrwxr-x 3 buildcentos buildcentos 4096 Jul 19 17:14 .. -rw-rw-r-- 1 buildcentos buildcentos 60982 Jul 19 17:18 .config [buildcentos@quark linux-2.6.9]$ make menuconfig make: *** No rule to make target `menuconfig'. Stop.
At this point I'm stuck. I've done the menuconfig before using the other procedure but no joy this time. I searched the entire directory tree but can not find a makeconfig file.
No Done listed here. You didn't skip this step did you? This is the one that sets up all the rest.
Hopefully you didn't take the 'version' here literally. it should be 2.6.9-34.0.2 or whatever else is current.
This path looks wrong to me. I believe it should be /home/buildcentos/rpmbuild/BUILD/kernel/linux-2.6.9/
There should be a ton more in that directory than this.
I suspect you may have left out step 2, or used the wrong path in a later step. Double check please.
Toward the end of the reply I did the entire procedure over again.
[buildcentos@quark ~]$ ls buildtree kernel-2.6.9-34.0.2.EL.src.rpm rpmbuild
I did not skip it although I did get the following error which I forgot to put in on my last message, sorry:
[buildcentos@quark SPECS]$ rpmbuild -bp kernel-2.6.spec error: Architecture is not included: i386
I did not change anything in the spec file.
No I change it as required. In may case it's:
/home/buildcentos/rpmbuild/BUILD/kernel/linux-2.6.9
That's what it is.
I agree, the question where are they?
I went throught he whole thing again and my results follow:
****************************************************************************** *****
[buildcentos@quark ~]$ ls buildtree kernel-2.6.9-34.0.2.EL.src.rpm rpmbuild [buildcentos@quark ~]$ rpm -i kernel-2.6.9-34.0.2.EL.src.rpm [buildcentos@quark ~]$ cd rpmbuild/SPECS [buildcentos@quark SPECS]$ ls kernel-2.6.spec [buildcentos@quark SPECS]$ rpmbuild -bp kernel-2.6.spec error: Architecture is not included: i386 [buildcentos@quark rpmbuild]$ pwd /home/buildcentos/rpmbuild
Note: I had to create the kernel and linux-2.6.9 directories when I did this the first time so if the rpmbuild should have created them it did not.
[buildcentos@quark rpmbuild]$ cd BUILD/kernel/linux-2.6.9 [buildcentos@quark linux-2.6.9]$ make makeconfig make: *** No rule to make target `makeconfig'. Stop. [buildcentos@quark linux-2.6.9]$ ls -la total 72 drwxrwxr-x 2 buildcentos buildcentos 4096 Jul 20 14:59 . drwxrwxr-x 3 buildcentos buildcentos 4096 Jul 20 14:55 .. -rw-rw-r-- 1 buildcentos buildcentos 60982 Jul 20 15:52 .config
****************************************************************************** *****
[buildcentos@quark SPECS]$ rpmbuild -bp kernel-2.6.spec error: Architecture is not included: i386
Woops, my fault. That should be rpmbuild -bp --target=i686 (or x86_64 depending on what you're using) kernel-2.6.spec
Cascading problem set. Redo everything again (sorry) with that command instead, and it should work. You'll also have to pass in the --target=i686 when you do the final rpmbuild --rebuild buildroot/SRPMS/kernel-foo.src.rpm also.
No problem, at least I'm not going crazy. I kept thinking, "what am I doing wrong" and "do I really want to post again, there going to think I stupid":)
I'm now doing the build but I'm seeing many errors and warnings may I assume that these are normal?
You also said something about keeping my own release numbers. I think the line is:
%define release 34.0.2.EL
So I should change it to something like:
%define release 34.0.2.EL.PRX.01
I'll rebuild it again and make that change before I make it the default boot kernel.
Speaking of making it the new boot kernel just how do I move the kernel so I can select it during boot and still be able to return to the "standard" kernel incase of problems? I think grub?
I'm writing all of this up so I can post it back over on the hylafax.org site in their wiki. Should help the next person that has to do this. Sure wish that the standard hylafax release would contain about 40 tty ports. They can't take up much space and it would solve this problem.
Better yet this should be a configurable parameter without having to rebuild the kernel. Hey kernel developers, how about that?
This is fun, but it sure can drive one crazy until you get the hang of it.
Thanks again for all the help.
John
PS: Build just finished and got these errors. I was in the following directory when I started the build.
/home/buildcentos/rpmbuild/BUILD/kernel-2.6.9/linux-2.6.9
And used the command:
rpmbuild --rebuild --target=i686 /home/buildcentos/rpmbuild/SRPMS/kernel-2.6.9-34.0.2.EL.src.rpm
The errors I got.
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory Finding Provides: /usr/lib/rpm/redhat/find-kmod-provides.sh Requires(rpmlib): rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/kernel-2.6.9-34.0.2.EL-root shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory Wrote: /home/buildcentos/rpmbuild/RPMS/i686/kernel-2.6.9-34.0.2.EL.i686.rpm Wrote: /home/buildcentos/rpmbuild/RPMS/i686/kernel-devel-2.6.9-34.0.2.EL.i686.rpm Wrote: /home/buildcentos/rpmbuild/RPMS/i686/kernel-smp-2.6.9-34.0.2.EL.i686.rpm Wrote: /home/buildcentos/rpmbuild/RPMS/i686/kernel-smp-devel-2.6.9-34.0.2.EL.i686.rpm Wrote: /home/buildcentos/rpmbuild/RPMS/i686/kernel-hugemem-2.6.9-34.0.2.EL.i686.rpm Wrote: /home/buildcentos/rpmbuild/RPMS/i686/kernel-hugemem-devel-2.6.9-34.0.2.EL.i686 .rpm Wrote: /home/buildcentos/rpmbuild/RPMS/i686/kernel-debuginfo-2.6.9-34.0.2.EL.i686.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.23183 shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory + umask 022 + cd /home/buildcentos/rpmbuild/BUILD chdir: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory + cd kernel-2.6.9 + rm -rf /var/tmp/kernel-2.6.9-34.0.2.EL-root + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.42450 shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory + umask 022 + cd /home/buildcentos/rpmbuild/BUILD chdir: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory + rm -rf kernel-2.6.9 + exit 0
Are these normal or do I still have something wrong?
It also looks like all of the files and directories are deleted during the build. That included the kernel.2.6.spec file. Not a problem but it just caught me off guard when they disapeared. It looks like a new copy of the sources with the changes I made was created in the SRPMS directory. Is that correct? If so I guess I just install it and rebuild. Nice touch if that's correct.
On Fri, Jul 21, 2006 at 03:12:49PM -0700, John Warren enlightened us:
You can do that, yes. I think by default, it also appends some information like the user building the RPM to the name. You can check out the spec file for that.
And the first thing that the RPM does is remove that directory to start from scratch :-)
If you're making changes to the spec file, you probably want rpmbuild -ba --target=i686 kernel.spec instead.
Errors are due to where you started. It did successfully create the RPMs, though.
Ahh, I bet your changes didn't make it in if you just make them in the BUILD/kernel... directory. The first thing rebuilding the src rpm does is wipe that directory out and unpack a fresh copy. You're best off making changes to the files in the SOURCES directory, and rebuilding from the .spec file. I think there's also a way to skip parts of the build process, so you could -bp to prep, make changes in BUILD, then skip the prep part of the build process so that it doesn't overwrite your changes. man rpmbuild for that.
Matt
On 7/21/06, Matt Hyclak hyclak@math.ohiou.edu wrote:
This works as well, assuming you copied your config back to the original name. That's really the only catch unless you're applying patches (next week's lesson :-P).
You can, but if you start off with a -bp, then move to -bc and the rest there's no way to tell rpm to finish the whole thing off and actually make the packages. It'll build, and test, but it will not produce an rpm. Initially I thought this was a bug/design flaw, then after talking with jbj I released it was intentional to keep lazy packagers from tweaking mid-build and other such lazy/bad habits.
This is why I wanted him to repackage everything back into his own src.rpm and --rebuild from it. -ba works just as well though.
There were several other steps before that which I did not list.
It goes something like this:
rpm -i kernel-2.6.9-34.0.2.EL.src.rpm Edit the kernel-2.6.spec file cp SOURCES/kernel-2.6.9-i686-smp.config BUILD/kernel-2.6.9/linux-2.6.9/.config Edit as required using menuconfig cp .config /home/buildcentos/rpmbuild/SOURCES/kernel-2.6.9-i686-smp.config rpmbuild --target=i686 -bs /home/buildcentos/rpmbuild/SPECS/kernel-2.6.spec rpmbuild --rebuild --target=i686 /home/buildcentos/rpmbuild/SRPMS/kernel-2.6.9-34.0.2.EL.PRX.01.src.rpm
Ahh I see, so which directory is the best place to be when you start the build?
I think they did, see above.
I'm still not sure just how to ket the kernel loaded. Adjusting the grub.conf I understand. I found this but I'm not sure if it's the right way to do it.
rpm -ivh --force kernel-smp-2.6.9-34.0.2.EL.PRX.01.i686.rpm
Thanks Matt
rpm -ivh --force kernel-smp-2.6.9-34.0.2.EL.PRX.01.i686.rpm
The --force is a bad idea. The rest of the command is fine. Also, since you're doing it this way, the kernel itself should tweak grub.conf for you as part of the post install script in the rpm.
Success, well 98% success anyway.
New kernel boots just fine if you leave it alone during the boot but I have run into one small problem that I home someone may have seen before.
During the boot Kudzu starts up. If you leave it alone and let it timeout the boot completes. If you enter the Kudzu then the boot will hang. If you CTRL-ALT-DEL the system will do a clean reboot. If you enter Kudzu it wants to remove the Generic modem driver.
System config for serial ports: One Mainpine OCT+ ports ttyS05 thru ttyS12, plus it sees ttyS20 the control port for the Mainpine, plus two modems on ttys00 and 01.
If you boot from the default kernel you will only see ports part of the Mainpines ports plus the two modems on ttys00 and 01 but Kudzu never starts.
I suspect Kudzu is seeing the additional ports now that the kernel is build to use them but I don't understand why it causes a problem with booting.
Anyone ever seen this?
Thanks to all that have help me get this far. You guys have been great.
yes
try
chkconfig kudzu off
of check all the levels it is avail at and do it that way
?? ;->
- rh
-- Robert Hanson - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
I suspect Kudzu is seeing the additional ports now that the kernel is build to use them but I don't understand why it causes a problem with booting.
Not to be mean, but this is one of the reasons the irc support channel chooses to not support kernel builds. It's likely that you're missing either an unspecified build dependency, or you've marked something in the kernel incorrectly in the config it's using to build. You may need to consult the build logs (assuming you kept them) and look for errors and the like. What you're running into is part of the "fun" of the rebuild process. Now you get to test it and figure out what broke.
Anyone ever seen this?
Thanks to all that have help me get this far. You guys have been great.
Sorry but this is kinda long.
Never would have taken it as being mean, it's just a statement of fact your passing on. I can understand the reason they would take this position and it's not unreasonable but I think this makes a VERY good case why changing the number of ttyS ports should NOT require a kernel rebuild. I never wanted to rebuild the kernel but the additional ports requirement forced me too.
IMHO, the number of ttyS ports should either be controlled by the number of ports that are found during boot, defaulted to something like 40+ ports on the standard build or a boot time configuration parameter. The simple way would be to make the standard kernel set to 40+ ports. With the exception of a system with very small memory the amount of additional memory required for the additional ports is a "drop in the bucket". The better way would be either automatic or boot parameter.
Coming back to my configuration, the only parameter I knowingly changed was the number of non-legacy tryS ports from 4 to 37 for a total of 41 ports. (Why 37 you might ask? It's 4 Mainpine OCT+ cards [24], plus their control ports plus the Dell RAC). When Kudzu popped up it was trying to remove a "Generic Serial Modem". I've been looking into this a little more this morning and I now suspect the problem is as follows:
The standard kernel has support for 4 legacy and 4 additional ports. The RAC was assigned to ttyS4. The Mainpine OCT+ first 3 ports were mapped to ttyS5, 6 and 7, it's 4th and 5th ports were being mapped to legacy ports ttyS2 and 3 and the last three were unused. The hardware configuration file, hwconf, shows "Generic Serial Modems" on ttyS0 through ttyS3 and nothing for the RAC or the Mainpine.
I think that Kudzu wants to remove ttyS2 and 3 but it's having a problem doing so. I suspect it may be crashing in such a way that it does not return control back to the boot process so the boots continues to wait for Kudzu to complete. I guess I could remove the Mainpine and boot the standard kernel and see what happens (weekend or late night project). Kudzu should try to remove the additional "Generic Serial Modems". If that also fail then there may be a Kudzu problem and not a kernel problem.
Question: would it be reasonable/safe to manually remove the entries for ttyS2 and 3 from the hwconf file and would that cause Kudzu not to think there was a "Generic Serial Modem" modem on those ports that needed to be removed?
I suspect that if one boots back into a standard kernel Kudzu will want to add those ports back into the hwconf file and I don't know if there is any way to keep it from doing so.
So far the kernel seems to be solid except for the problem with Kudzu.
Here is part of dmesg for both the standard kernel and the new build. FYI, in both cases ttyS4 is the Dell built-in RAC card.
Standard Kernel:
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS4 at I/O 0xec80 (irq = 185) is a 16550A ttyS5 at I/O 0xdc80 (irq = 225) is a 16550A ttyS6 at I/O 0xdc88 (irq = 225) is a 16550A ttyS7 at I/O 0xdc90 (irq = 225) is a 16550A ttyS2 at I/O 0xdc98 (irq = 225) is a 16550A ttyS3 at I/O 0xdca0 (irq = 225) is a 16550A Note: the control port was not seen.
New Kernel Build:
serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 41 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ACPI: PCI interrupt 0000:00:04.1[B] -> GSI 23 (level, low) -> IRQ 185 ttyS4 at I/O 0xec80 (irq = 185) is a 16550A ACPI: PCI interrupt 0000:01:06.0[A] -> GSI 16 (level, low) -> IRQ 225 ttyS5 at I/O 0xdc80 (irq = 225) is a 16550A ttyS6 at I/O 0xdc88 (irq = 225) is a 16550A ttyS7 at I/O 0xdc90 (irq = 225) is a 16550A ttyS8 at I/O 0xdc98 (irq = 225) is a 16550A ttyS9 at I/O 0xdca0 (irq = 225) is a 16550A ttyS10 at I/O 0xdca8 (irq = 225) is a 16550A ttyS11 at I/O 0xdcb0 (irq = 225) is a 16550A ttyS12 at I/O 0xdcb8 (irq = 225) is a 16550A ttyS20 at I/O 0xdcf8 (irq = 225) is a 16450
It's going to be interesting to see what happens if I added another Mainpine OCT+ card. Will it's ports start at 13 or 21? Time will tell.
No, it currently reads:
# Set to anything other than 'no' to force a 'safe' probe on startup. # 'safe' probe disables: # - serial port probing # - DDC monitor probing # - PS/2 probing SAFE=no
I guess I could set serial port probing to no.
See my other post but it seems to be "Generic Serial Modem" entries.
And have you read the kudzu man page?
Yes, but I thought that was more for manually using Kudzu.
-
Email Lists -
Jim Perrin -
John Warren -
Linus Hicks -
Matt Hyclak