Dizwell Informatics

News from Nowhere

Atlas – Installing Oracle on OpenSUSE 42+

1.0 Introduction

SUSE is a bit of a red-haired stepchild when it comes to distros: it’s been around for ever and everyone knows it to be stable, robust and capable. But no-one really loves it, hardly anyone knows how to pronounce its name… and even how you capitalize its spelling is up for grabs! It has additionally been tossed around between owners as if it’s radioactively contaminated!

There is also a quite complicated relationship between SUSE Enterprise Server (which is one of the few distros officially supported by Oracle for use with their database) and OpenSUSE. At its simplest, you can think of OpenSUSE being to SUSE ES what CentOS is to Red Hat. Sort of.

OpenSUSE also now comes in two main flavours: “Leap” and “Tumbleweed”. Leap is a periodic release (now up to version 42.2) that follows the main SUSE ES releases. It is thus stable (and slightly boring). Tumbleweed is a ‘rolling release’: install it once and you’ll never have to re-install because it gets incrementally upgraded over time …at least, until it breaks horribly become some new update wasn’t regression tested thoroughly …and then you do have to re-install after all! Tumbleweed is cutting-edge, slightly exciting and rather volatile in consequence.

Anyway, Atlas runs nicely on both flavours of OpenSUSE, though the screenshots for this page happen to have been taken (mostly) from a Tumbleweed system.

As is the case with all Atlas/Oracle installs, of course, your OpenSUSE server needs to be built with at least 5GB RAM and at least a 40GB hard disk.

Please watch the generic Atlas videos here, here and here to get an idea of how Atlas works in general. The generic documentation (including those videos) are available from this page. Below are OpenSUSE-specific notes.

2.0 What’s been tested?

  • OpenSUSE 42.1, 42.2
  • OpenSUSE Tumbleweed

3.0 Operating System media

I got my OpenSUSE Leap 42.2 ISO from here, and my Tumbleweed ISO was obtained from here.

Bear in mind that those links are only valid at the time of writing (mid-January 2017). You should check the project’s website for more up-to-date sources for Leap and Tumbleweed respectively.

4.0 Operating System installation issues

OpenSUSE has a nice installer, but a weird set of defaults… such that there are probably more non-default installation options to be taken with OpenSUSE than with any other distro on which Atlas runs! Additionally, it’s the only installer I know of that doesn’t even give you a chance to specify a proper hostname for your server: you have to do that manually after the O/S is up and running, I’m afraid… or live with the random names the installer assigns for you.

So, to start with:

During the installation, you are shown this screen with neither option checked. As you can see, you should switch on the option to add online repositories (otherwise, you won’t be able to download much software when the time comes). It’s up to you whether you also want to switch on the second option as well (I’d suggest leaving it switched off), but that first one needs turning on.


This is OpenSUSE’s default partitioning proposal. It’s an unholy mess, and you cannot accept it as-is, because (if you look carefully at the top three lines of text), it will result in a small 15.5GB root volume and a large 22.4GB /home volume. In itself, that’s not a bad thing to do with home Linux systems: splitting /home out into a separate volume means you can re-install the operating system at any time and not lose your own personal data in the process.

But for an Oracle database server, it’s a poor way of doing things -because Oracle’s software is installed into /u01/somewhere-or-other… and /u01 is a directory off the root partition, so that if your root partition is not big enough, the Oracle installation will fail.

You should therefore click the [Edit Proposal Settings] button and change this partitioning scheme as follows:

Now the specific choice of file systems to use is up to you: I’m sticking with Ext4 because I’m old-fashioned like that! And if you want to use LVMs or Encrypted LVMs, be my guest too, though I’m sticking with ye olde partitions because… er, well, I’m old-fashioned like that too!

The really important option here, though, is to un-check the option to propose a separate Home partition. Turn that off and click [OK], and you should see a revised partitioning proposal similar to this:

Short, succinct and to the point: we now have a proposal for a small-ish swap volume and a giant, all-in-one root partition. That’s what Atlas will check for; it’s what Oracle will need.

Apart from all that, the SUSE installer will chug along, slowly but surely, and you won’t need to alter anything else. Eventually, you’ll get to log onto your new operating system. If you’re running OpenSUSE in a VirtualBox or VMware virtual machine, you’ll be able to resize the display to something large enough to keep Atlas happy without having to install any guest additions, which is a bonus.

You will need to install wmctrl or xdotool, though. The command to do that is simply:

sudo zypper install wmctrl

…and the installation process should end up looking like this:

Just confirm ‘y’ when prompted: the installation takes mere seconds.

After that, given that you weren’t offered the choice of setting a sensible hostname for your new server, you might want to update your hostname to something a little less weird than the auto-generated name you’re currently running with. To do that, just click Start > Settings > Yast > System > Network Settings. 

Switch to the Hostname/DNS tab and make appropriate entries in the Hostname and Domain Name fields, over-writing their existing contents:

If you don’t have a proper domain name to use here, make one up: ‘home.test’ would work; as would ‘localdomain’ or something equally meaningless. The “dizwell.home” you see me using here is just one I made up and has no ‘real’ validity outside the walls of my study.

I’d also suggest switching off the option to ‘Change hostname via DHCP’, unless you happen to have a DHCP server properly configured to give out sensible hostnames automatically. Click [OK] when done: the hostname change should take effect immediately, without need for a subsequent reboot.

5.0 Running Atlas

Once you have a decent screen resolution and wmctrl or xdotool installed, fetch and run Atlas in the normal way:

wget http://bit.do/dizatlas -O atlas.sh
chmod +x atlas.sh

…after which, I simply followed the prompts.

6.0 Installing Oracle 12c

There are no major dramas during the Oracle database installation. On almost the first screen, you’ll be shown this terrible-looking warning:

Your environment might not meet Oracle’s exacting standards, according to the installer… but it’s actually fine. So click [Yes] to say you want to continue regardless.

After that, it’s pretty much click [Next] until it’s finished. There are no errors during the linking phase to worry about. Since there are no linking errors, Atlas will have created a post-install script in the oracle user’s Documents directory, which you can (optionally) run once the Oracle installation completes successfully. Since I am my own oracle user, the following screenshot shows me checking the contents of my own Documents directory:

Note that the file is already executable: Atlas created it that way. You can therefore run that script now, as yourself, using the following command:


Do that as yourself, not as root. The command will not appear to have done anything at all, and you’ll merely return to the next line on the command prompt. Nevertheless, it will actually have altered some of the interface settings for the command-line SQL*Plus tool so that its query results are presented more sensibly than they are by default:

The default SQL*Plus settings would have resulted in that query’s return being broken up into a fairly illegible mess. Nevertheless, it’s up to you whether to run the post-install script: it is entirely optional to do so.

Incidentally: the command you see me typing in that last screenshot (“sql“) is the alias of the full command (“sqlplus / as sysdba“). It is aliased with a reference to the rlwrap utility, so that if you get into SQL*Plus using it, you can press the up and down cursor keys to retrieve and scroll through any previous SQL commands you’ve typed. If you ever need the vanilla, un-rlwrapped version of SQL*Plus, however, then just type the full-blown sqlplus  command and you’ll be running the exact same program as before but without a command line history.