Converting CentOS to Oracle Linux with centos2ol script tutorial

Version 1.5 (corresponds to version 1.5 of centos2ol_wrapper )

Copyright 2019-2021 by Professor Nikolai Bezroukov. This is a part of unpublished lectures for the Linux administration class.

• Introduction
• Suggestions for enhancing the centos2ol script and  centos2ol_wrapper script
• The level of your preparedness and the quality of the backup decide the results of the conversion
• In case you plan mass conversion of servers, you need to study and possibly adapt the script to your need
  • Important notes and recommendations
  • Relevant Oracle recommendations
  • If you are behind proxy
  • Python 2 can be missing  in CentOS8

Introduction

Oracle provides an opportunity for CentOS users to convert their servers to Oracle linux and use it in the same terms as CentOS.  Unlike the situation of RHEL vs. CentOS there is no difference between licensed Oracle Linux and CentOS-style "free as in beer" Oracle linux and you can freely switch back and force.

Oracle Linux is (and always was) higher quality Red Hat clone then CentOS. In a way it is "CentOS done right." There is nothing to fear when switching to it from CentOS as long the Oracle adhere to its current (Ubuntu style) policy -- the OS and patches are free, the support is payable. And they consistently supported this policy for many years. Oracle UEK kernel can  work with DTrace (originated in Solaris) and that provides tremendous advantage in troubleshooting  complex situations and optimization of applications for senior system administrators. 

The conversion script called centos2ol is downloadable from GitHub using this link: oracle-centos2ol ).  The script is short ( 565 lines as of December 2020 version) and mostly self-documenting: it does not take long for any qualified sysadmin or Bash programmer to figure out how conversion is performed and what are the major steps in this process.  It works both for CentOS and RHEL version 8, 7 and 6 with  the main  area of application being  6 and 8 as support of CentOs7 was unchanged and will last till June 2024.  Especially interesting is this switch for CentOS6 as Oracle supports it longer than Red Hat -- till march  2021 (only servers with  Premium support, generally need the extended support)

ISOs are downloadable from Oracle Linux Downloads

Of cause, like is the case with any complex "surgical operation" on the  current OS you need to make full bare-metal backup before you start. You need to pay adequate attention to this part of the project. Please understand that if script ends prematurely due to errors encountered (especially due to lack of space in /boot partition or errors in RPM database) , you system will be in some "half-baked" state and not always rebootable.

In worst case the server after the conversion will be unbootable and you better be prepared to this situation  and know what to do. I would suggest Relax-and-Recover on RHEL as it provides recovery ISO with networking preconfigured and the access to NFS shares, which I would recommend for the backup. If the server size is small FIT USB drive is also an option for storing the backup image. Please note that most server have just USB 2.0 interface so USB2.0 drives are OK. The max size of FIT drives as of December 2020 was 512GB. See, for example,

• PNY 512GB Elite-X Fit USB 3.1 Flash Drive
• SanDisk 512GB Ultra Fit USB 3.1 Flash Drive

But if you store tar archive on NFS (I would recommend this solution) and store just a boot image on USB,  then 16GB drive is more then enough (10 pack costs $45 on Amazon)

The script code leaves mixed impression. On one hand bash arrays are used, which is a sign of professionalism. On the other hand, the script overuses single bracket conditionals.

There are some sad omissions in  error checking and general lack of "sanity" tests. For example, the script should check for space in /boot  and /var directories as a part of sanity checks. Also it does not checks at the beginning if Oracle repos are already present.   I would like to stress it again, that if  the script fails in advanced stages of conversion you inherit a half-converted system, repairing which more often then not requires senior sysadmin level of qualification, especially the knowledge of yum.  The same is true for the presence of extra repositories in /etc/yum.repos.d They are an invitation to the disaster on the stage of installation of packages (the most important stage) and need to be eliminated beforehand.

The script does not recognize if it was invoked the first time or the second time after the error. God forbid to run it after it bolted, for example on insufficient /boot space. It will destroy your OS erasing multiple vital RPMs (including sshd, crond -- over hundred RPM suffer from this "mass extinction" event ) And unless you know yum really well (yum log contains the names of deleted packaged which means that you can extract this list, delete obsolete firmware packages and re-install the rest),  you need to restore the server from the backup and start again.

ATTENTION:

To use the script your RPM database should not have any conflicts or dreadful  multilib problems, and preferably the box should be "updatable" via regular channels (it is not necessary that the box should be subscribed to Red Hat and your RPM database is in order; on a box with expired RHEL subscription you can also replace RHEL repos to CentOS repos just for the conversion)

If you need to convert multiple servers,  it makes sense to study the behaviour of the script in some VM boxes. You will see that the script is fragile and sometimes abruptly ends in the middle of the conversion process, leaving the box in some intermediate stage. And you need to learn how to continue the script form this stage, providing the values of necessary variables (which you can see from the trace -- unless the next server is identical to the previous, successfully converted server, the script should always be  run with the option  -x )  and  executing the remaining steps one by one with proper value of variables used.

Suggestions for enhancing the centos2ol script and  centos2ol_wrapper script

If you convert over a dozen servers you can benefit from simplifying the script limiting it to the version of CentOS you plan to convert. If for example you use exclusively to convert RHEL/CentOS6  or RHEL/CentOS8  server unnecessary branches can be removed making the script more transparent.

Here are some ideas about change you might wish to make. First of all the script suffer to acute lack of sanity checks. Most of those sanity checks can be written as a separate script (see, for example, my centos2ol_wrapper  script, which implemented server of the checks suggested below and additional steps designed to lessen the pain when your conversion fails ):

• One potentially useful addition is the check for the presence of  extra repositories in  /etc/yum.repos.d  and elimination of all but those that are CentOS related. This is simple to implement and can save people a lot of unnecessary troubles  (and you can always restore them from the backup later):

  Something like

  extra_repos=`ls /etc/yum.repos.d | grep -v CentOS | wc -l`
  if  (( extra_repos > 0 )); then 
    echo "Extra repos were found"
    ls /etc/yum.repos.d | grep -v CentOS
    echo "Eliminating extra repositories from /etc/yum.repo.d. Hopefully you have a backup: 
    cd /etc/yum.repos.d && ls /etc/yum.repos.d | grep -v CentOS | xargs /bin/rm 
    exit 255
  fi

• If /boot or /var are mount points,  you need to check free space in them programmatically. On some appliances /boot is 200MB or 500MB and may contain several updated kernels, so there is no space for the new one. This is pretty typical situation with regularly updated server running CentOS6 and CentOs7 as both of then has a long history of minor updates, each of which introduces an new version of the kernel  (ten for CentOS6, nine for CentOS7): 

  is_mounted=`mount | fgrep ' /boot type' | wc -l`
  if (( is_mounted > 0 )); then 
     free_space=`df -m | tail -1 | tr -s ' ' | cut -d ' ' -f 4`
     if (( free_space < 100 ));
        echo Insufficient amount of free space in boot partition: 
        df -h /boot
        exit 255
     fi
  fi

