Kevin Kempf's Blog

February 14, 2012

Switching from Redhat Linux to Oracle Linux in about 5,000 easy steps

Filed under: 11g, Oracle Linux — kkempf @ 4:15 pm

Wayback When

I remember being at Oracle Open World when Larry Ellison unveiled Oracle Enterprise Linux (OEL, which is now just Oracle Linux, or OL).    I think I even have a foam Oracle penguin and maybe even a t-shirt somewhere.  I was trying to understand why, as a loyal RedHat customer, I’d ever consider switching over to the “dark side”.  I even remember laughing to a colleague “Who in their right mind would want Oracle to support their Linux environment, they can’t even support their database?”.

Warming up to the idea

I thought it might be useful to note, for a moment, my experience level with Linux.  I’ve been using some flavor of Unix/Linux in various workplaces since 1999.  I hold an RHCSA (Red Hat Certified System Administrator) cert and I hope to pursue the next level, RHCE, within a few months.  Why am I mentioning this?  To demonstrate that I’m not an Oracle fan boy and if anything I have more of an inclination to run Red Hat than any other flavor of Linux at the moment.

As I mentioned in another post, we recently did a fairly major hardware refresh in our datacenter.  My 11i production database is currently a physical machine, and the box was available to me to tinker with prior to migration.  We’d even gotten to the point where we’d installed Red Hat Enterprise Linux (RHEL) 5.7 before I got the crazy idea to take a 2nd look at Oracle Linux.  I have no idea what the adoption rate is for OL, but they claim 8,000 customers on their information page.  I don’t know if that’s a lot or not.

What initially drove me to even consider Oracle Linux was not cost, but rather a series of really bad support tickets I had with Red Hat.  Unrelated, system service requests where Red Hat support went 0 for 3.  Why did my system lock up and the kernel panic?  Redhat: No idea. Twice.  The second time with really good logging enabled.   Then I had an issue where the system CPU (as opposed to user CPU) time was crazy high – in some sar reports as much as 20% of the total CPU usage.  Why is it so high?  Redhat: No idea.  At this point the little light bulb went off in my head.  I can pay less than half as much for bad support from Oracle.  And that’s really a pessimistic view.  In truth, there are some actual advantages to running Oracle on Oracle Linux, especially when you consider the Oracle Unbreakable Enterprise Kernel (UEK).

The Flavors of Oracle Linux

You can go, right now and pull Oracle Linux and install it on you machine.  You will, of course not be able to open a ticket (through my Oracle Support).  Basically, there’s 3 flavors of support with different cost levels:

  • Network Support: patches and updates only (this flavor was not offered by sales, not sure about this level)
  • Basic Support: add “complete Linux server lifecycle management, cluster software” (this is what we have)
  • Premier Support: add ksplice

I think I should take a minute to define a few things more clearly, as I wish my sales team would have:

  • Unbreakable Enterprise Kernel (UEK): Oracle’s home-grown kernel, available at any level of support.  From what I can tell, this kernel especially optimizes what Oracle perceives as deficiencies in the Red Hat kernel’s ability to handle big multi-processor (SMP) machines.
  • ksplice: a zero-downtime kernel patcher.  This is available only if you buy Premier Support and only if you are running the Oracle Unbreakable Enterprise Kernel (UEK)
  • Red Hat compatible kernel: the kernel Oracle creates based upon the same open-source feed Red Hat gets.  You can run Oracle Linux using either the UEK or the RH Compatible kernel, selected at boot time via grub
  • The Physical Address Extension (PAE) 32-bit kernel is available for Oracle Linux 5 (x86).  This was important to me because I run the 11i front end (has to be 32-bit!) on the PAE kernel which gets around the 4gb RAM limit imposed by 32-bit architecture.

Things I wish I’d known (or researched better) in retrospect

Before I dig into the “how” part of how to convert your Red Hat 5 machine to Oracle Linux, I thought I’d tell you more about the areas in which I have buyer’s remorse.

  • UEK.  This was one of the big upsells for me to Oracle Linux.  I planned to cut over to the Red Hat compatible kernel, then begin regression testing the “super” UEK kernel.  Except for one thing.  We’re a VMWare shop.  It’s not certified to run as a VMWare guest.  Until that changes, UEK is DOA in our datacenter.  If UEK is DOA, then so is ksplice.  If ksplice is DOA, then that means I definitely don’t need premier support.
  • Unbreakable Linux Network (ULN) pales in comparison to the Redhat Network.  You cannot release patches for update to the servers like you can with the Red Hat network.  Basically you can see what systems are registered, if they need updates, and what your CSI is.  Beyond that, you can see what versions of what packages are available in what release.
  • Managing servers is rather manual.  There is some promise that Enterprise Manager may make server management easier, but I can’t verify this.

