Bug 443772 - Link status should be visible when selecting network interface
Link status should be visible when selecting network interface
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
: FutureFeature, Reopened
Depends On:
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2008-04-23 04:28 EDT by Juha Tuomala
Modified: 2008-08-01 23:05 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-01 23:05:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Juha Tuomala 2008-04-23 04:28:20 EDT
Description of problem:

When installing over network into system that has multiple 
network interfaces, a dialog is displayed for selecting the
interface that should be used during the installation.

In most cases, user probably doesn't remember the interface
names nor possible different vendor/driver names and which 
one of those had the cable connected. I guess it's rare case
that all interfaces would have cable in the same network that
was used to boot up and could be used in installation.
  

Expected results:

There could be a column that would display interface's physical
link status to help to determine which interface should be selected.
Comment 1 David Cantrell 2008-04-23 21:11:56 EDT
I have played around with offering link status in the UI somehow, but it's not really easy given the 
limitations of our screen space.

We do offer a boot option that will use the first network interface with an active link:

ksdevice=link

Boot with that and it'll use the link with the network cable connected.
Comment 2 Juha Tuomala 2008-05-16 09:53:31 EDT
> but it's not really easy given the 
> limitations of our screen space.

Picture:

  http://tuju.fi/tmp/fedora/net.dev-f9.jpg

demonstrates that "Networking Device" is in the dialog
topic, and the 'device' and 'eth<n>' words are repeated
throughout the dialog. I agree that there aren't much
space but it could be used more efficiently.

Line:
  eth0 - Ethernet device eth0 - 00:0d:56:xx:xx:xx

could be written:
  eth0 - Ethernet - Link up   - 00:0d:56:xx:xx:xx
  eth0 - Ethernet - Link down - 00:0d:56:xx:xx:xx

and even those would be the same length, I think the
whole MAC address is mostly irrelevant at this point,
who would a) know them? b) able to check it as 99,99%
of physical interfaces don't have it visible anywhere
when the card is running and inserted into machine?

Perhaps someone writes the address down until installing
a card or reads it from the package but those are 
rare cases.

Also, a header row could save space:

  Device Type     Speed Link  Physical address
  ---------------------------------------------
  eth0   Ethernet 100   Up    00:0d:56:xx:xx:xx
  eth1   Ethernet 1000  Down  00:0d:56:xx:xx:xx


Anyway, with or without MAC address, please reconsider
adding the link status, even a speed (10/100 Mbit/s)
into dialog.
Comment 3 David Cantrell 2008-07-18 22:15:48 EDT
It's not just a matter of having enough room for the words "link up" and "link down".  What about non-
English languages?  We're trying to rely on the information given to us by the device discovery tools 
(currently udev and hal, maybe something else in the future).

The MAC address is request by a lot of people.  Many sites track systems by MAC address and I would 
be hesitant to remove or even change how that information is conveyed.

To make matters more difficult, link status doesn't always seem to work from what I've seen.  Some 
NICs will report link availability if there is a cable connected, but other cards are smarter depending on 
what you are plugged in to (router, switch, hub, and so on).

What I have been playing around with is giving users the option to identify the NIC during installation.  
In the dialog box, I want to add a new button.  If you select it (instead of OK or Back), it will blink the 
LEDs on the device so you can physically identify it on your system before proceeding with installation.  
Would that be an acceptable solution?
Comment 4 Juha Tuomala 2008-07-19 06:18:19 EDT
> To make matters more difficult, link status doesn't always seem 
> to work from what I've seen.  Some NICs will report link availability if
> there is a cable connected, but other cards are smarter depending on 
> what you are plugged in to (router, switch, hub, and so on).

Well, link-status is a interface information at OS level. If it doesn't
match with the reality, that's a problem, someone could call it as a bug.
But other parts of the system shouldn't be designed by existence of some
bug in lower levels. It's their sandbox and they should provide the right
information which rest can relay on.

> What I have been playing around with is giving users the option to 
> identify the NIC during installation.  
> In the dialog box, I want to add a new button.  If you select it 
> (instead of OK or Back), it will blink the LEDs on the device so 
> you can physically identify it on your system before proceeding with
> installation. Would that be an acceptable solution?

Well, how reliable *that* would be then? Would it be based on transmitting
something and changing the administrative status?

