6:41 a.m.
I've got F21 branched installed on an alternate partition on
my system, and I noticed this nonsense. On F21 I get this:
enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255
inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20<link>
ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet)
RX packets 112 bytes 13242 (12.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 84 bytes 10207 (9.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0
On F20 the same hardware (note the MAC address) gives this:
p6p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255
inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20<link>
ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet)
RX packets 1233320 bytes 144491797 (137.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2058583 bytes 2951769070 (2.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0
What was the point of "consistent" interface names again?
6:55 a.m.
On Wed, Aug 06, 2014 at 07:41:07AM -0400, Tom Horsley wrote:
What was the point of "consistent" interface names again?
Completely leaving aside the question of what exactly it _should_ mean, it
appears to mean "consistent on the same machine for a given OS release,
_across any possible hardware changes_".
This very much does not mean "consistent between machines in any useful way"
or, as you see here, "consistent across releases".
Those things would definitely be useful, but they're not what's meant. The
thing which _is_ meant *is* also useful, but for different reasons and
different problems (which might not even be problems you have).
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:08 a.m.
On Wed, 6 Aug 2014 07:55:55 -0400
Matthew Miller wrote:
"consistent on the same machine for a given OS release,
_across any possible hardware changes_"
Maybe, but I know I watched the interface names change
just because a new version of bisodevname was released
before biosdevname was engulphed by systemd. I wouldn't
be surprised at all to see a systemd update change
the names as well :-(.
I also love the new systemd conventions that give me
a different "consistent" name for my USB wifi dongle
depending on which USB port I plug it into :-).
http://home.comcast.net/~tomhorsley/game/biosdevname.html
7:29 a.m.
On Wed, Aug 06, 2014 at 08:08:10AM -0400, Tom Horsley wrote:
> "consistent on the same machine for a given OS release,
> _across any possible hardware changes_"
Maybe, but I know I watched the interface names change
just because a new version of bisodevname was released
before biosdevname was engulphed by systemd. I wouldn't
So, actually, the biosdevname goal was slightly different, and focused more
on predictability across machines when possible. (And specifically on
matching the silkscreened labels on Dell server hardware.)
It also went through a couple of unfortunate trial-and-error periods where
the naming policy changed.
be surprised at all to see a systemd update change
the names as well :-(.
That should not happen within a stable Fedora release and we'll treat it as
a bug if it does.
I also love the new systemd conventions that give me
a different "consistent" name for my USB wifi dongle
depending on which USB port I plug it into :-).
http://home.comcast.net/~tomhorsley/game/biosdevname.html
But consistent for each port, right? :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:37 a.m.
On 08/06/2014 07:08 AM, Tom Horsley wrote:
On Wed, 6 Aug 2014 07:55:55 -0400
Matthew Miller wrote:
> "consistent on the same machine for a given OS release,
> _across any possible hardware changes_"
Maybe, but I know I watched the interface names change
just because a new version of bisodevname was released
before biosdevname was engulphed by systemd. I wouldn't
be surprised at all to see a systemd update change
the names as well :-(.
I also love the new systemd conventions that give me
a different "consistent" name for my USB wifi dongle
depending on which USB port I plug it into :-).
http://home.comcast.net/~tomhorsley/game/biosdevname.html
I was having the same issue and finally resolved to make sure that my
"consistent" ethernet device was named eth0. I did that with
the following line in /etc/udev/rules.d/70-my-net-names.rules:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="c8:0a:a9:b1:46:c2", ATTR{dev_id}=="0x0",
ATTR{type}=="1", NAME="eth0"
Thereby forcing my device with that mac address to have name eth0. dmesg shows
udev/systemd changing this:
[ 3.975997] systemd-udevd[232]: renamed network interface eth0 to p6p1
[ 21.108994] systemd-udevd[421]: renamed network interface p6p1 to eth0
YMMV.
Kevin
12:48 p.m.
Would someone explain this to me:
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
wrote:
For a longer time udev shipped support for assigning permanent
"ethX"
names to certain interfaces based on their MAC addresses.
This turned out to have a multitude of problems, among them:
this required a writable root directory which is generally not available;
Huh? Why would that require a writeable root directory?
the statelessness of the system is lost as booting an OS image on a
system will result in changed configuration of the image;
on many systems MAC addresses are not actually fixed,
such as on a lot of embedded hardware and particularly
How do MAC addresses get changed on embedded systems?
on all kinds of virtualization solutions.
My guess is that virtualization could screw up any scheme,
including the current system.
Does rebooting a virtual machine have to change MAC addresses?
On a machine with just one network interface,
is there any reason not to call it eth0, fred or whatever the user wants?
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
12:54 p.m.
On 08/06/2014 10:48 AM, Michael Hennebry wrote:
wrote:
> For a longer time udev shipped support for assigning permanent "ethX"
> names to certain interfaces based on their MAC addresses.
> This turned out to have a multitude of problems, among them:
> this required a writable root directory which is generally not available;
Huh? Why would that require a writeable root directory?
There was a file in /etc/udev/rules.d/ that kept track of the mapping
from devices to the ethX names.
> the statelessness of the system is lost as booting an OS image on
a
> system will result in changed configuration of the image;
> on many systems MAC addresses are not actually fixed,
> such as on a lot of embedded hardware and particularly
How do MAC addresses get changed on embedded systems?
Some ethernet hardware on embedded systems doesn't have built-in MAC
addresses.
2:25 p.m.
On Wed, 6 Aug 2014, Samuel Sieb wrote:
On 08/06/2014 10:48 AM, Michael Hennebry wrote:
> wrote:
>> For a longer time udev shipped support for assigning permanent "ethX"
>> names to certain interfaces based on their MAC addresses.
>> This turned out to have a multitude of problems, among them:
>> this required a writable root directory which is generally not available;
>
> Huh? Why would that require a writeable root directory?
>
There was a file in /etc/udev/rules.d/ that kept track of the mapping
from devices to the ethX names.
Soft link it to something under /var .
>> the statelessness of the system is lost as booting an OS
image on a
>> system will result in changed configuration of the image;
>> on many systems MAC addresses are not actually fixed,
>> such as on a lot of embedded hardware and particularly
>
> How do MAC addresses get changed on embedded systems?
>
Some ethernet hardware on embedded systems doesn't have built-in MAC
addresses.
Not having any is not the same as changed.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
10:01 p.m.
On Sat, 30 Aug 2014, Lars Seipel wrote:
On Wed, Aug 06, 2014 at 02:25:46PM -0500, Michael Hennebry wrote:
>> Some ethernet hardware on embedded systems doesn't have built-in MAC
>> addresses.
>
> Not having any is not the same as changed.
They generate one at boot-time.
Not that it matters much, but the first two lines below "... Hennebry wrote:"
were written by Samuel Sieb.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
7:38 a.m.
On Wed, 2014-08-06 at 07:41 -0400, Tom Horsley wrote:
I've got F21 branched installed on an alternate partition on
my system, and I noticed this nonsense. On F21 I get this:
enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255
inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20<link>
ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet)
RX packets 112 bytes 13242 (12.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 84 bytes 10207 (9.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0
That's systemd:
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfac...
On F20 the same hardware (note the MAC address) gives this:
p6p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.134.30.143 netmask 255.255.255.0 broadcast 10.134.30.255
inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid 0x20<link>
ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet)
RX packets 1233320 bytes 144491797 (137.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2058583 bytes 2951769070 (2.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0
That's biosdevname:
https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming
In Fedora 21 we've more or less dropped biosdevname in favour of
systemd. systemd's system is a cleaner implementation and the weight of
opinion favours the systemd approach to naming. See the discussion from
https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards.
From F21 onwards new Fedora installations should reliably result in
the
use of the systemd naming scheme. Existing installs that use biosdevname
will continue to use it (with the same naming scheme, obviously) unless
the admin intervenes.
We should probably put this in the release notes.
8:06 a.m.
On Wed, 2014-08-06 at 14:38 +0200, Adam Williamson wrote:
In Fedora 21 we've more or less dropped biosdevname in favour of
systemd. systemd's system is a cleaner implementation and the weight of
opinion favours the systemd approach to naming. See the discussion from
https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards.
From F21 onwards new Fedora installations should reliably result in the
use of the systemd naming scheme. Existing installs that use biosdevname
will continue to use it (with the same naming scheme, obviously) unless
the admin intervenes.
We should probably put this in the release notes.
Done: https://fedoraproject.org/wiki/Documentation_Networking_Beat
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:32 a.m.
On Wed, Aug 06, 2014 at 02:38:30PM +0200, Adam Williamson wrote:
In Fedora 21 we've more or less dropped biosdevname in favour of
systemd. systemd's system is a cleaner implementation and the weight of
opinion favours the systemd approach to naming. See the discussion from
https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards.
From F21 onwards new Fedora installations should reliably result in the
use of the systemd naming scheme. Existing installs that use biosdevname
will continue to use it (with the same naming scheme, obviously) unless
the admin intervenes.
We should probably put this in the release notes.
Currently, as I understand it, to get back the eth0 naming scheme, one has
remove biosdevname as well as add the net.ifnames=0. Does that mean that
with F21, we will no longer need the step of rpm -e biosdevname?
The term "more or less" seems a bit unclear.
I'm looking at
https://fedoraproject.org/wiki/Documentation_Networking_Beat as well as the
bug report linked above, and from *that*, it looks as if it will no longer
be necessary for the rpm -e biosdevname step.
Thanks
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
11:43 a.m.
On 08/06/2014 09:32 AM, Scott Robbins wrote:
On Wed, Aug 06, 2014 at 02:38:30PM +0200, Adam Williamson wrote:
>
> In Fedora 21 we've more or less dropped biosdevname in favour of
> systemd. systemd's system is a cleaner implementation and the weight of
> opinion favours the systemd approach to naming. See the discussion from
> https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards.
>
> From F21 onwards new Fedora installations should reliably result in the
> use of the systemd naming scheme. Existing installs that use biosdevname
> will continue to use it (with the same naming scheme, obviously) unless
> the admin intervenes.
>
> We should probably put this in the release notes.
Currently, as I understand it, to get back the eth0 naming scheme, one has
remove biosdevname as well as add the net.ifnames=0. Does that mean that
with F21, we will no longer need the step of rpm -e biosdevname?
The term "more or less" seems a bit unclear.
I'm looking at
https://fedoraproject.org/wiki/Documentation_Networking_Beat as well as the
bug report linked above, and from *that*, it looks as if it will no longer
be necessary for the rpm -e biosdevname step.
Thanks
Hmm, I have biosdevname installed (and always have) and have never put
net.ifnames=0 anywhere that I'm aware of. I've used the
syntax that I put thru earlier since F19 and I'm now on F22.
Kevin
3:23 p.m.
On 2014-08-06 11:43 (GMT-0500) Kevin Martin composed:
Hmm, I have biosdevname installed (and always have) and have never
put net.ifnames=0
anywhere that I'm aware of.
I've included net.ifnames=0 on installer cmdline for every distro I've
installed for over a year. NAICT, Anaconda ignores it. I don't remember
exactly how on Fedora I get eth0, possibly as a result of editing and
renaming /etc/sysconfig/network-scripts/ifcfg-XXXX to ifcfg-eth0, but from
earlier installations carried forward into my Rawhides I do have the
following also:
-rw-rw-r-- 1 root root 0 Oct 4 2013 /etc/udev/rules.d/80-net-name-slot.rules
I see on
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
that that name has inexplicably been replaced for systemd v209 & up by
80-net-setup-link.rules.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
10:18 p.m.
On 08/06/2014 03:23 PM, Felix Miata wrote:
On 2014-08-06 11:43 (GMT-0500) Kevin Martin composed:
> Hmm, I have biosdevname installed (and always have) and have never
> put net.ifnames=0
> anywhere that I'm aware of.
I've included net.ifnames=0 on installer cmdline for every distro I've
installed for over a year. NAICT, Anaconda ignores it. I don't
remember exactly how on Fedora I get eth0, possibly as a result of
editing and renaming /etc/sysconfig/network-scripts/ifcfg-XXXX to
ifcfg-eth0, but from earlier installations carried forward into my
Rawhides I do have the following also:
-rw-rw-r-- 1 root root 0 Oct 4 2013
/etc/udev/rules.d/80-net-name-slot.rules
I see on
http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterf...
that that name has inexplicably been replaced for systemd v209 & up by
80-net-setup-link.rules.
For the record, nmcli will do this without breaking a
sweat. For example:
[root@g55 ~]# nmcli con edit ed0fea4d-ed28-4fdb-9a8c-c131bd78d030
===| nmcli interactive connection editor |===
Editing existing '802-3-ethernet' connection:
'ed0fea4d-ed28-4fdb-9a8c-c131bd78d030'
Type 'help' or '?' for available commands.
Type 'describe [<setting>.<prop>]' for detailed property description.
You may edit the following settings: connection, 802-3-ethernet
(ethernet), 802-1x, ipv4, ipv6
nmcli> print connection
['connection' setting values]
connection.id: p3p1
connection.uuid: ed0fea4d-ed28-4fdb-9a8c-c131bd78d030
connection.interface-name: --
connection.type: 802-3-ethernet
connection.autoconnect: no
connection.timestamp: 1407336689
connection.read-only: no
connection.permissions:
connection.zone: home
connection.master: --
connection.slave-type: --
connection.secondaries:
connection.gateway-ping-timeout: 0
nmcli> set connection.id eth0
nmcli> set connection.interface-name eth0
nmcli> save
Connection 'eth0' (ed0fea4d-ed28-4fdb-9a8c-c131bd78d030) sucessfully saved.
nmcli> quit
[root@g55 ~]#
reboot when that is done, it will now be eth0 forever and ever, amen. A
word of caution, however - do not do this if you have already set up
other connections that depend on it, because they will still be looking
for the former devname - which brings up a feature request. Maybe
NetworkManager should have bridge, bond, and VPN connection masters
and/or slaves either use the UUID for the identifier, or update the link
in the underlying DB when IDs are changed.
--
Dan Mossor
Systems Engineer at Large
Fedora QA Team | Fedora KDE SIG | Fedora Server SIG
Fedora Infrastructure Apprentice
FAS: dmossor IRC: danofsatx
San Antonio, Texas, USA
3:29 a.m.
On Wed, 2014-08-06 at 16:23 -0400, Felix Miata wrote:
On 2014-08-06 11:43 (GMT-0500) Kevin Martin composed:
> Hmm, I have biosdevname installed (and always have) and have never put
net.ifnames=0
> anywhere that I'm aware of.
I've included net.ifnames=0 on installer cmdline for every distro I've
installed for over a year. NAICT, Anaconda ignores it.
No, it doesn't, but I think you're all confused about what net.ifnames=0
is for. net.ifnames=0 turns off *systemd's* predictable device naming.
It does nothing about biosdevname. The kernel parameter for disabling
biosdevname is biosdevname=0 . If you want the most belt-and-braces
approach to making sure you never get 'predictable' device names of any
sort, do 'yum remove biosdevname' and add 'net.ifnames=0 biosdevname=0'
to your kernel cmdline. That should do the trick.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:27 a.m.
On Wed, 2014-08-06 at 10:32 -0400, Scott Robbins wrote:
On Wed, Aug 06, 2014 at 02:38:30PM +0200, Adam Williamson wrote:
>
> In Fedora 21 we've more or less dropped biosdevname in favour of
> systemd. systemd's system is a cleaner implementation and the weight of
> opinion favours the systemd approach to naming. See the discussion from
> https://bugzilla.redhat.com/show_bug.cgi?id=965718#c76 onwards.
>
> From F21 onwards new Fedora installations should reliably result in the
> use of the systemd naming scheme. Existing installs that use biosdevname
> will continue to use it (with the same naming scheme, obviously) unless
> the admin intervenes.
>
> We should probably put this in the release notes.
Currently, as I understand it, to get back the eth0 naming scheme, one has
remove biosdevname as well as add the net.ifnames=0. Does that mean that
with F21, we will no longer need the step of rpm -e biosdevname?
For a fresh Fedora 21 install with a normal package set, yes, you will
no longer need to remove it, as it won't be installed. Systems upgraded
from older releases that have biosdevname will continue to have it, of
course, and it is still present in the repositories and can be manually
installed or included in a kickstart.
The term "more or less" seems a bit unclear.
It was just a hedge for the point above: the package does still exist
and can be manually installed, and systems being upgraded will continue
to use it if they were before.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:28 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 6 Aug 2014 07:41:07 -0400
Tom Horsley <horsley1953(a)gmail.com> wrote:
I've got F21 branched installed on an alternate partition on
my system, and I noticed this nonsense. On F21 I get this:
enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.134.30.143 netmask 255.255.255.0 broadcast
10.134.30.255 inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid
0x20<link> ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet)
RX packets 112 bytes 13242 (12.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 84 bytes 10207 (9.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0
this comes systemd's naming structure.
On F20 the same hardware (note the MAC address) gives this:
p6p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.134.30.143 netmask 255.255.255.0 broadcast
10.134.30.255 inet6 fe80::20b:eff:fe0f:ed prefixlen 64 scopeid
0x20<link> ether 00:0b:0e:0f:00:ed txqueuelen 1000 (Ethernet)
RX packets 1233320 bytes 144491797 (137.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2058583 bytes 2951769070 (2.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 1 collisions 0
this comes from biosdevname's naming structure.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJT54GYAAoJEH7ltONmPFDRE4AQALDcOWuQyBurqmOd55OMXJuW
kWNAf9jn4Jz4WJOBnAFD64BNq1SHJ/ToxhbT3Ip7mr/ljRGs5Ctq52BX8nnxZ799
/JT3INAydphquIm5yLLTswyklsGfHhOnQnLyZRTmDLgXnxl1bMlKWhWLnXNKIPol
rXGRH2MqCO9eQQ9wC3C0HypwefcKa7e3Cmw3uioZ4sCni4GnhF3YrQ/wW26x6tGb
k/D6gHvYNp/76PrN+IOeTF2GYqN3UqVasMIthsdbpAFfwWJE7xPb6SecWLBNXXYj
/4O7UzvgxygMSLgQvjyit4g/7hIuPC0QAYwXi5EnQxn1EIqnhWPTkjRb8yxjk5HV
x78dVQFTNLuBklCDx/hA++rRdcxNrLfeLghOQxLJgoD7r4VgS/6TQ2IHkgBIYIlY
kPzDeaLkblkwMfpPZ6azrqMVD0TBqiGacH/penjuW0pFxDR/36X33CMP6lDliQMh
Nkm7C0WzDv0c0H++rWEmosbjTmi/1t7YXI5E7fyf9zLwyEM2u/b1uSxfuiY4IU11
x+KDm9PTOcqnhKdUGgF6b5TQ4mLpwMCexdTEJgsB7W6hngEgMqcTaukCZE4b8h22
8B6XW/aXOog9k0iSJvIKaVinAmK7Ase6WEZKozxmYVTpfPu/GtvMuDMuUVdYt18m
acynVG+xp4ha/35snBL1
=PQQ0
-----END PGP SIGNATURE-----
3526
days inactive
3551
days old
18 comments
11 participants
participants (11)
-
Adam Williamson -
Dan Mossor -
Dennis Gilmore -
Felix Miata -
kevin martin -
Lars Seipel -
Matthew Miller -
Michael Hennebry -
Samuel Sieb -
Scott Robbins -
Tom Horsley