From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)
Description of problem:
Star Office is installed on a local hard disk with the /net option. The
user's home directories get mounted from a HP-UX server via NFS. Things
worked perfectly with our RedHat 6.2 machines. But since we introduced
RedHat 7.1 on some of our machines Star Office won't work on those
machines. The error messages differ depending on whether the user has used
Star Office before.
Steps to Reproduce:
a) User that has not previously used Star Office:
1. Run soffice. "User" part of the installation will run as expected.
2. Run soffice again.
b) User who has previously used Star Office on RH 6.2 (meaning that the
configuration files are already in place in his home directory):
1. Run soffice. Star Office will work as expected.
2. Close Star Office.
3. Run soffice again.
a) Star Office will abort loading with the message "failed to load
b)An error message "Error loading document
macro://#initialize.Explorer.Main() BASIC >runtime error Object variable
not set" will appear. After clicking "Ok" Star Office is started but the
icons on the Star Office desktop are missing and the file open/save dialogs
don't contain any files or directories so working with Star Office is not
Expected Results: Star Office should have started up normally and show the
Star Office desktop.
If a user with the "corrupted" configuration files from RH 7.1 goes back to
RH 6.2 Star Office will have the same error messages. The only thing that
helps is deleting the configuration files and doing the user part of the
installation again on RH 6.2.
We're using StarOffice 5.2 on NFS mounted home directories (both RH6.2 and RH
7.1) just fine. I've patched StarOffice with updates available from sun...
maybe that will help you too.
I can confirm this bug: all old rh 6.2 workstations have only some little
problems, but RedHat 7.1 with all updates and several kernels from the 2.4 tree
can't use StarOffice 5.2 anymore. When I softlink .user52.rdb and the
so2-directory to a local disk area, everything runs well.
Because the dmfe driver isn't included in the standard rh kernel I always have
to recompile the kernel by myself. I even tried the new 2.4.6 and discovered an
horrible nondeterministic bug: I copied two files to to an 6.2 NFS-server, two
7.1 clients with 2.4.6 kernel couldn't see the files with ls - although I could
get them with cat !!!
One Debian system and older rh-versions hadn't a problem to ls these two files.
What's going on here? People at my company don't like rh-versions greater than
6.2 because things go worse than better.
Where is the solution of the StarOffice problem? It has something to do with NFS
and the new kernel, I can definetely confirm that.
I found a workaround: Install StarOffice 5.2 remote on a RH 6.2 system with your
home NFS-mounted to this remote host, then use StarOffice on the local host with
2.4.x-kernel. This explains the comment above.
Well, the previous workaround will work fine unless the user decides to do
something in Preferences. Then Star Office will try to write to the
configuration file(s) and corrupt them and we have the same problem again. The
only working workaround I see at the moment is a wrapper script that does the
- check if configuration files exist in the user's home (meaning Star Office has
already been started and installed), if not, give the user default configuration
files created by a local "dummy" user
- copy the configuration files to a directory in /tmptmp (or any other local,
- set $HOME to this directory
- start Star Office
- when Star Office has finished, copy the configuration back to the user's home
and reset $HOME
Seems to have gone away with the 2.4.9 kernel upgrade.
This may be a duplicate of bugid #52652.