Switching to Oracle Linux

I’m assuming at this point, that you’re running RHEL 5.7.  While certainly you could be running something else, you’d have to be smart enough to make some changes in the steps I will outline.   RH6 isn’t certified with much, as far as I can tell.

This outline is derived from a lot of disparate sources.  In fact, I wish Oracle would have one, good, thorough document to walk me through all this, but they don’t appear to.

  • Go get the appropriate up2date packages from Oracle, based on the RH release you’re running, and land the RPMs somewhere on your server.
  • Install the up2date RPMs
    • rpm -Uvh up2date*rpm
    • Import the GPG Key for RPMs
      • rpm –import /usr/share/rhn/RPM-GPG-KEY
    • Save yourself a headache, update the RHN uuid of your server
      • # /usr/bin/uuidgen -r
        • e949dadc-c182-3ec2-9de7-44ag8a0d2bea
        • vi /etc/sysconfig/rhn/up2date-uuid
          • confirm the line rhnuuid matches the key you just generated
          • if not, pound it out and replace it:
            • rhnuuid=e949dadc-c182-3ec2-9de7-44ag8a0d2bea
    • Run the Oracle Registration TUI (Text User Interface)
      • up2date-nox – – register     (this actually launches the TUI) ** for OL6, it’s bundled now just run uln_register
      • If you have a proxy server between you and the internet
        • export http_proxy=<your port>
        • edit /etc/yum.conf for future ease
          • under [main] add this line
          • proxy=<your port>
          • Import the GPG Key for RPMs
        • Here’s screenshots from the TUI

      It always seems to say this...

      Hit next to waive all your rights

      Not sure I like hard coding my ULN login

      Hardware gathered information


  • Update your Repos and packages
    • cd /etc/yum.repos.d
    • rename your existing .repo files
      • mv rhel-source.repo rhel-source.repo.old
      • mv rhel-debuginfo.repo rhel-debuginfo.repo.old
      • note that the .repo suffix is what signifies that a repo file is “active”
    • use wget to fetch the oracle repos
    • edit the public-yum-el5.repo to activate (enable) the appropriate subscription channels
      • [ol5_u7_base]
      • enabled=1
    • update your packages
      • # up2date -i yum-rhn-plugin
      • # yum update
    • #yum install kernel
    • #yum install kernel-uek (optional, install the unbreakable kernel)
    • #yum install oracle-linux (optional Oracle packages, pair with UEK I believe)
  • reboot to new kernel
    • check /etc/grub.conf to ensure it is to your satisfaction
    • #reboot -i to restart the host, select the appropriate kernel when the grub menu option appears

First Impressions

So what I failed to mention in my original post were impressions about the migration.  We’ve been running Oracle Linux 5.7 for 3 weeks now.   Aside from the branding/logo changes  (A penguin in Oracle armor instead of the Red Hat shadow man) I don’t see much difference at all.  Not that I’d really have any reason to expect to.

Since this OS upgrade coincided with a  hardware upgrade, I feel it would be unfair to speculate on performance improvement.  Meaning, I suspect anything works better on the latest CPU and hardware architecture.  Suffice it to say, after a short period of fretting about the new OS, I just don’t monitor it anymore.  It works fine.

My concern about how much more manual the Oracle Linux experience hasn’t changed much.  I now understand that I could create a local RPM mirror, which would be updated daily through Oracle Enterprise Manger 11g, and thus through Enterprise Manager, I could push or release updates to my Oracle Linux servers.  That’s all fine and good, but that’s just one more layer of complication I’d rather not have to deal with.  I may go that route eventually, but since I’m comparing apples to apples, I simply say:  “I don’t have to do that with Red Hat”.

One impression I got throughout the whole conversion process was a general disjointedness from Oracle.  One of the main reasons I posted this blog entry was because the whole process, from information (sales) to install is all over the place.  I mean literally, all over the place.  The steps above are provided in a complete manner nowhere that I am aware of.  There’s a document here about how to wget the repo’s, a document there about how to deal with duplicate RHN UUID’s, another page to download the up2date RPMs, another page telling you how to register with the Oracle Linux network.  I suppose I can’t expect Oracle to advertise that the UEK kernel isn’t certified for VMWare, but it’s important, and I’d rather have learned that up front than on my own trying to boot a DEV VM into UEK.   Support told me to use up2date to update my packages, but when I put that in my (original) blog posting here, I was corrected in the comments and told of yum-rhn-plugin (noted in the steps above).   I looked back to see what Open World I was at when Oracle Linux was announced:  it was Fall of 2006.  I would think that after 5 years, this would be a bit more refined.

