Hey, Thanks for reading, i hope you can share your know-how.
When working on VLAN configurations i swithed to launching nm-connetion-editor from bash … at one point nm-c-e exited and on relaunch showed just the template of the window, no content.
At that point i also noticed NetworkManager was no longer functioning. At that point i started testing various things to only arrive at noticing again and again NetworkManager segfault when the main interface is activated. This was not so before, it is unclear what happens or why or how to analyse it.
In the meantime i’ve upgraded to Rocky Linux 9 in the hope this would remediate these shennanigans to no avail. The problem persists and notable is also the upgrade did not go well. That’s another issue.
People who’d like to work on analysing this issue are welcome. I have a core-dump but not much experience analysing them.
If the Rocky Linux infrastructure is online to receive core-dumps i’d consider uploading it.
Upgrades are not supported purely for that reason. Recommended is clean install your new Rocky 9 and restore your data or at least ensure the /home or whatever partitions that have data are not formatted when installing the new version.
A likely explanation is that the initial error corrupted configuration in a manner that NetworkManager fails to parse. One should remove the problematic configuration files.
sudo journalctl -u NetworkManager should show the messages that the service did give when it did (try to) start. Hopefully errors that point to culprit.
People do attempt “upgrades” from one distro (e.g. Rocky 8) to different distro (e.g. Rocky 9) because they wish to keep data and config, rather than adapt and restore. Keeping broken config does not help. Besides, NetworkManager in el9 defaults to new config format, although it should still be able to read the legacy format (as good as el8 did …)
@iwalker Thanks, in all i just have one issue after the upgrade. EL8 Package are reported with requirements/dependencies which are not found, this does not go away since because the package does not exist it cannot be removed trough rpm/dnf.
Other problems reported related to modules, this I’ve partially remediated through ‘dnf module reset …’
… eventually i had to install RL9 from scratch, i was unable to rpm/dnf may way out of it due to circular dependencies
@jlehtone thanks, i’ve used Debian for many years and rarely had issues upgrading when done procedurally, problem is i find no meaningful indication of what error is at play or where it is originating from
I don’t know how Debian implements upgrades. With RHEL Red Hat basically creates a distinct “fork” for each major version and keeps each major version essentially unchanged its entire lifespan (10+ years). Major versions are thus distinct and there tend to be drastic changes from one to an another (although el8 and el9 are separated by “only” three years). There is at least openssl-1.1.1* to openssl-3 hop in el8->el9 that affects several packages; nothing is “gradual” about that.
yeah, that’s why for someone coming from Debian the Red Hat ecosystem can be confusing … there are no trackable version increments, just backports of patches to a version. Explained poorly but that’s about the gist of the confusion.
In that, seeing RL9 break dependency for KeepassXC because the dependency is set as = is a bit awkward. Someone responded to this that’s not break “in the future” but that seems quite illogical since dependencies break “back in time” far more often than “forward in time”
either way, still learning more about the Red Hat/Rock Linux ecosystem