The Good News: On this Friday the 13th I decided to skydive out out of CentOS 8.4 and into Rocky Linux 8.4. After checking, double checking and triple checking EVERYTHING, I ran ./migrate2rocky -r early this morning. Everything went smooth as silk… until I reached the very end and it ran into conflicting packages. I thought I was TOAST but a helpful idea was presented: I simply ran dnf update --allowerasing and just like magic the conflicts were resolved. Some packages said Rocky Linux but I was not so sure, so I ran hostnamectl and it said that I was now indeed running Rocky Linux 8.4 Green Obsidian. So I shutdown the machine and rebooted it. Having confirmed every which way I could, I was indeed running Rocky Linux 8.4, I was perplexed when the menu popped up and read CentOS 8.4, though when it popped up I was indeed still in Rocky Linux 8.4
So CentOS 8.4 is on the Menu, but not Rocky Linux. Any idea how to fix this problem?
I assume the migration script does not rewrite this. Once new kernel updates from Rocky Linux are installed, those should identify themselves as “Rocky Linux” in GRUB.
What happened is the dnf distro-sync stage of migrate2rocky failed for you, and you ran dnf update instead (which worked). dnf update will not replace (or in the case of the kernel install) RockyLinux packages if they are not a newer version than what is available in CentOS.
You can run dnf --allowerasing distro-sync to get the Rocky Linux kernel and replace other CentOS packages that are still on your system.
For a moment I might have save myself a whole lot of trouble with a capital T. I ran the command
dnf update --allowerasing distro-sync
and it came back and said, “All packages up to date. Nothing to do.” Then for a lark I ran the command
dnf --allowerasing distro-sync
and then then all hell broke loose! At first it said:
Install 2 Packages
Downgrade 88 Packages
“Ok” I thought and hit “Y”
What happened next was Trick or Treat Madness. After saying “Y” it said:
Downloading Packages
(# / 1852)
The last time I did this years ago it said something strange large number which I thought I thought it was REPLACING, instead it ERASED my entire HDD. I learned my lesson. It got up to Package (16 / 1852) before I was able to kill the Downloads.
I was interested in this command as every time I update I have duplicate repros, and I still don’t know if I have holdover CentOS 8.4 packages or not. I thought I had converted everything. I thought before proceeding I better check in with you guys before I end up doing something STUPID that erases my drive and leaves me with a disabled machine.
Is the command:
dnf update --allowerasing distro-sync
– or is it –
dnf --allowerasing distro-sync ?
I have either A) a lot of CentOS 8.4 packages that still need to need to be updated to the corresponding Rocky Linux 8.4 packages or B) I just saved myself a whole lot of work. There is a vast difference between 88 packages and 1852 packages
Any advice you can provide me would be appreciated. Will the " – allowerasing simply erase my entire NVMe drive which holds Rocky Linux 8.4, or will it replace the current packages with updated Rocky Linux 8.4 packages?
Your first command (#1), update, has argument ‘distro-sync’. The command updates package named “distro-sync”.
Your second command (#2), distro-sync has no arguments. Since no package is given, all installed packages are considered. Look up the description of distro-sync from man dnf
Thank you for the explanation. It makes logical sense. I looked up the man pages for dnf and decided to go with a “SAFE” – I HOPE – option and am currently running the command:
dnf distro-sync
that is minus the “allowerasing”. I am terrified that “allowerasing” might wipe out my entire NVMe drive that contains Rocky Linux 8.4. Would you have gone with
dnf --allowerasing distro-sync ??
Yeah I still remember my lesson from years ago, and “–allowerasing” of 1852 packages sounds like a very BAD idea.
From CentOS Linux I’ve acquired a mantra: “never migrate; always fresh install”.
In essence, always be able to install fresh and restore (from backups).
With a easy routine for that at hand I can freely experiment without fear.
The command will display a summary of what it will do before it does it (and you can bail by answering “N”). You said further back that it will upgrade two packages and downgrade 88, but it mentioned nothing about removing any?
It is normal for a large number of packages to get downgraded, they actually are not downgraded by rather replaced by packages with the same version but other following artifacts (dist id, or module build information) which makes dnf think that they’re being downgraded. It is safe to allow dnf to “downgrade” these.
You don’t see very many packages that it will upgrade because those were already taken care of when you previously ran dnf --allowerasing update.
So in summary, just look at the list of stuff it will do before you answer “y”. If it doesn’t say there that it’s going to remove packages then it won’t.
I am still in the process of configuring “ocelot”, and need to move one large file off of the 2TB HDD, so as of this posting nothing is backed up, so I need to be super cautious rather than fly by the seat of my pants. “allowerasing” has a terrifying vision. when it talks about 1852 packages not 88. I seemed to “fixed” the problem by running “dnf distro-sync” to bring any packages that were not already marked as Rocky Linux packages, but were still leftover CentOS 8.4 packages now into sync. Maybe once I have the 2TB drive setup for backup I might revisit the “allowerasing” command. I still don’t get how it said 88 and 2 and then comes up and says 1852. BTW I did run “dnf distro-sync” – minus the --allowerasing – and held by breath but the command worked flawlessly. At completion I rebooted and up came Rocky.
I think you’re confusing 1852 steps with 1852 packages. 1852 does sound like a lot, though. At the end of the day you do need to backup before you attempt this step (you should have backed up before attempting the migration to begin with).