Does this script not support running on a remote Centos8.4 server? I.e. a Google Cloud VM?
Lost all network connectivity after upgrades to NetworkManager package(s) started.
Sorry to hear you had problems with migrate2rocky.sh.
Checking with folks in Mattermost (chat.rockylinux.org). Hopefully we’ll have somebody back here to answer soon.
I’ve tested it extensively via a normal VM with a ssh connection and I didn’t loose network connectivity during the migration.
Can you provide a copy of the migrate2rocky.log file?
Unfortunately I have deleted that VM and stood up a new VM in it’s place with Rocky 8.4 as the OS (now available in the google VM offers). I was not very far along with the replacement Centos server and felt it would be easier to press ahead with Rocky. Sorry, I did not think about looking for the log and all I can say is that the migrate process stopped after the Network Management package was installed. I did have a static IP address configured and shorewall firewall activated in the Centos installation along with ssh and apache installed and running.
I used the migration script to migrate my remote vpses hosted on a physical system in a datacenter and the ssh connection didn’t cut off it stayed active the whole time on both of my vpses.
FYI Rocky maintainers - it looks like I lost network connectivity again after a dnf update. I lost all connectivity with my vm. Right after these packages were updated:
Running scriptlet: firewalld-0.8.2-6.el8.noarch 54/101
Cleanup : firewalld-0.8.2-6.el8.noarch 54/101
Running scriptlet: firewalld-0.8.2-6.el8.noarch
I’m running Rocky 8.4 on a google cloud Virtual Machine (vm) and for my firewall I use shorewall and ssh for connectivity. After about minutes I used the Google Web interface to stop the vm and thankfully after starting it back up I was able to regain connectivity. But I was worried for a few minutes!
This sounds like you have both shorewall and firewalld active and when firewalld gets updated somehow it resets the firewall rules which causes your connections to get dropped until shorewall, in turn, gets reset. The solution is likely to make sure that firewalld is disabled with:
systemctl stop firewalld
systemctl disable firewalld
…which should prevent firewalld from attempting to interfere with the firewall.