There is an open bug (8930861) with Oracle 11g R2 that causes the Database Configuration Assistent (DBCA) to not start on 32 bit Linux. If you see somthing like
An unexpected error has been detected by HotSpot Virtual Machine:
# SIGSEGV (0xb) at pc=0xa2bbd36e, pid=19555, tid=3085252272
# Java VM: Java HotSpot(TM) Server VM (1.5.0_17-b02 mixed mode)
# Problematic frame:
+# C [libnnz11.so+0x3c36e]+
you have probably hit it. (The above message is copied since I have meanwhile deleted the 32 bit VM. In my case the address was slightly different but the rest of the message was obviously coming from the same underlying reason.) The current workaround is to install on a 64 bit Linux. Given that probably no-one is running a 32 bit version in production these days, this seems acceptable. Also, chances are that this will never be fixed because of the aforementioned lack of 32 bit versions running in production.
Sometimes people wonder why Oracle DB (both 10g and 11g) will not start after installation on Linux/Unix. In many cases the simple reason is the content of /etc/oratab. For each database it contains a line in the format
$ORACLE_SID:$ORACLE_HOME:START_DB_FLAG:The last column is set to “N” by default. Just change it to “Y” and run $ORACLE_HOME/bin/dbstart again. Your database should come up now.
When you are running Linux (or any other Unix-like OS) on a mobile computer, you may have a bit of a problem with mounting shares from a server. On a normal PC with a fixed connection to the server, you would simply add the appropriate entries to /etc/fstab and have them mounted automatically during startup. But since I am not “always on”, this was not an option. So I added the “noauto” option to the entries in /etc/fstab, which effectively means that they get ignored during system startup. Of course I could later call
mount /my/mountpoint manually for each entry. But this is cumbersome. So I went and wrote a small script (download here). For security reasons the extension of the script is set to .sh.txt instead of .sh, so you will need to rename it before execution.
There are a few conditions for the script to work:
- Effectively the script will call “mount /my/mountpoint” for each relevant entry in /etc/fstab. All configuration details for the actual mount operation need to be provided in /etc/fstab. So before running the script, make sure those manual calls go through without problems.
- For CIFS mounts the credentials should be provided using the “credentials” option from mount.cifs (see respective man page for details). Those can then be protected properly. And should there be several people using the system, they can maintain their passwords by themselves.
- Currently there is connectivity check to the server(s). So you will get delays/errors when calling the script without a proper connection.
The script will detect whether a particular mount point is in use and skip the respective entry for mounting. The same goes for umount when the mount point is not used.
For CIFS mounts you will most likely need to call the script with sudo. At least on Fedora 12 I could not get mount.cifs to work for normal users, event with the SETUID bit set.
The file system type for the mount command has been changed from smbfs to cifs. So using “-t smbfs” will not work any more. Instead you need to enter something like this:
mount -t cifs -o username=user[,uid=500,gid=500] //machine/share[/path] /mountpoint
There seems to be a documentation bug in the man pages, because they still mention smbfs.