hmm, on Wed, Feb 02, 2011 at 10:24:55PM -0500, Nick Holland said that > problems which are easy to fix. Having worked with similar problems > (and their recovery) on other OSs...ick.
talking about other OS's and risking making a fool of myself, what do the others think about the new scheming fedora plans to implement? [1] disks have solved their ambiguity, DUID's are great. a unique identifier is not necesseraly helpful for a nic in this case however. now, however <insert your opinion> that scheme might be, there is a certain logic to it. the physical placement of the card (esp in the case of replacing a faulty one is the ultimate word regarding that nic's role in the given machine. i always pereferred the openbsd naming to linux's because one can put a "face" to the nic, it's not just eth[0-9]. it is esp. useful if cards are mixed in the box :] (e.g. rl is outbound, re inbound, etc) > A much better solution to your original problem would be to have spare > parts on hand enabling you to replace the failed re0, in which case you so it's not enough that you are in great stress because of the outage and you need to replace the faulty card(s), you have to make sure it uses the same driver as well? :] i am sorry but this seams to me as the parallel case of "policy problems shouldnt be solved in software" applied here on the hardware. the ideal state would be just to replace the card and be done with it (of course this still wouldn't work if an embedded nic needs replacing with an external one) [1] http://digitizor.com/2011/01/25/fedora-15-network-device-naming/ -f -- pain is inevitable, suffering is optional.
