Red Hat Bugzilla – Bug 462487
FEAT RHEL6 (1337): anaconda enhancement request: MAC+link state
Last modified: 2010-07-02 14:48:06 EDT
+++ This bug was initially created as a clone of Bug #261161 +++
Description of problem:
In the installer wenever presented with lists of NICs, not only should the
vendor info be presented, but also the MAC address and the link state
Version-Release number of selected component (if applicable):
Steps to Reproduce:
--- Additional comment from email@example.com on 2007-09-04 20:36:00 EDT ---
Realistically, there's only so much room in 80x25. MAC address information *is*
shown in the GUI installer network configuration.
--- Additional comment from firstname.lastname@example.org on 2007-09-04 23:21:12 EDT ---
There are two places in anaconda (text mode install) where you will be presented
with a list of NICs:
1) In stage 1, the loader, you are asked which NIC to use if you are performing
a network-based install and anaconda couldn't figure which NIC of yours to use.
You can bypass this screen with kickstart settings, command line boot
parameters, or just having one NIC. If you do see this screen, anaconda shows
you the device name and description (but not MAC addr) as provided by kudzu.
2) In stage 2, the installer, you are presented with a list of NICs and offered
the opportunity to configure their state on the final system. In RHEL 5.0, this
was a linear set of screens that simply looped over each NIC in the system. In
RHEL 5.1, the user is presented with a menu to select the NIC to configure. On
the individual screen, the user is shown the device description and MAC address
as well as asked questions as to how to configure the devices postinstall state
(enable IPv4, IPv6, use DHCP or not, hostname, and so on). If you only have one
NIC, you don't get the menu of NICs, but you are shown the device description
and MAC address as you progress through the configuration screens.
So, I think we have addressed the MAC address issue in RHEL 5.1. Please try a
snapshot or beta. The only area where we haven't shown the MAC address is in
the stage 1 NIC selection screen. But, as Bill stated, there is only so much
screen space in an 80x25 environment. Plus, the stage 1 screen is only to
configure the NIC for use during installation. We have plenty of ways of
specifying the NIC to use (kickstart, ksdevice= parameter) that adding the MAC
address to this menu is really unnecessary.
Regarding link state...the only situation I can think of where that's useful
during installation is to select a NIC that has a connection. You can pass
ksdevice=link for that now and anaconda uses the first NIC it finds with an
Is this feature request based on what's seen during a RHEL 5.0 installation or a
--- Additional comment from email@example.com on 2007-09-17 13:41:04 EDT ---
Adjusting priority due to our new priority inclusion criteria as outlined in
--- Additional comment from firstname.lastname@example.org on 2007-09-17 14:23:44 EDT ---
(In reply to comment #3)
> There are two places in anaconda (text mode install) where you will be presented
> with a list of NICs:
Yes, we were hoping we would get the MAC address for both the stage1 prompt when
doing a network install as well as in stage2 when setting up networking for the
> So, I think we have addressed the MAC address issue in RHEL 5.1. Please try a
> snapshot or beta. The only area where we haven't shown the MAC address is in
> the stage 1 NIC selection screen. But, as Bill stated, there is only so much
> screen space in an 80x25 environment.
Many of our systems have 10 or more NICs all of the same type. These are
usually large servers where using text install is the norm (agreed that VNC
would work but still is not the typical choice). I just pulled up the RHEL5.1
installer and it appears there is plenty of space for this. Right now the lines
in the menu look like this:
| eth0: UNCONFIGURED ^ |
| eth1: UNCONFIGURED # |
it would still be nice and clean if it were something like this:
| eth0 XX:XX:XX:XX:XX:XX : UNCONFIGURED ^ |
| eth1 XX:XX:XX:XX:XX:XX : UNCONFIGURED # |
or something like that...
> Plus, the stage 1 screen is only to
> configure the NIC for use during installation. We have plenty of ways of
> specifying the NIC to use (kickstart, ksdevice= parameter) that adding the MAC
> address to this menu is really unnecessary.
Most large server installs are not done via kickstart. I agree that the stage 2
location is the one that is more cricital however but we really would like it in
> Regarding link state...the only situation I can think of where that's useful
> during installation is to select a NIC that has a connection. You can pass
> ksdevice=link for that now and anaconda uses the first NIC it finds with an
> active connection.
This is also helpful in stage 2. If I know there is only 1 NIC connected I know
which one to set up for the OS install. It is not unusual at all for me to go
back in after the install, run ethtool to try to figure out which one actually
is connected and reconfigure to use that one.
> Is this feature request based on what's seen during a RHEL 5.0 installation or a
> 5.1 installation?
Seen in 5.1, btw, we _really_ appreciate the new menu based prompt for NICs
added to 5.1. It is a big help on the large systems with multiple NICs.
--- Additional comment from email@example.com on 2007-11-20 07:34:58 EDT ---
Withholding QE ack since we don't have a proposed solution.
--- Additional comment from firstname.lastname@example.org on 2007-11-20 07:42:57 EDT ---
Quality Engineering Management has reviewed and declined this request. You may
appeal this decision by reopening this request.
--- Additional comment from email@example.com on 2008-04-14 10:26:26 EDT ---
> in the menu look like this:
> | eth0: UNCONFIGURED ^ |
> | eth1: UNCONFIGURED # |
> it would still be nice and clean if it were something like this:
> | eth0 XX:XX:XX:XX:XX:XX : UNCONFIGURED ^ |
> | eth1 XX:XX:XX:XX:XX:XX : UNCONFIGURED # |
This might be the case when the nic is not configured "UNCONFIGURED", but when
the nics are configure, showing the mac and the configuration values just does
not fit on the screan.
--- Additional comment from firstname.lastname@example.org on 2008-06-09 09:10:01 EDT ---
Also, please refer to https://fedoraproject.org/wiki/Anaconda/Features/NewTextUI
to see where we are trying to go with text installs.
--- Additional comment from email@example.com on 2008-06-11 14:45:09 EDT ---
Given the current direction that text installs are going to be given (comment
#9) this will not get in RHEL5
--- Additional comment from firstname.lastname@example.org on 2008-09-01 18:07:46 EDT ---
Can this be reopened for RHEL6?
Cloned for RHEL6
The underlying problem - that there's simply not enough room in text mode to display this extra information - is not going to be corrected in RHEL6. This is simply a limitation of text mode, and is one big reason why we are trying to push people to using GUI or VNC installs if at all possible. 5.3 will include a feature that allows you to identify individual NICs by flashing the lights on them, to aid in this sort of task, however.
Closing this one as NEXTRELEASE as RHEL6 will pick up the identification feature we also added for 5.3 as well.
The feature requested has already been accepted into the upstream code base
planned for the next major release of Red Hat Enterprise Linux.
When the next milestone release of Red Hat Enterprise Linux 6 is available,
please verify that the feature requested is present and functioning as
Created attachment 427989 [details]
multiple NICs in loader
This screenshot shows 5 NICs in loader. The MAC address and the Indenify button are both present.
Created attachment 427991 [details]
multiple NICs in stage2
In stage2 ew now have NetworkManager and that one is used for network configuration. It will show all available interfaces and allow the user to configure them.
Comments #6 and #7 are with anaconda-13.21.50-9.el6 (0622.1 tree). I'm moving this to VERIFIED.
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.