Bug 1695894 - Ethernet interface names are not preserved after install
Summary: Ethernet interface names are not preserved after install
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-03 21:01 UTC by Doug Ledford
Modified: 2019-04-11 02:14 UTC (History)
13 users (show)

Fixed In Version: anaconda-30.25.5-1.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-11 02:14:06 UTC
Type: Bug


Attachments (Terms of Use)

Description Doug Ledford 2019-04-03 21:01:41 UTC
Description of problem:

If you use the kernel command line ifname=lom0:MAC_ADDRESS1 ifname=lom1:MAC_ADDRESS2, and then use those interface names for network commands in a kickstart file like so:

network  --bootproto=static --device=lom0 --ethtool="autoneg on" --gateway=172.31.254.254 --ip=172.31.254.253 --nameserver=172.31.255.253,172.31.254.254 --netmask=255.255.255.0 --noipv6 --activate
# network  --bootproto=dhcp --device=lom1 --noipv6 --activate
network  --hostname=ipa-mo.xsintricity.com

then on reboot, the system will not keep the persistent device names and the interfaces will not come up with the proper config

Version-Release number of selected component (if applicable):

Fedora-30 Server Beta

How reproducible:

100%

Steps to Reproduce:
1. Boot with custom kernel command that defines network interface names:
linuxefi /vmlinuz inst.stage2=hd:UUID=9fc1593d-7c28-4bba-8763-1207a899652b
     inst.ks=hd:UUID=9fc1593d-7c28-4bba-8763-1207a899652b
     ifname=lom0:24:5e:be:22:45:6b ifname=lom1:24:5e:be:22:45:6c inst.gpt quiet
2. Use a kickstart that configures the devices based upon the proscribed names
3. Reboot

Actual results:

The original, BIOS dev names are found on reboot (enp5s0 and enp4s0), there are /etc/sysconfig/network-scripts files for lom0 and lom1, those files specify the right MAC address, but they are ignored, and the interfaces are started with default dhcp configs

Expected results:

The system would preserve the persistent device names and activate the proper network configuration files

Additional info:

Comment 1 Radek Vykydal 2019-04-04 11:00:07 UTC
Nothing has changed on anaconda side regarding ifname= option handling (compared to F29 where the renaming works after booting installed system).

Anaconda still just writes both DEVICE and HWADDR in the respective ifcfg file.

F29:
Generated by parse-kickstart
TYPE="Ethernet"
DEVICE="lom0"
HWADDR="52:54:00:9f:21:28"
UUID="3daca7f0-bc09-4f70-bdfe-0382191d22ce"
ONBOOT="yes"
BOOTPROTO="static"
IPADDR="10.43.136.71"
NETMASK="255.255.255.0"
GATEWAY="10.43.136.254"
IPV6INIT="no"
DNS1="10.43.136.2"

F30:
# Generated by parse-kickstart
TYPE="Ethernet"
DEVICE="lom0"
HWADDR="52:54:00:9f:21:28"
UUID="e068ee61-5b7c-4338-9cb2-1ab263c2ee73"
ONBOOT="yes"
BOOTPROTO="static"
IPADDR="10.43.136.71"
NETMASK="255.255.255.0"
GATEWAY="10.43.136.254"
IPV6INIT="no"
DNS1="10.43.136.2"


IIRC it is udevd which based on ifcfg used to rename the device? From the journal of installed system:

F29:
Apr 04 12:19:15 myhn systemd-udevd[544]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 04 12:19:15 myhn kernel: 8139cp 0000:00:03.0 lom0: renamed from eth0
Apr 04 12:19:16 myhn systemd-udevd[556]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 04 12:19:16 myhn kernel: 8139cp 0000:00:07.0 lom1: renamed from eth1

F30:
Apr 04 12:31:39 myhn systemd-udevd[666]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 04 12:31:39 myhn kernel: 8139cp 0000:00:03.0 ens3: renamed from eth0
Apr 04 12:31:39 myhn systemd[1]: Reached target Sound Card.
Apr 04 12:31:39 myhn systemd-udevd[669]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 04 12:31:39 myhn kernel: 8139cp 0000:00:07.0 ens7: renamed from eth1

