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.
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.
> 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.
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?
> 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.
(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 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.