CLOS-4330: Inhibit upgrade when NetworkManager manages no device - #68
Merged
azheregelya merged 1 commit intoJul 31, 2026
Conversation
A keyfile under /etc/NetworkManager/conf.d setting `unmanaged-devices=*`
is survivable while network-scripts is installed: the legacy
network.service brings the interfaces up instead. CloudLinux 9 drops
network-scripts entirely, so the same configuration leaves the upgraded
host with no network at all - no SSH, no ICMP, reachable only from the
hypervisor console, which reads from outside as a hung upgrade.
Upstream's el8toel9 checkifcfg actor covers the equivalent NM_CONTROLLED=no
setting in ifcfg files and inhibits on it, but it never looks at conf.d, so
this class of configuration reaches the reboot completely unreported.
CheckNetworkManagerUnmanaged (ChecksPhase) closes that gap the same way
upstream handles its half: it surfaces the problem as an inhibitor with a
remediation hint and lets the administrator decide, rather than editing
network configuration on their behalf. Deciding whether an interface should
be handed to NetworkManager is not ours to make silently, and an
auto-rename that guessed wrong would cause exactly the outage it is meant
to prevent.
Consequences of reporting rather than mutating, both deliberate:
* Provenance no longer matters. An earlier revision keyed on RPM
ownership plus a machine-generation marker comment, because it had to
be sure a file was machine-written before renaming it. Nothing is
modified now, so any wildcard override is flagged regardless of who
wrote it - a hand-written one strands the host just as effectively.
That removes the heuristic entirely.
* A false positive is an annoyance requiring a waiver, not a broken host.
Only the wildcard form is matched. Targeted values (`=mac:...`,
`=interface-name:eth1`) exclude named devices, and deciding whether the
excluded one carries the host's connectivity is not something this check
can do reliably.
Gated on target major version >= 9. This repository is shared by the 7->8
and 8->9 upgrade paths, and on CloudLinux 8 network-scripts is still
present, so inhibiting a 7->8 upgrade over this would be a false positive.
Verified on a USERLAND-AUTO CL8 nopanel guest (template 6663) whose
one-context-written override is the real-world case:
Inhibitors: 2 -> `leapp preupgrade` exits 1
INHIBITOR: NetworkManager is configured not to manage any device
severity: high
Files with the problematic configuration:
- /etc/NetworkManager/conf.d/50-unmanaged-devices.conf
and with the file removed the report disappears, leaving only the
unrelated sshd inhibitor. 17 unit tests pass on that guest under the real
leapp framework.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
azheregelya
approved these changes
Jul 31, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A keyfile under
/etc/NetworkManager/conf.dsettingunmanaged-devices=*is survivable while network-scripts is installed: the legacy network.service brings the interfaces up instead.CloudLinux 9 drops network-scripts entirely, so the same configuration leaves the upgraded host with no network at all - so no SSH, only something like VNC setup still accessible.
Upstream
checkifcfgactor covers the equivalent NM_CONTROLLED=no setting in ifcfg files and inhibits on it, but it never looks at conf.d, so this class of configuration reaches the reboot completely unreported.CheckNetworkManagerUnmanaged (ChecksPhase) closes that gap the same way upstream handles its half: it surfaces the problem as an inhibitor.
Only the wildcard form is matched. Targeted values (
=mac:...,=interface-name:eth1) exclude named devices, and deciding whether the excluded one carries the host's connectivity is not something this check can do reliably.Gated on target major version >= 9. On CloudLinux 8 network-scripts is still present, so inhibiting a 7->8 upgrade over this would be a false positive.