Reassigning to systemd for comments.

I'll attach journal for F29 and F30.

Comment 2 Lukáš Nykrýn 2019-04-04 11:05:54 UTC
Could you list the packages that were installed in the f30 case?

Comment 3 Lukáš Nykrýn 2019-04-04 12:13:57 UTC
Maybe just to clarify, my suspicion is that we don't install initscripts package anymore, and it contains the binary that does naming of devices based on DEVICE HWADDR lines in ifcfg files.

Comment 4 Doug Ledford 2019-04-04 13:15:14 UTC
(In reply to Lukáš Nykrýn from comment #3)
> Maybe just to clarify, my suspicion is that we don't install initscripts
> package anymore, and it contains the binary that does naming of devices
> based on DEVICE HWADDR lines in ifcfg files.

On my system, initscripts is indeed not installed.  This is also probably why we have no ifup or ifdown commands (what are supposed to be their replacements?)

Comment 5 Doug Ledford 2019-04-04 13:17:00 UTC
I supposed I should point out though that ifrename is installed on the system, and if there were entries in /etc/iftab, maybe it would do the work.  But why aren't we just using the old /etc/udev/rules.d/70-persistent-net-names.rules file thing?  That takes things out of initscripts hands entirely (and it's also what the rdma package does for ipoib device names)?