• Logs in this centos2ol.sh script are way too primitive. You can enhance them. A very simple  but useful change is to replace echo statements that signify the start of the next step in conversion with call to step_info function (the script has waterfall logic and consists of dozen or so steps with failure on each mostly being fatal.)  For example (implementation taken from centos2ol_wrapper):

  function step_info
  {
     echo
     echo
     echo "============================================================================"
     echo "*** LINE $1, STEP: $2"
     echo "============================================================================"
     sleep 3
  }

  Replacement should affect mostly echo statements that start from the first column, and there are not that many of them:

  [0]  # egrep '^echo' centos2ol.sh
  centos2ol.sh:echo "Checking for required packages..."
  centos2ol.sh:echo "Checking your distribution..."
  centos2ol.sh:echo "Checking for yum lock..."
  centos2ol.sh:echo "Checking for required python packages..."
  centos2ol.sh:echo "Finding your repository directory..."
  centos2ol.sh:echo "Learning which repositories are enabled..."
  centos2ol.sh:echo -e "Repositories enabled before update include:\n${enabled_repos}"
  centos2ol.sh:echo "Looking for yumdownloader..."
  centos2ol.sh:echo "Backing up and removing old repository files..."
  centos2ol.sh:echo "Downloading Oracle Linux release package..."
  centos2ol.sh:echo "Switching old release package with Oracle Linux..."
  centos2ol.sh:echo "Installing base packages for Oracle Linux..."
  centos2ol.sh:echo "Switch successful. Syncing with Oracle Linux repositories."
  centos2ol.sh:echo "Sync successful. Switching default kernel to the UEK."
  centos2ol.sh:echo "Removing yum cache"
  centos2ol.sh:echo "Switch complete. Oracle recommends rebooting this system."

• The third, slightly more complex modification is introduce the ability to skip steps providing the staring step as a parameter. You need also introduce a dump of key variables after each step to ensure proper restart form a particular step and then sourcing them if you start not from the first step.  There are very few global variables in the script

The level of your preparedness and the quality of the backup decide the results of the conversion

It goes without saying that unless you have a reliable backup you are playing with fire, even if you have enough qualification to repair problems with yum.  All thinks  equal. you knowledge of yum and boot process are two decisive factors. Good understanding of "what is what" in /boot and the ability to manually edit grub menu are essential.

Trivial mistakes like lack of space often lead to non-trivial problems. Problems with RPM database, inaccessible repositories or lack of space in /boot or /var automatically lead to failure.

The most nasty situation arise when you run the script second time after the error in a hope that it can continue (for example if you have inaccessible repo left or no space in /boot). At this point you can hit a nasty bug in the script in the function remove_repos, because in their excessive zeal to resore the system after error  the programmers did not understand that in certain situations those packages that they want to delete via YUM have dependences  and a lot of them  (line 65 in the current version of the script)

yum remove -y "${new_releases[@]}"

At this point the horror show with deletion of 300+ RPM packages starts(368 in my experiment). The list includes  dracut (making the system unbootable), sshd, cron and many other vital packages. This situation can be easily modeled on a test box by leaving less that 17MB of space in /boot and rerunning the script after the failure. 

It is an interesting test of sysadmin abilities and probably only senior sysadmins can make the system bootable again. If you want you can prepare yourself  on a test box but it is better to avoid this situation and block execution of the script is oracle repos are present (like was done in my wrapper script mentioned above).  It also makes sense to comment out this yum remove -y line as it does in this situation no good at all.  Even the idea to restore repositories is questionable as at this point your system in semi-baked state this change does not do you any good. In most case people want to continue, not to return to the initial stage. So all this procedure can be replace with a dummy.  

The next situation you need to learn is dreadful "multilib" problem in RPM database (or any other problem that course yum fail during the update. )

bash -x centos2ol.sh 2>&1 | tee /root/cenos2ol.$HOSTNAME.log

Generally before you touch any production boxes, you need run it on a at least half dozen test boxes to understand how it works and, especially,  how to recover from the situation when it breaks in the middle of operation. Please understand that in some situation. For example in the example above when you run the script the second time in a hope that it will continue from the right place your server can be "almost gone" (all depends on the level of your yum skills) and you might need to restore it from the backup.  

I used some servers that are about to be  decommissioned for experimentation with the script. They have a mixture of CentOS6 and CentOS7 in various stages of patching typical for large corporate datacenters ;-). Most were CentOS 6.8 with some CentOS6.9 and CentOs7.7.

Out of a dozen servers I semi-destroyed one by running the script again after the failure (it hanged on reboot). It was my second server and I did not yet get to speed with the script so this can be explained by my inexperience. But later I run into serious troubles in two other which I eventually managed to "save".  So my failure rate was around 25%. You  need to cut this rate at least in half as most problems were due to my inexperience and rush -- on some servers I did not perform all the necessary checks and check them. And those were one were I run into troubles. Which proper preparation and not very complex setups the script works very reliably. 

So in large production boxes conversion you probably can expect a single digit failure rate if you servers are not very uniform, which problem concentration on the most complex setup with non-standard drivers (IBM GPFS is one example) and complex hardware bound packages installed.  Or close to zero if the server are uniform like happens in HPC clusters.  Most my failure were due to the problems with RPM database, especially multilib version problem (Server Fault has several posts with advice on how to solve them, for example centos7 - Multilib version problems on CentOs 7), which often arise on servers with R language installed.

Without being able to solve typical situation, especially when the scripts fails on yum update (no space, errors in yum RPM database, etc) your system will be in "semi-converted", non-rebootable stage. All-in-all this script is a dangerous tool and a reliable bare metal backup (for example from  FIT USB drive)  is the only way that can reliably save you from SNAFU.  

In case you plan mass conversion of servers, you need to study and possibly adapt the script to your need

The whole conversion script is around  600 lines of Borne shell style programming, which starts from line 77.  If you convert only one  version of CentOS/RHEL to Oracle Linux you can simplify the script dramatically  by remove branches related to versions, you do not need. For example, for version 6  which is important for those who try to extent the life of RHEL6 servers, it can be cut in half as most operations are related to version 7 and 8. That makes variables dependences more transparent.  Also at lease one fragment is simply redundant and can be implemented in a separate script  -- the code related to option -r -- reinstall all packages belongs to this category.

Because the logic of script is a typical JCL style step by step execution in case of failure can imitate already executed steps by putting proper value into variables used in subsequent  steps (taken form from your trace), and deleting all already executed steps from the script  (there is only a dozen of such variables in the whole script.)   If case script exits with error the OS can be in some intermediate stage and you have no other options then try to "finish the job" -- attempt to reexecute the script after fixing a particular problem can be disastrous (see above). Some steps (for example, the instillation and activation of Oracle UEK kernel can be simply skipped, as in this case the last thing you want  is to try this kernel after the conversion  ;-).

