kickstart fails statically built custom kernel: anaconda doesn't honor static NIC/SATA driver in kernel?
Kickstart fails for statically built custom booting kernel, although the custom kernel is built form the same version stock kernel source. My anaconda and kernel source are both of stock versions on Centos 5.
At the kickstart 'F3' screen, the following error messages appear:
Modules to insert tg3 ... ... ERROR: no network devices in choose network device! ERROR: no network drivers for doing kickstart ERROR: unable to bring up network.
The network card driver tg3 is statically built into custom kernel to fix NIC driver loading sequence problem( I have mixed type NICs on these boxes), so there is no tg3.ko in my rolled modules/modules.cgz file.
Does this problem mean that kickstart/anaconda doesn't recognize NIC/SATA drivers statically built into booting kernel? Anaconda needs everything to exist in dynamic module form (*.ko in modules.cgz)?
Thanks.
Guolin Cheng wrote: ...
The network card driver tg3 is statically built into custom kernel to fix NIC driver loading sequence problem( I have mixed type NICs on these boxes), so there is no tg3.ko in my rolled modules/modules.cgz file.
Could you explain "loading sequence problem"?
Mogens
Mogens,
The Booting Sequence problem is described below:
Two types of NICs are installed on one machine, BIOS/PXE boots from one type, but after that Linux/Kickstart kernel detect another type NIC as eth0 and trying to install from that unconnected NIC.
A custom kernel is built to statically built-in the BIOS/PXE detected NIC's driver into kernel, hoping to fix the problem in a hard way but failed.
Kickstart/anaconda always try to load a .ko driver for each detected NIC types, so when the driver is static built (into kernel), the Kickstart process hangs because it can not locate/load the related .ko module file.
I have fixed the problem in a non-standard way, not very elegant but works.
By the way, the suggested 'noprob,nonet' and 'device eth0 <module1>:<module2>:...' combination doesn't work at all for my case -- since the latter is defined in a ks.cfg but my ks.cfg needs to be downloaded from network.
--Guolin
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Mogens Kjaer Sent: Saturday, June 09, 2007 5:49 AM To: CentOS mailing list Subject: Re: [CentOS] kickstart fails statically built custom kernel: anacondadoesn't honor static NIC/SATA driver in kernel?
Guolin Cheng wrote: ...
The network card driver tg3 is statically built into custom kernel to fix NIC driver loading sequence problem( I have mixed type NICs on these boxes), so there is no tg3.ko in my rolled modules/modules.cgz file.
Could you explain "loading sequence problem"?
Mogens
Guolin Cheng wrote:
Mogens,
The Booting Sequence problem is described below:
Two types of NICs are installed on one machine, BIOS/PXE boots from one type, but after that Linux/Kickstart kernel detect another type NIC as eth0 and trying to install from that unconnected NIC.
You don't need a custom kernel to fix this problem.
If the interface from which you've PXE booted is named eth1, you can fix the installation by appending "ksdevice=eth1" to the append line in the pxelinux.cfg/default file.
Mogens
--- Mogens Kjaer mk@crc.dk wrote:
Guolin Cheng wrote:
Mogens,
The Booting Sequence problem is described below:
Two types of NICs are installed on one machine,
BIOS/PXE boots from one
type, but after that Linux/Kickstart kernel detect
another type NIC as
eth0 and trying to install from that unconnected
NIC.
You don't need a custom kernel to fix this problem.
If the interface from which you've PXE booted is named eth1, you can fix the installation by appending "ksdevice=eth1" to the append line in the pxelinux.cfg/default file.
This doesn't work, I think. the 'ksdevice=eth1' or 'ksdevide=link' ways don't work well, because the kickstart process will write MAC addresses to ifcfg-eth* files, and that will just leave headaches to local disk boot.
Another problem with this method is: you have to predict which eth? the pxe-booted NIC will be detected as. If there are more than several types of mixed NIC boxes, then this method becomes too cubersome and not applicable.
Mogens
-- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk@crc.dk Homepage: http://www.crc.dk _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
Robinson Tiemuqinke wrote: ...
This doesn't work, I think. the 'ksdevice=eth1' or 'ksdevide=link' ways don't work well, because the kickstart process will write MAC addresses to ifcfg-eth* files, and that will just leave headaches to local disk boot.
I don't understand this.
Another problem with this method is: you have to predict which eth? the pxe-booted NIC will be detected as. If there are more than several types of mixed NIC boxes, then this method becomes too cubersome and not applicable.
Cumbersome, maybe, but making a custom kernel for each different installation would be worse.
Mogens
-
Guolin Cheng -
Mogens Kjaer -
Robinson Tiemuqinke