It is an unfortunate fail, indeed. Network-scripts was removed in F41 saying that it would continue working the same thanks to NetworkManager-initscripts-ifcfg-rh. But, at the same time, the latter was planned to be removed also in F41, and nobody noticed.

There was an automatic conversion but it was enabled only for those using NetworkManager only, not for network-scripts users.

Maybe not many people is affected? This is the first complain that I hear, so I don't know if it is worth it to do something about it.

> The only way is to manually set all thru nmcli (or ip), which is not what you want on a server.

Millions of servers installations are being configured with NetworkManager/nmcli. Why is not what you want on a server? If what you want is to drop configuration files directly, you can put your configs in keyfile format as /etc/NetworkManager/system-connections/*.nmconnection.

> Millions of servers installations are being configured with NetworkManager/nmcli. Why is not what you want on a server? If what you want is to drop configuration files directly, you can put your configs in keyfile format as /etc/NetworkManager/system-connections/*.nmconnection.

This is missunderstanding - you do not want to do that when you counted for a minimal downtime, but suddelny you are left without a complete network setup on the server, where there is not a simple one, including VLANs, multiple IPs, routes etc. and you have to set it with tool that you do not know. To be honest this was really a hard time experience - 

1. setting static IP via nmcli, great there is IP, suddenly (after many seconds) the IP is dropped again... until you set con to manual instead auto the connection is still switching to DHCP

2. setting VLAN
nmcli con add type vlan ifname VLAN2 dev enp2s0f0 id 2 
oh.. a wrong interface lets do
nmcli con del type vlan ifname VLAN2 dev enp2s0f0 id 2 (used to do that with "ip")
interface "type, VLAN2, ifname..." not known, enp2s0f0 successfuly deleted.... what?! My precisou enp2s0f0 con is now gone

3. adding secondary IP to con... nothing happens, you have to down, up the interface (you are connected thru...) really?

4. restarting NM, takes several seconds for ip to show any results (i.e. it takes time to configure interfaces), nmtui not installed by default, still do not know how to setup ipv6 RA, did not found and easy way how to "nmcli com migrate" configs on F40, maybe I had to setup virtual with same interfaces, NM starts to overwrite resolv.conf much later for some reason (left the server working Ok, in the morning the DNS was not working anymore, resolv.conf only contained ipv6 address).


I do not know how to fix this situation, because in F41 (during upgrade) it is too late. It would require releasing F40 (EOL) package for something like networking-scripts that does bring NM and ifcfg plugin and once migrate the configs. But still this does not guarantee this will be the latest config during upgrade that is migrated. I would at least consider updating "known issues" for F41 if there is still something like this (even thou I did not read them this time anyway...), maybe providing instructions how to migrate the configs in case you end up without them (because I did not found any easy way to do that when already upgraded). Bringing back the NM ifcfg plugin to F41 would solve this too, but not sure if possible.

I have prepared a custom build of NetworkManager with support for ifcfg files. Use it like this:
1. Enable the COPR repository listed below for F41: dnf copr enable ihuguet/NetworkManager-with-ifcfg-f41 
2. Install the custom NetworkManager
3. Restart NetworkManager: sudo systemctl restart NetworkManager
4. Use it to migrate the ifcfg files to keyfile (nmcli connection migrate). Note that ifcfg files with NM_CONTROLLED=no are never used by NetworkManager, so you will need to manually remove those lines first.
5. Replace NetworkManager for the F41 stock version and remove the COPR repository
6. Restart NetworkManager and / or reboot.

COPR repositories:
- Fedora 41: https://copr.fedorainfracloud.org/coprs/ihuguet/NetworkManager-with-ifcfg-f41/
- Fedora 42: https://copr.fedorainfracloud.org/coprs/ihuguet/NetworkManager-with-ifcfg-f42/

It's the first time that I configure a COPR repo, and I think I missed something with the version number or something. As the version from the COPR repository is the same than the official repo (1.50.3-1), it is not installed with dnf install or update. Use `dnf reinstall --repo copr:copr.fedorainfracloud.org:ihuguet:NetworkManager-with-ifcfg-f41 NetworkManager`.

Ok, thanks, this helped, but was not flawless - 
1. the same packagename makes it hard to download via dnf, ended up downloading the package manually a installing via rpm 
2. not sure what would be correct way to migrate configs - I removed my "handmade" configs, stopped NM, reinstalled NM and started NM, and nothing happened, old setting still in place - seems like NM was not able to "deconfigure" existing interfaces, I also had to enable ifcfg plugin and reboot - it converted the ifcfg configs more or less fine just "crashed" on rather old ifcfg-eth0:0 file which was converted but later NM was not able to load it (also NM deleted migrated ifcfg files, which is not nice...), I had to do a several reboots to make things "perfect", in between them suddenly the enp2xxx devices were renamed to enp6xxx instead, making all the configs useless again, not sure this is related to NM, more of a kernel/udev thing, so just a coincidence. Had to rename the network devices in all other services again...

So as a workaround this is usable, hopefully not many people will have this problem.

I proposed new common issue in https://discussion.fedoraproject.org/t/after-upgrade-to-f41-system-is-left-completely-without-network-setup-if-previously-networking-scripts-were-used/153915

Thanks for posting the known issue, I was planning to do so. Can you add how to enable the ifcfg plugin to the explanation?

About the interface renaming: NM does not rename interfaces, it's probably a kernel or udev thing, as you say.