Re: Consistent names changed yet again?
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. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 henne...@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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 6 Aug 2014 07:41:07 -0400 Tom Horsley horsley1...@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=4163UP,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 0x20link 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=4163UP,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 0x20link 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- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 mat...@fedoraproject.org Fedora Project Leader -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
Would someone explain this to me: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ 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 henne...@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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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 henne...@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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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- 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/PredictableNetworkInterfaceNames/ 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/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Consistent names changed yet again?
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- 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/PredictableNetworkInterfaceNames/ 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