All that said, my final word on this is that while frustrating and non-intuitive, the migration to Oracle Linux has been fine.  It’s too early to say I recommend it, but I will say at this point, that I’m not regretting moving to it, and I think it’s worth a look.  Even if you’re from the old-school Sun/RedHat/AIX/HPUX environments like me.



  1. Hi Kevin,

    A few notes:

    Firstly, don’t enable the public-yum repository if you’re registering your server with ULN. Just install the yum-rhn-plugin RPM from ULN (using up2date -i yum-rhn-plugin) and yum will work just fine directly with ULN. We’re looking at updating the switching documentation to make this known.

    Secondaly, unlike Red Hat, we don’t have entitlements for servers, so you don’t need to register all of them with ULN. You can use the following script to setup a local yum mirror of the ULN channels and then just configure yum on your remaining servers to point to the local yum mirror: — only the yum server itself needs to be registered with ULN.

    This is the same mechanism that’s used by EM12c under-the-hood, btw. And, you can use any version of the Linux Management Pack for EM with an active Oracle Linux subscription, so if you’re running EM11g, that’s fully supported for free too. No need to upgrade to 12c for Linux Management.

    Hope that helps,

    Comment by Avi Miller — February 14, 2012 @ 7:53 pm

    • Thanks for the feedback. I actually realized that I’d neglected to cover my initial impressions so this post is pretty sterile. In regards to you first suggestion about yum, I’ll try it out. This really didn’t smell right to me, and I opened an SR this week. I actually started using up2date because it was the solution offered by my analyst on SR 3-5301945541. I’m really not wanting to set up a yum mirror so I purposefully avoided that tidbit, though I did see it. And I’ll let you know what I can find about the plug in under EM11g. I did look into it, but it seems like it said I didn’t need the plugin under 11g and that it was already there so I didn’t pursue it further. I’ll double back and update the post based on this.

      Comment by kkempf — February 14, 2012 @ 9:32 pm

      • There is no plug-in for EM11g: it has been built into the base install of EM since 10gR5. Setup -> Patching -> Linux Patching (from memory). Same with EM11g and EM12c.

        I’ve checked your SR as well, and I’ll let the analyst know that yum-rhn-plugin is available on both OL5 and OL6 for future reference.

        Comment by Avi Miller — February 14, 2012 @ 9:37 pm

      • I see where you’ve asked me to navigate, but the first thing it wants to know under setup is on which host my RPM repository is. I have no interest in setting up a RPM repository. Am I out of luck?

        Comment by kkempf — February 15, 2012 @ 11:59 am

  2. Hi Kevin, thanks a lot for sharing your experiences and impressions with Oracle Linux. Avi has already addressed the other points, I’d just like to comment on the following you wrote: “Unbreakable Enterprise Kernel (UEK): Oracle’s *proprietary* kernel” – I beg to differ. In contrast to the RHEL kernel, the sources of our kernel are publicly available from the following git source tree:;a=shortlog , including each individual commit and developer comment. UEK is based on mainline Linux, every bug fix and improvement we apply to this kernel is also submitted upstream, for inclusion in future mainline kernel releases.

    Comment by Lenz Grimmer — February 15, 2012 @ 6:07 am

    • Duly noted. Proprietary is probably not the best word. I’ll revise my write-up when I address a few other issues; I guess home-grown would be more accurate.

      Comment by kkempf — February 15, 2012 @ 7:57 am

      • Thanks – we actually strive to stay as close to mainline as possible – the UEK will be rebased with mainline every 12-18 months, to keep the delta small. That makes it probably less “home-grown” than other distributions’ kernels.

        Comment by Lenz Grimmer — February 15, 2012 @ 10:43 am

  3. Hi — yes, you need to create a local repository for EM to work — all of the local hosts are patched from the local repository, with EM automatically updating that repository from ULN on a daily basis. Essentially, EM is a complete local management tool, which would be the provisioning and patching equivalent of Satellite Server from Red Hat, thus it needs local repositories from which to work.

    (Not sure if this reply will go in the right place: I’m replying from a different machine today).

    Comment by Avi Miller — February 15, 2012 @ 4:39 pm

  4. A somewhat belated additional comment on Ksplice: “This is available only if you buy Premier Support and only if you are running the Oracle Unbreakable Enterprise Kernel (UEK)”. According to we’re now supporting the Red Hat compatible kernel as well; we now also have a free trial version for RHEL. We’ll update the getting started page on accordingly.

    Comment by Lenz Grimmer — August 10, 2012 @ 4:40 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Create a free website or blog at