While trace is generally enough to recover the value of the variable to execute subsequent steps, I would strongly recommend to  instrument the script with additional echo commands writing to the /tmp or other directories the current value of variables used at each step. This instrumentation will take an hour or two of your time but can save many hours if you run into troubles on production box.  You can create dump_vars function that accepts pairs of name of variable and ties value and dump them into a file.

Most of the echo commands that start from position 1 in this script signify the start of the particular step. those echo command can be replaced by the calls to the step_info function, as suggested above

The dump of the variables used in his step can be placed directly below.

WARNING: I would warn you not to use the option -r which reinstall all RPM to oracle making CentOS (or Red Hat ) repositories unnecessary. You should not risk running into problem at this stage and it is better done after the conversion as the code is completely independent should be better provided in a separate script.  You can emulate this functionality with a custom script quite easily, and execute it later. 

NOTE: After script runs, CentOS repositories are preserved as disabled and all updates will be coming from Oracle repos.

Troubleshooting

As I already mentioned several times, especially bad situation arise when due in desperation you decide to run the script the second time and at this point the script mistakenly removes a several hundred of the original RPMs without installing new. At this point ssh stop working although existing session survives and is the only "window" into the botched server.  Which is not a good situation, if the server is remote and has no or bad DRAC/ILO ;-) That's why backup using rear or similar bare metal backup/restore software is really important and it should be debugged, implemented and tested  (as in recovery of OS from non bootable stage)  before you even start.

In order to continue from the point of failure you need to know the values of some variables. The only way to get them current is executing the script as

bash -x centos2ol.sh 2>&1 | tee /root/cenos2ol.$HOSTNAME.log

bash -x centos2ol.sh 2>&1 | tee /root/cenos2ol.$HOSTNAME.log

After script ends you need carefully study grub/grub2  menu. It should contain two new entries, one with "Red Hat compatible kernel" and the other  with "Oracle Linux Server Unbreakable Enterprise Kernel"  Note that the script changes the first entry of the boot menu by  introducing  the directive default. Most of sysadmins never saw this directive before and might skip at first glance. You will be better off changing it to zero and reordering boot menu items in the editor inread.

At this point you need to decide which entry should be first and check if all relevant boot files for this entry are present. If you recovered from the failure of script somewhere in the middle and re-executed some steps manually it is safer to specify the same version of the kernel with which the server was booted previously ( vmlinuz-2.6.32-642.1.1.el6.x86_64 in the example below)

