Oracle XE on SuSE

June 12th, 2011

Today it became necessary to deploy Oracle XE on a new SuSE system. This did not seem a big deal; we had already deployed a version of Oracle 10g XE on SuSE 10.2 quite a while back and as far as I remembered it was a simple rpm deployment. This time the XE was the same but we were deploying on OpenSuse 11.2.

Everything seemed to install fine, but darned if Oracle would not come up at all with no errors logged anywhere to give us a clue. We paused to wonder; perhaps the versions of glibc and libaio (stated as requirements) were too new - should we revert to something older? As it happens we had to deploy Tomcat v6 with Java v1.6+ and our normal alternative - Centos/RedHat - had only prior versions of these. So it was either go back to RHEL v5 - requiring an upgrade to Java/Tomcat - or figure out what was wrong and get the SuSE system working.

It was Friday; plan B won - but it took us quite a while to figure out what was going wrong!

The Problem

First off we downloaded the XE rpm version from Oracle's website then installed it using the rpm command
rpm -ivh oracle-xe-univ-
It did complain a bit but these were warning messages because the startup script in /etc/init.d was missing a few presets expected by SuSE system configuration.
 blacktav:/srv/ftp/Oracle # rpm -ihv oracle-xe-univ- Preparing... 
########################################### [100%] 1:oracle-xe-univ 
########################################### [100%] Executing Post-install steps... 
insserv: warning: script 'oracle-xe' missing LSB tags and overrides insserv: Default-Start 
undefined, assuming default start runlevel(s) for script `oracle-xe' oracle-xe 0:off 1:off 
2:off 3:on 4:off 5:on 6:off You must run '/etc/init.d/oracle-xe configure' as the root 
user to configure the database. 
These extras were not needed as the service was configured to start-up correctly and the LSB component is just documentation to describe the product. All seemed good.
  1. an oracle user account & group had been added as oracle
  2. the product tree had been populated under /usr/lib/oracle/xe
For convenience at this point we added entries in /etc/ (oracle.conf) to add the Oracle libraries and in /etc/profile.d ( to add Oracle binaries to our path and a few convenience variables for Oralcle such as ORACLE_HOME and the likes. These steps are also detailed in the Oracle Installation Guide. And so to the final step, doing the configuration step with
/etc/init.d/oracle-xe configure
This step should initialise our database file and actually launch both the SQL engine and Oracle's management webtool servers. We were expecting to use this in the wild, wild Interweb so we decided to provide a difficult password for the system users; we accepted defaults for the other values. This interaction creates a file in /etc/sysadmin (oraclexe.conf) which is a reference for configuration information by the startup script. This "seemed" to complete without error but something was not right; neither the engine nor the admin web application were running. All Oracle had said was:
Starting Oracle Database 10g Express Edition Instance...Done Installation Completed 
Successfully. To access the Database Home Page go to ""
Oracle had not installed itself at all - there was no oradata/XE tree, nor other folders which the various conf/scripts should have created. t took us quite a while to figure this one out; what seems to have gone wrong was that the oracle user account had been created with a password. When we assigned a password during the interaction, this password was used to initiate an su session when the database was actually configured by the oracle user. Because the passwords were now different, su could not work and the script did not have sufficient privileges to create the folders required. There were other issues around simply running sqlplus; depending on our trial: libaio was missing, the binary was not in the path or ORACLE_HOME was not set.


Anyway we eventually figured it out. This is what we should have done:
  1. make sure you have the required libraries (glibc and libaio); you might need a 32b of libaio if you are installing a 32b application on a 64b platform
  2. install using the command
    rpm-ihv oracle-xe-univ-
  3. set the oracle user's password to "oracle" with passwd oracle
  4. in /etc/profile.d add an file in which you can add the lines
    export PATH=$PATH: export ORACLE_HOME 
  5. log off and on again so these exports can take effect. Before continuing, make sure you can startup sqlplus
  6. now you can finish off with /etc/init.d/oracle-xe configure; accept the defaults and when prompted for a password use "oracle"; your system should pause displaying
    Configuring Database...
    after a few minutes it should finish and you should have a working Oracle instance which you can check by going to If you have started an installation and reached a point where it has failed like above; it should be possible to remove oraclexe.conf from /etc/sysconfig and try again from step 3.


There are essentially two steps to be completed: install from rpm and configure the application. In order for the configuration step to succeed you need to ensure:
  1. the sqlplus tool can be started from the command-line
  2. the configure script can su to the oracle user account using the password provided
For whatever reason, neither of these are satisfied by the tools or the process documented by Oracle Security Alert: once installed, remember to change the oracle user password to something more secure: the default is obviously widely known.

SuSE 11.3 Multi-head

November 30th, 2010

On Thursday, I decided to upgrade from OpenSuse 11.2 to 11.3 I was highly suspicious that this would work so bundled up all my important documents, systems, settings & whatever and stored them safely away in my secret place. Downloaded and made a CD from the 64b Network Install ISO and promptly booted my system from the CD. Chose the upgrade option and went and made a couple of nice curries while the beast took 2 hours to download whatever it needed. …and when I came back…. Almost everything was working perfectly!

Better than that, some of the packages I had installed from the Packman repository were flagged correctly and through Yast's Software Management tool I was able to update, remove or whatever any packages that the installer did not know what to do with. And that was it; local applications were working fine, and all my important apps were all brand new and shiny recent versions - even weird stuff I had in /usr/local/bin continued to work fine. Wow! Seriously impressed.

Getting multi-head dual screens to work in OpenSuse 11.3 with a Radeon card

Only one fly in the ointment - almost a disastrous one as well. I have 2 monitors fed off a Radeon card which had given problems before though 11.2 seemed to cope well. But not 11.3 and definitely not KDE. Here's what I had to do:

Support Multi-head

Seems the latest kernel does not support automatic mode lines from RadeonHD cards so this feature should be turned off. Quite simple when you know what has to be done; edit your /boot/grub/menu.lst file and add the switch


to each of your kernel lines. Then just reboot. This allows you to at least choose multi-head behaviour.

Why graphics mode setting has been moved to kernel is beyond me; I would think this will make life much more difficult for folks pulling graphics cards in and out (yes, I have done that in the past) and general graphics issues. But perhaps this is only the start of some grand design thought up by someone.

Anyhow, if you have a Radeon or Nvidia card, this tweak may help you sort graphics problems.

Saving Multi-head Settings

Now I was able to choose the KDE control for configuring my multi-head setup: System Settings → Display After some experimentation, this was fine. But as soon as I logged out and back in again, the settings were lost. Here's what you can do:
  1. As before, configure your display as required and leave the configuration tool
  2. at this point, the settings have been saved in
    as a set of xrandr commands
  3. you can test these settings by logging out and in again and then running this script
  4. what we really want to do is execute this script as we login; presumably KDE does attempt this but if the X session is not ready, then nothing happens. We could add it to our profile or .bashrc, but then it would execute every-time we opened a terminal. Instead add a link to the script in
    then it will execute as KDE comes up for your user's account

Of course, this is only a workaround for KDE which should be doing it for us; if anyone has a better plan, please let me know.

Despite this minor hiccup, I am loving OpenSuse 11.3 - it actually feels quicker and more responsive than 11.2 and several tools that I use all the time have improved dramatically. Well done the Suse team on delivering such a painless upgrade!

© 2013 Andy Ferguson