7:58 a.m.
Hello, know someone how work in F18 network interface naming? Or when
is there any docs for this?
In this my case, I want MAC-based interfaces naming.
I found these two documents:
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfac...
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
but it seems as first isn't too detailed and say about F19, and if
I did (according to second) udev rules, then nothing happens, as if
they aren't there. My rules:
$ cat /etc/udev/rules.d/70-moje-net.rules
# Bus 01:00.0 - PCI device 0x1969:0x1048 Atheros Attansic L1; atl1:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1e:8c:93:b5:8d", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# External PCI device 0x8086:0x10d3 Intel CT Desktop Adapter w. 82574L; e1000e:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1b:21:69:5f:74", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# External PCI device 0x1186:0x1300 D-Link System Inc DFE-528TX w. RTL8139; 8139too
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1b:11:63:96:35", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
These rules works in F17 and earlier versions.
8:33 p.m.
Marko Vojinovic writes:
On Mon, 25 Feb 2013 22:51:15 +0100
poma <pomidorabelisima(a)gmail.com> wrote:
> On 02/25/13 21:01, Reindl Harald wrote:
> […]
> > so switch to anything else as ethX in your naming in
> > /etc/udev/rules.d/70-persistent-net.rules
> > like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
> >
> > so you would not have race-conditions in kernel/udev naming the
> > interfaces
Just a small comment --- I believe everyone following this thread is
aware that these race conditions are the very reason for the
introduction of biosdevname in the first place.
In order to avoid race conditions, one can either use biosdevname and
have eth* be replaced by different names like em* and p*p*, or one can
disable biosdevname, configure udev manually, and have have eth* be
replaced by names like lan* and wan*.
The actual difference between the two methods is about system
maintenance --- when your network card burns out (these things happen,
unfortunately), biosdevname allows you to plug a new card into the same
pci slot and just turn the machine back on, with no extra
configuration. If you are configuring udev manually, and tie nic names
to MAC addresses, you are required to reconfigure udev for
the new MAC address of the new card.
The pain is greater in the latter case, while I see no gain at all,
compared to the way of biosdevname.
Maybe the OP can enlighten me *why* does he need MAC-oriented naming
scheme so badly? Just curious... :-)
This is how the network devices were configured originally, by whatever
component was used to install whatever Fedora release was initially
installed on this machine. I don't remember which one it was, but that
must've been how ifcfg-* was set up some time ago, by whatever version of
Anaconda was in effect at that time.
I don't see the big hassle with binding network interfaces by MAC addresses.
It's not like I replace NIC cards every week.
Plus, the MAC binding came in handy when the kernel switcherooed them on me.
It's a much more spectacular failure mode. It's better to have not anything
come up at all, then have all the firewall rules wrong.
P.S. There's something magical about ethX. Even after I moved eth1 to wan0,
there was one boot where eth0 came up as eth1, even though nothing came up
at eth0, and the other NIC came up normally as wan0, so I ended up with wan0
and eth1.
But after moving both of them to lan0 and wan0 things seemed to be settled
down…
8:15 p.m.
On Tue, 26 Feb 2013 03:10:59 +0100
Marko Vojinovic wrote:
The actual difference between the two methods is about system
maintenance
Yea, and when you update your system with a new and improved
biosdevname, you can find nothing working because the
"immutable" names have changed:
http://home.comcast.net/~tomhorsley/game/biosdevname.html
Loads of fun for everyone!
1:15 p.m.
Am 25.02.2013 19:37, schrieb Frantisek Hanzlik:
Rahul Sundaram wrote:
> Hi
>
>
> On Mon, Feb 25, 2013 at 1:09 PM, Frantisek Hanzlik <franta(a)hanzlici.cz
> <mailto:franta@hanzlici.cz>> wrote:
>
>
> 'biosdevname' I have not installed, I have systemd v197 and
> according to previously mentioned:
>
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
>
> custom rules in /etc/udev/rules.d/ should works - but not in F18!?
>
>
> Yes because these changes were considered too intrusive to push in an update.
> Refer to
>
> https://admin.fedoraproject.org/updates/FEDORA-2013-0655/systemd-197-1.fc...
>
> So for Fedora 18, biosdevname manages the devices by default. biosdevname
> will probably be superseded by the systemd/udev update in Fedora 19
>
> Rahul
Hm, thanks for reference. But how I get MAC-based naming now (how it was
working in F17 and before)?
as all the years before
[root@srv-rhsoft:~]$ cat /etc/udev/rules.d/70-persistent-net.rules
# srv-rhsoft
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="24:be:05:1a:c0:27", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="68:05:ca:0d:62:c1", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="28:10:7b:ca:be:51", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
# workstation
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="78:ac:c0:b1:76:e4", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1b:21:b6:5f:28", ATTR{dev_id}=="0x0",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
[root@srv-rhsoft:~]$
7:49 p.m.
On 02/26/13 01:50, Frantisek Hanzlik wrote:
poma wrote:
> If Fedora kicking your ass, kick it back! ;)
I think I must. Although I'm no debater and my English skills
are bad, I must heard and say what I thing - that present Fedora
development is bad.
Truth is in the eye of the beholder.
Sure.
Fran, cheers!
poma
10:35 p.m.
Sam Varshavchik wrote:
Frantisek Hanzlik writes:
> Marko Vojinovic wrote:
> > Maybe the OP can enlighten me *why* does he need MAC-oriented naming
> > scheme so badly? Just curious... :-)
>
> Why badly?
> ethX are native kernel device, all Linux users ever know them, until
> now was not problem with using them. Why should be it problem now?
Because an occasional boot now comes up with eth1 being eth0, and eth0 being
eth1. And on the next boot, everything would be back to normal.
Yes, in contrast with old times where all works we are living now
much better and joyfully ;)
But - end of gags and compliments: Just released systemd-197-1.fc18.2
solve this problem, /etc/udev/rules.d/*net* rules works again.
Thanks to developers :)
3:33 a.m.
On Mon, 25 Feb 2013 22:43:09 -0500
Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Marko Vojinovic writes:
> On Mon, 25 Feb 2013 21:33:04 -0500
> Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
> > Marko Vojinovic writes:
> Also, have you ever built a cluster? Typically, you install and
> configure everything on one system, and then push the harddrive
> image to all other (headless) nodes. Once the whole thing boots,
> you find out that all config files for all NICs are wrong (since
> MAC addresses will be different), and you have no network access to
> any of the nodes... On a 100-node cluster this can be a very big
> pain.
In that kind of a situaton you're not going to have those nodes
multihomed. They'll typically have one LAN port, and that's about it,
so you don't care about MAC addresses.
The performance of a cluster made of single-NIC nodes connected to a
switch is limited by the speed of the switch, which is a Bad Idea.
Rather, nodes on a cluster usually have at least 4 NICs, though this
varies greatly with the intended purpose of the cluster. Typically, the
first NIC is connected to the switch, the second and third are
crossovers directly to the left and right nearest-neighbor nodes, and
fourth is used as a backup. Depending on the purpose of the cluster,
the connection topology may even be far more complicated.
Now imagine the kernel which randomly assigns eth* names to those four
ports at boot, differently for every single node. It's a very big mess
to fix, and a big headache to maintain.
This is more important when you're building a router with a LAN
and a
WAN port. I can see a situation like this when you're provisioning a
bunch of nodes in a web farm.
But I could probably think up of a scripted approach to hack up an
image that gets pushed to all the nodes, then have them on their
first boot figure out their NICs and their MAC addresses, and fix up
the ifcfg* rules and udev rules to bind them the way I have it set up
on my piddly router.
Yes, that's exactly what was being done prior to biosdevname --- a
script would be launched on every node of the cluster, to "align its
virtual position", i.e. figure out how the node is connected to the
rest of the system. But this is more complicated than you might think
--- the hardware technicians would connect the node such that the
leftmost NIC port goes to the left node, the rightmost goes to the
right one, and the "middle" nodes go to the primary and backup
switches. Once your script reads off the eth*-to-MAC relationship, how
does it figure out which MAC is connected to the left neighbor, and
which to the right one? This requires sending test signals back and
forth among nodes, and your script gets very ugly, very fast. Especially
in circular topologies, where the leftmost node is on the right of the
rightmost one.
Besides, these solutions just don't scale well. Even if the script
gets it right initially, what happens when a node dies and gets
replaced by a backup? Run the script again for the whole cluster? No
way, other nodes may be live and doing something. Or when new nodes are
attached to the cluster? Or when your problem changes and you need to
rewire the virtual geometry?
I agree that solutions to these problems exist and can be
implemented, but just compare all that to the biosdevname situation,
where you just need to plug all nodes physically correctly --- something
which was typically already done by the technicians --- and be done
with it.
Best, :-)
Marko
11:50 a.m.
Am 27.02.2013 18:20, schrieb Bill Davidsen:
A good implementation would allow naming by slot, or MAC, or just a
default like calling the first one eth0 and the
next eth1. It would be done in one and only one place and use a human readable text file
for config. We don't seem
to have that, and the default of an unpredictable name in all cases justs adds one more
thing to be overcome.
thank you
it would be glad if siftware-developers these days would have
your knowledge and understanding how the real world works
11:29 a.m.
Marko Vojinovic wrote:
On Mon, 25 Feb 2013 21:33:04 -0500
Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
> Marko Vojinovic writes:
>
>> Maybe the OP can enlighten me *why* does he need MAC-oriented naming
>> scheme so badly? Just curious... :-)
>
> This is how the network devices were configured originally, by
> whatever component was used to install whatever Fedora release was
> initially installed on this machine. I don't remember which one it
> was, but that must've been how ifcfg-* was set up some time ago, by
> whatever version of Anaconda was in effect at that time.
>
> I don't see the big hassle with binding network interfaces by MAC
> addresses. It's not like I replace NIC cards every week.
Not necessarily the NIC itself. But moving the hard drive from a dead
box to a new box will have the same effect. This is done more often,
I guess.
Also, have you ever built a cluster? Typically, you install and
configure everything on one system, and then push the harddrive image
to all other (headless) nodes. Once the whole thing boots, you find out
that all config files for all NICs are wrong (since MAC addresses will
be different), and you have no network access to any of the nodes...
On a 100-node cluster this can be a very big pain.
You make the point for me that name by slot or "call the first one eth0"
also
have uses.
Though I admit that building a three-digit-node cluster is not an
"every
week" thing either. :-)
Building a cluster is not a common exercise, although adding or replacing nodes
might be in some cases.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
11:20 a.m.
Marko Vojinovic wrote:
On Mon, 25 Feb 2013 21:15:40 -0500
Tom Horsley <horsley1953(a)gmail.com> wrote:
> On Tue, 26 Feb 2013 03:10:59 +0100
> Marko Vojinovic wrote:
>
>> The actual difference between the two methods is about system
>> maintenance
>
> Yea, and when you update your system with a new and improved
> biosdevname, you can find nothing working because the
> "immutable" names have changed:
>
> http://home.comcast.net/~tomhorsley/game/biosdevname.html
>
> Loads of fun for everyone!
Well, everything has bugs. And you saw how badly motherboard bioses can
be written, it is not easy to write something like biosdevname and have
it working perfectly for everyone in its very first version. Btw, I am
not trying to play an advocate for biosdevname here, but rather just
trying to understand why the OP needs MAC-based naming so badly.
The problem here is that the whole naming implementation is based on the
assumption that people want to name slots. That might be true if you have a
single server, but in a data center with hundreds of rack mounted servers, it's
not. When a server goes bad it is replaced with the current model for that load,
which generally changes every 12-24 months as new models come out. So a
replacement with different biosnames is the norm, and putting labels on the back
of the NIC next to the port is the norm. DASD is external, so that just plugs
in, but anything based on slot names is going to be wrong.
In addition to assuming that slots will not change, the assumption is made that
all NICs are the same, and that any NIC plugged into a slot will do. Alas,
that's not the case in a large data center, a mix of single and dual NIC cards
is common, and some fiber is possible, perhaps for NAS. biosname introduces the
requirement that every NIC must go in the right slot, one more labeling thing to
do and possibly go wrong.
A good implementation would allow naming by slot, or MAC, or just a default like
calling the first one eth0 and the next eth1. It would be done in one and only
one place and use a human readable text file for config. We don't seem to have
that, and the default of an unpredictable name in all cases justs adds one more
thing to be overcome.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
11:03 a.m.
Tom Horsley wrote:
On Tue, 26 Feb 2013 03:10:59 +0100
Marko Vojinovic wrote:
> The actual difference between the two methods is about system
> maintenance
Yea, and when you update your system with a new and improved
biosdevname, you can find nothing working because the
"immutable" names have changed:
http://home.comcast.net/~tomhorsley/game/biosdevname.html
I think the bugzilla status might be WONTFIX rather than NOTABUG. Or perhaps
CANTFIX no matter no many time it gets broken in another way.
Loads of fun for everyone!
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
3:03 a.m.
On 02/26/13 03:10, Marko Vojinovic wrote:
On Mon, 25 Feb 2013 22:51:15 +0100
poma <pomidorabelisima(a)gmail.com> wrote:
> On 02/25/13 21:01, Reindl Harald wrote:
> […]
>> so switch to anything else as ethX in your naming in
>> /etc/udev/rules.d/70-persistent-net.rules
>> like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
>>
>> so you would not have race-conditions in kernel/udev naming the
>> interfaces
Just a small comment --- I believe everyone following this thread is
aware that these race conditions are the very reason for the
introduction of biosdevname in the first place.
In order to avoid race conditions, one can either use biosdevname and
have eth* be replaced by different names like em* and p*p*, or one can
disable biosdevname, configure udev manually, and have have eth* be
replaced by names like lan* and wan*.
The actual difference between the two methods is about system
maintenance --- when your network card burns out (these things happen,
unfortunately), biosdevname allows you to plug a new card into the same
pci slot and just turn the machine back on, with no extra
configuration. If you are configuring udev manually, and tie nic names
to MAC addresses, you are required to reconfigure udev for
the new MAC address of the new card.
The pain is greater in the latter case, while I see no gain at all,
compared to the way of biosdevname.
Maybe the OP can enlighten me *why* does he need MAC-oriented naming
scheme so badly? Just curious... :-)
Replaying to me, quoting Reindl, asking Fran.
Enlighten you, no one can.
Cheers,
poma
3:02 a.m.
Am 26.02.2013 03:10, schrieb Marko Vojinovic:
The actual difference between the two methods is about system
maintenance --- when your network card burns out (these things happen,
unfortunately), biosdevname allows you to plug a new card into the same
pci slot and just turn the machine back on, with no extra
configuration. If you are configuring udev manually, and tie nic names
to MAC addresses, you are required to reconfigure udev for
the new MAC address of the new card.
The pain is greater in the latter case, while I see no gain at all,
compared to the way of biosdevname.
Maybe the OP can enlighten me *why* does he need MAC-oriented naming
scheme so badly? Just curious... :-)
well, do a restore-probe of a virtual machine backup
usually it get assigend a new MAC and you do not want
get it up ith a IP-collission before you changed
ifcfg-ethX
10:23 p.m.
Hi
On Mon, Feb 25, 2013 at 10:43 PM, Sam Varshavchik <mrsam(a)courier-mta.com>wrote:
Marko Vojinovic writes:
> Not necessarily the NIC itself. But moving the hard drive from a dead
> box to a new box will have the same effect. This is done more often,
> I guess.
>
Maybe, but still not often enough to worry about.
There are many such issues. Dell designed biosdevname to solve actual
issues that customers ran into with Dell systems that they pre-bundle Linux
with. You may not run into such issues with your laptop but people who
manage multiple boxes certain were dealing some of the hassles
Rahul
10:02 p.m.
Frantisek Hanzlik writes:
Marko Vojinovic wrote:
> Maybe the OP can enlighten me *why* does he need MAC-oriented
naming
> scheme so badly? Just curious... :-)
Why badly?
ethX are native kernel device, all Linux users ever know them, until
now was not problem with using them. Why should be it problem now?
Because an occasional boot now comes up with eth1 being eth0, and eth0 being
eth1. And on the next boot, everything would be back to normal.
9:54 p.m.
Marko Vojinovic wrote:
On Mon, 25 Feb 2013 22:51:15 +0100
poma <pomidorabelisima(a)gmail.com> wrote:
> On 02/25/13 21:01, Reindl Harald wrote:
> […]
>> so switch to anything else as ethX in your naming in
>> /etc/udev/rules.d/70-persistent-net.rules
>> like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
>>
>> so you would not have race-conditions in kernel/udev naming the
>> interfaces
Just a small comment --- I believe everyone following this thread is
aware that these race conditions are the very reason for the
introduction of biosdevname in the first place.
"race conditions" on few static NICs?
"race conditions" which udev could serve well?
It sounds weird...
In order to avoid race conditions, one can either use biosdevname
and
have eth* be replaced by different names like em* and p*p*, or one can
disable biosdevname, configure udev manually, and have have eth* be
replaced by names like lan* and wan*.
The actual difference between the two methods is about system
maintenance --- when your network card burns out (these things happen,
unfortunately), biosdevname allows you to plug a new card into the same
pci slot and just turn the machine back on, with no extra
configuration. If you are configuring udev manually, and tie nic names
to MAC addresses, you are required to reconfigure udev for
the new MAC address of the new card.
The pain is greater in the latter case, while I see no gain at all,
compared to the way of biosdevname.
During approx. last ten years I had only two bad network adapters
(as their single fault, I not consider situations when blow out whole
box). Then I have no problem with this.
Maybe the OP can enlighten me *why* does he need MAC-oriented naming
scheme so badly? Just curious... :-)
Why badly?
ethX are native kernel device, all Linux users ever know them, until
now was not problem with using them. Why should be it problem now?
And regards MAC-based naming: as before, until now has never been
problem with, why now?
And why is MAC based naming important for me? E.g:
- I often rebuild our Linux boxes and want right working with NICs in
other bus positions or even other mainboards.
- my boxes works not in vacuum but in normal or dusty environment
and must be periodically cleaned. And I want right function even
when I pull up NICs and then insert them in other order. I had
simply ethernet cable and relevant NIC marked (WAN2, DMZ, LAN3,..)
and want when I put cable to equally marked NIC right work.
Best, :-)
Marko
9:43 p.m.
Marko Vojinovic writes:
On Mon, 25 Feb 2013 21:33:04 -0500
Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
> Marko Vojinovic writes:
>
> > Maybe the OP can enlighten me *why* does he need MAC-oriented naming
> > scheme so badly? Just curious... :-)
>
> This is how the network devices were configured originally, by
> whatever component was used to install whatever Fedora release was
> initially installed on this machine. I don't remember which one it
> was, but that must've been how ifcfg-* was set up some time ago, by
> whatever version of Anaconda was in effect at that time.
>
> I don't see the big hassle with binding network interfaces by MAC
> addresses. It's not like I replace NIC cards every week.
Not necessarily the NIC itself. But moving the hard drive from a dead
box to a new box will have the same effect. This is done more often,
I guess.
Maybe, but still not often enough to worry about.
Also, have you ever built a cluster? Typically, you install and
configure everything on one system, and then push the harddrive image
to all other (headless) nodes. Once the whole thing boots, you find out
that all config files for all NICs are wrong (since MAC addresses will
be different), and you have no network access to any of the nodes...
On a 100-node cluster this can be a very big pain.
Though I admit that building a three-digit-node cluster is not an "every
week" thing either. :-)
In that kind of a situaton you're not going to have those nodes multihomed.
They'll typically have one LAN port, and that's about it, so you don't care
about MAC addresses.
This is more important when you're building a router with a LAN and a WAN
port. I can see a situation like this when you're provisioning a bunch of
nodes in a web farm.
But I could probably think up of a scripted approach to hack up an image
that gets pushed to all the nodes, then have them on their first boot figure
out their NICs and their MAC addresses, and fix up the ifcfg* rules and udev
rules to bind them the way I have it set up on my piddly router.
9:32 p.m.
On Mon, 25 Feb 2013 21:33:04 -0500
Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
Marko Vojinovic writes:
> Maybe the OP can enlighten me *why* does he need MAC-oriented naming
> scheme so badly? Just curious... :-)
This is how the network devices were configured originally, by
whatever component was used to install whatever Fedora release was
initially installed on this machine. I don't remember which one it
was, but that must've been how ifcfg-* was set up some time ago, by
whatever version of Anaconda was in effect at that time.
I don't see the big hassle with binding network interfaces by MAC
addresses. It's not like I replace NIC cards every week.
Not necessarily the NIC itself. But moving the hard drive from a dead
box to a new box will have the same effect. This is done more often,
I guess.
Also, have you ever built a cluster? Typically, you install and
configure everything on one system, and then push the harddrive image
to all other (headless) nodes. Once the whole thing boots, you find out
that all config files for all NICs are wrong (since MAC addresses will
be different), and you have no network access to any of the nodes...
On a 100-node cluster this can be a very big pain.
Though I admit that building a three-digit-node cluster is not an "every
week" thing either. :-)
Best, :-)
Marko
9:12 p.m.
On Mon, 25 Feb 2013 21:15:40 -0500
Tom Horsley <horsley1953(a)gmail.com> wrote:
On Tue, 26 Feb 2013 03:10:59 +0100
Marko Vojinovic wrote:
> The actual difference between the two methods is about system
> maintenance
Yea, and when you update your system with a new and improved
biosdevname, you can find nothing working because the
"immutable" names have changed:
http://home.comcast.net/~tomhorsley/game/biosdevname.html
Loads of fun for everyone!
Well, everything has bugs. And you saw how badly motherboard bioses can
be written, it is not easy to write something like biosdevname and have
it working perfectly for everyone in its very first version. Btw, I am
not trying to play an advocate for biosdevname here, but rather just
trying to understand why the OP needs MAC-based naming so badly.
As a side note... A distinction should always be made between design
choices and bug fixing. Introduction of biosdevname is a design choice,
because it has introduced some new functionality (previously
unavailable). This is not the same thing as fixing a bug of some
existing stuff. So the old mantra "if it ain't broke, don't fix
it" does not apply in this case. Similarly for other "new and shiny"
stuff, like systemd, grub2, kernel modesetting, ext4 (a while back),
etc. They are all different design choices, which aim to improve
functionality of the system. Linux is an evolving piece of software,
like it or not. ;-)
Best, :-)
Marko
8:10 p.m.
On Mon, 25 Feb 2013 22:51:15 +0100
poma <pomidorabelisima(a)gmail.com> wrote:
On 02/25/13 21:01, Reindl Harald wrote:
[…]
> so switch to anything else as ethX in your naming in
> /etc/udev/rules.d/70-persistent-net.rules
> like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
>
> so you would not have race-conditions in kernel/udev naming the
> interfaces
Just a small comment --- I believe everyone following this thread is
aware that these race conditions are the very reason for the
introduction of biosdevname in the first place.
In order to avoid race conditions, one can either use biosdevname and
have eth* be replaced by different names like em* and p*p*, or one can
disable biosdevname, configure udev manually, and have have eth* be
replaced by names like lan* and wan*.
The actual difference between the two methods is about system
maintenance --- when your network card burns out (these things happen,
unfortunately), biosdevname allows you to plug a new card into the same
pci slot and just turn the machine back on, with no extra
configuration. If you are configuring udev manually, and tie nic names
to MAC addresses, you are required to reconfigure udev for
the new MAC address of the new card.
The pain is greater in the latter case, while I see no gain at all,
compared to the way of biosdevname.
Maybe the OP can enlighten me *why* does he need MAC-oriented naming
scheme so badly? Just curious... :-)
Best, :-)
Marko
6 p.m.
poma wrote:
On 02/25/13 21:01, Reindl Harald wrote:
[…]
> so switch to anything else as ethX in your naming in
> /etc/udev/rules.d/70-persistent-net.rules
> like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
>
> so you would not have race-conditions in kernel/udev naming the interfaces
>
mv /etc/udev/rules.d/70-persistent-net.rules(70-moje-net.rules)
/etc/udev/rules.d/70-persistent-net.rules.bkp(70-moje-net.rules.bkp)
/boot/grub2/grub.cfg:
linux /vmlinuz-… ifname=eth0-atl1:00:1e:8c:93:b5:8d
ifname=eth1-e1000e:00:1b:21:69:5f:74 ifname=eth2-8139too:00:1b:11:63:96:35
/etc/default/grub:
GRUB_CMDLINE_LINUX="… ifname=eth0-atl1:00:1e:8c:93:b5:8d
ifname=eth1-e1000e:00:1b:21:69:5f:74 ifname=eth2-8139too:00:1b:11:63:96:35"
dmesg | grep rename ;)
man dracut.cmdline
Cheers,
poma
Thanks and yes, it is documented and will work. But why has kernel did
that what udev did well before and systemd shit not know now?
And whereas Fedora docs say that should be working by udev rules?
6:31 p.m.
On 02/26/13 01:00, Frantisek Hanzlik wrote:
poma wrote:
> On 02/25/13 21:01, Reindl Harald wrote:
> […]
>> so switch to anything else as ethX in your naming in
>> /etc/udev/rules.d/70-persistent-net.rules
>> like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
>>
>> so you would not have race-conditions in kernel/udev naming the interfaces
>>
>
> mv /etc/udev/rules.d/70-persistent-net.rules(70-moje-net.rules)
> /etc/udev/rules.d/70-persistent-net.rules.bkp(70-moje-net.rules.bkp)
>
> /boot/grub2/grub.cfg:
> linux /vmlinuz-… ifname=eth0-atl1:00:1e:8c:93:b5:8d
> ifname=eth1-e1000e:00:1b:21:69:5f:74 ifname=eth2-8139too:00:1b:11:63:96:35
>
> /etc/default/grub:
> GRUB_CMDLINE_LINUX="… ifname=eth0-atl1:00:1e:8c:93:b5:8d
> ifname=eth1-e1000e:00:1b:21:69:5f:74 ifname=eth2-8139too:00:1b:11:63:96:35"
>
> dmesg | grep rename ;)
>
> man dracut.cmdline
>
>
> Cheers,
> poma
Thanks and yes, it is documented and will work. But why has kernel did
that what udev did well before and systemd shit not know now?
And whereas Fedora docs say that should be working by udev rules?
Before has passed, even now.
Don't expect everything to be served up on a plate.
It's *open* source, so read it, grep manuals, follow the appropriate
mailing lists, stay tuned…
If Fedora kicking your ass, kick it back! ;)
Cheers,
poma
3:51 p.m.
On 02/25/13 21:01, Reindl Harald wrote:
[…]
so switch to anything else as ethX in your naming in
/etc/udev/rules.d/70-persistent-net.rules
like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
so you would not have race-conditions in kernel/udev naming the interfaces
mv /etc/udev/rules.d/70-persistent-net.rules(70-moje-net.rules)
/etc/udev/rules.d/70-persistent-net.rules.bkp(70-moje-net.rules.bkp)
/boot/grub2/grub.cfg:
linux /vmlinuz-… ifname=eth0-atl1:00:1e:8c:93:b5:8d
ifname=eth1-e1000e:00:1b:21:69:5f:74 ifname=eth2-8139too:00:1b:11:63:96:35
/etc/default/grub:
GRUB_CMDLINE_LINUX="… ifname=eth0-atl1:00:1e:8c:93:b5:8d
ifname=eth1-e1000e:00:1b:21:69:5f:74 ifname=eth2-8139too:00:1b:11:63:96:35"
dmesg | grep rename ;)
man dracut.cmdline
Cheers,
poma
2:01 p.m.
Am 25.02.2013 20:52, schrieb Frantisek Hanzlik:
You perhaps think HWADDR - yes, I have it there, but without it
I probably will not have above error, but it hasn't nothing with
desired naming order - I will have still bad ethN associeted with
given interface.
yes, but have it on two places where each of them would
let to not work if it does not match is bad
(as years before, as You wrote, but it seems isn't working now)
And when I set 'udev_log="debug"' in my /etc/udev/udev.conf, then
I will get a lot libudev infos in /var/log/message - but there is no one line
about ethX.
so switch to anything else as ethX in your naming in
/etc/udev/rules.d/70-persistent-net.rules
like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
so you would not have race-conditions in kernel/udev naming the interfaces
1:52 p.m.
Reindl Harald wrote:
Am 25.02.2013 19:09, schrieb Frantisek Hanzlik:
> What I have are classic interface names ethNN, only with unwanted
> order, my rules simply not works, thus when later network start,
> I have typical message:
> /etc/sysconfig/network-scripts/ifup-eth: Device eth2 has unexpected MAC address.
Ignored
>
> Some idea?
remove the line with the MACADDR in ifcfg-ethX files
nobody needs them there
You perhaps think HWADDR - yes, I have it there, but without it
I probably will not have above error, but it hasn't nothing with
desired naming order - I will have still bad ethN associeted with
given interface.
And as you wrote in second mail, I have on my F18 box udev rules:
$ cat /etc/udev/rules.d/70-moje-net.rules
# Bus 01:00.0 - PCI device 0x1969:0x1048 Atheros Attansic L1; atl1:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1e:8c:93:b5:8d", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"
# External PCI device 0x8086:0x10d3 Intel CT Desktop Adapter w. 82574L; e1000e:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1b:21:69:5f:74", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth1"
# External PCI device 0x1186:0x1300 D-Link System Inc DFE-528TX w. RTL8139; 8139too
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:1b:11:63:96:35", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth2"
(as years before, as You wrote, but it seems isn't working now)
And when I set 'udev_log="debug"' in my /etc/udev/udev.conf, then
I will get a lot libudev infos in /var/log/message - but there is no one line
about ethX.
1:14 p.m.
Am 25.02.2013 19:09, schrieb Frantisek Hanzlik:
What I have are classic interface names ethNN, only with unwanted
order, my rules simply not works, thus when later network start,
I have typical message:
/etc/sysconfig/network-scripts/ifup-eth: Device eth2 has unexpected MAC address. Ignored
Some idea?
remove the line with the MACADDR in ifcfg-ethX files
nobody needs them there
12:37 p.m.
Rahul Sundaram wrote:
Hi
On Mon, Feb 25, 2013 at 1:09 PM, Frantisek Hanzlik <franta(a)hanzlici.cz
<mailto:franta@hanzlici.cz>> wrote:
'biosdevname' I have not installed, I have systemd v197 and
according to previously mentioned:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
custom rules in /etc/udev/rules.d/ should works - but not in F18!?
Yes because these changes were considered too intrusive to push in an update.
Refer to
https://admin.fedoraproject.org/updates/FEDORA-2013-0655/systemd-197-1.fc...
So for Fedora 18, biosdevname manages the devices by default. biosdevname
will probably be superseded by the systemd/udev update in Fedora 19
Rahul
Hm, thanks for reference. But how I get MAC-based naming now (how it was
working in F17 and before)?
12:56 p.m.
Hi
On Mon, Feb 25, 2013 at 1:49 PM, Frantisek Hanzlik <franta(a)hanzlici.cz>wrote:
For now I manualy rename interfaces via /usr/sbin/ifrename (from
wireless-tools package), but I hope it is possible did it in some
native way.
Well, the previous releases included
/etc/udev/rules.d/70-persistent-net.rules which isn't there anymore but the
syntax is documented at
https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
You can create such custom rules yourself
Rahul
12:49 p.m.
Rahul Sundaram wrote:
Hi
On Mon, Feb 25, 2013 at 1:37 PM, Frantisek Hanzlik wrote:
Hm, thanks for reference. But how I get MAC-based naming now (how it was
working in F17 and before)?
yum remove biosdevname and reboot or disable it via boot option, biosdevname=0
Rahul
Rahul I not have biosdevname installed. After start I get ethNN
interfaces, but in random order - and now I need find how made it
MAC-based.
For now I manualy rename interfaces via /usr/sbin/ifrename (from
wireless-tools package), but I hope it is possible did it in some
native way.
12:43 p.m.
Tom Horsley wrote:
On Mon, 25 Feb 2013 19:09:28 +0100
Frantisek Hanzlik wrote:
> Some idea?
Well, I see the file /lib/udev/rules.d/71-biosdevname.rules has
a comment that says you can disable biosdevname by using the
biosdevname=0 parameter on the kernel. Maybe that works.
So I should now install 'biosdevname', then disable it on kernel
cmdline and MAC-based network interface naming should work?
When it's true, then...
... such bestiality is possible only in Fedora!
12:32 p.m.
Hi
On Mon, Feb 25, 2013 at 1:09 PM, Frantisek Hanzlik <franta(a)hanzlici.cz>wrote:
'biosdevname' I have not installed, I have systemd v197 and
according to previously mentioned:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
custom rules in /etc/udev/rules.d/ should works - but not in F18!?
Yes because these changes were considered too intrusive to push in an
update. Refer to
https://admin.fedoraproject.org/updates/FEDORA-2013-0655/systemd-197-1.fc...
So for Fedora 18, biosdevname manages the devices by default. biosdevname
will probably be superseded by the systemd/udev update in Fedora 19
Rahul
12:09 p.m.
Tom Horsley wrote:
On Mon, 25 Feb 2013 14:58:17 +0100
Frantisek Hanzlik wrote:
> These rules works in F17 and earlier versions.
You could try "yum erase biosdevname", but if they have
eradicated whatever udev bit paid attention to the old
name rules it might not work.
'biosdevname' I have not installed, I have systemd v197 and
according to previously mentioned:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
custom rules in /etc/udev/rules.d/ should works - but not in F18!?
And as I understand them, in systemd v197+ isn't more biosdevname
package needed, as this is integrated into systemd/udev.
What I have are classic interface names ethNN, only with unwanted
order, my rules simply not works, thus when later network start,
I have typical message:
/etc/sysconfig/network-scripts/ifup-eth: Device eth2 has unexpected MAC address. Ignored.
Some idea?
10:58 a.m.
Marko Vojinovic wrote:
On Mon, 25 Feb 2013 22:51:15 +0100
poma <pomidorabelisima(a)gmail.com> wrote:
> On 02/25/13 21:01, Reindl Harald wrote:
> […]
>> so switch to anything else as ethX in your naming in
>> /etc/udev/rules.d/70-persistent-net.rules
>> like "lan0", "lan1", "wan0", "wan1" in
ifcfg-lan1....
>>
>> so you would not have race-conditions in kernel/udev naming the
>> interfaces
Just a small comment --- I believe everyone following this thread is
aware that these race conditions are the very reason for the
introduction of biosdevname in the first place.
So we could have one more source of confusion? Was that needed?
In order to avoid race conditions, one can either use biosdevname
and
have eth* be replaced by different names like em* and p*p*, or one can
disable biosdevname, configure udev manually, and have have eth* be
replaced by names like lan* and wan*.
The actual difference between the two methods is about system
maintenance --- when your network card burns out (these things happen,
unfortunately), biosdevname allows you to plug a new card into the same
pci slot and just turn the machine back on, with no extra
configuration. If you are configuring udev manually, and tie nic names
to MAC addresses, you are required to reconfigure udev for
the new MAC address of the new card.
The pain is greater in the latter case, while I see no gain at all,
compared to the way of biosdevname.
Maybe the OP can enlighten me *why* does he need MAC-oriented naming
scheme so badly? Just curious... :-)
So that when you have to open the server and do work the NIC cards can be
plugged in any slot and the name on the NIC socket and the label on the cable
will still work. A system board dies and I pull the cards out of the case, slide
a new server case into the rack, drop in the boards, plug the disk cables in the
back, and I'm up and going again even if the new case is not identical to the
old. As you said, it's about system maintenance.
I believe that at least 75% of the users of Fedora have a total of one NIC and
want it called eth0 as it has been. Just my read on that.
It would be desirable for everyone if there were one and only one place where
naming was done, and it was controlled by a set of rules, used in order, applied
to each NIC and using "first match" logic. See example.
# NOC control NIC - any card in the control slot
NAME="noc0" SLOT="b5p7q91s4"
# WAN ports
# current NIC
NAME="wan0" MAC="52:54:00:12:00:02"
# dual port card - replace next down time
NAME="wan0" MAC="52:54:00:12:01:40"
NAME="wan1" MAC="52:54:00:12:01:41"
# LAN port
NAME="lan0" MAC="52:54:00:12:00:51"
# the unreliable 10/100 service port on the mobo
NAME="bad" MAC="52:54:00:12:00:66"
# any unknown cards in the order found
NAME="eth+" NOMATCH
Note that with only the last rule default would be eth0.
Just my take on the issue, since I have no influence on Fedora or any other
distro, I don't expect anyone to pick up on this and allow users to use whatever
they find fits their needs, but the current naming scheme is inflexible, and was
probably implemented by someone used to labeling slots on servers. When I was a
project leader for a server group at at&t we labeled the NIC, and as noted, I
think most desktop users would be happy with eth0 rather than some random number
based on the slot, bridge, and some unreliable guess if the NIC is built-in or
on a card.
--
Bill Davidsen <davidsen(a)tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
4083
days inactive
4085
days old
36 comments
8 participants
participants (8)
-
Bill Davidsen -
Franta Hanzlík -
Marko Vojinovic -
poma -
Rahul Sundaram -
Reindl Harald -
Sam Varshavchik -
Tom Horsley