| DATE | TIME | WHERE |
| Thu Jan 27 2011 | All Day | #fedora-test-day (webirc) |
If you come to this page before or after the test day is completed, your testing is still valuable, and you can use the information on this page to test, file any bugs you find at Bugzilla, and add your results to the results section. If this page is more than a month old when you arrive here, please check the current schedule and see if a similar but more recent Test Day is planned or has already happened.
What to test?
Today's installment of Fedora Test Day will focus on Network Interface Naming in Fedora Rawhide
Traditionally network interfaces in Linux are named ethN. With multiple network adapters, both onboard and add-in, single and multiport, in modern Server platforms, the naming of these interfaces is non-deterministic. In specific, 'eth0 does not always map to Gb1 or 'Embeddec NIC 1' as named on the server chassis. This makes the existing naming not very user friendly for administration.
Please refer to the following link for more details on the issue itself and various solutions we proposed upstream to address this issue -
- http://linux.dell.com/wiki/index.php/Oss/libnetdevname#Implementation
- http://linux.dell.com/wiki/index.php/Oss/libnetdevname#Presentations_at_various_forums
We address this issue by assigning names to network interfaces based on their physical location on the system board. Biosdevname which is a Dell developed utility, can suggest names to network interfaces, which are physical location based. http://linux.dell.com/biosdevname/
Naming convention followed is -
- Embedded devices: em<port>
- Add-in PCI cards: pci<slot>#<port>_<virtual function instance>
On a PowerEdge R710 server with 4 onboard network interfaces, 1 single port add-in network adapter on PCI slot 4, one dual port network adapter on PCI slot 3, the interfaces will be named as follows -
[root@fedora-14-r710 ~]# ls /sys/class/net/ em1 em2 em3 em4 lo pci3#1 pci3#1_0 pci3#1_1 pci3#2 pci3#2_0 pci3#2_1 pci4#1
- em1 - ethernet-on-motherboard 1
- em2 - ethernet-on-motherboard 2
- pci3#1 - ethernet interface physically located on PCI slot no 3, port 1
- pci3#2 - ethernet interface physically located on PCI slot no 3, port 2
Who's available
The following cast of characters will be available testing, workarounds, bug fixes, and general discussion ...
- Development - Developer1 (irc_nick1), Developer2 (irc_nick2)
- Quality Assurance - Tester1 (irc_nick3), Tester2 (irc_nick4), Tester3 (irc_nick5)
Prerequisite for Test Day
List any prerequisite needs for the test event. A fresh system, virtualized guest, a blank DVD ... a desire to break software?
- Usb key
- Usb externally connected HD IDE/SATA
- Empty HD IDE/SATA/SCSI
- Free space on HD
Here's a chunk which is commonly used for most Test Days. Replace XX with whatever Fedora release is pending:
- An updated Fedora XX pre-release, Rawhide (tips on installing Rawhide below), or a nightly live image
- Your hardware profile uploaded to Smolt according to these instructions
How to test?
High level details on how a contributor can get involved. This can include (but not limited to):
- Areas to target with exploratory testing
- A list of pre-defined test cases to execute
- How to report back results
Here's another common chunk (again, replace XX as above):
Update your machine
If you're running Fedora XX, make sure you have all the current updates for it installed, using the update manager. If you want to try Rawhide, see the instructions on the Rawhide page on the various ways in which you can install or update to Rawhide. Or:
Live image
Optionally, you may download a non-destructive Rawhide live image for your architecture. Tips on using a live image are available at FedoraLiveCD. Live images can be found here.
Test Cases
Provide a list of test areas or test cases that you'd like contributors to execute. For other examples, see Category:Test_Cases.
Test Results
Construct a table or list to allow testers to post results. Each column should be a test case or configuration, and each row should consist of test results. Include some instructions on how to report bugs, and any special instructions. Here's an example, from a Palimpsest test day:
If you have problems with any of the tests, report a bug to Bugzilla usually for the component udisks, or gnome-disk-utility for bugs in the Palimpsest graphical front end itself. If you are unsure about exactly how to file the report or what other information to include, just ask on IRC and we will help you. Once you have completed the tests, add your results to the Results table below, following the example results from the first line as a template. The first column should be your name with a link to your User page in the Wiki if you have one, and the second should be a link to the Smolt profile of the system you tested. For each test case, if your system worked correctly, simply enter the word PASS. If you had trouble, enter the word FAIL, with a footnote indicator, and put a link to the bug report in the References column (as in the example line). For tests you could not perform, enter a dash.
| User | Smolt Profile | Sample test 1 | Sample test 2 | Sample test 3 | Sample test 4 | References |
|---|---|---|---|---|---|---|
| Sample User | HW |  |
 |
 |