Hide Forgot
Created attachment 560729 [details] Screenshot of anaconda error. Description of problem: When doing a kickstart install of RHEL6.2 GA, specifying the kickstart file with "ks=http://" or "ks=nfs:" fails on SGI UV systems, which use EFI. (It works on other non-EFI x86_64 systems.) Anaconda complains: Welcome to Red Hat Enterprise Linux for x86_64 Error downloading kickstart file Unable to download the kickstart file. Please modify the kickstart parameter below or press Cancel to proceed as an interactive installation. http://128.162.237.12/~tee/RHEL62/ks-x86_64.cfg The only protocol that works is "ks=hd:sda4:". This seems to imply that the network isn't working. But if I then do ^Z to get a shell prompt, I am able to verify that the network is up by downloading the same kickstart file. bash-4.1# wget http://128.162.237.12/~tee/RHEL62/ks-x86_64.cfg --2001-01-03 17:14:31-- http://128.162.237.12/~tee/RHEL62/ks-x86_64.cfg Connecting to 128.162.237.12:80... connected. HTTP request sent, awaiting response... 200 OK Length: 25345 (25K) [text/plain] Saving to: `ks-x86_64.cfg' 100%[======================================>] 25,345 --.-K/s in 0.002s 2001-01-03 17:14:31 (9.84 MB/s) - `ks-x86_64.cfg' saved [25345/25345] Version-Release number of selected component (if applicable): RHEL6.2 GA How reproducible: 100% Steps to Reproduce: 1. Try to do a kickstart install using "ks=http://" or "ks=nfs:" on an SGI UV system. Actual results: Anaconda complains "Error downloading kickstart file". Expected results: The kickstart file should be downloaded, and the install started. Additional info:
Created attachment 560730 [details] Log files from /tmp Here are all of the log files from /tmp after the error occurs.
Please attach the logs as individual plain/text attachments. This makes it alot easier to evaluate them, and allows bugzilla to search them.
Created attachment 560900 [details] /tmp/anaconda.log
Created attachment 560901 [details] /tmp/syslog
I've reattached all of the files from /tmp. Please note that there was also an empty zero-length ks.cfg in /tmp.
In the syslog, note the relatively short amount of time between when ethX comes up and when it attempts to fetch the kickstart file. I wonder if there's some sort of timing problem here where the interface isn't really quite ready yet. Your test from the shell works because enough time has elapsed.
Hmm. You're right. After the error, if I wait a minute and try again, it works. So when it says "Waiting for NetworkManager to configure eth0", it must not really be waiting until the interface is up.
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
No, the waiting for NetworkManager message is waiting for NetworkManager to tell us it's done. "Done" is defined by NetworkManager in that sense, which may or may not translate to "wait until the network link is up and traffic is flowing". A workaround that may work in your case is the linksleep= parameter. Add linksleep=5 or something like that to your installer boot command line and see if that works.
I'm no longer set up to test this, but I'll make a note of the linksleep= parameter in case it ever comes up again. I've lowered the Severity, since there is an easy workaround (waiting a few seconds and retrying). Thanks.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
devel_ack- per comment #11.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.