Comment 6 Lukáš Nykrýn 2019-04-04 13:19:53 UTC
(In reply to Doug Ledford from comment #4)
> (In reply to Lukáš Nykrýn from comment #3)
> > Maybe just to clarify, my suspicion is that we don't install initscripts
> > package anymore, and it contains the binary that does naming of devices
> > based on DEVICE HWADDR lines in ifcfg files.
> 
> On my system, initscripts is indeed not installed.  This is also probably
> why we have no ifup or ifdown commands (what are supposed to be their
> replacements?)

In rhel8 NM ships the ifup and ifdown as a compatibility wrapper around nmcli. Not sure if they want to do the same thing in Fedora.

Comment 7 Zbigniew Jędrzejewski-Szmek 2019-04-04 13:31:59 UTC
> Anaconda still just writes both DEVICE and HWADDR in the respective ifcfg file.

Anaconda needs to make sure that something that groks those files is installed. Currently, that is either
initscripts or NetworkManager. Neither is mandatory AFAIK. I guess the easiest solution to keep things working
as before would be to pull in initscripts, if ifnames= is given.

Longer-term, it would be nice if anaconda use udev .link files to configure the interface names.
This would work independently of any network stack. Something like this for the example above:

# /etc/systemd/network/lom0.link
[Match]
MACAddress=52:54:00:9f:21:28

[Link]
Name=lom0

# /etc/systemd/network/lom1.link
[Match]
MACAddress=24:5e:be:22:45:6c

[Link]
Name=lom1

But the question of who will configure the network still remains.

I'll reassign this to anaconda, since it's a question of matching the config anaconda writes with the installed
package set.

Comment 8 Doug Ledford 2019-04-04 13:44:17 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #7)
> > Anaconda still just writes both DEVICE and HWADDR in the respective ifcfg file.
> 
> Anaconda needs to make sure that something that groks those files is
> installed. Currently, that is either
> initscripts or NetworkManager. Neither is mandatory AFAIK. I guess the
> easiest solution to keep things working
> as before would be to pull in initscripts, if ifnames= is given.
> 
> Longer-term, it would be nice if anaconda use udev .link files to configure
> the interface names.
> This would work independently of any network stack. Something like this for
> the example above:
> 
> # /etc/systemd/network/lom0.link
> [Match]
> MACAddress=52:54:00:9f:21:28
> 
> [Link]
> Name=lom0
> 
> # /etc/systemd/network/lom1.link
> [Match]
> MACAddress=24:5e:be:22:45:6c
> 
> [Link]
> Name=lom1
> 
> But the question of who will configure the network still remains.
> 
> I'll reassign this to anaconda, since it's a question of matching the config
> anaconda writes with the installed
> package set.

The link files didn't work for me.  I created the files by hand, then rebooted the system, and it came back up with the same link names.  Do I have to recreate the initramfs after making these files?

Comment 9 Zbigniew Jędrzejewski-Szmek 2019-04-04 14:33:26 UTC
I should not have spoken without testing ;)

The .link files are sorted alphanumerically, and letters come after digits, so a name like "lom0.link" comes after "99-default.link" and is totally useless.

What I wrote above should work, except that the file names should be more like:

-----------------------------------------------------
# /etc/systemd/network/10-lom0.link
[Match]
MACAddress=52:54:00:9f:21:28

[Link]
Name=lom0
-----------------------------------------------------
# /etc/systemd/network/10-lom1.link
[Match]
MACAddress=24:5e:be:22:45:6c

[Link]
Name=lom1
-----------------------------------------------------

In general, this configuration can be tested fairly easy with udevadm:
sudo SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/FOO

We put a bit of work in recent systemd releases to make the output useful.
If something is unclear or illogical there, please file a bug upstream.

Comment 10 Doug Ledford 2019-04-04 14:45:00 UTC
Confirmed, the link files work once being renamed.

Comment 11 Radek Vykydal 2019-04-05 08:15:37 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #7)
> > Anaconda still just writes both DEVICE and HWADDR in the respective ifcfg file.
> 
> Anaconda needs to make sure that something that groks those files is
> installed. Currently, that is either
> initscripts or NetworkManager. Neither is mandatory AFAIK. I guess the
> easiest solution to keep things working
> as before would be to pull in initscripts, if ifnames= is given.
> 
> Longer-term, it would be nice if anaconda use udev .link files to configure
> the interface names.
> This would work independently of any network stack.

Thank you for the hints. I'd prefer to use the udev .link files, seems like more transparent and future proof solution. I think Anaconda can generate the files based on ifname= boot options.

Comment 12 Radek Vykydal 2019-04-08 13:44:17 UTC
(In reply to Radek Vykydal from comment #11)

> Thank you for the hints. I'd prefer to use the udev .link files, seems like
> more transparent and future proof solution. I think Anaconda can generate
> the files based on ifname= boot options.

My concern here would be how the .link based renaming comes along with ifname= used in initramfs - the use case would be root on iSCSI or boot from iSCSI (SAN). I wasn't able to check this with rawhide as installation into root on iSCSI seems to be broken here. So I tried to use both ifname= and .link files in installer environment and it seems to be working.
Zbigniew, do you think we should be safe here?

Comment 13 Radek Vykydal 2019-04-08 13:56:42 UTC
Patch generating .link files based on ifname= option:
https://github.com/rhinstaller/anaconda/pull/1940

Comment 14 Zbigniew Jędrzejewski-Szmek 2019-04-08 14:34:47 UTC
I'm not an expert in dracut...

dracut.cmdline(7) says:
> It is recommended to either bind an interface to a MAC with the ifname
> argument, or to use the systemd-udevd predictable network interface names.
> ifname=<interface>:<MAC>
> Assign network device name <interface> (ie "bootnet") to the NIC with MAC
> <MAC>.
So it's not entirely clear whether what the expected effect of *combining* the
two approaches should be.

But looking at the code, dracut has modules.d/40network/ifname-genrules.sh which
creates /etc/udev/rules.d/80-ifname.rules. 80-ifname is before 80-net-setup-link,
so it seems ifname= will "win" over the .link files, because 80-net-set-link.rules
do nothing if NAME= is set. (And even if it was the other way around, I think the
result would be the same, because 80-ifname.rules sets NAME= unconditionally.)

So I think this patch is OK:
- the dracut config will still parse ifname= and it'll take priority over the .link files
- this might not matter anyway, because the effect of ifname= and the link files
  generated from it should be the same.

I hope this answers the question.

Comment 15 Radek Vykydal 2019-04-08 14:44:44 UTC
Yes, thank you!

Comment 16 Fedora Update System 2019-04-09 16:03:47 UTC
anaconda-30.25.5-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e2e3cfdb2b

Comment 17 Fedora Update System 2019-04-10 14:37:52 UTC
anaconda-30.25.5-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e2e3cfdb2b

Comment 18 Fedora Update System 2019-04-11 02:14:06 UTC
anaconda-30.25.5-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.