Re: OOo 1.1 in sid with rootfs mounted readonly via NFS
On Mon, 2004-02-23 at 11:46, Gavin Hamill wrote:
> I seem to have the same problem as this guy, but his e-mail address now
> bounces, and was curious if the problem has since come to light by
> others before I file a more formal bug report:
I've not had any more feedback on the problem that he had.
> A .openoffice directory isn't even created in $HOME, nor .sversionrc
> (name from memory...).
>
> The last .ttf that's opened is one of the Bitstream Vera family which is
> being used for the main KDE display, so they seem to be correctly
> configured (I tried reinstalling them anyway, just in case)
OK.
> I've also looked through strace outputs, and none of it seems to suggest
> anything is particularly wrong, but will of course provide a full trace
> if needed :)
>
> One of the irritating bits is that I see it trying to write a
> 'Setup_err.txt' (again, filename from memory...) but being 'access
> denied' - I assume then it's trying to write the errorlog to somewhere
> in /usr rather than $HOME where OOo was launched. Is there some way to
> override this so I can find where it's failing?
I don't know. You could try running /usr/lib/openoffice/setup instead
of letting the wrapper run it for you. You might get some extra
information that way.
Also, take a look at this upstream issue:
http://www.openoffice.org/issues/show_bug.cgi?id=17517
"The problem was resolved when I started to use the nfs-kernel Debian
package instead of nfs-user Debian package."
Also, does the workaround described help?
"I've done some experiments on NFS and the problem seems connected
with
the lock options. Infact by setting
STAR_PROFILE_LOCKING_DISABLED=1
export STAR_PROFILE_LOCKING_DISABLED
into program/soffice all seems to work.
Another way is to mount nfs area with -o nolock option."
If you still have a problem, file a bug report to help keep track of the problem.
Chris
Reply to: