Fedora 15 Changes Network Device Naming Scheme 132
dkd903 writes "Fedora developer Matt Domsch has announced that Fedora 15 is breaking the conventional ethX naming scheme used for Ethernet devices by adopting a new scheme called Consistent Network Device Naming. The ethX naming scheme works fine as long as the system has only one Ethernet port. However if there are more than one Ethernet ports, the actual problem starts."
Does this mean.... (Score:2)
Re: (Score:3, Informative)
You should use LLDP a protocol for discovering what iface is connected to what port on the switch. There is an lldpd available for pretty much all distros.
Re: (Score:2)
Yes, it's all changing, but that's not such a bad thing given the rationale. Yet even though I read TFA I still have two questions:
Re:Does this mean.... (Score:4, Interesting)
Debian (and its derivatives, including Ubuntu) have been taking a less disruptive approach to this for years now by assigning persistent ethN device names based on MAC addresses. For example, if the system has no device names assigned and sees 01:23:45:67:89:ab as the first Ethernet device's address, that becomes eth0 from that point forward. The next Ethernet device that gets enumerated is going to be eth1, and so forth. This means it handles the USB device case in the way most users would expect.
I suppose there is some advantage to using geographic addresses for people with lots of multi-NIC machines to build, and for people who need to hot-swap cards for reliability reasons. I suspect that Debian's udev-based approach could handle the latter either now or with minor tweaks, though.
Re: (Score:2)
And this
Re: (Score:2)
If they are independent ports with the same MAC address, either the hardware vendor or the device writer screwed up, because there's no sensible way to put them on the same Ethernet segment. (I assume you do not mean a hub on a card, with one port going to the host, which I have seen advertised in some places. If you don't think a big vendor can screw up that badly, let me tell you about the major Unix workstation vendor who delivered ~30 computers to the university I attended where every single workstati
Re: (Score:2)
As I said, Sun quad-port Ethernet cards often come with all four ports defaulting to the same MAC address. I believe they are typically used to create a high-bandwidth bonded connection to a single switch, so having four ports with the same address isn't a problem.
(In my case, I'm using the cards to *create* a switch, so having the same MAC address still isn't a network problem. It did take me a while to convince udev to give the ports stable interface names, though.)
Re: (Score:2)
The excitement of the "ifup/ifdown ethX" game with co-workers watching for the green light while mapping blade enclosures is no more? What a shame.
What kind of blade enclosure are you using where the mapping between blade ethernet ports and external ethernet ports is not hardwired and/or trivially viewable through the management interface ?
We did this years ago (Score:2)
At my last job we sold CentOS-based routers and fileservers. I'd rename the interfaces ethWAN and ethLAN in the /etc/sysconfig/network-scripts/ifcfg-eth* scripts. And then labeled the interfaces on the box for the installer. Worked pretty well, until we started messing with VLANs, and the init scripts choked on VLANs attached to renamed interfaces.
Debian's udev rules also tried it, but it didn't work out so well for systems that had a lot of changes - we've got machines in the field that are on /dev/eth8.
Re: (Score:2)
Ubuntu does a similar thing but it remembers the MAC address for network devices, using a new ethX reference for each new MAC address.
Not a big deal on a desktop or laptop, but if you use removable drives (like we do for the Linux class I teach) it can cause issues as students move from one workstation to another with their portable installs on usb drives.
Re: (Score:2)
Note that while the autogenerated persistent-net-rules identifies based on mac addresses you can customise the rules to match based on other stuff and afaict any custom rules will be left alone (only devices with no rule at all get an autogenerated rule).
So if you know the machines will only have one nic you can probablly write a rule that will match anything and have it work fine.
still a crappy solution (Score:2)
the proposed solution depends on the slot the board is in? These must have been Apple II guys who haven't come out of cave in the last 20 years.
Why don't they just use an alias for the MAC address on the cards, so that it is totally general?
Re: (Score:1)
I think this is already done in Linux. At least, if you clone your system to another machine with different MAC addresses, you will get new ethX identifiers. That is, if eth0 and eth1 was used on the original machine, when you clone the OS to another one, its device names will be eth2 and eth3.
I really do not understand what the article is talking about.
Re: (Score:2)
That's udev's configuration (done by your distro maintainers) and has nothing to do with anything else.
Re: (Score:1)
Udev is part of the Linux project, so it is very much to the point. The problem has already been solved by replacing devfs with udev, so it is a non issue.
Re: (Score:2)
Re: (Score:2)
Why don't they use an alias for the network they are on. That way the network keeps the same name if you move the cable. For Wireless this is easy (using essid), for wired you either need something based on the dhcp server or statically configured.
Re: (Score:1)
Instead of the dumb "eth0", mine would be "00:1E:90:47:69:93". it's fairly unique. it doesn't change on reboot. all of the ethernet cards on your network will have a unique address. problem solved. they should have asked me first.
Re: (Score:3)
Until your NIC dies and you replace it. But life is full of annoyances.
However, I don't see the need for this scheme. Calling them ethN where N is an index into a MAC cache is perfectly fine. if the NIC dies and you replace it, just edit the cache. No biggie. This Fedora15 scheme just adds complexity for little reason.
Re: (Score:1)
I still use fedora, but I hate all of the new "smart" daemons that figdet the network whenever a device gets plugged in. I mostly find they screw up they networking and just set it and forget it manually.
Re: (Score:2)
Because you often need specific configuration for hardware, not *just* the network. For instance, a wifi device may connect to the same network but requires an essid and encryption key. Further, two devices sometimes connect to the same network for performance reasons.
Mac address is the preferable identifier, in my opinion. "Slot" is a terrible identifier for desktops due to USB network devices, but is probably okay for servers (who uses USB networking on a server?). But Fedora is intended for use in bo
Re: (Score:2)
You could do both? Try comparing it with partition and harddisk labelling in linux. It can be done by silly inpredicable id's like network currently do, they can be set by hardware unique id's, reliable except when you replace broken hardware or by partition labels. I prefer labels, but it does depend on user interaction, fortunately one thing doesn't exclude the other. /dev/network/by-id/*
Re: (Score:2)
Well, considering Apple still had that eyesore of an OpenFirmware device tree in relatively recent machines, maybe they weren't in a cave, just a basement on the Apple campus.
On the bright side, this new proposal is so completely and utterly ugly, admins will finally start paying attention and name their ethernet devices approriately, instead of just running with the default.
False (Score:5, Interesting)
Wrong, udev handles this very fine. This is a complicated solution to a non-problem.
Re: (Score:1)
Indeed, my observations seem to indicate that the device name is assigned once when detected and it gets an increasing number. If you clone your system to another machine with other MAC addresses, there will be new device identifiers for the new cards since the old ones are bound to other MAC addresses.
Is the initial assignment random? I don't know, but I would assume that the built-in are assigned first and then any PCI cards. At least, this is what I have observed, also, I have never seen a built in wirel
Re:False (Score:5, Informative)
Actually, it doesn't. The interfaces can be named the same on reboot, but the initial numbering is semi-random.
The problem arises when you're trying to deploy a large number of machines, and you know which devices are where on the PCI buses (modern servers are coming with 4 Ethernet ports on the motherboard now). That way, you can assign VLANs and IPs to specific ports in a kickstart file and the installer doesn't have to play the "which interface is eth1" game. Which is not fun. We should not be relying on automagic configuration for something as basic as ethernet...
<rant>this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on</rant>
This doesn't get into crappy BIOSes that enumerate devices badly, or NICs that have a bad habit of initializing late.
Re: (Score:2, Insightful)
<rant>this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on</rant>
Take a look at /dev/disk. You should find what you're looking for there.
/dev/disk/by-id/ (Score:3, Interesting)
this is why I don't like the /dev/sd* interfaces in Linux - you have to dig deep into /proc to find out which port SATA and SAS devices are on
You might appreciate /dev/disk/by-id/:
$ ls -l /dev/disk/by-id/ ../../sdb ../../sda
total 0
lrwxrwxrwx 1 root root 9 Dec 24 10:58 ata-ST3500630AS_9QG32BJ5 ->
CLIPPED FOR LAMENESS FILTER
lrwxrwxrwx 1 root root 9 Dec 24 10:58 ata-ST3500641AS_3PM1BA52 ->
CLIPPED FOR LAMENESS FILTER
The /dev/disk tree can be super useful for, e.g. iSCSI device names in scripts.
Re: (Score:2)
I prefer /dev/disk/by-path
This way whatever disk I put in the eSATA is on my backup mountpoint, and the USB key in a specific USB port is logs.
Re: (Score:2)
/dev/disk/by-path/pci-0000:00:11.0-scsi-7:0:0:0-part1 /media/backup auto noauto,noatime,user 0 0 /dev/disk/by-path/pci-0000:02:00.0-usb-0:4:1.0-scsi-0:0:0:0-part1 /var/log ext4 noatime 0 0
Doesn't that break if you change motherboards or re-cable disk controllers?
Re: (Score:2)
Please don't use /dev/disk/by-id. SUSE uses this and it breaks virtualization.
You cannot change the underlying disks (eg. to do migration or V2V) without the guest becoming unbootable.
Use filesystem UUIDs instead. These survive all sorts of migrations and conversions intact, and are even useful in the non-virtual case -- eg. if you swap SATA disks around.
Rich.
Re: (Score:2)
You cannot change the underlying disks (eg. to do migration or V2V) without the guest becoming unbootable.
Why is the guest even aware of the parent's ID?
Use filesystem UUIDs instead. These survive all sorts of migrations and conversions intact, and are even useful in the non-virtual case -- eg. if you swap SATA disks around.
Hrm, I had trouble when I previously switched to all-UUID's as I found it's not possible to change the UUID of an md device, which breaks several schemes (or at least makes for a bit of
Re: (Score:2)
You can change the underlying disks - we do this for virt-v2v [fedorahosted.org].
Fixing /dev/disk stuff is just one of the things that makes conversions harder than they should be [wordpress.com].
RAID/md is not used much by virtual machines (it's done on the host instead) so I can't comment on what problem you had.
Rich.
Re: (Score:3)
The problem arises when you're trying to deploy a large number of machines, and you know which devices are where on the PCI buses (modern servers are coming with 4 Ethernet ports on the motherboard now).
Strange, I've never encountered this problem when deploying images on a batch of identical servers. I know that Debian has an issue when the MAC address of a NIC changes, so you'll have to edit a file (that I've got documented somewhere in an install procedure but for the love of god can't remember by heart), but I've never had the problem under RHEL so far. I've only run into the problem on debian after replacing NICs on a server, and when using virtual machines under Xen (which by now is ages ago).
Finally
Re:False (Score:5, Interesting)
Persistency: once eth0, always eth0 - this is what most commentators here seem to think this is all about, but it's already taken care of by udev with most modern distributions.
Enumeration: Lacking previous knowledge, the order in which interfaces are enumerated. I would think this would be deterministic, but you say it's random (what is "semi-random?"). I'll take your word for it. It seems this is the problem they're trying to address. MAC addresses are indeed useless for this, in a general case, since we may be trying to enumerate ports on plug in boards (e.g. there's no guarantee the MAC in slot 1 will be lower than the MAC in slot 2).
Naming: The article says they're changing the naming. This is what makes no sense. It's not "required." ethx is just fine, as long as the names are enumerated consistently (meaning that on two "identical" boxes, the order is identical based on physical port).
Re: (Score:1)
Usually by probing and or trail and error exploration, or you can order by PCI discovery, MAC address, or ARPing an interface to discover other servers or gateways MAC address so you can preferrentially order them.. but each situation is unique. After you have the information used to order, you "can" embed that in the UDEV rules so that the na
Re: (Score:2)
If you want predictable names from hardware, and you want to be able to add and remove devices the only solution would be to allocate enormous holes if you want to keep the current ethx naming scheme. i.e.
eth0 - eth999 on board
eth1000 + slot * 1000 + port for cards
etc
Re: (Score:2)
Persistency: once eth0, always eth0 - this is what most commentators here seem to think this is all about, but it's already taken care of by udev with most modern distributions.
To some extent. The persistency is taken care of by adding state to the system, that is, by storing the MAC's somewhere. That fails e.g. if you switch out a broken NIC, or if due to some hw failure you move the HD to another identical server.
Naming: The article says they're changing the naming. This is what makes no sense. It
Re: (Score:2)
but you say it's random (what is "semi-random?")
Afaict it's determined by the order in which the interfaces are first seen, that in turn depends on the order the drivers were loaded in which in turn depends on details like the kernel/udev versions. So two identical servers installed with identical installation media used in exactly the same way will most likely (but still not gauranteed) come up with the ports in the same order but use different versions or types installation media and/or slightly different
Re: (Score:2)
I would say it's more reasonable to expect to have to make config changes when replacing hardware (new NIC or MB, as you said), than to have to make changes when simply moving the same hardware within a system.
Re: (Score:2)
Re: (Score:2)
The issue of semi-random device names at deployment time is a good point. Maybe an extension to udev that allows you to pick the bus type/port to assign each name to?
Re: (Score:2)
To add to your rant... throw Fiber Channel into the mix, say 100 LUNs from two or three arrays with multipathing and a cluster of 2 or 3 systems.
Ugly. Very ugly.
Re: (Score:2)
For the same reasons the guy you replied to said - bad BIOSes as well as the fact the OS won't know which are "on-board" and which aren't since they're all hanging off the PCI or PCI-E bus.
Re: (Score:2)
Thankyou for pre-empting my question.
I know as much about linux device management as Ted Stevens knows about TCP/IP, and yet my first thought was 'doesn't udev already deal with this?'
Re: (Score:2)
Re: (Score:2)
Sometimes... (Score:3)
Usually udev handles this correctly. /etc/udev/rules.d/70-persistent-net.rules and rebooted, and then everything was renumbered, I went from there, and it has been stable since. Took me a while to figure
Recently I was swapping NIC cards in and out of my server, and after putting a card back in, only one of my 3 network cards was functioning. Fortunately there was a system message saying that udev was renaming eth1 to eth2 (I don't know why it was), and neither eth1 or eth2 was functioning. I blew away
Re: (Score:1)
NIC cards? Really?
Re: (Score:2)
Yes. NIC = Network Interface Controller. So what's the deal with calling them network interface controller cards?
Re: (Score:2)
I was thinking the same thing, I haven't seen any distro that assigns adapters arbitrarily. The only problem I've ever had with device naming is that Ubuntu totally loses any adapter configuration done with the GUI network managers if you add or remove an adapter.
Agree, but IME they should fix udev's net rules. (Score:1)
I run a cluster with eth0 and eth1 defined. If I swap out a network card on a machine, a new eth2 gets created, rendering that machine unreachable over the network. To fix this, I edit /etc/udev/rules.d/70-persistent-net.rules manually.
Udev doesn't seem intelligent enough to figure out how to do the substitution automatically.
Re: (Score:3)
Re: (Score:1)
My ubuntu server did this by default (I don't remember which 8.x was used for installing). I remember when I replaced my mini-itx with a laptop (HDD went inside laptop) to continue as my router and had to shuffle MACs (2nd ethernet was a USB bridge which was unchanged since it was present on both HWs).
Because udev just happens to other people? (Score:1)
I mean it's not like network cards have unique identifiers or anything... sigh.
Uniqueness of IDs not enough (bad info is bad) (Score:2)
You cannot meaningfully use the MAC addresses in a JumpStart kind of situation as you don't know at jump-start creation which adapter will be which in the MAC address sort order, particularly when you are using insert cards.
I use udev, but then I edit the persistent rules it generates to rename my interfaces "intX" and "extX" (internal and external interfaces) for making firewall rules and so on.
The problem is that there is no real "right answer" for naming devices berfore you identify them explicitly.
Oddly
Silly (Score:2)
There are a lot of device file naming conventions which could be adopted and would serve some useful purposes, but this isn't one. Hasn't the trend been *away* from trying to identify things by how they're plugged in toward identifying them for what they are?
Re: (Score:2)
The big difference here is that its very common to have multiple "identical" ethernet ports (all of our servers have had at least two GigEs on the motherboard for many years now), and real stuff is plugged into the otherwise identical ports based on physical location. More to the point, what's plugged in is generally unusable without further configuration (esp. in the server world) and one configuration will not work when swapped with the other. That's actually fairly uncommon with other devices - typical
Re: (Score:2)
Consistent naming is, indeed, beneficial, but there's no benefit from this change.
What you're after is making sure that logical configuration always maps back to the correct physical link. Since there's no way to assure this the next best bet is to make sure that it always maps back to the *same* physical link. It would also be good, I suggest, to name devices in a manner which aids human identification. Naming devices after what bus they're plugged in to solves neither of these well and the former not at a
What the h**k! (Score:2)
2. the MAC address for each ethernet is the thing that allows you to discern among all of them, 1, 2 or 65536!
3. Good move, Fedora. Then you can change also the
FINALLY this will be fixed. (Score:2)
As has been mentioned above - you can tell from your comments you are just a home user.
Try writing OS-level software (stuff that is imaged onto the device) that depends on the NIC in position 1 on the PCI bus always being the management interface (IE, the first port in the chassis). Remember this software has to know IN ADVANCE which port it is, you can't use the MAC for this at all.
This has been a problem in Linux for years and one that developers have always had to hack and slash around. I am glad RedHat
Re: (Score:3)
As has been mentioned above - you can tell from your comments you are just a home user.
Try writing OS-level software (stuff that is imaged onto the device) that depends on the NIC in position 1 on the PCI bus always being the management interface (IE, the first port in the chassis). Remember this software has to know IN ADVANCE which port it is, you can't use the MAC for this at all.
This has been a problem in Linux for years and one that developers have always had to hack and slash around. I am glad RedHat is finally fixing it. Hopefully other distributions will follow suit.
I don't understand what you're saying. If you wanted to do that, you could do it a since years with udev IN ADVANCE of your software you want to launch.
Since YEARS udev has put persistent device naming so that what is said in the article is wrong, because you will always get the same name for your devices.
Since years, I actually have my Ethernet interfaces which are not named eth0-X but sth else, which is based on any arbitrary value you want that is provided by udev, including PCI slot and what not.
So what
Re: (Score:2)
udev is nice once you have your devices up and running. Note however, that your parent is talking about install time, when udev still has to run its discovery.
I partly agree with GP, it would be nice to have a consistent way to select network interfaces in advance; I don't think giving up the eth<X> naming scheme is necessary for that.
Mart
Re: (Score:1)
What install time? If the distro supplies udev rules to map eth0 to the NIC in the lowest PCI slot, they will be available to udevd running during the installation. If your installation image lacks udevd, then throw it in there. All the other distributions does that..
If by "install time" you mean the milliseconds it takes for udev to notice the device and then rename it then, sure, you have a point, but what problems do you have that requires solving that?
The original article is here (Score:1)
http://webcache.googleusercontent.com/search?q=cache:mIvkJYLNHM0J:domsch.com/blog/%3Fp%3D455+matt+domsch+ethernet&cd=1&hl=en&ct=clnk&gl=uk [googleusercontent.com]
His blog seems be down with all the floods of people telling him to lay off the crack pipe.
Application compatibility? (Score:3)
Re: (Score:2)
What's this going to cause as far as applications, is it going to require every single app that talks to ethernet to have special functions for Fedora?
I've used arbitrary interface names for years and have yet to encounter an ethernet-related application that doesn't work with it.
Re: (Score:1)
Network devices aren't reliably named ethX already. If you assume that, you've got issues. We've got machines with strange network interfaces, and they come up with different names.
So, if you're going to try to figure out what interfaces to play with, you should ask the system what the network interfaces are. Don't try and glob /dev/.
So, ifconfig -a tells me I've got eth0, sit0, lo, vmnet1 and vmnet8 on my RHEL workstation. sit0 is down, the rest are all operating and valid. On an RHEL server, we've go
Re: (Score:2)
Not a good idea.... (Score:1)
Fedora Core already makes use of "udev" and it does a decent job. Then there are the "interface-specific" scripts in "network-scripts" that do a decent job of naming or renaming interfaces along with other stuff. The combined method of "udev" and "network-scripts" confused me when "udev" became "useful" since I was used to using those "network-scripts", but I learned how stuff works. Why can't this Redhat engineer just leave things alone?
As for this Redhat developer's claims that problems start when multipl
Re: (Score:3)
I agree partly with you.
It's true that consistent interface naming has just worked for years with multiple interfaces.
The author is talking about races but they are not explained in his paper and are marked as thinks since 2009.
What this basically boils down to is that now distributions can streamline the naming of your interfaces without you having to go test them the first time you install your OS to know which is which. You'll now know immediately from your OS.
This shouldn't upset anyone, except people t
Re: (Score:2)
Actually, Matt Domsch is from Dell ... not Redhat. So you can take the tinfoil-hat-of-conspiracy off (or put on another layer depending on your feelings towards Dell). This change is coming from an actual *need* from a certain segment of Linux users/admins. I suspect anyone who has had to deal with NIC failure/reconfiguration on a system with more than 2 cards will welcome this as it is trying to take advantage of newer BIOS technology to deterministically assign names to cards based on the actual physical
Re: (Score:2)
Hmm isn't that what udev is for? (Score:2)
Dunno it is really an issue. Seems to me Fedora are making work for themselves. In Debian they use a 70-persistent-net.rules file to tag interfaces with the same name each time they are detected. Works nicely especially when you have multiple interfaces and one that is removable.
Just another FTSTP really.
Re: (Score:2)
Once it's booted, yes. Getting this stuff running in an auto-build via kickstart and suchlike isn't quite as easy. You just want to cable up servers and make $interface "the one in the top left" and not have to wait for the kernel to randomly assign it on the first boot and use trial and error to find it.
bah.... (Score:1)
Comment removed (Score:4, Insightful)
Re:Article is a joke and false (Score:5, Informative)
With the existing system, if you wipe the disk and reinstall, will the interface names always be the same? It sounds like that is what they are trying to ensure. It could be helpful for frequently re-imaged machines and for diagnostics.
Re: (Score:2)
With the existing system, if you wipe the disk and reinstall, will the interface names always be the same? It sounds like that is what they are trying to ensure. It could be helpful for frequently re-imaged machines and for diagnostics.
No, they won't necessarily be the same. However, the problem I see with this is what happens when you move the PCI cards around on the bus to accommodate new hardware? What if you have a quad port card... now you have 4 ports that suddenly get renamed because you moved the ethernet card from slot 2 to slot 3 to make room for an additional RAID card. Ugh...
Assigning them via udev and MAC seems to be a much better solution than this one that solves one problem and creates another.
Re: (Score:2)
Whilst this solution does not particularly offer any more device consistency with what is already in Fedora, the idea here I believe is to make the ethernet configuration stateless in addition to consistent.
This is not the case at the moment, as the network scripts add udev rules binding ethX named devices against the MAC address of the underlying device itself (so Mac AA:BB:CC:DD:EE:FF is always ethX). This additionally offers no indication of which PCI device this is referring to, and on ethernet cards wi
Re: (Score:1)
Re: (Score:2)
It's the only one that does this, even the identical machine sitting beside it doesn't do this.
Nothing in Linux guarantees port numbers. Some things try, but none guarantee.
Re: (Score:2)
re multiple eth (Score:1)
good idea (Score:1)
Please no... (Score:3)
This 'solves' one problem but creates another.
Yes, sometimes in a multi-homed server, the ordering gets confusing. *however* if trying to write a script to operate on a range of heterogeneous systems, 'eth0', etc is more likely to work than 'em0','pci0',etc. Most places that do have confusing names compensate by one of the following:
-Using ethtool to see what driver manages it and deal with it that way (basically mimicking this design), but this has the same issues, which lead many places to do the second option.
-Detecting what subnet they are via DHCP and using that information to find the 'right' nic for something or other.
In multi-homed systems, the bios-dictated topology is usually less important than the IP topology.
Re: (Score:3)
I will also say that I would not mind: /dev/disks. /dev/sd is still there, but /dev/disks/ provide convenient schemes to find the 'right' sd in a complicated environment. If there were a simple utility that given 'ifnamefor em0' spews out 'eth0', that would be fine. You could *not* enumerate an interface multiple times in ifconfig/ip output, would have to be a separate utility.
-Something akin to
-As others mentioned, using bios information to dictate eth order. Consume the onboard nics 'in order', then th
Keep ethX, make it unambiguous (Score:1)
How about a compromise? Keep the ethX names, but use the proposed scheme to have an unambiguous order in which the names are assigned.
Re: (Score:2)
Or something like the /dev/disks/ hierarchy.
eth0, etc etc still as is, but a way to trivially enumerate the names they want to the 'eth' names.
Noooo Change is hard! (Score:1)
I prefer having greater clarity and visibility into which dev is which specific piece of hardware.
The new convention is pretty straight forward and consistent. I like consistent.
Re: (Score:1)
Re: (Score:1)
Fedora isn't going to change it for everyone. [2] (Score:1)
The feature[1] is only for some servers (HP, DELL), so that the device name would match the label on the port. THERE IS NO NEED TO PANIC.
also, it won't change your settings, it will only change on new installations.
[1] https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
[2] https://fedoraproject.org/wiki/FeatureList - " On Dell and HP servers with multiple network ports on the motherboard, name them lomX rather than ethX. "
Re: (Score:2)
THERE IS NO NEED TO PANIC.
You're new to Slashdot, aren't you?
Is reading the manual too hard? (Score:1)
I am a noob at this stuff, but even I can find on Wikipedia the following:
udev supports persistent device naming, which does not depend on, for example, the order in which the devices are plugged into the system. The default udev setup provides persistent names for storage devices. Any hard disk is recognized by its unique filesystem id, the name of the disk and the physical location on the hardware it is connected to.
udev rules can match on properties like the kernel subsystem, the kernel device name, the
Re: (Score:1)
There is a way.. it has been solved before.. 2005 (Score:1)
About time something is done (Score:1)
The details are in the redhat bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=491432 [redhat.com]
I use the fix where you tell udev to ignore ethernet cards and let the normal modprobe.conf load t
/dev files (Score:2)
Re: (Score:2)
Exactly what compatibility is broken?
If you are relying on all of your Ethernet devices to be named ethX instead of using the output of ifconfig or looking in sys/class/net, you are doing something wrong.
In fact, the system I am looking at now has four interfaces that are not named ethX. bond0, dummy0, sit0, and lo. Every piece of software I use that works with Ethernet devices seems to have no problem with this.