Kickstart via PXE/NFS

Tue May 15 13:42:03 UTC 2007

Could you post your ks.cfg file, specifically the networking section. I
have seen this, even when the kernel loads correctly, because the
networking information is incorrect.

________________________________

From: kickstart-list-bounces at redhat.com
[mailto:kickstart-list-bounces at redhat.com] On Behalf Of
SSTinsley at upsfreight.com
Sent: Tuesday, May 15, 2007 4:43 AM
To: Discussion list about Kickstart
Cc: kickstart-list at redhat.com; kickstart-list-bounces at redhat.com
Subject: RE: Kickstart via PXE/NFS

kickstart-list-bounces at redhat.com wrote on 05/14/2007 04:14:11 PM:

> You still have never answered the question.  We are trying to help 
> you here.  It doesn't matter whether or not your second NIC is 
> plugged in, it does however matter whether or not it is on the same 
> bus as the NIC you are pxebooting from.  As for why it works in pxe 
> and doesn't work in kickstart, they are two entirely different 
> systems.  pxe comes from the system BIOS, and the kickstart 
> installer comes from RHEL.  The reason this is important is because 
> RHEL 4 + enumerates the bus differently (and according to Red Hat 
> properly) than either pxe or previous RHEL versions. 
>   
> As for "complicated", my time goes back to building "unattend.txt" 
> files for Windows 95 (and every version since), and kickstart is FAR
> more powerful and easier to use than any of the windows technologies
> that are included with the OS.  And if you don't like kickstart, try
> using YAST sometime, that will make you old before your time. 
>   
> This list is very helpful and has gotten many people to quality 
> build setups, but disparaging the tool that we are trying to help 
> you deploy isn't going to win friends or help. 
>   
> At the end of the day, if you don't like anaconda, do something 
> about it.  It's open source and you can dive in and fix the things 
> you don't like, and submit the patches upstream.  There are many 
> things *I* would like to see changed, but I don't have the time to 
> write a patch, so I have to live with it or work around it.  At 
> least now I can make the changes if I wanted to... Sure wish I could
> have done that in Windows 10 years ago when I was trying to get an 
> unattend.txt file to bring up a backup domain controller that wasn't
> online with the primary since it hadn't been built yet and was 
> located in a different state. 
>   
> Chip 

I appreciate your time and help. Just a bit frustrated after working on
this for 2 solid days 
and watching the PC boot about 50 times. 

If you want free software to be successful, the standard answer can't be
"fix it yourself if you 
don't like it". Many people, like me are not programmers. You don't want
me in messing with code. 
People will eventually go where they can find someone to supply the fix.
In my case, that is 
RedHat. And I have a case open with them. I was hoping I might get the
problem solved faster going 
this route. 

kickstart-list-bounces at redhat.com wrote on 05/14/2007 04:01:42 PM:

> For the second interface, try turning it off in the bios. I believe 
> you're running into an enumeration problem with the onboard NIC's. 
> Whether you have it plugged in or not, it is probably where the issue
is. 
>   
kickstart-list-bounces at redhat.com wrote on 05/14/2007 04:03:21 PM:

> I had a similar issue.  I had only one NIC cabled to the switch.  
> The initial DHCP request was successful but it would fail on finding
> the ks.cfg file. 
>   
> I ended up turning off all the NICs in the bios and this helped. 
>   
>   

I disabled the second interface in the bios as suggested. No difference.
Let me describe 
what happened and show you the anacaonda log and you may see why this is
so puzzling. 

The process up through the kernel load works fine. The initial DHCP
request shows up on the 
network snoop, the pxelinux downloads. I get the PXE menu and kick off
the auto install. 
The kernel and initrd download successfully. Here is the cmdline passed
to the kernel based 
on the contents of /proc/cmdline. 

initrd=rhel_v4/initrd.img ks=http://10.1.1.253/redhat/ks_rhel_v4.cfg
BOOT_IMAGE=rhel_v4/vmlinuz 

On the screen, I see the initial Anaconda screen with various messages
on loading drivers. Then 
a message is displayed that DHCP is attempting to start eth0. It fails
and the net config screen 
appears. I set it for DHCP again. No luck. Here is what shows up in the
anaconda log after several 
DHCP attempts from the network config screen. 

 only have one network device: eth0 
* sending dhcp request through device eth0 
* waiting for link... 
* 0 seconds. 
* running dhcp for eth0 
* pump told us: No DHCP reply received 
* eth0 isn't a wireless adaptor 
* waiting for link... 
* 5 seconds. 
* running dhcp for eth0 
* pump told us: No DHCP reply received 
* waiting for link... 
* 5 seconds. 
* running dhcp for eth0 
* pump told us: No DHCP reply received 
* waiting for link... 
* 5 seconds. 
* running dhcp for eth0 
* pump told us: No DHCP reply received 
* waiting for link... 
* 2 seconds. 
* no DNS servers, can't look up hostname 
* ks location: http://10.1.1.253/redhat/ks_rhel_v4.cfg 
* transferring http://10.1.1.253//./redhat/ks_rhel_v4.cfg to a fd 
* failed to retrieve http://10.1.1.253///redhat/ks_rhel_v4.cfg 
* trying to mount CD device hda 
* trying to mount CD device scd0 
* going to set language to en_US.UTF-8 

I finally assign the IP address statically on the network config screen.
Anaconda moves 
on to ask for the location of the RedHat image. I supply the NFS
information to get the 
release. Here is the odd part. Anaconda again shows that it is running
DHCP to start 
interface eth0 even though I just supplied the static information. I am
still snooping 
the network and I see this DHCP request and the same IP gets assigned
that I had 
statically entered earlier. Anaconda then starts an interactive install.

* trying to mount CD device hda 
* trying to mount CD device scd0 
* going to set language to en_US.UTF-8 
* setting language to en_US.UTF-8 
* 164 keymaps are available 
* need to set up networking 
* going to pick interface 
* going to do getNetConfig 
* sending dhcp request through device eth0 
* waiting for link... 
* 0 seconds. 
* running dhcp for eth0 
* doing kickstart... setting it up 
* waiting for link... 
* 0 seconds. 
* starting to STEP_URL 
* going to do nfsGetSetup 
* mounting nfs path 10.1.1.253:/export/redhat/rhel4.0_ES_U5 
* mounting nfs path 10.1.1.253:/export/redhat/rhel4.0_ES_U5 
* mounted 10.1.1.253:/export/redhat/rhel4.0_ES_U5 on /mnt/source 
* can access /mnt/source/RedHat/base/stage2.img 

So, with only one interface active in the BIOS, why do the first several
DHCP attempts fail, 
showing no network traffic at all? Then this last DHCP request shows up
on the network and 
succeeds. However, at this point it is too late as the process is past
the point where 
the kickstart file needs to be retrieved. Crazy!! 
NOTE: THIS DOCUMENT MAY CONTAIN CONFIDENTIAL AND NONPUBLIC INFORMATION.
IT IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL(S) OR ENTITY(IES)
NAMED ABOVE, AND OTHERS SPECIFICALLY AUTHORIZED TO RECEIVE IT. If you
are not the intended recipient of this document, you are notified that
any review, dissemination, distribution or copying of this communication
is prohibited. If you have received this communication in error, please
notify me immediately by return email, delete the electronic message and
destroy any printed copies. Thank you for your cooperation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/kickstart-list/attachments/20070515/7576d47f/attachment.htm>