Description of problem: I am booting anaconda "rescue", with boot images reachable over NFS. Therefore I have to configure at least one network interface, which I do using DHCP and images do load. A moment later anaconda asks me if I want to configure network interfaces on the system and it turns out that both existing interfaces are "UNCONFIGURED" despite this detail that it should be pretty simple to check that this is not the case. So I go through an exercise of configuring the same interface again. This time is easier to pick the right one as not only MAC but a card type is displayed. The net effect is that I end up with an interface configured like that: 3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:02:b3:a3:60:e4 brd ff:ff:ff:ff:ff:ff inet 192.xxx.yyy.193/24 brd 192.168.23.255 scope global eth1 inet 192.xxx.yyy.192/24 brd 192.168.23.255 scope global secondary eth1 inet6 fe80::202:b3ff:fea3:60e4/64 scope link valid_lft forever preferred_lft forever In other words, eventually two different leases were used on the same interface instead of one and I had to go through the same configuration twice. If there is a possibility that some other configuration may be required then I would expect to be asked: "Should I use this configuration or you want to change it?". Version-Release number of selected component (if applicable): boot images dated 2008-01-22
Fixed in rawhide. The correct configuration is shown now on the first run of that dialog box. This was actually a bug on RHEL-5 that I had already fixed. However, you are experiencing two bugs here, and I've only fixed one of them. The other is coming with a larger set of network rewrites I'm doing in anaconda. If you do a network boot of anaconda rescue mode, when it gets to the screen you're talking about, anaconda will rerun the DHCP client even though the device was configured to pull across the stage 2 image. I know about this, it's a different bug, I'm working on it. I just wanted to let you know here.