I recently installed Rocky Linux 9.4. When I run dnf search openjdk I ends in this failure:
Error: Failed to download metadata for repo ‘appstream’: Cannot prepare internal mirrorlist: Curl error (6): Couldn’t resolve host name for http[colon]//mirrorlist[dot]centos[dot]org/?release=9-stream&arch=x86_64&repo=AppStream&infra=stock [Could not resolve host: mirrorlist.centos.org]
I was surprised to see the centos.org reference. Is that to be expected?
This was a fresh install, however, the last step I did was restore files via tar from centos 8 stream previously on this host. I used the ‘k’ option of tar to prevent overwrite of existing files. Now I’m worried I may have inadvertently place old centos configuration on the system.
No. You’ve added repo files from CentOS. The repo files in Rocky Linux 9 are much different from CentOS 8, so using k with tar wouldn’t have helped here. Go through /etc/yum.repos.d and remove any CentOS repo file you have, and you should be fine to run dnf again.
Hi nazunalika & gerry. Thanks for the response. This has confirmed my fear. I’m going to set aside next Saturday to reinstall then be much more careful during the restore step. It will be good too because I’ll have another opportunity to run through the cups and nfs setup. One of the problems with reliable software is one tends to forget items involved in setup one did a few years back. With kind regards, -Randy
One can use “rpm -qf filename” to check which package did provide that filename.
The rpm will say, e.g. file /etc/yum.repos.d/cuda-rhel9.repo is not owned by any package and I would know that cuda-rhel9.repo is my doing. Alas, the installer does create some files too, so some “not owned” files are actually intentional and vital for the system to to function.
Restore from tarball does belong to the category of “source installs”, which one should avoid as they are likely to turn into unmanageable.
There are now configuration management systems. Examples: Ansible, Chef, Puppet.
The Ansible is included in Rocky – package ansible-core – and there is package rhel-system-roles too. The latter is documented by Red Hat in (public) RHEL docs.
Why do I mention these? (They do need some initial investment, like every tool.) Lets say I want port 443/tcp open on firewall. I could have “Ansible playbook” that says so, and Ansible would figure out how to create the actual config in Rocky 9, CentOS 7, etc. Furthermore, this plain text (YAML, actually) play would be easy to backup and redeploy. (In fact, the “cuda-rhel9.repo” I had written with Ansible.) Now I don’t have to remember what I have modified in my machine. I just have to figure out what my plays write to the machine(s). (And check git for earlier versions.) When I first heard about Ansible, a play was described as “complex” – a clear “Hold my beer!” moment.
Thanks for your post – lots of good info there. This thread reminds me one cannot be good at everything! Experience matters!
In real life I’m software engineer. At home though my wife and daughters expect services, such as print, and nfs-backup, to just work. It was at end end of a long day of getting Rocky Linux 9.4 installed and working, I was mentally tired, but knew I wanted to get back various files, especially those under /home, so off I went, with the tar restore, somehow not really thinking through the consequences :-(.
In my work life we use Red Hat Enterprise GNU/Linux 7 (now moving to 8), so while my main at home machine is System 76 running Pop!_Os, I do want one of my machine to be RHEG/L like – hence CentOS – now Rocky Linux (kudos to all the folks that make RL available!). At work our sys-admins have been rolling out Chef. Alas, several packages we rely on were rpm -e’d off the system!
Those have user data and do indeed need to be transferred/restored somehow. That part of tar was perfectly sensible. It has only two possible gotchas:
Uid/gid/usernames/groups are not in /home but are referred to by those files. Hence, creating accounts to match the data is a thing
I have seen user (DE, application, etc) config to act odd. New DE/whatever did use old settings with unexpected results. (Personally, I had Zoom misbehave …). Even the default ~/.bash_profile, ~/.bashrc on Rocky 9 do differ from el8. Merging old customizations … at least one can use ~/.bashrc.d/ in Rocky 9 for “easing the future”
I did think of the UID issue and make sure to pick the correct UID/GUID during account and group creation. I’ll keep an eye out during the reinstall for /home items like the bash profile/run config. Fortunately I run this system as a server and am the only one to login to it.