ncm-network nmstate: error with unconfigured interface with bootproto=dhcp #1671
Comments
|
yes, your vlan config would not be correct without this #1667 |
|
Ok, I'll do. At first glance it was not clear it was the same pb... so I preferred to wait for your confirmation! |
|
@aka7 unfortunately the PR you mentioned doesn't help, even if it fixes the VLAN problem. But the other errors remain about
I attached the |
|
@jouvin the config it generated looks good to me. I'm wondering If NM has already created a connection already under a different profile name? I'll try test this locally tomorrow. also verify output of |
|
Here is I checked that in my last tests, CCM config and |
|
@jouvin thanks for sharing the output. I can't see anything obvious. what do you get what you run a manually and or trying I would first try to see if you can manually edit the file and get the interface up using nsmtateclt apply, following https://nmstate.io/examples.html#dynamic-ip-configuration. This way we can see if I missed to add a option for dhcp config. I must say we don't have any host configured with dhcp with nmstate so I haven't tested this part on a active host. |
|
@aka7 Below is the output from the suggested command: Whether I delete or not the connection, the output of |
|
I tried to apply a dhcp config internally here with nmstate/nm and it worked fine, although this was single interface vm. I'm starting to wonder if you should look at the warning you see? The other thing of note, is you are trying to apply for em2, but error is looking at the config you shared, they appear to be in order, which is puzzling. One more thing you can try is perhaps delete all current connections you see in the nmcli output and then apply again? |
|
@aka7 Thanks for pointing the version mismatch problem, my eyes are tired, I don't see these details! It was due to the fact I upgraded the machine to a more recent Yum snapshot but forgot to reboot it. This one was easy! Unfortunately it has no impact on the other problems. Exceppt that after reboot It is weird... as is the fact that it gives an error for all the interfaces (the same as for I found https://forums.centos.org/viewtopic.php?t=79957 pointing about a somewhat similar issue (even if the context is different) and saying that connection names in nmcli must match kernel interface names displayed by Here There is also a long thread, https://forums.rockylinux.org/t/unable-to-manage-activate-network-interface/7440/17, about this error in a context where it was related to the HW if I understood properly... I should may try another HW to see if it specific to it or a wider problem. |
|
@aka7 I think I identified the problem. It seems to be caused by all th "unused" interfaces (not connected, without a static configuration) that have the I cannot say whether it should be expected (the existing |
jouvin
changed the title
|
Sorry for the late follow-up, working on too many things in //. I was able to install from scratch an EL9 machine this morning and I had When |
|
We use ncm-resolver to manage resolv.conf so we set it false. When this is
false, it does two things,
1. creates the resolv.yml file with no settings for dns.
2. adds a drop-in file to disable NetworkManager to manage dns. Otherwise
ncm-resolver and NetworkManager fight over resolv.conf.
nmstateclt apply is a merge so when it runs apply with an empty settings it
shouldn't remove anything that's already configured, AFAIK. So resolv.yml
being empty isn't the issue I dont think. What error do you see?
I think your issue is more to do with dns=none being set when
nm_manage_dns=false,
i.e at /etc/NetworkManager/conf.d/90-quattor.conf it will set dns=none.
But this is expected behaviour. So sounds like you need NetworkManger to
manage dns when using dhcp? therefore setting to true in your case is
correct.
Regards
…On Thu, 28 Mar 2024 at 11:06, Michel Jouvin ***@***.***> wrote:
Sorry for the late follow-up, working on too many things in //. I was able
to install from scratch an EL9 machine this morning and I had ncm-nmstate
working properly after setting nm_manage_dns=true. It seems to be a
requirement, may be we should document it at list or see if we can have a
default different whether we use ncm-network or ncm-nmstate.
When false, it creates a /etc/nmstate/resolv.yml (may be it should
not...) where all the parameters are empty and this gives an error when
applying this configuration.
—
Reply to this email directly, view it on GitHub
<#1671 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADLYRYWBWEFW7VQC2LWRDQDY2PTQTAVCNFSM6AAAAABET7PFUCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRUHEZDINZWGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
A. Karim
|
|
@aka7 I think there is a misunderstanding: we don't use DHCP. I got the error on a freshly installed server, so I suspect a chicken & egg problem betwen ncm-nmstate and the resolver configuration by other means (I didn't experience it in the test done before). The "got" value in the error message is the configuration coming from Kickstart I guess. As the profile had Since then, I tried to reinstall the system with the new setting and the first run of SPMA fails with an error saying it is unable to resolve the hostname of the YUM server so I suspect |
|
BTW we don't use |
|
@jouvin understood. Yes there are few things (hacks/workaround whatever you want to call it) we had to put in at post ks to fix the initial first reboot resolver issue, because NetworkManager interferes with resolv.conf by the time ncm runs. So what we did is add the drop-in file in post ks for networkmanger not to manage dns so its there on ks post reboot, then you will get resolv.conf untouched as is from kickstart install. NOTE: this isn't nmstate issue, this is a result of being forced to use NetworkManager in rhel9 which does all the changes early on in reboot process on first reboot and creates the empty managed by NM resolve.conf. |
|
Do you have something like this in post ks? if not try this |
|
@aka7 sorry if gave the impression that I thought it was ncm-nmstate fault... I understood it is the change in the workflow introduced by NetworkManager use that take the controls of everything related to the network early in the boot process... In fact my attempt to reinstall with |
|
Unfortunately after adding the suggested hook, I get the following error when running What is the missing bit? |
|
@aka7 I checked that after booting, you can run successfully |
|
@jouvin that is strange, I haven't experienced this issue. What is contents of resolv.conf before and after the reboot? Normally if it has been replaced by NetworkManager it will have a comment on it? We did have to fix few ncm dependency issues but that is because we configure local dns caching using metaconfig so we make sure that his is run before ncm-resolver. But I know you said you dont have this setup, however, check if you have any ncm ordering issue and the contents of resolv.conf when it stops working to see if NM is changing it back. |
|
@aka7 i think it may be related to quattor/ncm-cdispd#56. May be the fact that ncm-cdispd doesn't have a proper systemd unit file results in an incorrect ordering... I may try to fix it next week, should not be difficult. Have you seen my previous comment about AII complaining it has no plug in for custom? |
|
@jouvin |
|
@aka7 thanks. I can imagine it is an add-on you développed. If it is the case, if you can share it I'm interested! |
|
@aka7 good news. I reinstalled my test system with the new cdp-listend and ncm-cdispd that both use a systemd unit instead of the legacy init scripts and now everything works properly. I didn't use the AII hook (as I'm missing the corresponding plugin) and I use |
|
@jouvin great news. I would be interested in the updated cdp-listend without chkconfig once its merged. I will take a look to see what we added for the custom hook and if we can put a PR through. its very useful. I thought it was from upstream. |
|
@aka7 I don't think the |
|
@jouvin I'm bit lost on this, which PR should I try? |
|
@aka7 about the PR, you may want to try stdweird/ncm-cdispd#1, which is a PR I opened on @stdweird PR, quattor/ncm-cdispd#61 that was adressing the missing systemd unit but not removing the chkconfig requirement. As for |
|
@jouvin thanks. makes sense. I didnt hit this issue until recently when I tried build an image and use that, then spma failed trying to install chkconfig. but |
|
@aka7 the Pr I mentioned is for ncm-cdispd. There is a similar PR for cdp-listend (by me) that suppress everything chkconfig related from cdp-listend rpm. |
|
@jouvin I guess what I'm saying is, do we now need to install /etc/init.d/cdp-listend ? I thought it also fixes this, but it doesn't. |
|
@aka7 yes my pr is supposed to fix this pb. It worked on the few machines we installed. |
|
@jouvin so I think your PR stops it pulling in chkconfig pkg but /etc/init.d still gets created. So if we still need to use chkconfig pkg it will fail to install. So my question is should this be omitted too. |
|
@aka7 i must double check but the goal of the Pr is to stop creating /etc/Init.d. If its not the case I 'need to fix it. Ill check the rpm I use as I had no conflict with chkconfig, conversely to the previous situation... |
|
@jouvin so from what I've noticed, so don't you also need this? |
|
@aka7 I'm sure you got it right, I'll have a look. I think I did it in 2 steps but I may have down a mistake pushing the fixes... |
|
@aka7 I suggest closing this issue (or keeping it for the original subject!) and moving the discussion about |
|
@jouvin yes that's fine by me. |
We are trying to use ncm-network nmstate variant on a EL9 system, using the ncm-network version from Jan. 10, 2024. Unfortunately, we are still fighting with unsupported device name: we are using
em(instead ofeth) and it seems to be a problem. Below is the output of the first messages fromncm-networkoutput. It seems to loop on these errors...If it helps, our interface configuration in the profile is:
One thing that is probably not related to this error but may hurt is the VLAN naming scheme we use and seems to be a potential problem according to #1660...
The text was updated successfully, but these errors were encountered: