Red Hat Bugzilla – Bug 429947
anaconda does not allow to correct network interface choices
Last modified: 2008-04-02 14:41:37 EDT
Description of problem:
While booting over a network a machine with two network interfaces,
and picking up an network method installation, like NFS, one arrives
eventually to "Configure TCP/IP" form. So far so good but assume
that on a previous screen a "wrong" interface was chosen and
that we are using DHCP configuration (I can do here IPv4 only).
After a long timeout an attempt to configure fails, as expected,
and one can go "Back" one screen and pick up another interface.
This time a configuration attempt returns quickly and ...
we are starring back at "Configure TCP/IP". There is no apparent
way forward. An info on vt3 shows that at least DHCPOFFER
was received and on vt4 "eth1: links becomes ready". No further
The only way out appears to be to restart the whole installation
procedere from scratch and choose another network interface this
Version-Release number of selected component (if applicable):
boot images dated 2008-01-22
every time on few tries
I think clumens made an attempt to fix this a day or two ago
Yes, this should be fixed in today's rawhide.
Hm, I tried that with 20080329 images. If that bug was fixed in January
then it is back.
Here's the UI flow I'm seeing:
pick URL method -> pick wrong ethernet device -> configure tcp/ip -> wait wait
wait -> configure tcp/ip -> back -> pick right ethernet device -> configure
tcp/ip -> enter URL
Is this not the same flow that you are seeing?
The flow I got, at least on Saturday, was like that:
pick wrong ethernet device -> try to configure tcp/ip via DHCP ->
wait wait wait -> back -> pick right ethernet device ->
try to configure tcp/ip via DHCP again -> quickly back to a dialog
screen with an interface configuration -> go into a configuration
After that reboot->pick up right ethernet device->configure->
get asked for URL.
I see that there are 20080331 images available. Should I try that
again? Downloading 100M+ of stage2.img is for me not so speedy
I retried that with 20080402 images and now this behaves like expected,
i.e. like in comment #4. Let us hope that it will stay that way
(although this is really not critical at all as rebooting in that moment
is still "cheap").