Description of problem:
When attempting to install Fedora 8 via Kickstart by passing network parameters
as kernel arguments, the installation does not complete. The installation
process gets stuck at "Sending request for IP information for eth0...". The same
set of arguments works fine with the Fedora 7 installer.
Version-Release number of selected component (if applicable):
Boot the installer image with the kickstart file path, and static network
Steps to Reproduce:
1. Boot installer/initrd on a machine connected to a network without DHCP.
Supply the 'ip', 'netmask', 'gateway', 'dns', 'ks' and 'ksdevice' arguments.
System remains stuck, displaying:
| Sending request for IP information for eth0... |
System should configure network, fetch kickstart file and proceed normally with
I've tried to install a paravirtualized Xen guest using the following config:
kernel = "/mnt/Fedora-8-i386-DVD/images/xen/vmlinuz"
ramdisk = "/mnt/Fedora-8-i386-DVD/images/xen/initrd.img"
extra = "text ip=192.168.1.3 gateway=192.168.1.1 dns=192.168.1.1
name = "freeipa"
memory = "512"
disk = [ 'phy:/dev/hermesVG/freeipa,xvda,w', ]
vif = [ 'mac=aa:00:00:40:21:42, bridge=xenbr0', ]
vcpus = 1
on_reboot = 'destroy'
on_crash = 'destroy'
When anaconda gets at the kickstart download stage it returns an error saying
that it can't get the kickstart file (there's no traffic on the http server).
I've also tried to a Xen kickstart install without specifying the network
configuration in the boot parameters (only the kickstart file) and even if I
select to configure manually the IPv4 settings and anaconda asks me for the
details, afterwards it still tries to configure the interface using DHCP
("Sending request for IP information for eth0...").
Just in case it's relevant, I'm running kernel-xen-2.6.21-2950.fc8 &
xen-3.1.0-13.fc8 and using the original Fedora DVD (not some updated respin).
*** Bug 371821 has been marked as a duplicate of this bug. ***
Note that the presence of DHCP server does not workaround this bug (see bug
371821 for more info)
I have exactly the same problem. Providing the static network settings via the
kickstart file itself is also broken (rather than the kernel command line as the
original bug report states). Providing the kickstart file on the hard drive
(via ks=hd:...) does not work, either.
Switching virtual consoles to VC4 shows repeated attempts to DHCPDISCOVER with:
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 ..... After 4 attempts, it
times out, then the cycle repeats.
This basically means it is impossible to install via the network to a headless
machine with static IP addresses (which I have done since Fedora 3). I have
also noticed lots of other peculiarities with the F8 install that didn't seem to
be present in F7, like the machine hanging for many minutes (10+) when booting
the install kernel. Is the F8 install kernel just trash? Is there another,
better, install kernel image out there?
Should I assume this bug is not going to get looked at? I'd like to see it
fixed, but given > 2 months with no apparent update, I'm guessing this means it
will not be, or at least not until Fedora 9 timeframe...
For Fedora 9, probably not. The networking code path in loader needs A LOT of
work. I am currently working on that, but I would prefer to fix it correctly
rather than paper over it with a short term fix (that's sort of how we ended up
with the choose your own adventure code path we have now).
I tested it in Fedora-9 Beta, the problem still exists
Fedora 9 final, same problem.
Please "paper over" the bug so users can use the system. A perfect and beautiful
piece of code is great, but an immediate fix would be better!
I'm moving this to F9 bugs, as the bug is still present in the current release.
Please fix this issue.. It has been around for such a long time :(
Yes, please, fix it or if there is a way to work around it, please let us know.
This single bug has kept me at F7 instead of upgrading to F8 or F9. I have
LOTS of machines, and not being able to use kickstart is crippling...
At least, this issue should be in the release notes.
I lost a fair amount of time today trying to figure out what I was doing wrong,
just to discover it was never possible...
Fixed in anaconda-18.104.22.168-1, please test when that version appears in the rawhide tree.