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:
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.
Could you list the packages that were installed in the f30 case?
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.
(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?)
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)?
(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.
> 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.
(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?
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.
Confirmed, the link files work once being renamed.
(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.
(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?
Patch generating .link files based on ifname= option: https://github.com/rhinstaller/anaconda/pull/1940
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.
Yes, thank you!
anaconda-30.25.5-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e2e3cfdb2b
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
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.