- 1 Network enablement and network configuration
- 2 Modes of configuration
- 3 Selection of device to be enabled in installer
- 4 Wireless
- 5 IPv6
- 6 Bugs and issues
Network enablement and network configuration
Network enablement in installer
Configure and activate a network device to be used during installation, e.g. to get kickstart, packages, or for network-backed storage. The configuration can be supplied with boot parameters, or kickstart, or if needed user will be prompted to configure a device in UI. Network enablement can happen in loader or in stage 2:
- In loader:
- for kickstart
- if network is needed in loader, e.g. to fetch kickstart or updates over network, if installing over vnc, or running sshd in installer
- in rhel5 also in case of network installations (i.e. using remote stage 2 or repositories)
- for kickstart
- In stage 2, using text mode UI or GUI:
- when setting up network attached storage (iscsi, fcoe)
- when using network repository
Additional devices can be activated in GUI, using NetworkManager Connection Editor (nm-c-e) by checking Connect Automatically. Since RHEL 6 and Fedora 16, additional devices can be activated (in loader) using kickstart network option
--activate (this can be needed e.g. when downloading packages from one NIC/subnet and having iSCSI target on separate NIC/subnet).
Once the device is activated, it can't be reactivated with changed configuration (e.g. static configuration with fixed nameserver, see bug 504983). I want to offer this possibility in GUI which requires option to activate/disconnect a device on demand (see device activation). It can be worked around by editing configuration files.
Network configuration of target system
Can be done with kickstart or in GUI using nm-c-e. Undesirably, checking Connect Automatically in nm-c-e will activate the device after the configuration is saved (see ONBOOT side-effect). I am not aware of any problems caused by this side effect which is invisible to the user (Anaconda doesn't wait for NetworkManager activating the device), but I can imagine there might be some lurking.
As you can see, configuration of installer environment and target system is not well separated. It is because using nm-c-e for enablement we have to use the same configuration files for installer and target system configuration.
On Live CD, network is configured in Live CD environment using NetworkManager Applet on panel.
Modes of configuration
These anaconda boot options can be used to enable network in loader (e.g. for getting kickstart, updates image, or for vnc):
asknetwork, dhcpclass, dhcptimeout, dns, essid, ethtool, gateway, ip, ipv6, ksdevice, linksleep, mtu, netmask, nicdelay, noipv4, noipv6, wepkey.
network command can be used both to enable and configure devices. The behaviour has been changing in the course of adoption of NM.
- RHEL 5 - in case of network installation the first
networkcommand from kickstart activates or reactivates (if the device has already been enabled e.g. to get kickstart using default DHCP or configuration given in boot parameters) relevant device with configuration set by the command. For non-network installs (e.g. for media or hd install) the device of the first network command is only configured for target system. Other
networkcommands only set configuration for target system, the devices are not activated in installer.
- RHEL 6.0, Fedora 15 - the same as in RHEL 5, but already activated device is not reactivated with configuration set in network command , it is only configured for the target system. Another difference from RHEL 5 is that the first network command device is activated also for non-network installs .
- RHEL 6.1, Fedora 16 - expected behaviour is the same as in RHEL 5 (bug 668395) with option to activate additional devices using new
network --activateoption (bug 638131). Note that the device from first
networkcommand is (re)activated regardless of the option (to keep the behaviour of RHEL 5).
For RHEL 6.0, Fedora 14, and later, devices that are supposed not to be activated in installer and have
onboot option set will be activated just before downloading packages due to ONBOOT side-effect. We have no reports of problems caused by this, but in some cases activation of the device could cause change of routing table making packages inaccessible.
Loader text UI
Serves for selection and/or configuration of a network device that should be enabled in loader. It is skipped if the information is provided via boot options or kickstart unless required by boot option
asknetwork. Configuration options of this UI are a subset of nm-c-e which is used in GUI.
Once the device is successfully activated, there is no possibility to change its configuration in loader UI (see bug 504983).
Configuration of selected device:
The IPv6 options correspond to following options of nm-c-e:
- Automatic, DHCP only
If both IPv4 and IPv6 configuration is enabled, failing IPv4 configuration of activated device means that activation is considered as failing overall (which corresponds to Require IPv4 addressing for this connection to complete checked in nm-c-e or
Static (Manual) configuration:
- Gateway: entry is used both for IPv4 and IPv6, only one gateway is allowed. Bad, considtent with boot options and kickstart.
- Name Server: entry can contain more name servers separated by comma.
- IPv4 Address: and IPv6 Address: is present only if manual configuration of respective protocol is selected in previous dialog.
When enabling network in stage 2, this device selection / network enablement confirmation dialog appears:
Selected device will then be configured using NetworkManager Connection Editor (nm-c-e):
nm-c-e is run as separate process. Anaconda should ensure that the selected device will be actually activated in installer.
More of target system network configuration (beyond the devices that has been enabled in installer and the configuration they used) can be done from hostname screen by clicking on Configure Network button:
The saved (target system) configuration will not be applied to device that have been already activated in installer environment. To achieve this, the device must be deactivated and reconnected which can be done only from shell in
tty2, for example by editing of configuration files. See this issue for details.
On the other hand, the device which had not been activated yet will be activated by checking Connect Automatically.
Text mode UI
Rather limited compared to nm-c-e.
Editing configuration files
Anaconda is communicating with NetworkManager mostly with
ifcfg files (nm-c-e stores its configuration there too). It can be handy to edit them directly for debugging or as workaround solution. Files can be edited using shell in virtual terminal
tty2 ([Ctrl][Alt][F2]). Their location is
/etc/sysconfig/netwrok-scripts/ifcfg-<device name>. The configuration will be applied in installer after the device is disconnected (its
ifcfg file is removed) and reactivated (an
ifcfg file is copied back to its location with
ONBOOT=yes set). So configuration of active device for installer environment can be changed this way:
mv /etc/sysconfig/network-scripts/ifcfg-eth0 /tmp vi /tmp/ifcfg-eth0 mv /tmp/ifcfg-eth0 /etc/sysconfig/network-scripts
At the end of the installation,
ifcfg files are copied to target system tree to directory
Selection of device to be enabled in installer
This is behaviour in rhel6-branch which should go into rawhide soon (but probably not into F15):
- Automatic use of device configured in iBFT and having active link.
network --deviceoption. For the first
networkcommand defaults to
ksdeviceboot option, device used to fetch kickstart, or prompt in loder UI (how about detected iBFT device with link?). For next
--deviceoption is mandatory (will be enabled only with
- Dialog in loader UI if none of above applies.
Passing SSID and WEP key with boot parameters or kickstart is supported in Fedora 14. Other methods of authentication can be set in GUI using nm-c-e, although there are some issues with AP selection which could be solved with integration of NetworkManager Applet.
- IPv6 default gateway not honoured https://bugzilla.redhat.com/show_bug.cgi?id=677609
- NM bug 604334 - fixed, not in F15 Alpha, will it get into F15? Seems so, we're working on it.
- anaconda boot option
gatewaydosn't work, and kickstart was broken recently. Patches will go in F15 soon.
gatewayoption is common for ipv4 and ipv6 in boot options, kickstart, and loader UI. The problem is that it allows (unlike nameserver/dns) only one value (bug 562538). I think adding
gateway6to ks/boot options is a way to go, rather than allowing both values in existing
IPV4_FAILURE_FATAL=yesby default so ipv4 failing and ipv6 configuration succeeding is considered as failing overall (bug 633815). Well, I think this is OK, ipv4 can be turned out explicitly in boot options, kickstart, or UI. We don't want to pass over ipv4 configuration fail silently.
/etc/resolv.confis not updated with ipv6 nameserver by NM - bug 672282 - this should be fixed in NM - will it get into F15? Seems promising.
- IPv6 accessibility of Fedora repository mirrors. From what I know it should be working. I don't have access to outer ipv6 world so I can't even try it myself.
- Network installation on IPv6-only networks
Bugs and issues
- DVD install defaults to ONBOOT=no leaving networking down after reboot - bug 498207. This is rather sore issue. Only devices enabled during install will have set ONBOOT=yes by default. For other devices, the setting has to be configured.
- Before rebooting we could detect having no device to be activated automatically and offer change on the last screen (probably with just Configure Network button on the screen).
- No more than one device can be activated in installer with kickstart (e.g.: one NIC for repositories, another for iSCSI). Bug 638181. Done in rhel 6.1 - in testing.
- Reading configuration from iBFT in anaconda instead of passing the task to NetworkManager and dracut. Bug 634016. Done in rhel 6.1 - in testing.
noipv6probably don't work correctly for more devices activated with different settings in some cases because loader is using global flags for it. We should use IPV4_UNUSED_METHOD in loaderData->ipv4method or reset the flags when processing ks at least (master, rhel6-branch).
- Configuration of successfully activated device in installer environment can't be changed (related bugs: bug 592856, 504983, 635239, 688527 (rhel6-branch)). There is no way to disconnect the device and activate it so that changed configuration could be applied (except for workaround by editing configuration files). In desktop, this is done with NetworkManager Applet which offers also selection of access points for wireless connection. The use case is static configuration with wrong DNS server IP. In this case a device is considered as being successfully activated and user is not given second chance to configure network. i.e. to change device configuration or to enable another device (for example when adding network repo or iSCSI drive in stage 2 for the latter). It would be nice to have chance to change network configuration of installer environment at any moment, something like NM systray icon. The question is how to integrate it in anaconda UI, there are UX design concerns and implementation concerns (NM Applet is a C application using freedesktop.org systray interface specification). Other possibility is to add reconfigure option just to places where we might want it. It would require our own UI implementing the functionality of NM Applet. I proposed patches for these two approaches (they concern only GUI) on anaconda-devel-list (follow the links for screencasts):
Update for F15: NM applet was simplified and gnome-control-center network has the functionality we would need in anaconda (list of devices/connections with info, on/off switch, access point selection for wireless, button to edit connection settings in nm-c-e)
- Places in stage 2 where option of network (re-)configuration would be useful (regardless of network enablement).
- Standard step (the hostname screen) with optional network configuration. It is the only opportunity currently.
- Advanced storage screen.
- Repository UI screen. Note that this wouldn't help in case of edit of failing base repository which happens in dialog before repository UI screen step (tasksel step) so successful enablement of network with wrong static values (e.g. dns) is fatal here. I attempted to reorganize repository UI to deal with it .
- Before reboot to give chance to automatically activate a device after reboot, see this issue.
- Support for stateless dhcp6 in loader UI - should happen in nm-c-e first as we provide only subset of it (bug 656335)
- Check that anaconda works well with new (F15) Consistent Network Device Naming - after move from
peverything seems to work nice.
- [Back] in loader UI, Manual TCP/IP Configuration screen, doesn't work in F15. It does on rhel6-branch so I guess it got screwed up in master by some other patch since I had fixed it (commit ec146852176e2b41ace7725ed8eda337842d3160).
- review [Retry] after failing enablement in loader
- Doesn't work when enabling net to get kickstart (probably never has) or when activating devices from kickstart. Well it is kickstart case, so missing option to correct in UI is not so terrible.
- Does it work in non-ks cases when activating early network for vnc, sshd, syslog? Isn't early networking too early?
- Unable to retrieve ftp repository unless adding a http repo first - https://bugzilla.redhat.com/show_bug.cgi?id=679709 - this bug has a sad long confusing history...
- allow single Return to accept DHCP net config on stage1 network page - 648357
- KeyError: 'wlan0' - https://bugzilla.redhat.com/show_bug.cgi?id=668158
- Anaconda reports "Network error" despite DHCP being successfully configured - 669019 - dhcp timeouted
nameserverin loader UI allows only for single address (bug 660316)
- consider for rhel6-branch
- For media installs sshd can be started uselessly without networking - bug 643738
- Enable support for static ipv6= cmdline option - https://bugzilla.redhat.com/show_bug.cgi?id=679108
- 802.1q vlan tagging in anaconda appears to no longer work - https://bugzilla.redhat.com/show_bug.cgi?id=668065 - needs triage, RFE?
- insertion of static network IP fails on install - bug 654440 - needs triage, seems like notabug
- error downloading kickstart file from nfs with just "ks" - bug 653655
- depends on NM's 658855 ?, next-server option
- Renaming ethX devices during install creates duplicates - 652499 - doing unusal things...
- HostName is empty by default? - 633012 - [NEEDINFO]
- IPv6 default gateway not honoured - 677609
- Documentation update:
- Fedora - TODO: update Installation Guide
- RHEL: big update posted in https://bugzilla.redhat.com/show_bug.cgi?id=679104
- https://bugzilla.redhat.com/show_bug.cgi?id=647462 (rhel 6.1, F15) -
- https://bugzilla.redhat.com/show_bug.cgi?id=668395 (rhel 6.1, F15) -
- https://bugzilla.redhat.com/show_bug.cgi?id=647462 (rhel 6.1, F15) -
- limit heralding of 'ibft' and 'bootif' for ks network --device in rhel as they are not handled well in stage 2 processing (exception raised)
- hostname setting
- NM sets hostname when bringing up device (as part of policy)
- ifcfg-rh updates
/etc/sysconfig/networkbut it seems that it just writes out a new one with
- update for kickstart handling changes in loader
- new in NM 9.0: org.freedesktop.NetworkManager.Settings.SaveHostname(), hostname property