Convey uses a highly modified CentOS kernel to work with our attach coprocessor. Currently to setup a system for delivery we do a cold install using a "stock" CentOS cold install using kickstart. During that cold install we lay down our modified kernel and reboot the system with that kernel. After the reboot we are able to access the coprocessor management processor and down load updated firmware then reboot the system to have a completed install.
My goal is to be able to boot a "modified" kernel on the cold install step so we can download the firmware updates and eliminate the second boot.
I have tried using using the bzImage generated from the modified kernel build but that kernel fails to be able to load the kickstart file :-(
I have done searches trying to find the .config file used to build the kernel booted during cold install but have had no luck.
I am guessing I have either have too much or too little included in the kernel. I tried to make sure everything I thought was needed were not modules but included in the kernel.
Does anyone have any suggestions? --- Tom Murphy Platform Support Convey Computer 1-866-338-1768 tmurphy@conveycomputer.com Support Site: http://conveysupport.com/ Support Ticket : http://rt.conveysupport.com/
On Fri, 2011-01-28 at 15:19 -0600, Tom G Murphy wrote:
Nothing hard about doing this I do it a lot.....
My RT KickStart built into isolinux %post # Update the Install # We pull in our kern.repo file for updates. Magic! yum -y install -c http://192.168.2.200/kicks/kern.repo kernel-rt # Clean out the filth. yum clean all
Thanks John. This is what I do to put our modified kernel into place.
The modified kernel has routines to talk to our coprocessor via the pcibus and it is not a standard device. A generic kernel does not know how to talk to the coprocessor, what I want to do is build an install kernel that can talk to the coprocessor via pci.
A more detailed description of our system is at www.conveycomputer.com.
Thanks a lot.
On Fri, Jan 28, 2011 at 4:36 PM, JohnS jses27@gmail.com wrote:
On Fri, 2011-01-28 at 15:19 -0600, Tom G Murphy wrote:
Nothing hard about doing this I do it a lot.....
My RT KickStart built into isolinux %post # Update the Install # We pull in our kern.repo file for updates. Magic! yum -y install -c http://192.168.2.200/kicks/kern.repo kernel-rt # Clean out the filth. yum clean all
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
On 01/28/2011 11:01 PM, Tom Murphy wrote:
The modified kernel has routines to talk to our coprocessor via the pcibus and it is not a standard device. A generic kernel does not know how to talk to the coprocessor, what I want to do is build an install kernel that can talk to the coprocessor via pci.
Whats so cool with your kernel ? And where can I download it ?
- KB
Tom G Murphy wrote, On 01/28/2011 04:19 PM:
<SNIP>
My goal is to be able to boot a "modified" kernel on the cold install step so we can download the firmware updates and eliminate the second boot.
I have tried using using the bzImage generated from the modified kernel build but that kernel fails to be able to load the kickstart file :-(
But it does boot with out errors? Can you install (just CentOS) using it but without using the kickstart file?
I have done searches trying to find the .config file used to build the kernel booted during cold install but have had no luck.
I am guessing I have either have too much or too little included in the kernel. I tried to make sure everything I thought was needed were not modules but included in the kernel.
Does anyone have any suggestions?
Are you starting with the kernel SRPM from CentOS?
When I did something similar for a system needing to boot from USB on RHEL 4, I started with the srpm for the kernel that matched the kernel that would be installed by the "cold install", and used the config files that came in it. I had to mod the config file to force all the USB physical devices I new were going to be used in the install process to be built in, IIRC I figured out that I did not want to mess with all the modules and I did not want to mess with the contents of the initrd provided by RH (it broke bad anytime I did), so I ONLY forced with the USB to not be a module and let the other modules be provided by the contents of the original initrd.
secondary trick, change all the "%define build*"s in the spec file that you don't need to 0. it speeds up the build a lot.
On 01/28/2011 09:19 PM, Tom G Murphy wrote:
I am guessing I have either have too much or too little included in the kernel. I tried to make sure everything I thought was needed were not modules but included in the kernel.
Does anyone have any suggestions?
use the %post thing as John pointed out, and kexec the new install. What you have there is clearly not CentOS, so you should have no reason to not break it further up to achieve the tech path you desire.
- KB
Thanks, this is an great idea.
On Fri, Jan 28, 2011 at 6:14 PM, Karanbir Singh mail-lists@karan.orgwrote:
On 01/28/2011 09:19 PM, Tom G Murphy wrote:
I am guessing I have either have too much or too little included in the kernel. I tried to make sure everything I thought was needed were not modules but included in the kernel.
Does anyone have any suggestions?
use the %post thing as John pointed out, and kexec the new install. What you have there is clearly not CentOS, so you should have no reason to not break it further up to achieve the tech path you desire.
- KB
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
JohnS -
Karanbir Singh -
Todd Denniston -
Tom G Murphy -
Tom Murphy