Anyway, my desktop box which I reinstall more frequently is under table.
I can go on my knees, grawl under table, inhale some dust and try to figure
some blinking light behind the dark back of the computer. But I didn't expect
that it would be part of the installation of shiny new Fedora. Most likely
I would do the trial-n-error cycle again.

I would address this kind of issue based on the majority's needs. Having 
two net interfaces is probably already under 10 or 5% of majority. 
Are majority those ~10% desktop or server hardware? How easily their
cabling+interfaces are accessible? Server might even be in rack space
where person doing the installation has no physical access (yes, at
my work there is such, only KVM console network).

Anyway, I *would* assume, that the information for decision process of the
installation will be presented *on* screen whenever it's possible. Anything
else would be against good good human interface.

Having other people's comments on this might also help.
Comment 5 David Cantrell 2008-08-01 23:05:29 EDT
(In reply to comment #4)
> > To make matters more difficult, link status doesn't always seem 
> > to work from what I've seen.  Some NICs will report link availability if
> > there is a cable connected, but other cards are smarter depending on 
> > what you are plugged in to (router, switch, hub, and so on).
> 
> Well, link-status is a interface information at OS level. If it doesn't
> match with the reality, that's a problem, someone could call it as a bug.
> But other parts of the system shouldn't be designed by existence of some
> bug in lower levels. It's their sandbox and they should provide the right
> information which rest can relay on.

I don't think I explained it very well.  Some cards just don't give us the information we're looking for.  
The driver makes a guess or just doesn't provide the information.  It's inconsistent, at least from what 
I've seen.  However, it is what we have to rely on for now.

> > What I have been playing around with is giving users the option to 
> > identify the NIC during installation.  
> > In the dialog box, I want to add a new button.  If you select it 
> > (instead of OK or Back), it will blink the LEDs on the device so 
> > you can physically identify it on your system before proceeding with
> > installation. Would that be an acceptable solution?
> 
> Well, how reliable *that* would be then? Would it be based on transmitting
> something and changing the administrative status?

It's the same as doing 'ethtool -p' on the interface.

> Anyway, my desktop box which I reinstall more frequently is under table.
> I can go on my knees, grawl under table, inhale some dust and try to figure
> some blinking light behind the dark back of the computer. But I didn't expect
> that it would be part of the installation of shiny new Fedora. Most likely
> I would do the trial-n-error cycle again.
> 
> I would address this kind of issue based on the majority's needs. Having 
> two net interfaces is probably already under 10 or 5% of majority. 
> Are majority those ~10% desktop or server hardware? How easily their
> cabling+interfaces are accessible? Server might even be in rack space
> where person doing the installation has no physical access (yes, at
> my work there is such, only KVM console network).

The majority case is one active network interface.  In the event that you have two or more NICs that are 
wired and have active links, you are suddenly not in the majority.  Most people won't see the device 
selection screen, or if they do it will be because they are asked to choose the wireless interface or the 
wired interface of which the descriptions provided are sufficient on every system I've seen.

Rather than providing information such as Link Up or Link Down in the UI, the main driving 
development philosophy in the installer is to make things just work.  As soon as we have to stop and 
ask the user for something, we've complicated matters.  Granted, there are obviously things that we 
have to prompt for, but we try to keep these to a minimum.

For you use case, I still fail to see how providing Link Up or Link Down in the description line in the UI 
is any better than booting with 'ksdevice=link' which will pick the first interface with an active link.

> Anyway, I *would* assume, that the information for decision process of the
> installation will be presented *on* screen whenever it's possible. Anything
> else would be against good good human interface.

I agree with you, however, I would have to say the need for a decision has to be there.  And for this use 
case, I think we already provide enough information for the user to continue automatically (e.g., 
ksdevice=link).

> Having other people's comments on this might also help.

If you want to continue the discussion, let's take it to anaconda-devel-list@redhat.com so we can get 
input from the other developers.  For now, I'm going to close this bug as WONTFIX.  If a discussion 
shows up on the mailing list and we come up with a different solution, I'll work on that.

Thanks for the input.  BTW, I am not trying to be negative, just constructive.  If I sound negative, it's 
usually because I'm trying to play devil's advocate just to get more information and more "what if's" for 
the situation.

Note You need to log in before you can comment on or make changes to this bug.