Red Hat Bugzilla – Bug 453265
IPV6 only installation flaws
Last modified: 2009-02-14 15:37:55 EST
Description of problem:
On installing fedora rawhide with a static IPv6 addressing scheme several
installation flaws are encountered.
Version-Release number of selected component (if applicable):
Rawhide anaconda 18.104.22.168
Steps to Reproduce:
1. Start a network installation of rawhide
2. IPv6screen1 shows the TCP/IP configuration IPv4 disabled and IPv6 enabled
with manual configuration.
3. IPv6screen2 shows the given IPv6 addressing schemme
4. IPv6screen3 shows the URLsetup screen as I use a http-based installation.
Altough I have givven the DNS nameserver address in the previous step I can not
use FQDN, but have to specify by IPv6 address notation. (DNS is not working here).
5. IPv6screen4 shows the Network configuration screen.Altough I have given a
static IPv6 address, this screen defaults to DHCP. It should default to static.
The interface is marked 'active' but furtheron in the installation this wil
change to 'not active'.
6. IPv6screen5 shows the IPv6 Configuration for my interface. It defaults to
'Automatic neighbor discovery. It should default to the addressing scheme give
in step 3. Furthermore if I change to 'Manual address configuration' I can not
give the DNS address and default gateway. (It is possible to give these
parameters in the griphic installation though).
7. IPv6screen6 shows the result after changing to static IPv6 addressing scheme
in the interface configuration screen. Although given a static address, this
screen still shows DHCP for eth0.
8. After completing the installation on first reboot I have a DHCP IPv4 address
on my interface and a autodiscovered IPv6 address (not the assigned static one).
dhcpclient is running on eth0. The service NetworkManager is active and the
service network is not. This is already filed as bug#445506.
9. On stopping NetwokManager and starting network I have no interface active,
because in ifcfg-eth0 there is the line "ONBOOT=no" although at step 5 the
interface was marked active. If I change to "ONBOOT=yes" and restart the network
service the interface is configured as expected.
10. The anaconda-ks.cfg file has not adopted the IPv6 addressing scheme as would
have been a IPv4 addressing scheme.
- DNS is not funktioning in the retrieval of images stage.
- The addressing scheme is not adopted from one step to another as expected.
- There is in textmode no possibility to assign a static IPv6 DNS address and
- On first boot the network interface is not configured as asked for in the
- The anacond-ks.cfg file does not addopt the IPv6 addressing scheme
- The image URL should be funktioning with a FQDN.
- The addressing scheme from the image retrieval step should be adopted by the
networ interface configuration step
- It should be possible to assign a default gateway and DNS address in the
network configuration step
- On first boot the static IPv6 addressing scheme should be configured as ask
for in the installation process.
- The anaconda-ks.cfg file should adopt the IPv6 addressing scheme in a
This report is in part a follow up of bug#230949 and bug#433290, which are
solved, but leave some flaws. The screen shots metioned are uploaded in an
Several small flaws prevent the installation of fedora rawhide using a IPv6
static addressing scheme out of the box. At the moment manual after
configuration is needed to achieve the wanted result.
Created attachment 310505 [details]
Screenshots belonging to this description
Since we've moved to NetworkManager in anaconda, IPv6 installations won't work until NetworkManager gains IPv6 support (even though IPv6 installation support first appeared in FC-5, NetworkManager is a different animal).
I am working with NetworkManager upstream to get the necessary bits present there so I can then rework the UI elements and other code in anaconda.
This will not be done for F-10.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
*** This bug has been marked as a duplicate of bug 450088 ***