Skip to main content

Posts

Showing posts from February, 2010

Installing Oracle VM Manager on Fedora

Although my Oracle VM Manager was running on OEL, I reinstalled the machine with Fedora and obviously I wanted the OVM Manager back on it. The installation was pretty straight forward. Two tiny things had to be done in order to convince the installer to proceed. I needed to comment out the checks for the OS and the libaio package. After this the installer was on its way. During the Oracle XE installation I adapted the swapfile (created a big additional swapfile) as the XE installer decided to stop when tere was not enough swap space. Conclusion: OVM Manager runs fine on Fedora.

Starting with my OVM

Added a 1 TB disk to my OVM machine :-) [root@ovm ~]# mkfs -t ext3 /dev/sdb mke2fs 1.39 (29-May-2006) /dev/sdb is entire device, not just one partition! Proceed anyway? (y,n) y Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 122109952 inodes, 244190646 blocks 12209532 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 7453 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 38 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [root@ovm ~]# So - now the fun...

dbca - Exception in thread "main"

Sometimes error messages are very misleading. If you see an error stating: Exception in thread "main" you expect that this is some java-related issue. Maybe the classpath is wrong, your JAVA_HOME is not set, etc. I had this error when I was starting up the Oracle dbca. After some checks and different tries I found out that the DISPLAY environment was set, but to a different screen, which I was not using. So even when you check the dbca shell script, you will find a build-in check for the DISPLAY environment. But now the check passed with flying flags - as it was set. The problem that my dbca was unable to use this DISPLAY lead to the java error. Setting the DISPLAY to the one I was using (and setting xhost to allow all) solved this.