title Oracle Linux Server Red Hat Compatible Kernel (2.6.32-754.35.1.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-754.35.1.el6.x86_64 ro root=UUID=45323d56-fd44-4e02-bc82-149f6c0cc4d1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32-754.35.1.el6.x86_64.img
title Oracle Linux Server Red Hat Compatible Kernel (2.6.32-642.1.1.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-642.1.1.el6.x86_64 ro root=UUID=45323d56-fd44-4e02-bc82-149f6c0cc4d1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32-642.1.1.el6.x86_64.img
title Oracle Linux Server Unbreakable Enterprise Kernel (4.1.12-124.45.6.el6uek.x86_64)
root (hd0,0)
kernel /vmlinuz-4.1.12-124.45.6.el6uek.x86_64 ro root=UUID=45323d56-fd44-4e02-bc82-149f6c0cc4d1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-4.1.12-124.45.6.el6uek.x86_64.img
title CentOS (2.6.32-642.1.1.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-642.1.1.el6.x86_64 ro root=UUID=45323d56-fd44-4e02-bc82-149f6c0cc4d1 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
initrd /initramfs-2.6.32-642.1.1.el6.x86_64.img

Important notes and recommendations

Check for complex grub setups with failover to rear or similar advance things.  Also sometimes the selected kernel in not the first in the menu (look at the directives default and failover; The directive default specify which kernel will be booted, starting from zero ) .  Make it the first as this is what most sysadmin automatically expect in grub menu.

1. Before you begin the conversion you  need to uninstall any kernel from centosplus or elrepo or any other repo that isn't CentOS-Base. For example kernel for AMD Rizen CPU (Oracle does support this this CPU; see Issue #4 · oracle-centos2ol)
2. Never run this script without protecting  your session from disconnect via screen session  or something similar. Disconnect of ssh session in the middle of the conversion is the last thing you want and it often takes an hour to download all the packages involved if your system is not up to date.  I saw cases when over 700 packages were downloaded.
3. If possible, make your system the most recent version by running yum update before the conversion and verify that you RPM/YUM database does not have any issues like multilins, etc.
4. Install a FIT drive on the server and create a bootable recovery version of your system on it (for example via Relax-and-Recover command

   /usr/sbin/rear -v mkrescue

5. Backup your system using  on NFS or FIT USB drive using bare metal backup such as Relax-and-Recover. In case the resulting system becomes unbootable you will have an option to get back to square one.
6. Carefully check and remove extra repositories from you. Presence of extra repositories leads to difficult to correct errors.  The scripts can delete RPM that it did not install and at this point you need senior sysadmin skills to revive the system.
   • Always remove EPEL repo and other "non-standard" repos from yum before the upgrade. Otherwise you might experience big troubles in the middle of the script. It is very picky as for repositories present.
7. Ensure that your system has "clean" RPM/YUM database  with no multilib problems or similar YUM database warts.
8. It is better to run the script via bash -x  so see at what line it fail. That helps to determine how to proceed as in this case the system might be unbootable and gives you the values on important variables before failure. The latter allows to delete offending part and continue with the installation by putting those values directly into the script. This allows avoiding execution of steps that completed successfully.  And believe me, you will have cases when the script aborts somewhere in the middle.
9. If your system is not too old (let's say no more two dot versions from the current) you do not need to update the system before  the conversion as some bloggers recommend. 
10. The script works even in case your RHEL subscription expired.  And with completely CentOS boxes running CentOS6.8, which no longer can be updated from CentOS repositories.
11. Ensure that there is enough space not only in /var (at least 5GB is needed) but also in /boot. I encountered one system in which /boot was made very small (200MB)  and there were 6 previous versions of kernel present due to updates, so there was no space for oracle kernel to be put.  That means that I was forced manually execute the  remaining command (just four command at this point) to save the box:

    yum install kernel-2.6.32-754.35.1.el6.x86_64
    arch=$(uname -m)
    uek_path=$(find /boot -name "vmlinuz-*.el${os_version}uek.${arch}")
    echo $uek_path
    uek_path=/boot/vmlinuz-4.1.12-124.45.6.el6uek.x86_64
    find /boot
    grubby --set-default="${uek_path}"
    echo "Removing yum cache"
    rm -rf /var/cache/{yum,dnf}

12. You can run yum update command after the reboot to update more RPMs. You can also extract  and execute separately the parts centos2ol script  which creates the list of CentOS RPM and reinstall Oracle RPM instead (mapfile is a Bash built-in that reads lines from standard input into an indexed array variable.)

    mapfile -t list_of_centos_rpms < <(rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n" | grep CentOS | awk '{print $1}')
    if [[ -n "${list_of_centos_rpms[*]}" ]]; then
        echo "Reinstalling RPMs: ${list_of_centos_rpms[*]}"
        yum --assumeyes --disablerepo "*" --enablerepo "ol*" reinstall "${list_of_centos_rpms[@]}"
    fi

13. NFS mounted volumes survive the transition, but IBM GPFS does not: drivers are de-installed as they are not ins standard repositories.  You need to reinstall the drivers. 

Relevant Oracle recommendations

Before you switch

Remove all non-standard kernels i.e. kernels that are not from either the CentOS base or updates repos. Click for more info.

1. Ensure your CentOS yum or dnf configuration is working, i.e. there are no stale repositories.
2. Disable all non-CentOS repositories. You can re-enable the repos after the switch.
3. Ensure you have at least 5GB of free space in /var/cache.
4. All automatic updates, e.g. via yum-cron should be disabled.

Usage

1. Login to your CentOS Linux 6, 7 or 8 instance as a user who has sudo privileges.
2. Either clone this repository or download the centos2ol.sh script.
3. Run sudo bash centos2ol.sh to switch your CentOS instance to Oracle Linux.

Usage options

• -r Reinstalls all CentOS RPMs with Oracle Linux RPMs

  If a system is switched to Oracle Linux and there is no newer Oracle Linux version of a package already installed then the CentOS version remains. This option proceeds to reinstall any CentOS RPM with an identical version from Oracle Linux. This is not necessary for support and has no impact to a systems functionality but is offered so a user can remove CentOS GPG keys from the truststore. A list of all non-Oracle RPMs will be displayed after the reinstall process.
   

• -V Verify RPM information before and after the switch

  This option creates four output files:

  • sorted list of installed RPMs before the switch
  • sorted list of installed RPMs after the switch
  • result of verification of all installed RPMs against the RPM database before the switch
  • result of verification of all installed RPMs against the RPM database after the switch

If you are behind proxy

If you are behind proxy it might make sense to download Oracle Linux ISO and create a local repository out of it, which you can use in case of troubles.  Also, this situation requires more careful checking of all prerequisites as recovery from a failure is more difficult. For example any extra repository that is not accessible, for example EPEL,  might be fatal

Python 2 can be missing in CentOS8

See, for example, steps in How To Migrate CentOS Linux To Oracle Linux - OSTechNix

... ... ...

A word of caution

I used this script to migrate CentOS 7 to Oracle Linux 7. The transition was not successful at the first time. However, I got lucky at the second attempt. I do not recommend this script in production. Because, it broke my CentOS 7 server at first attempt and the server didn't boot. Luckily, it was just a testing VM and I simply reinstalled it. So I can't guarantee that this script will convert CentOS to Oracle Linux without any issues. YOU HAVE BEEN WARNED.

Let us begin the migration.

Migrate CentOS Linux To Oracle Linux

First of all, backup your important data, just in case.

... ... ...

Let us check the CentOS 7 version:

$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

Check centos release version

Next, make sure you have installed Python 2.x, which is required by centos2ol script. If python2 is not available, you may get the following output:

Checking for required packages...
'python2' command not found. Please install or add it to your PATH and try again.
For assistance, please email <[email protected]>.

To install Python2, simply run:

$ sudo dnf install python2

Or,

$ sudo yum install python2

Next, download the centos2ol.sh script:

$ curl -O https://linux.oracle.com/switch/centos2ol.sh

Or, download it from GitHub:

$ curl -O https://raw.githubusercontent.com/oracle/centos2ol/main/centos2ol.sh

and run it as root or sudo user to start migrating your CentOS Linux to Oracle Linux:

$ sudo sh centos2ol.sh

Or,

$ sudo bash centos2ol.sh

Now the Oracle Linux migration process will start.

The centos2ol script will backup the existing CentOS repository files, add Oracle Linux repositories, replace centos logos with oracle logos, update a few core packages and install the latest Oracle Unbreakable Enterprise Kernel.

... ... ...

NEWS CONTENTS

• 20201230 : Switching from CentOS to Oracle Linux: a hands-on example ( Dec 15, 2020 Simon Coter Blog )
• 20201229* Migrer de CentOS Oracle Linux Petit retour d'exp rience Le blog technique de Microlinux ( Dec 30, 2020 , blog.microlinux.fr ) [Recommended]
• 20201229 : Oracle Linux is "CentOS done right" ( Dec 21, 2020 , distrowatch.com )
• 20201228 : Time to move to Oracle Linux ( Dec 28, 2020 , www.cyberciti.biz )
• 20201228 : This quick and dirty hack worked fine to convert centos 8 to oracle linux 8 ( Dec 28, 2020 , blog.centos.org )
• 20201210 : Oracle Linux -- A better alternative to CentOS ( Dec 10, 2020 , linux.oracle.com )
• 20111222 : Converting CentOS 6 to RHEL 6 ( Dec 22, 2011 , End Point Blog )
• 20111222 : 6 comments: ( )
• 20111222 : Converting from CentOS to Red Hat ( Converting from CentOS to Red Hat , )

Old News ;-)

[Dec 30, 2020] Switching from CentOS to Oracle Linux: a hands-on example

In view of the such effective and free promotion of Oracle Linux by IBM/Red Hat brass as the top replacement for CentOS, the script can probably be slightly enhanced.

The script works well for simple systems, but still has some sharp edges. Checks for common bottlenecks should be added. For exmple scale in /boot should be checked if this is a separate filesystem. It was not done. See my Also, in case it was invoked the second time after the failure of the step "Installing base packages for Oracle Linux..." it can remove hundreds of system RPM (including sshd, cron, and several other vital packages ;-).

And failures on this step are probably the most common type of failures in conversion. Inexperienced sysadmins or even experienced sysadmins in a hurry often make this blunder running the script the second time.

It probably happens due to the presence of the line 'yum remove -y "${new_releases[@]}" ' in the function remove_repos, because in their excessive zeal to restore the system after error the programmers did not understand that in certain situations those packages that they want to delete via YUM have dependences and a lot of them (line 65 in the current version of the script) Yum blindly deletes over 300 packages including such vital as sshd, cron, etc. Due to this execution of the script probably should be blocked if Oracle repositories are already present. This check is absent.

After this "mass extinction of RPM packages," event you need to be pretty well versed in yum to recover. The names of the deleted packages are in yum log, so you can reinstall them and something it helps. In other cases system remain unbootable and the restore from the backup is the only option.

Due sudden surge of popularity of Oracle Linux due to Red Hat CentOS8 fiasco, the script definitely can benefit from better diagnostics. The current diagnostic is very rudimentary. It might also make sense to make steps modular in the classic /etc/init.d fashion and make initial steps shippable so that the script can be resumed after the error. Most of the steps have few dependencies, which can be resolved by saving variables during the first run and sourcing them if the the first step is not step 1.

Also, it makes sense to check the amount of free space in /boot filesystem if /boot is a separate filesystem. The script requires approx 100MB of free space in this filesystem. Failure to write a new kernel to it due to the lack of free space leads to the situation of "half-baked" installation, which is difficult to recover without senior sysadmin skills.

See additional considerations about how to enhance the script at http://www.softpanorama.org/Commercial_linuxes/Oracle_linux/conversion_of_centos_to_oracle_linux.shtml

Dec 15, 2020 Simon Coter Blog

... ... ...

We published a blog post earlier this week that explains why , but here is the TL;DR version:

• Oracle Linux is free to download, distribute and use (even in production) and has been since its release over 14 years ago
• Installation media, updates and source code are all publicly available on the Oracle Linux yum server with no login or authentication requirements
• Since its first release in 2006, Oracle Linux has been 100% application binary compatible with the equivalent RHEL version. In that time, we have never had a compatibility bug logged.

For these reasons, we created a simple script to allow users to switch from CentOS to Oracle Linux about five years ago. This week, we moved the script to GitHub to allow members of the CentOS community to help us improve and extend the script to cover more CentOS respins and use cases.

The script can switch CentOS Linux 6, 7 or 8 to the equivalent version of Oracle Linux. Let's take a look at just how simple the process is.

Download the centos2ol.sh script from GitHub

The simplest way to get the script is to use curl :

$ curl -O https://raw.githubusercontent.com/oracle/centos2ol/main/centos2ol.sh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10747 100 10747 0 0 31241 0 --:--:-- --:--:-- --:--:-- 31241

If you have git installed, you could clone the git repository from GitHub instead.

Run the centos2ol.sh script to switch to Oracle Linux

To switch to Oracle Linux, just run the script as root using sudo :

$ sudo bash centos2ol.sh

Sample output of script run .

As part of the process, the default kernel is switched to the latest release of Oracle's Unbreakable Enterprise Kernel (UEK) to enable extensive performance and scalability improvements to the process scheduler, memory management, file systems, and the networking stack. We also replace the existing CentOS kernel with the equivalent Red Hat Compatible Kernel (RHCK) which may be required by any specific hardware or application that has imposed strict kernel version restrictions.

Switching the default kernel (optional)

Once the switch is complete, but before rebooting, the default kernel can be changed back to the RHCK. First, use grubby to list all installed kernels:

[demo@c8switch ~]$ sudo grubby --info=ALL | grep ^kernel
[sudo] password for demo:
kernel="/boot/vmlinuz-5.4.17-2036.101.2.el8uek.x86_64"
kernel="/boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64"
kernel="/boot/vmlinuz-4.18.0-193.el8.x86_64"
kernel="/boot/vmlinuz-0-rescue-0dbb9b2f3c2744779c72a28071755366"

In the output above, the first entry (index 0) is UEK R6, based on the mainline kernel version 5.4. The second kernel is the updated RHCK (Red Hat Compatible Kernel) installed by the switch process while the third one is the kernel that were installed by CentOS and the final entry is the rescue kernel.

Next, use grubby to verify that UEK is currently the default boot option:

[demo@c8switch ~]$ sudo grubby --default-kernel
/boot/vmlinuz-5.4.17-2036.101.2.el8uek.x86_64

To replace the default kernel, you need to specify either the path to its vmlinuz file or its index. Use grubby to get that information for the replacement:

[demo@c8switch ~]$ sudo grubby --info /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64
index=1
kernel="/boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64"
args="ro crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet $tuned_params"
root="/dev/mapper/cl-root"
initrd="/boot/initramfs-4.18.0-240.1.1.el8_3.x86_64.img $tuned_initrd"
title="Oracle Linux Server (4.18.0-240.1.1.el8_3.x86_64) 8.3"
id="0dbb9b2f3c2744779c72a28071755366-4.18.0-240.1.1.el8_3.x86_64"

Finally, use grubby to change the default kernel, either by providing the vmlinuz path:

[demo@c8switch ~]$ sudo grubby --set-default /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64
The default is /boot/loader/entries/0dbb9b2f3c2744779c72a28071755366-4.18.0-240.1.1.el8_3.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64

Or its index:

[demo@c8switch ~]$ sudo grubby --set-default-index 1
The default is /boot/loader/entries/0dbb9b2f3c2744779c72a28071755366-4.18.0-240.1.1.el8_3.x86_64.conf with index 1 and kernel /boot/vmlinuz-4.18.0-240.1.1.el8_3.x86_64

Changing the default kernel can be done at any time, so we encourage you to take UEK for a spin before switching back.

It's easy to access, try it out.

• Switch from CentOS to Oracle Linux
• Installation media and updates freely available from the Oracle Linux yum server .
• UEK source code on GitHub

For more information visit oracle.com/linux .

[Dec 29, 2020] Migrer de CentOS Oracle Linux Petit retour d'exp rience Le blog technique de Microlinux

Highly recommended!

Google translation

Notable quotes:

"... Free to use, free to download, free to update. Always ..."

"... Unbreakable Enterprise Kernel ..."

"... (What You Get Is What You Get ..."

Dec 30, 2020 | blog.microlinux.fr

In 2010 I had the opportunity to put my hands in the shambles of Oracle Linux during an installation and training mission carried out on behalf of ASF (Highways of the South of France) which is now called Vinci Autoroutes. I had just published Linux on the onions at Eyrolles, and since the CentOS 5.3 distribution on which it was based looked 99% like Oracle Linux 5.3 under the hood, I had been chosen by the company ASF to train their future Linux administrators.

All these years, I knew that Oracle Linux existed, as did another series of Red Hat clones like CentOS, Scientific Linux, White Box Enterprise Linux, Princeton University's PUIAS project, etc. I didn't care any more, since CentOS perfectly met all my server needs.

Following the disastrous announcement of the CentOS project, I had a discussion with my compatriot Michael Kofler, a Linux guru who has published a series of excellent books on our favorite operating system, and who has migrated from CentOS to Oracle Linux for the Linux ad administration courses he teaches at the University of Graz. We were not in our first discussion on this subject, as the CentOS project was already accumulating a series of rather worrying delays for version 8 updates. In comparison, Oracle Linux does not suffer from these structural problems, so I kept this option in a corner of my head.

A problematic reputation

Oracle suffers from a problematic reputation within the free software community, for a variety of reasons. It was the company that ruined OpenOffice and Java, put the hook on MySQL and let Solaris sink. Oracle CEO Larry Ellison has been the center of his name because of his unhinged support for Donald Trump. As for the company's commercial policy, it has been marked by a notorious aggressiveness in the hunt for patents.

On the other hand, we have free and free apps like VirtualBox, which run perfectly on millions of developer workstations all over the world. And then the very discreet Oracle Linux , which works perfectly and without making any noise since 2006, and which is also a free and free operating system.

Install Oracle Linux

For a first test, I installed Oracle Linux 7.9 and 8.3 in two virtual machines on my workstation. Since it is a Red Hat Enterprise Linux-compliant clone, the installation procedure is identical to that of RHEL and CentOS, with a few small details.

Normally, I never care about banner ads that scroll through graphic installers. This time, the slogan Free to use, free to download, free to update. Always still caught my attention.

An indestructible kernel?

Oracle Linux provides its own Linux kernel newer than the one provided by Red Hat, and named Unbreakable Enterprise Kernel (UEK). This kernel is installed by default and replaces older kernels provided upstream for versions 7 and 8. Here's what it looks like oracle Linux 7.9.

$ uname -a
Linux oracle-el7 5.4.17-2036.100.6.1.el7uek.x86_64 #2 SMP Thu Oct 29 17:04:48 
PDT 2020 x86_64 x86_64 x86_64 GNU/Linux

Well-crafted packet deposits

At first glance, the organization of official and semi-official package filings seems much clearer and better organized than under CentOS. For details, I refer you to the respective explanatory pages for the 7.x and 8.x versions.

• Oracle Linux 7 Package Repositories
• Oracle Linux 8 Package Repositories

Well-structured documentation

Like the organization of deposits, Oracle Linux's documentation is worth mentioning here, because it is simply exemplary. The main index refers to the different versions of Oracle Linux, and from there, you can access a whole series of documents in HTML and PDF formats that explain in detail the peculiarities of the system and its day-to-day management. As I go along with this documentation, I discover a multitude of pleasant little details, such as the fact that Oracle packages display metadata for security updates, which is not the case for CentOS packages.

Migrating from CentOS to Oracle Linux

The Switch your CentOS systems to Oracle Linux web page identifies a number of reasons why Oracle Linux is a better choice than CentOS when you want to have a company-grade free as in free beer operating system, which provides low-risk updates for each version over a decade. This page also features a script that transforms an existing CentOS system into a two-command Oracle Linux system on the fly. centos2ol.sh

So I tested this script on a CentOS 7 server from Online/Scaleway.

# curl -O https://linux.oracle.com/switch/centos2ol.sh
# chmod +x centos2ol.sh
# ./centos2ol.sh

The script grinds about twenty minutes, we restart the machine and we end up with a clean Oracle Linux system. To do some cleaning, just remove the deposits of saved packages.

# rm -f /etc/yum.repos.d/*.repo.deactivated

Migrating a CentOS 8.x server?

At first glance, the script only predicted the migration of CentOS 7.9 to Oracle Linux 7.9. On a whim, I sent an email to the address at the bottom of the page, asking if support for CentOS 8.x was expected in the near future. centos2ol.sh

A very nice exchange of emails ensued with a guy from Oracle, who patiently answered all the questions I asked him. And just twenty-four hours later, he sent me a link to an Oracle Github repository with an updated version of the script that supports the on-the-fly migration of CentOS 8.x to Oracle Linux 8.x.

So I tested it with a cool installation of a CentOS 8 server at Online/Scaleway.

# yum install git
# git clone https://github.com/oracle/centos2ol.git
# cd centos2ol/
# chmod +x centos2ol.sh
# ./centos2ol.sh

Again, it grinds a good twenty minutes, and at the end of the restart, we end up with a public machine running oracle Linux 8.

Conclusion

I will probably have a lot more to say about that. For my part, I find this first experience with Oracle Linux rather conclusive, and if I decided to share it here, it is that it will probably solve a common problem to a lot of admins of production servers who do not support their system becoming a moving target overnight.

Post Scriptum for the chilly purists

Finally, for all of you who want to use a free and free clone of Red Hat Enterprise Linux without selling their soul to the devil, know that Springdale Linux is a solid alternative. It is maintained by Princeton University in the United States according to the principle WYGIWYG (What You Get Is What You Get ), it is provided raw de-cluttering and without any documentation, but it works just as well.

---

Writing this documentation takes time and significant amounts of espresso coffee. Do you like this blog? Give the editor a coffee by clicking on the cup.

[Dec 29, 2020] Oracle Linux is "CentOS done right"

Notable quotes:

"... If you want a free-as-in-beer RHEL clone, you have two options: Oracle Linux or Springdale/PUIAS. My company's currently moving its servers to OL, which is "CentOS done right". Here's a blog article about the subject: ..."

"... Each version of OL is supported for a 10-year cycle. Ubuntu has five years of support. And Debian's support cycle (one year after subsequent release) is unusable for production servers. ..."

"... [Red Hat looks like ]... of a cartoon character sawing off the tree branch they are sitting on." ..."

Dec 21, 2020 | distrowatch.com

Microlinux

• And what about Oracle Linux? (by Microlinux on 2020-12-21 08:11:33 GMT from France)

If you want a free-as-in-beer RHEL clone, you have two options: Oracle Linux or Springdale/PUIAS. My company's currently moving its servers to OL, which is "CentOS done right". Here's a blog article about the subject:

https://blog.microlinux.fr/migration-centos-oracle-linux/

Currently Rocky Linux is not much more than a README file on Github and a handful of Slack (ew!) discussion channels.

Each version of OL is supported for a 10-year cycle. Ubuntu has five years of support. And Debian's support cycle (one year after subsequent release) is unusable for production servers.

dragonmouth

9 • @Jesse on CentOS: (by dragonmouth on 2020-12-21 13:11:04 GMT from United States)

"There is no rush and I recommend waiting a bit for the dust to settle on the situation before leaping to an alternative. "

For private users there may be plenty of time to find an alternative. However, corporate IT departments are not like jet skis able to turn on a dime. They are more like supertankers or aircraft carriers that take miles to make a turn. By the time all the committees meet and come to some decision, by the time all the upper managers who don't know what the heck they are talking about expound their opinions and by the time the CentOS replacement is deployed, a year will be gone. For corporations, maybe it is not a time to PANIC, yet, but it is high time to start looking for the O/S that will replace CentOS.

Ricardo

"This looks like the vendor equivalent..." (by Ricardo on 2020-12-21 18:06:49 GMT from Argentina)

[Red Hat looks like ]... of a cartoon character sawing off the tree branch they are sitting on."

Jesse, I couldn't have articulated it better. I'm stealing that phrase :)

Cheers and happy holidays to everyone!

[Dec 28, 2020] Time to move to Oracle Linux

Dec 28, 2020 | www.cyberciti.biz

• TuxRuffian Dec 8, 2020 @ 23:43

  Does this mean no more SIGs too? OEL 8 is about to see a giant surge in utilization! reply link

• Just a geek Dec 8, 2020 @ 23:45

  Time to move to Oracle Linux. One of their partners is always talking about it, and being it is free, and tracks RHEL with 100% binary compatibly it's a good fit for use. Also looked at their support costs, and it's a fraction of RHEL pricing!

Kyle Dec 9, 2020 @ 2:13

It's an ibm money grab. It's a shame, I use centos to develop and host web applications om my linode. Obviously a small time like that I can't afford red hat, but use it at work. Centos allowed me to come home and take skills and dev on my free time and apply it to work.

I also use Ubuntu, but it looks like the shift will be greater to Ubuntu. Noname Dec 9, 2020 @ 4:20

As others said here, this is money grab. Me thinks IBM was the worst thing that happened to Linux since systemd... Yui Dec 9, 2020 @ 4:49

Hello CentOS users,

I also work for a non-profit (Cancer and other research) and use CentOS for HPC. We choose CentOS over Debian due to the 10-year support cycle and CentOS goes well with HPC cluster. We also wanted every single penny to go to research purposes and not waste our donations and grants on software costs. What are my CentOS alternatives for HPC? Thanks in advance for any help you are able to provide. Holmes Dec 9, 2020 @ 5:06

Folks who rely on CentOS saw this coming when Red Hat brought them 6 years ago. Last year IBM brought Red Hat. Now, IBM+Red Hat found a way to kill the stable releases in order to get people signing up for RHEL subscriptions. Doesn't that sound exactly like "EEE" (embrace, extend, and exterminate) model? Petr Dec 9, 2020 @ 5:08

For me it's simple.
I will keep my openSUSE Leap and expand it's footprint.
Until another RHEL compatible distro is out. If I need a RHEL compatible distro for testing, until then, I will use Oracle with the RHEL kernel.
OpenSUSE is the closest to RHEL in terms of stability (if not better) and I am very used to it. Time to get some SLES certifications as well. Someone Dec 9, 2020 @ 5:23

While I like Debian, and better still Devuan (systemd ), some RHEL/CentOS features like kickstart and delta RPMs don't seem to be there (or as good). Debian preseeding is much more convoluted than kickstart for example. Vonskippy Dec 10, 2020 @ 1:24

That's ok. For us, we left RHEL (and the CentOS testing cluster) when the satan spawn known as SystemD became the standard. We're now a happy and successful FreeBSD shop.

[Dec 28, 2020] This quick and dirty hack worked fine to convert centos 8 to oracle linux 8

Notable quotes:

"... this quick n'dirty hack worked fine to convert centos 8 to oracle linux 8, ymmv: ..."

Dec 28, 2020 | blog.centos.org

Phil says: December 9, 2020 at 2:10 pm

this quick n'dirty hack worked fine to convert centos 8 to oracle linux 8, ymmv:

repobase=http://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage
wget \
${repobase}/redhat-release-8.3-1.0.0.1.el8.x86_64.rpm \
${repobase}/oracle-release-el8-1.0-1.el8.x86_64.rpm \
${repobase}/oraclelinux-release-8.3-1.0.4.el8.x86_64.rpm \
${repobase}/oraclelinux-release-el8-1.0-9.el8.x86_64.rpm

rpm -e centos-linux-release --nodeps
dnf --disablerepo='*' localinstall ./*rpm 
:> /etc/dnf/vars/ociregion
dnf remove centos-linux-repos
dnf --refresh distro-sync
# since I wanted to try out the unbreakable enterprise kernel:
dnf install kernel-uek
reboot
dnf remove kernel

[Dec 10, 2020] Oracle Linux -- A better alternative to CentOS

Currently limited of CentOS 6 and CentOS7.

Dec 10, 2020 | linux.oracle.com

Oracle Linux: A better alternative to CentOS

We firmly believe that Oracle Linux is the best Linux distribution on the market today. It's reliable, it's affordable, it's 100% compatible with your existing applications, and it gives you access to some of the most cutting-edge innovations in Linux like Ksplice and DTrace.

But if you're here, you're a CentOS user. Which means that you don't pay for a distribution at all, for at least some of your systems. So even if we made the best paid distribution in the world (and we think we do), we can't actually get it to you... or can we?

We're putting Oracle Linux in your hands by doing two things:

• We've made the Oracle Linux software available free of charge
• We've created a simple script to switch your CentOS systems to Oracle Linux

We think you'll like what you find, and we'd love for you to give it a try.

FAQ

Wait, doesn't Oracle Linux cost money?

Oracle Linux support costs money. If you just want the software, it's 100% free. And it's all in our yum repo at yum.oracle.com . Major releases, errata, the whole shebang. Free source code, free binaries, free updates, freely redistributable, free for production use. Yes, we know that this is Oracle, but it's actually free. Seriously.

Is this just another CentOS?

Inasmuch as they're both 100% binary-compatible with Red Hat Enterprise Linux, yes, this is just like CentOS. Your applications will continue to work without any modification whatsoever. However, there are several important differences that make Oracle Linux far superior to CentOS.

How is this better than CentOS?

Well, for one, you're getting the exact same bits our paying enterprise customers are getting . So that means a few things. Importantly, it means virtually no delay between when Red Hat releases a kernel and when Oracle Linux does:

So if you don't want to risk another CentOS delay, Oracle Linux is a better alternative for you. It turns out that our enterprise customers don't like to wait for updates -- and neither should you.

What about the code quality?

Again, you're running the exact same code that our enterprise customers are, so it has to be rock-solid. Unlike CentOS, we have a large paid team of developers, QA, and support engineers that work to make sure this is reliable.

What if I want support?

If you're running Oracle Linux and want support, you can purchase a support contract from us (and it's significantly cheaper than support from Red Hat). No reinstallation, no nothing -- remember, you're running the same code as our customers.

Contrast that with the CentOS/RHEL story. If you find yourself needing to buy support, have fun reinstalling your system with RHEL before anyone will talk to you.

Why are you doing this?

This is not some gimmick to get you running Oracle Linux so that you buy support from us. If you're perfectly happy running without a support contract, so are we. We're delighted that you're running Oracle Linux instead of something else.

At the end of the day, we're proud of the work we put into Oracle Linux. We think we have the most compelling Linux offering out there, and we want more people to experience it.

How do I make the switch?

Run the following as root:

curl -O https://linux.oracle.com/switch/centos2ol.sh
sh centos2ol.sh

What versions of CentOS can I switch?

centos2ol.sh can convert your CentOS 6 and 7 systems to Oracle Linux.

What does the script do?

The script has two main functions: it switches your yum configuration to use the Oracle Linux yum server to update some core packages and installs the latest Oracle Unbreakable Enterprise Kernel. That's it! You won't even need to restart after switching, but we recommend you do to take advantage of UEK.

Is it safe?

The centos2ol.sh script takes precautions to back up and restore any repository files it changes, so if it does not work on your system it will leave it in working order. If you encounter any issues, please get in touch with us by emailing [email protected] .

[Dec 22, 2011] Converting CentOS 6 to RHEL 6

Dec 22, 2011 | End Point Blog

Posted by Jon Jensen |
Tags: hosting, open-source, redhat, sysadmin, tips

A few years ago I needed to convert a Red Hat Enterprise Linux (RHEL) 5 development system to CentOS 5, as our customer did not actively use the system any more and no longer wanted to renew the Red Hat Network entitlement for it. Making the conversion was surprisingly straightforward.

This week I needed to make a conversion in the opposite direction: from CentOS 6 to RHEL 6. I didn't find any instructions on doing so, but found a RHEL 6 to CentOS 6 conversion guide with roughly these steps:

1 2 3 4 5 6 7 8 9 10 11 12 13

yum clean all mkdir centos cd centos wget http://mirror.centos.org/centos/6.0/os/x86_64/RPM-GPG-KEY-CentOS-6 wget http://mirror.centos.org/centos/6.0/os/x86_64/Packages/centos-release-6-0.el6.centos.5.x86_64.rpm wget http://mirror.centos.org/centos/6.0/os/x86_64/Packages/yum-3.2.27-14.el6.centos.noarch.rpm wget http://mirror.centos.org/centos/6.0/os/x86_64/Packages/yum-utils-1.1.26-11.el6.noarch.rpm wget http://mirror.centos.org/centos/6.0/os/x86_64/Packages/yum-plugin-fastestmirror-1.1.26-11.el6.noarch.rpm rpm --import RPM-GPG-KEY-CentOS-6 rpm -e --nodeps redhat-release-server rpm -e yum-rhn-plugin rhn-check rhnsd rhn-setup rhn-setup-gnome rpm -Uhv --force *.rpm yum upgrade

I then put together a plan to do more or less the opposite of that. The high-level overview of the steps is:

1. Completely upgrade the current CentOS and reboot to run the latest kernel, if necessary, to make sure you're starting with a solid system.
2. Install a handful of packages that will be needed by various RHN tools.
3. Log into the Red Hat Network web interface and search for and download onto the server the most recent version of these packages for RHEL 6 x86_64:
   • redhat-release-server-6Server
   • rhn-check
   • rhn-client-tools
   • rhnlib
   • rhnsd
   • rhn-setup
   • yum
   • yum-metadata-parser
   • yum-rhn-plugin
   • yum-utils
4. Install the Red Hat GnuPG signing key.
5. Forcibly remove the package that identifies this system as CentOS.
6. Forcibly upgrade to the downloaded RHEL and RHN packages.
7. Register the system with Red Hat Network.
8. Update any packages that now need it using the new Yum repository.

The exact steps I used today to convert from CentOS 6.1 to RHEL 6.2 (with URL session tokens munged):

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

yum upgrade shutdown -r now yum install dbus-python libxml2-python m2crypto pyOpenSSL python-dmidecode python-ethtool python-gudev usermode mkdir rhel cd rhel wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/redhat-release-server/6Server-6.2.0.3.el6/x86_64/redhat-release-server-6Server-6.2.0.3.el6.x86_64.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/rhn-check/1.0.0-73.el6/noarch/rhn-check-1.0.0-73.el6.noarch.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/rhn-client-tools/1.0.0-73.el6/noarch/rhn-client-tools-1.0.0-73.el6.noarch.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/rhnlib/2.5.22-12.el6/noarch/rhnlib-2.5.22-12.el6.noarch.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/rhnsd/4.9.3-2.el6/x86_64/rhnsd-4.9.3-2.el6.x86_64.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/rhn-setup/1.0.0-73.el6/noarch/rhn-setup-1.0.0-73.el6.noarch.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/yum/3.2.29-22.el6/noarch/yum-3.2.29-22.el6.noarch.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/yum-metadata-parser/1.1.2-16.el6/x86_64/yum-metadata-parser-1.1.2-16.el6.x86_64.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/yum-rhn-plugin/0.9.1-36.el6/noarch/yum-rhn-plugin-0.9.1-36.el6.noarch.rpm?__gda__=XXX_YYY&ext=.rpm' wget 'https://content-web.rhn.redhat.com/rhn/public/NULL/yum-utils/1.1.30-10.el6/noarch/yum-utils-1.1.30-10.el6.noarch.rpm?__gda__=XXX_YYY&ext=.rpm' wget https://www.redhat.com/security/fd431d51.txt rpm --import fd431d51.txt rpm -e --nodeps centos-release rpm -e centos-release-cr rpm -Uhv --force *.rpm rpm -e yum-plugin-fastestmirror yum clean all rhn_register yum upgrade

I'm expecting to use this process a few more times in the near future. It is very useful when working with a hosting provider that does not directly support RHEL, but provides CentOS, so we can get the new servers set up without needing to request a custom operating system installation that may add a day or two to the setup time.

Given the popularity of both RHEL and CentOS, it would be neat for Red Hat to provide a tool that would easily switch, at least "upgrading" from CentOS to RHEL to bring more customers into their fold, if not the other direction!

6 comments:

Kristof Wevers said...

Did you manage to get support on this system from Red Hat? So after the conversion?

February 15, 2012 at 4:39:00 AM EST

Jon Jensen said...

Kristof, it's an interesting question. I haven't tried to get support from Red Hat on this system yet. I'm going to assume that paying the RHN subscription fee means I'll get support, but am happy to hear any counterevidence. :)

February 15, 2012 at 10:37:00 AM EST

jgoldschrafe said...

On several of our systems, I had to also modify /etc/yum.conf to replace distroverpkg=centos-release with distroverpkg=redhat-release in order to get Yum to properly expand the $releasever variable in our repo URLs.

February 4, 2013 at 8:59:00 AM EST

Jon Jensen said...

Here are current instructions on converting from RHEL 6.4 to CentOS: http://blog.endpoint.com/2013/04/converting-rhel-59-and-64-to-centos.html

April 4, 2013 at 10:12:00 AM EDT

Mostly Nothing said...

I followed this and it worked fine. I had to go through a browser to download the rpms, and needed the --proxy in the rhn_register.

One artifact is the kernel is labeled as CentOS in the grub menu, a reinstall of that cleans up the menu.

thanks!

November 24, 2014 at 2:26:00 PM EST

Jobin Joseph said...

Its not supported by redhat. You will be simply paying for the subscription since you wont get support for the server if any issue arise.
https://access.redhat.com/solutions/25037

February 16, 2015 at 3:34:00 PM EST

Converting from CentOS to Red Hat

dna.org

Recommended Links

Softpanorama Recommended

Top articles

[Dec 29, 2020] Migrer de CentOS Oracle Linux Petit retour d'exp rience Le blog technique de Microlinux Published on Dec 30, 2020 | blog.microlinux.fr

Sites

Oracle conversion script

• Conversion Script (centos2ol.sh)
• Conversion Script Project

Red Hat conversion to RHEL script

This is a Python script written in completely incomprehensible over-modulazed manner. Python obscurantism in action ;-)

• How to convert from CentOS or Oracle Linux to RHEL - Red Hat Customer Portal
  • Convert2RHEL download page - Red Hat Customer Portal
    • • RPM for Oracle Linux 8 and CentOS 8
      • RPM for Oracle Linux 7 and CentOS 7
      • RPM for Oracle Linux 6 and CentOS 6

Youtube

• Convert CentOS to Oracle Linux

Oracle FAQ

• Oracle Linux : Frequently Asked Questions (FAQs)
• Oracle Linux- A better alternative to CentOS

Etc

• oracle-centos2ol- Script and documentation to switch CentOS Linux to Oracle Linux
• ORACLE-BASE - Convert CentOS 8 to Oracle Linux 8 (OL8)

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: January 03, 2021