I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
In addition to the mediatomb configuration needing to be changed, I also noticed a more serious issue here: the firewalld zone associated with em1 did not get ported to eno1 during the upgrade. That could have serious unexpected implications for security.
In my case, it wasn't that serious, because my default zone was more locked down than the one I had for that NIC, but I can imagine scenarios where it could be a problem.
For the most part, the upgrade experience was great, but I thought I'd mention this particular issue for consideration/discussion, because I wasn't aware of the naming change in advance, and it could have serious consequences for function and security.
On Sat, Nov 7, 2015, 12:28 Christopher ctubbsii-fedora@apache.org wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
In addition to the mediatomb configuration needing to be changed, I also noticed a more serious issue here: the firewalld zone associated with em1 did not get ported to eno1 during the upgrade. That could have serious unexpected implications for security.
In my case, it wasn't that serious, because my default zone was more locked down than the one I had for that NIC, but I can imagine scenarios where it could be a problem.
For the most part, the upgrade experience was great, but I thought I'd mention this particular issue for consideration/discussion, because I wasn't aware of the naming change in advance, and it could have serious consequences for function and security.
This is also a good reason why the default firewalld zone should be very restrictive.
Christopher ctubbsii-fedora@apache.org wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
On any computer where it matters which network interface is connected to which network, I recommend writing some Udev rules to set permanent interface names based on the MAC address.
Write a file named /etc/udev/rules.d/01-network-interface-naming.rules with content similar to this:
SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:dc:b0", NAME:="world" SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:dc:e5", NAME:="gigabit" SUBSYSTEM=="net", ATTR{address}=="fc:f8:ae:ea:08:85", NAME:="wifi"
"01" in the filename causes it to be loaded before other files with higher numbers. Assignment with ":=" prevents later rules from clobbering the names. I found that capital letters don't work in the hexadecimal MAC addresses, so write them with small letters.
We shouldn't have to do this manually, and it definitely shouldn't be as difficult as it was to find out how to do it, but on the upside you get meaningful names so that you won't have any trouble remembering which interface is which.
(I hope no one turns Udev inside out anytime soon.)
Björn Persson
Am 08.11.2015 um 17:14 schrieb Björn Persson:
Christopher ctubbsii-fedora@apache.org wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
On any computer where it matters which network interface is connected to which network, I recommend writing some Udev rules to set permanent interface names based on the MAC address.
Write a file named /etc/udev/rules.d/01-network-interface-naming.rules with content similar to this:
SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:dc:b0", NAME:="world" SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:dc:e5", NAME:="gigabit" SUBSYSTEM=="net", ATTR{address}=="fc:f8:ae:ea:08:85", NAME:="wifi"
"01" in the filename causes it to be loaded before other files with higher numbers. Assignment with ":=" prevents later rules from clobbering the names. I found that capital letters don't work in the hexadecimal MAC addresses, so write them with small letters.
We shouldn't have to do this manually, and it definitely shouldn't be as difficult as it was to find out how to do it, but on the upside you get meaningful names so that you won't have any trouble remembering which interface is which.
(I hope no one turns Udev inside out anytime soon.)
Björn Persson
Please don't do this. For MAC based name assignment you can use the ifcfg-* files with HWADDR="<MAC>".
Harald Hoyer harald.hoyer@gmail.com wrote:
Am 08.11.2015 um 17:14 schrieb Björn Persson:
Christopher ctubbsii-fedora@apache.org wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
On any computer where it matters which network interface is connected to which network, I recommend writing some Udev rules to set permanent interface names based on the MAC address.
Write a file named /etc/udev/rules.d/01-network-interface-naming.rules with content similar to this:
SUBSYSTEM=="net", ATTR{address}=="00:0c:46:16:dc:b0", NAME:="world" SUBSYSTEM=="net", ATTR{address}=="00:1e:8c:cf:dc:e5", NAME:="gigabit" SUBSYSTEM=="net", ATTR{address}=="fc:f8:ae:ea:08:85", NAME:="wifi"
"01" in the filename causes it to be loaded before other files with higher numbers. Assignment with ":=" prevents later rules from clobbering the names. I found that capital letters don't work in the hexadecimal MAC addresses, so write them with small letters.
We shouldn't have to do this manually, and it definitely shouldn't be as difficult as it was to find out how to do it, but on the upside you get meaningful names so that you won't have any trouble remembering which interface is which.
(I hope no one turns Udev inside out anytime soon.)
Please don't do this.
I tend to not listen much to people who tell me to do stuff without stating any reasons. If you want me to change, and you're not in a position to give me orders, then you need to explain why the thing I'm doing is bad.
For MAC based name assignment you can use the ifcfg-* files with HWADDR="<MAC>".
Are you saying that HWADDR is a selection? It's described in /usr/share/doc/initscripts/sysconfig.txt as "ethernet hardware address for this device". That sounds like an assignment to me, assigning a new MAC address to the interface. If it would say "of" instead of "for", then I would understand it as a selection. I'll admit though, that if HWADDR is a selection, then it's easier to understand why both HWADDR and MACADDR exist.
Then I would need a way to use the ifcfg file to assign a name to the interface. I can find two candidates: DEVICE, and the interface name that is part of the filename. DEVICE is described as "name of physical device". Using "of", that sounds like a selection: "Apply the settings in this file to the interface that has this name." As for the filename, I've always assumed that that was either a selection or just a name without any special meaning. Using the filename to assign a name to an interface would seem really weird. Also, I don't see any explanation of how DEVICE and the filename interact.
Furthermore, my backups show that the ifcfg files I had when I upgraded from Fedora 15 to 17 did contain both HWADDR and DEVICE, and that didn't prevent the interface names from changing unpredictably on every reboot. Apparently there was a race between two or more components that each tried to set its own interface names. I pieced together those Udev rules based on hints I found on various blogs, and my interface names have been stable ever since.
Considering all of the above, I'm not at all convinced that your method works.
Björn Persson
Am 11.11.2015 um 16:23 schrieb Björn Persson:
I tend to not listen much to people who tell me to do stuff without stating any reasons. If you want me to change, and you're not in a position to give me orders, then you need to explain why the thing I'm doing is bad.
For MAC based name assignment you can use the ifcfg-* files with HWADDR="<MAC>".
Are you saying that HWADDR is a selection? It's described in /usr/share/doc/initscripts/sysconfig.txt as "ethernet hardware address for this device". That sounds like an assignment to me, assigning a new MAC address to the interface. If it would say "of" instead of "for", then I would understand it as a selection. I'll admit though, that if HWADDR is a selection, then it's easier to understand why both HWADDR and MACADDR exist
"HWADDR=" is the phyiscal address "MACADDR=" is for changing it, known as "clone MAC" on routers
DEVICE=wan HWADDR=24:be:05:1a:c0:27
[root@srv-rhsoft:~]$ ifconfig wan wan: flags=67<UP,BROADCAST,RUNNING> mtu 1500 ether 24:be:05:1a:c0:27 txqueuelen 100 (Ethernet) RX packets 3521821 bytes 1182354436 (1.1 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2904184 bytes 3006634333 (2.8 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 20 memory 0xf7c00000-f7c20000
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
Rich.
Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
that is simple to solve forever
* add "net.ifnames=0 biosdevname=0" to your kernel params * get rid of NetworkManager * rename your ethernet-devices in the ifcfg-files based on the MAC * survives yum-upgardes from Fedora 9 to Fedora 23 * nobody needs NM and that other stuff on static configured servers * frankly even with a DHCP wan-interface it works perfectly
the machine below has 16 network-interfaces and the IP is configured via DHCP and after get rid of all the "improvements" no loger troubles ______________________________________
[root@srv-rhsoft:~]$ cat /etc/sysconfig/network-scripts/ifcfg-wan ########################### # WAN (Chello) # ###########################
DEVICE=wan HWADDR=24:be:05:1a:c0:27
TYPE=Ethernet BOOTPROTO=static ONBOOT=yes ARPCHECK=no NM_CONTROLLED=no USERCTL=no IPV6INIT=no MTU=1500 ETHTOOL_OPTS="wol d; -K ${DEVICE} tso on rx on tx on gro on; -G ${DEVICE} rx 2048 tx 2048; -C ${DEVICE} rx-usecs 75" ______________________________________
[root@srv-rhsoft:~]$ cat /etc/systemd/system/network-wan-bridge.service [Unit] Description=Network Internet Bridge After=network.service systemd-networkd.service network-online.target
[Service] Type=forking ExecStartPre=-/usr/sbin/brctl addbr br-wan ExecStartPre=-/usr/sbin/brctl stp br-wan off ExecStartPre=-/usr/sbin/brctl setageing br-wan 600 ExecStartPre=-/usr/sbin/brctl setfd br-wan 5 ExecStartPre=-/usr/sbin/brctl addif br-wan wan ExecStartPre=-/usr/sbin/brctl addif br-wan vmnet1 ExecStartPre=-/usr/sbin/ifconfig br-wan hw ether 00:50:8D:B5:CC:DE up ExecStart=/usr/sbin/dhclient -4 -H srv-rhsoft -q -R subnet-mask,broadcast-address,routers,interface-mtu br-wan ExecStartPost=-/usr/sbin/ifconfig br-wan -multicast -allmulti ExecStartPost=-/usr/sbin/ifconfig vmnet1 0.0.0.0 -multicast -allmulti up ExecStopPost=-/usr/sbin/ifconfig br-wan down ExecStopPost=-/usr/sbin/brctl delbr br-wan
Restart=always RestartSec=1
PrivateTmp=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW
ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr
InaccessibleDirectories=-/mnt InaccessibleDirectories=-/mnt/data
On Sun, Nov 08, 2015 at 08:36:57PM +0100, Reindl Harald wrote:
Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
that is simple to solve forever
- add "net.ifnames=0 biosdevname=0" to your kernel params
- get rid of NetworkManager
- rename your ethernet-devices in the ifcfg-files based on the MAC
- survives yum-upgardes from Fedora 9 to Fedora 23
- nobody needs NM and that other stuff on static configured servers
- frankly even with a DHCP wan-interface it works perfectly
I agree, except it's not "simple" :-)
Maybe giving permanent names to network interfaces (of our own choice or from a standard set) is something we should be able to choose at installation time?
Rich.
Am 08.11.2015 um 20:42 schrieb Richard W.M. Jones:
On Sun, Nov 08, 2015 at 08:36:57PM +0100, Reindl Harald wrote:
Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
that is simple to solve forever
- add "net.ifnames=0 biosdevname=0" to your kernel params
- get rid of NetworkManager
- rename your ethernet-devices in the ifcfg-files based on the MAC
- survives yum-upgardes from Fedora 9 to Fedora 23
- nobody needs NM and that other stuff on static configured servers
- frankly even with a DHCP wan-interface it works perfectly
I agree, except it's not "simple" :-)
define simple
it's in any way simpler then find out after a update that you can no longer reaach your machine because all that "predictable" crap changed multiple times in the past with no gain for 99% of all setups (most have only one NIC and for them eth0 was as predictable as something can be)
Maybe giving permanent names to network interfaces (of our own choice or from a standard set) is something we should be able to choose at installation time?
yes that would make things way easier because when you have 5 network-interfaces and a plan what they are supposed to do you could start naming them and later just try out "who is who" by plugin a cable (they easy way with physical access while and after setup)
the same way when you see the MAC-address you giving the name you can plugin your cables before setup, depending on the hardware there may be some label which port has which MAC, however - the only "persistent" thing of a network-interface it's his MAC address
IMPORTANT: it *must* be clear where this paring is configured in case you need to replace a NIC and adtop the configuration
Maybe giving permanent names to network interfaces (of our own choice or from a standard set) is something we should be able to choose at installation time?
Actually, what people want is to forbid any renaming during updates, because that breaks all kinds of stuff. The system should keep the install-time naming or whatever the admin (not the system) changed it to later
(Guess I know now why I have a headless system to rescue)
On Sun, 2015-11-08 at 20:36 +0100, Reindl Harald wrote:
Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
that is simple to solve forever
- add "net.ifnames=0 biosdevname=0" to your kernel params
- get rid of NetworkManager
FYI, NetworkManager has nothing to do with device naming at all. So disabling NM will do nothing to solve your problems with device names.
Dan
On Sun, Nov 8, 2015, 14:29 Richard W.M. Jones rjones@redhat.com wrote:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/ :// https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/ wiki.freedesktop.org https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/ /www/Software/ https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/ systemd https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/ / https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/ PredictableNetworkInterfaceNames https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/ / https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
Rich.
It's a good policy and a good idea, but I thought it had already been done with the em1 naming. I guess i misunderstood when it'd be implemented.
Am 08.11.2015 um 21:25 schrieb Christopher:
On Sun, Nov 8, 2015, 14:29 Richard W.M. Jones <rjones@redhat.com It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/>:// <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/>wiki.freedesktop.org <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/>/www/Software/ <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/>systemd <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/>/ <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/>PredictableNetworkInterfaceNames <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/>/ <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> Rich. It's a good policy and a good idea, but I thought it had already been done with the em1 naming. I guess i misunderstood when it'd be implemented.
there is nothing good in changing network interface naming every few years and there where even reports that after updates even the systemd-implementation changed it again (not only the switch form biosdevname to systemd)
doing that on systems with just one ethernet interface (the majority) every few years is nothing else than asking for troubles
a skilled sysadmin can solve all that problems at his own, a non-skilled has repeatly problems to solve which did not exist in the past where eth0 was normal
Reindl Harald h.reindl@thelounge.net wrote:
a skilled sysadmin can solve all that problems at his own, a non-skilled has repeatly problems to solve which did not exist in the past where eth0 was normal
I guess you were lucky in the past. My experience was that interface names were unstable in the "eth0" days. After an upgrade eth0 and eth1 could suddenly swap names with each other, and adding or removing a network card could trigger a renaming of other network cards that had not been touched. Network interface names have always been unreliable, and apparently they're still unreliable, unless you have configured your own names and ensured that your configuration overrides anything else that tries to rename interfaces.
Björn Persson
Am 08.11.2015 um 22:59 schrieb Björn Persson:
Reindl Harald h.reindl@thelounge.net wrote:
a skilled sysadmin can solve all that problems at his own, a non-skilled has repeatly problems to solve which did not exist in the past where eth0 was normal
I guess you were lucky in the past. My experience was that interface names were unstable in the "eth0" days. After an upgrade eth0 and eth1 could suddenly swap names with each other, and adding or removing a network card could trigger a renaming of other network cards that had not been touched. Network interface names have always been unreliable, and apparently they're still unreliable, unless you have configured your own names and ensured that your configuration overrides anything else that tries to rename interfaces
what about read and quote correctly?
"doing that on systems with just one ethernet interface (the majority) every few years is nothing else than asking for troubles"
the problems you are talking about *did not* affect single-nic machines, the new ones does
Richard W.M. Jones wrote:
Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
Oh the irony!
Unpredictable, unstable network interface names. (I presume they previously changed from eth0 to p6p1, so that's already the SECOND breakage.) Hooray for this "feature"!
Kevin Kofler
On 11/08/2015 07:29 PM, Richard W.M. Jones wrote:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
The p6p1 and em1 interface names come from ( Dells ) biosdevname not systemd and most likely the biosdevname component got removed on upgrade or superseded by other udev rules.
Arguably biosdevname component should have been obsoleted in F19 as a component and in Anaconda and Dracut when predictable network interface names got introduced with systemd in the distribution, to prevent these kind of surprises but here we are so "surprise" ...
JBG
Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
Rich.
em* and p?p? come from biosdevname, which should not be used and is deprecated.
On Mon, Nov 09, 2015 at 04:55:40PM +0100, Harald Hoyer wrote:
Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
On Sat, Nov 07, 2015 at 05:28:54PM +0000, Christopher wrote:
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1.
Is this something that was expected? It certainly surprised me.
It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand.
"predictable, stable network interface names" https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfac...
Rich.
em* and p?p? come from biosdevname, which should not be used and is deprecated.
I'm merely observing what happened when I updated a bunch of servers from F22 to F23. I didn't intentionally install nor uninstall biosdevname at any point.
Rich.
On Mon, Nov 09, 2015 at 08:50:55PM +0000, Richard W.M. Jones wrote:
em* and p?p? come from biosdevname, which should not be used and is deprecated.
I'm merely observing what happened when I updated a bunch of servers from F22 to F23. I didn't intentionally install nor uninstall biosdevname at any point.
But you should have. Biosdevname what deprecated 3 years ago (with Fedora 19 or 20*), you should have migrated your rules to udev's naming scheme and remove biosdevname. This was quite long transition period, even longer than biosdevname usage, which was default between Fedora 15 and 19 (2 years).
* although I can't find the mention in Release Notes for neither F19 nor F20. We may have underdelivered on this :(
On 11/10/2015 06:06 AM, Tomasz Torcz wrote:
On Mon, Nov 09, 2015 at 08:50:55PM +0000, Richard W.M. Jones wrote:
em* and p?p? come from biosdevname, which should not be used and is deprecated.
I'm merely observing what happened when I updated a bunch of servers from F22 to F23. I didn't intentionally install nor uninstall biosdevname at any point.
But you should have. Biosdevname what deprecated 3 years ago (with Fedora 19 or 20*), you should have migrated your rules to udev's naming scheme and remove biosdevname. This was quite long transition period, even longer than biosdevname usage, which was default between Fedora 15 and 19 (2 years).
- although I can't find the mention in Release Notes for neither F19 nor F20. We may have underdelivered on this :(
Biosdevname has not "officially" been deprecated ( still mentioned in the guidelines and still available for download ) and it only got removed from comps and Anaconda in F21 ( which is something that should have happened in F19 ) and up to that point it was still installed by default so machine upgrades from <F21 --> F21 - F22 - F23 will still have it, clean installs of F21+ should however not ( unverified ).
The WG's or any of the live CD's might still be deliberately shipping it ( like the serverWG might think it was a good idea to ship it like they are still shipping rsyslog etc ) .
JBG
On Tue, Nov 10, 2015 at 07:06:51AM +0100, Tomasz Torcz wrote:
On Mon, Nov 09, 2015 at 08:50:55PM +0000, Richard W.M. Jones wrote:
em* and p?p? come from biosdevname, which should not be used and is deprecated.
I'm merely observing what happened when I updated a bunch of servers from F22 to F23. I didn't intentionally install nor uninstall biosdevname at any point.
And this is the crux of the problem: for some reason biosdevname stopped working for you. This was not intentional and should not happen. Is biosdevname it still installed? Can you file a bug against systemd and attach output of 'sudo udevadm test /sys/class/net/eno1' (or whatever the name the device has in the end)?
But you should have. Biosdevname what deprecated 3 years ago (with Fedora 19 or 20*), you should have migrated your rules to udev's naming scheme and remove biosdevname.
That's true, but not really relevant. We neither removed biosdevname nor announced that is not supported anymore, and if it suddenly stopped working we need to figure out why.
Zbyszek
On Tue, Nov 10, 2015 at 9:21 AM Zbigniew Jędrzejewski-Szmek < zbyszek@in.waw.pl> wrote:
On Tue, Nov 10, 2015 at 07:06:51AM +0100, Tomasz Torcz wrote:
On Mon, Nov 09, 2015 at 08:50:55PM +0000, Richard W.M. Jones wrote:
em* and p?p? come from biosdevname, which should not be used and is
deprecated.
I'm merely observing what happened when I updated a bunch of servers from F22 to F23. I didn't intentionally install nor uninstall
biosdevname
at any point.
And this is the crux of the problem: for some reason biosdevname stopped working for you. This was not intentional and should not happen. Is biosdevname it still installed? Can you file a bug against systemd and attach output of 'sudo udevadm test /sys/class/net/eno1' (or whatever the name the device has in the end)?
But you should have. Biosdevname what deprecated 3 years ago (with
Fedora 19
or 20*), you should have migrated your rules to udev's naming scheme and remove biosdevname.
That's true, but not really relevant. We neither removed biosdevname nor announced that is not supported anymore, and if it suddenly stopped working we need to figure out why.
Well, I still have biosdevname-0.6.2-1.fc23.x86_64 installed on the desktop machine I mentioned was upgraded in the original post, where the NIC was changed from em1 to eno1 on the upgrade.
On Tue, Nov 10, 2015 at 02:21:13PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 10, 2015 at 07:06:51AM +0100, Tomasz Torcz wrote:
On Mon, Nov 09, 2015 at 08:50:55PM +0000, Richard W.M. Jones wrote:
em* and p?p? come from biosdevname, which should not be used and is deprecated.
I'm merely observing what happened when I updated a bunch of servers from F22 to F23. I didn't intentionally install nor uninstall biosdevname at any point.
And this is the crux of the problem: for some reason biosdevname stopped working for you. This was not intentional and should not happen. Is biosdevname it still installed?
Yes: biosdevname-0.6.2-1.fc23.x86_64
Can you file a bug against systemd and attach output of 'sudo udevadm test /sys/class/net/eno1' (or whatever the name the device has in the end)?
TBH I've fixed the machines and I don't particularly want to pursue this bug. However I have attached the output of:
sudo udevadm test /sys/class/net/enp3s0
to this email, in case anyone else wants to take this up.
Rich.