Well the time has come to bite the bullet: I got CentOS 8.3 installed, updated the machine and rolled it over to 8.4, installed KDE and got that working, and finally added various packages to CentOS 8.4 that we need. With the exception of backing up the machine, ( CentOS 8.4) which will be the final step, is there a Step-by-Step guide or scripts to migrate CentOS 8.4 to Rocky Linux 8.4? BTW in case someone asks this is NOT the “CentOS Streams” version, but rather the Stable version. I know the migration path uses a migration script called migrate2rocky.sh but that is about all I know. I’ve scanned this website for actual instructions but didn’t find any – or maybe read right over them – quite possible. I will be migrating a FULLY functioning KDE CentOS 8.4, FULLY tricked out OS over to Rocky Linux, with the intent of NEVER looking back to CentOS. This is going to be a 1 Way => Trip. The Backup of CentOS 8.4 is just in case I Crash and Burn – I’ve done that on more than one occasion, and my Backup saved my bacon!! It was a pain to get CentOS 8.4 installed and don’t want to lose that work. With the exception of backing up CentOS 8.4 all I need is a guide or HOWTO to convert CentOS 8.4 to Rocky 8.4, then draw in a DEEP breath and scream “GERONIMO”.
Any help you all can provide would be GREATLY appreciated.
OK using the old stagecraft motto of “Measure twice and cut once”. Are you saying all I need to do is run the script, "./migrate2rocky.sh?!? do I need to append either or the -r or -V to the command? Do I have to first unmount the drive before I run the script or can I actually run the script while I am running CentOS 8.4, in much the same way as I do when rolling over the machine from one point release to another by simply running dnf update?
Just have the machine booted as normal, the script goes away changes the repos, removes CentOS specifics and installs the rocky equivalents. The only thing to be wary of is the Rocky Linux doesn’t support Secure Boot yet, so you will need to turn that off in your BIOS/VM configuration before the script will do the conversion (it will check and abort if it finds you’re running in Secure Boot mode).
Given that I don’t run Windows, I don’t run Secure Boot. No problem there. When you say, “Just have the machine booted as normal” I assume that to mean at the CLI I simply type ./migrate2rocky.sh. Should I append the “-r” option or not? If all I need to do is type that simple command at the CLI this will indeed a rather painless conversion. Today is the day I backup the drive and by Friday or Saturday, to convert the drive.
BTW a trivia question: I classically partitioned my drive. Will I lose my partitions??
Secure boot isn’t something that comes with Windows. It is a UEFI feature that only permits the loading of signed boot loaders / UEFI drivers. You may need to disable this feature in your UEFI settings (press F2 or ESC or whatever during boot to get to these).
I probably still don’t have to worry about it – or at least that is my HOPE – as my setup is running in straight LEGACY mode, and UEFI – as I understand it – is needed only if you are running Windows. Now IF UEFI – even though I am not using it – still needs to be disabled – that is going to present a whole other level of complexity as my motherboard is an ASUS Prime X570 Pro. The BIOS of it is quite intimidating as it is, to actually have to go rooting around to see if UEFI is enabled or not. If you are familiar with the Modern ASUS BIOS then you know what I am talking about. That said there is something that pops up in the BOOT Priority Menu that says UEFI ( think it deals with Manjaro but that does not work). I ignore it and select the NVMe 4.0 drive that holds my CentOS 8.4 OS and nothing else which is set up as a LEGACY drive. The /boot partition is set up as /boot/grub2; not /boot/uefi/grub2. (…and use the grub2-mkconfig -o /boot/grub2/grub.cfg, and not the one for UEFI ). AFAIK I should be SAFE since I am not using anything that would be affected by UEFI… UNLESS of course this looks at the actual BIOS itself, in which case I have a long process of trying to find where to totally disable UEFI in BIOS. I think in its current form it is set in binary form ie LEGACY or UEFI for people who are running dual boot system, one of which is Windows which requires both Secure Boot and UEFI be turned on.
Progress is progressing: even as we speak I am backing up the NVMe 4.0 drive that holds the CentOS 8.4 OS. Thank you too for setting my mind at rest as last night – maybe migraine induced – I got the notion that the conversion might wipe out all my classical partition allocations. There was a lot of work spent configuring 8.3 ==> 8.4 adding and testing the various programs we use., etc. NOT to back the drive up first. The life of being an “Official Test Guinea Pig”!!
Assuming the UEFI thing does not force me to go rooting around in BIOS to find where it is that I need to first DISABLE it, I am still on schedule to do the conversion somewhere between Friday and Saturday.
Just to be absolutely sure: I run ./migrate2rocky -r as root from within a konsole in CentOS 8.4 while CentOS 8.4 is running?!? If so it should not come as too great a shock, as I have sort of done the exact same thing every time I have rolled over CentOS from one point release to another by issuing the command dnf update. This is just a wee bit different in that I am converting one OS to another OS, and I had better get it right the first time around!!
Again Brian, Thank You for your help, as it is greatly appreciated.
@desercat No, UEFI is not just for Windows. Fedora uses UEFI and this is definitely not Windows. It also installs on a system with secure boot enabled. Legacy boot, is when a system would use the MBR, so you would not have a /boot/efi directory on that kind of system. When UEFI is enabled, instead of using the MBR it uses /boot/efi instead. My Linux Mint install has secure boot disabled, because the NVIDIA drivers wouldn’t work. For Windows, it also uses a partition on the disk for UEFI, that is why Windows now generally has at least 2/3 partitions once it’s installed than compared to legacy installs or older Windows installs using the MBR.
Don’t panic about the SecureBoot stuff, the migration script checks for it being turned on and will stop running the migration before anything is changed and tell you if you have it enabled (that’s how I caught it the first time!), so you won’t hose anything.
Ah!!! [Sigh of relief]. Nice to know that where I’m heading someone else has gone before. CentOS 8.4 is now fully backed up. So sometime either tomorrow or Saturday I jump!! I now also have an idea where to look if it stops in its tracks. I am just hoping I will have no issues and all goes smoothly.
Thank you for the input. I am 99% sure I am fine, but not 100% sure. I am “Old School” in that I use a “Classic Partitioning” Scheme where you specify each partition and its size, rather than allowing the computer to automatically decide what’s best. In all cases the first partition I create is /boot not /boot/efi. That said I went prowling around and under the directory /boot there is a sub directory called /efi and a sub sub directory called EFI under which you find a sub sub sub directory called centos, all those sub directories are EMPTY.
Just for fun I have this nifty little utility called inxi that gives you all the information you could ever want about your computer. Inxi with the -D option tells you everything you might ever want to know about your drives. Under /dev/nvme0n1 – my NVMe 4.0 drive – which is dedicated to, and holds ONLY my CentOS 8.4 OS, under “Scheme” it says “MBR”.
In THEORY I should be good to go… UNLESS this goes as the BIOS level, but in THEORY I should have no problem when I go to the conversion . Fingers crossed.
Yesterday morning on Friday the 13th I decided I would take the plunge and do the conversion. Having checked, double checked, and triple checked everything I issued the command ./migrate2rocky -r . The conversion was sooth as silk… until the very end when I got a whole lot of errors. Most of of the errors had to do with conflicting dependencies. I was preparing to break out my CentOS 8.4 backup when I noticed a suggested command “–allowerasing” . Having used this command once before I ran the command dnf update --allowerasing. It wanted to erase 90 dependencies and 2 packages!! I said NO!!! I then scrolled up and discovered that what it wanted to erased were 90 unused and/or not needed dependencies and 2 packages. This time I said YES, and it promptly erased it all. and finished the conversion. I ran I ran hostnamectl, confirmed that I was indeed running Rocky Linux 8.4. As a check I also manually prowled the outback of /etc. Yep I was running Rocky Linux 8.4 . The ONLY problem that still remains is after I rebooted the machine the MENU still says CentOS 8.4 but it comes up in Rocky Linux 8.4. Does anyone know how to fix the Menu to read Rocky Linux 8.4??
Two final notes: It seems I am not the only one with the problem of suddenly getting notices of conflicting dependencies and packages, as posters over in CentOS 8 are reporting them too.
The final note is something I have just started noticing. Every time I update the machine IO get something like the following:
dnf check-update
Last metadata expiration check: 1:03:31 ago on Fri 13 Aug 2021 04:01:43 PM EDT.
It might have always been there and I failed to notice it. But this time it seems very prominent … as “In-Your-Face” prominent. When did this start? Might this be the reason I got all these sudden Error dependencies and packages notices? I run a Clean Machine and the only time I get such Error notices is just before a transition to the next point release. Then I use yum/dnf update --exclude [package] the longer the --exclude line grows is a sure sign that the next point release is on the way. That does not seem to be the case here. These dependency problems are of recent vintage.
I will assume it is the grub2 menu, but which one is a better question. I am testing 5 different linux distros on 6 different drives (1 NVMe 4.0; 2 2.5" SSDs, and 3 HDD’s ). and some of the distros are duplicates, but on different drives. Each with all the same distros, but in different jumbled order I am almost terrified that some there maybe crosslinked files. The ONLY drive that I know for sure is CLEAN is the NVMe 4.0 on which I have Rocky Linux 8.4 “just converted” before that it was CentOS 8.4 of which I had two copies. I suspect part of the problem is located in BIOS and which of the various drives it chooses as the DEFAULT. Usually the LAST used OS’s Menu becomes the the DEFAULT for the next time. Last night I proceeded to DELETE and the other copy of Rocky Linux and scrub it clean and managed to do it without accidentally DELETING my newly converted Rocky Linux 8.4 v2.
I thought about running grub2-mkconfig -o /boot/grub2/grub.cfg but now that you mention it if I run the grub config command, then Rocky Linux 8.2 v2’s menu should become the MASTER MENU – so that as I narrow down the number of drives and OS’s the entries will become fewer and fewer, and any duplicate OS’s will disappear – openSUSE 15.3 Leap should be the last of the duplicates.
Thanks for helping me to unscramble my brains. I’ll keep you posted. Worst comes to worst I nuke the system, but that is why I made SURE my backup is CLEAN.
Well I ran grub2-mkconfig -o /boot/grub2/grub.cfg rebooted and everything still said CentOS 8.4. The good news is that it dumped OS’s that had long never worked or had been deleted. So now I am down to CentOS 8.4 / Rocky Linux 8.4 and two copies of openSUSE 15.3.
My next stop was to go to openSUSE and run grub2-mkconfig -o /boot/grub2/grub.cfg over there, and rebooted the machine. That worked as the first items there were SUSE 15.3, followed by Rocky Linux 8.4 AND CentOS 8.4 and referenced the nvme0n1 drive for both. I then started to prowl everything from /boot/grub2/grub.cfg to /etc/default/grub and /etc/grub.d.
Next I ran my nifty GoTo utility Grub-Customizer. in Rocky, the only thing in the menu is stuff pointing to openSUSE but ZERO to either CentOS or Rocky. Yet when I went over to SUSE and ran Grub-Customizer I got the SUSE start up menu. When I clicked on Rocky that triggered end string of of verbose messages, that ran by so fast it was hard to see there were startup errors, but Rocky did come up. When I boot from Rocky there are no messages.
A few minutes ago I MAY have found the answer as to WHY the menu reads CentOS, and hints at a possible solution: Under /boot there is a Sub Directory called /loader. When checking against my CentOS 7.9 OS, /loader is absent. Opening /loader there is Sub-Sub Directory called /entries opening /entries there appear to be 3 kernels plus a “rescue” and the files all in “.conf”. Opening the files to read them:
The first line says Title: CentOS (kernel number) 8,
The second line says Version: (kernel number)
The third line says Linux: /vmlinuz-(kernel number)
The fourth line says: Initrd: /initramfs-(kernel number)
The fifth line says Options
The sixth line says id: centos-(long number) (kernel number)
The SOLUTION has got to involve the /boot/loader/entries files.
RHEL 7 does not use/support BLS. RHEL 8 does and has BLS as default.
Without BLS menuentry for each kernel is in grub.cfg and the file has to be edited when kernels are installed/removed.
With BLS each kernel has its own file and the grub.cfg has only a call to BLS.
Another “menu” that can have bogus entries is the EFI.
It probably would have entry for CentOS that loads /boot/efi/EFI/centos/shim.efi (or whatever).
You have grub.cfg in /boot/grub2 which means that you have machine in legacy mode.
[sarcasm on] GREAT! [/sarcasm off] Thank you so very much jlehtone for the link. Seriously!! It was a great resource. It should be included in every hacker’s tool box. It explains so very much between CentOS 7.x and CentOS 8.4 / Rocky Linux 8.4. I had just gotten the hang of grub2 vis-a-vis in CentOS 7.x, now I have to figure out this new creature in CentOS 8.4 / Rocky Linux 8.4 . And YES I do use Legacy mode. Does grub2-mkconfig -o /boot/grub2/grub.cfg ? still work with this new beast?
Well it is off for more experimentation. Again, Thank You for the link.
You can mark this [SOLVED ???] Using the information that jlehtone provided Boot Loader Specification I went into /boot/loader/entries and edited all the .conf files and changed all the entries that said CentOS 8 and to read Rocky Linux 8.4 and also changed the one line in each file that said centos to read rocky, then saved each file, and for good measure ran grub2-mkconfig -o /boot/grub2/grub.cfg, then rebooted. Now the menu comes up what once showed CentOS now shows ONLY Rocky Linux 8.4. While during the grub2-mkconfig -o /boot/grub2/grub.cfg process openSUSE 15.3 is found and referenced as being in /dev/sdb2, it does not show up in the Rocky Linux 8.4 Menu… which is kind of odd. But I’ll take my victories where I can find them. At least for the time being the menu now correctly reads that the OS as being Rocky Linux 8.4, NOT CentOS 8. The REALLY BIG question is will the menu hold together when Rocky Linux releases its NEXT kernel, and will the Menu be subsequently updated. That’s the million dollar question!!
EFI boot is not the same as secure boot. EFI boot is supported by RockyLinux and migrate2rocky, SecureBoot currently is not. SecureBoot does require EFI boot but the opposite is not true. Do note that EFI is required for newer larger hard disk drives (MBR is limited to disks no larger than 2TB). As you have noted you are using MBR boot, which is fine, but it pays to correct when people assume that EFI is the same thing as SecureBoot, it is not.
It was not necessary to edit boot loader entries. The old CentOS kernel will eventually fall off of the list, and the RockyLinux kernel should be the default. Editing the list to change the name of the CentOS kernel to RockyLinux doesn’t actually change it to a RockyLinux kernel, if you select that entry at boot time you are still booting to the CentOS kernel, you just happened to rename it to it says it’s a RockyLinux one. See this entry in the README for migrate2rocky.
. And YES I do use Legacy mode. Does