<tt>kickstart-list-bounces@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.</tt> <tt>> </tt> <tt>> 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.</tt> <tt>> </tt> <tt>> 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.</tt> <tt>> </tt> <tt>> 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.</tt> <tt>> </tt> <tt>> Chip </tt> 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. <tt>kickstart-list-bounces@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.</tt> <tt>> </tt> <tt>kickstart-list-bounces@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.</tt> <tt>> </tt> <tt>> I ended up turning off all the NICs in the bios and this helped.</tt> <tt>> </tt> <tt>> </tt> <tt>I disabled the second interface in the bios as suggested. No difference. Let me describe</tt> <tt>what happened and show you the anacaonda log and you may see why this is so puzzling.</tt> <tt>The process up through the kernel load works fine. The initial DHCP request shows up on the</tt> <tt>network snoop, the pxelinux downloads. I get the PXE menu and kick off the auto install.</tt> <tt>The kernel and initrd download successfully. Here is the cmdline passed to the kernel based</tt> <tt>on the contents of /proc/cmdline.</tt> <tt>initrd=rhel_v4/initrd.img ks=http://10.1.1.253/redhat/ks_rhel_v4.cfg BOOT_IMAGE=rhel_v4/vmlinuz</tt> <tt>On the screen, I see the initial Anaconda screen with various messages on loading drivers. Then</tt> <tt>a message is displayed that DHCP is attempting to start eth0. It fails and the net config screen</tt> <tt>appears. I set it for DHCP again. No luck. Here is what shows up in the anaconda log after several</tt> <tt>DHCP attempts from the network config screen.</tt> <tt> only have one network device: eth0</tt> <tt>* sending dhcp request through device eth0</tt> <tt>* waiting for link...</tt> <tt>* 0 seconds.</tt> <tt>* running dhcp for eth0</tt> <tt>* pump told us: No DHCP reply received</tt> <tt>* eth0 isn't a wireless adaptor</tt> <tt>* waiting for link...</tt> <tt>* 5 seconds.</tt> <tt>* running dhcp for eth0</tt> <tt>* pump told us: No DHCP reply received</tt> <tt>* waiting for link...</tt> <tt>* 5 seconds.</tt> <tt>* running dhcp for eth0</tt> <tt>* pump told us: No DHCP reply received</tt> <tt>* waiting for link...</tt> <tt>* 5 seconds.</tt> <tt>* running dhcp for eth0</tt> <tt>* pump told us: No DHCP reply received</tt> <tt>* waiting for link...</tt> <tt>* 2 seconds.</tt> <tt>* no DNS servers, can't look up hostname</tt> <tt>* ks location: http://10.1.1.253/redhat/ks_rhel_v4.cfg</tt> <tt>* transferring http://10.1.1.253//./redhat/ks_rhel_v4.cfg to a fd</tt> <tt>* failed to retrieve http://10.1.1.253///redhat/ks_rhel_v4.cfg</tt> <tt>* trying to mount CD device hda</tt> <tt>* trying to mount CD device scd0</tt> <tt>* going to set language to en_US.UTF-8</tt> <tt>I finally assign the IP address statically on the network config screen. Anaconda moves</tt> <tt>on to ask for the location of the RedHat image. I supply the NFS information to get the</tt> <tt>release. Here is the odd part. Anaconda again shows that it is running DHCP to start</tt> <tt>interface eth0 even though I just supplied the static information. I am still snooping</tt> <tt>the network and I see this DHCP request and the same IP gets assigned that I had</tt> <tt>statically entered earlier. Anaconda then starts an interactive install. </tt> <tt>* trying to mount CD device hda</tt> <tt>* trying to mount CD device scd0</tt> <tt>* going to set language to en_US.UTF-8</tt> <tt>* setting language to en_US.UTF-8</tt> <tt>* 164 keymaps are available</tt> <tt>* need to set up networking</tt> <tt>* going to pick interface</tt> <tt>* going to do getNetConfig</tt> <tt>* sending dhcp request through device eth0</tt> <tt>* waiting for link...</tt> <tt>* 0 seconds.</tt> <tt>* running dhcp for eth0</tt> <tt>* doing kickstart... setting it up</tt> <tt>* waiting for link...</tt> <tt>* 0 seconds.</tt> <tt>* starting to STEP_URL</tt> <tt>* going to do nfsGetSetup</tt> <tt>* mounting nfs path 10.1.1.253:/export/redhat/rhel4.0_ES_U5</tt> <tt>* mounting nfs path 10.1.1.253:/export/redhat/rhel4.0_ES_U5</tt> <tt>* mounted 10.1.1.253:/export/redhat/rhel4.0_ES_U5 on /mnt/source</tt> <tt>* can access /mnt/source/RedHat/base/stage2.img</tt> <tt>So, with only one interface active in the BIOS, why do the first several DHCP attempts fail,</tt> <tt>showing no network traffic at all? Then this last DHCP request shows up on the network and</tt> <tt>succeeds. However, at this point it is too late as the process is past the point where </tt> <tt>the kickstart file needs to be retrieved. Crazy!!</tt> <DIV> 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. </DIV>