s390utils ships a udev rule and a script that reads ifcfg files and configures the interface ([1]). http://pkgs.devel.redhat.com/cgit/rpms/s390utils/tree/ccw_init?id=5871612e5a2a6397914e6c5564814dd146da8a62 On RHEL8, "network-scripts" (the `network.service` from "initscripts" package) is already deprecated. On RHEL9, NetworkManager will stop writing ifcfg file by default, see bug 1894877. This may require action from s390utils to do something, or at least to discuss, document and investigate potential problems.
ah, I missed that on RHEL9 this already changed: http://pkgs.devel.redhat.com/cgit/rpms/s390utils/tree/ccw_init?id=2ade7f47aa718238a50b44a4f3a4a75ab873715f#n40 Sorry about that. So, I guess this is already under control/fixed? It does however make me wonder whether a (udev) shell script "grepping" through NetworkManager configuration is the right solution? Is there are reason this is done by udev, and not NetworkManager? At least, the setting of the "OPTIONS=" could be done by NetworkManager, or why not? Note that in a similar vain, udev's rename_interfaces (which currently parses ifcfg files), won't be updated to parse keyfiles (bug 1851279).
IIRC we had to update the network interface initialization for the installer environment, because it started to use keyfiles already. So we should be safe. But your questions make sense and I will prepare a meaningful answer. Or perhaps it will be a start of a new discussion.
What's still missing for full compatibility is that ccw_init needs to extract all the other s390-options (except for 'layer2') from the NM keyfile. Correct Dan?
(In reply to Julian Wiedmann from comment #3) > What's still missing for full compatibility is that ccw_init needs to > extract all the other s390-options (except for 'layer2') from the NM > keyfile. Correct Dan? I believe that's right, only the layer2 option is extracted/used now. And IIRC I had quite hard time to find an "ini files" parser for shell.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.