At a guess, because the script actually calls the setup program with a
response file. My guess would be it is actually setup requiring X
access...

I am sure you are right.  It just seems odd to supply a command line
installer that still requires graphics mode.  Makes life harder for a
sysadmin doing a remote install.

As far as I know we don't need a running Xserver but the libraries. We
will change the behaviour for a later OOo versions.

As far as I know we don't need a running Xserver but the libraries. We
will change the behaviour for a later OOo versions.

You can specify the option -nogui ( but only together with a
responsefile installation ) to the setup. This option should work
since OpenOffice643C.

*** This issue has been marked as a duplicate of 7630 ***

My report is for the "install" script which according to comment 2
already calls "setup" with a response file.  My suggestion is that the
install script should call the setup program with the -nogui option if
that is all that is required.

MH 

MH showed me the install script. I've just added the -nogui switch to
the setup -r ... call.
Fixed in cws setup07.

Hi, 
 
I did not know the -nogui switch existed in the >= 643. 
 
This is actually improtnat for the packagers and should be cc's to dev@installation since 
many Linux packagers end up using some sort of dummy X server to make sure the intall 
works with autoresponse files. 
 
Thanks, 
 
Kevin 
 
 
Does it still require the precense 

Please verify.

Is integrated in install script with cws setup07.

Verified.

Works is fixed in OOo 1.1 Beta2. => closed

Installing OOo beta 2.  Problem is still there.

Ran "./install --prefix=/opt" get "cannot connect to X server message"

Set DISPLAY and used "xhost +" to temporarily enable root access to x
server and install script completes perfectly but never makes use of
any graphical capabililty (as far as I can tell).

Essentially - see comment 1.

Hi,  
  
Yes, the loader.c handles this properly if you are using an autoresponse file but in  
setup2/source/ui/unxmain.cxx you can see the following:  
  
unsigned char check_fontpath ()  
{  
        Display* display;  
        char* display_name = NULL;  
        if( (display=XOpenDisplay(display_name)) == NULL )  
        {  
                (void) fprintf( stderr, "cannot connect to X server\n" );  
                exit( -1 );  
        }  
        return check_fontpath(display);  
}  
  
So somehow the output of MayUseX needs to get passed from the loader.c to here  
to be used to prevent the attemtped connection to the X server if an autorespose file  
is being used.  
  
Hope this helps,  
  
Kevin  
  

Hi Dirk,
does it need any additional changes.

check_fontpath() will not be called when -nogui is set ( except when
-debug is set, too )

Hi,

A few observations... there is no -nogui switch supported by the code that is now 
tagged for cws_srx644_ooo11beta2

So perhaps setup2 for OOo does not have the features that your internal tree has?

Right now in cws_srx644_ooo11beta2 the code looks for the option -r: (and others) 
and then sets a MayUseX boolean value to false that if that is false the loader.c does 
not open the display but as far as I can tell check_fontpath is still called in that CVS 
version and so it does abort with the Can't access X error message.

So are there some internal to Sun changes that need to make it to the OOo 1.1 Beta2 
tree (cws_srx644_ooo11beta2) in time for the RC?

Thanks,

Kevin

*** Issue 18206 has been marked as a duplicate of this issue. ***

Hi, 
 
 
Copying this to hear so that it gets seen by Hamburg! 
 
There is not a  nogui switch supported in OOo 1.1rc3 source code in setup2. 
This must be a Star thing?  Or I am missing it someplace? 
 
There is a routine that is invokes "MayUseX" that looks to see if a response file is 
being used.  If so, it will not try to reference anything X related. 
 
But this fails when CheckFontPath() is invoked in setup.bin and so X is still needed. 
 
This one should have been fixed but whatever fix exists simply was not moved to 
OOo 1.1rc3. 
 
Kevin 
 
 

Hi, 
 
I think the culprit is the following piece of code in setup2/source/ui/unxmain.cxx in rc3 
 
unsigned char check_fontpath () 
{ 
        Display* display; 
        char* display_name = NULL; 
        if( (display=XOpenDisplay(display_name)) == NULL ) 
        { 
                (void) fprintf( stderr, "cannot connect to X server\n" ); 
                exit( -1 ); 
        } 
        return check_fontpath(display); 
} 
 
 
Kevin 
 

Hi, 
 
I did find this in setup2/source/ui/main.cxx 
 
   else if( aParameter == "NOGUI" )                        // NOGUI 
        eParameter = PAR_NOGUI; 
 
so it does look like the nogui code is there. 
 
So is simply adding -nogui enough? 
 
Does the NOGUI go in the response file itself or in the invocation of setup. 
 
Previously we had tried .... 
 
      ./setup -v -nogui -r:${TMPFILE} 
 
but that failed with unknown option? 
 
So how do we properly pass this parameter to setup.bin? 
 
Is it set in the response file itself?  If so where/how? 
 
cat << EOF >> ${TMPFILE} 
[ENVIRONMENT] 
INSTALLATIONMODE=$installtype 
INSTALLATIONTYPE=STANDARD 
DESTINATIONPATH=$prefix/$oo_home 
OUTERPATH= 
LOGFILE= 
LANGUAGELIST=<LANGUAGE> 
 
[JAVA] 
JavaSupport=preinstalled_or_none 
 
EOF 
 
 
Thanks, 
 
Kevin 
 
 

Hello Kevin,

I've just checked our OOo 1.1 rc3 linux version and everything works
fine for me. Do you really use version 1.114 of main.cxx. The setup
should be called with '-nogui' as argument. ( There had been a bug
with enforceing -nogui used together with -r ( use -nogui as last
parameter to work around that one ), but that bug has been fixed
before 1.114 ).
Did you get the message 'Initializing installation program.....' from
the loader?
BTW, you don't use the parameter '-debug', do you?

Perhaps, you can check whether the if or the else part of the
statement in line 412 of main.cxx is used?

Dirk

Hi, 
 
I see, I tested with rc2 by mistake and not rc3.  rc3 does now allow -nogui and I have 
tested it and all seems fine. 
 
I have asked for permission on releases to make this change for OOo 1.1 final since 
it has 0 risk of collateral damage. 
 
If it gets approved, all should be fine. 
 
BTW: does anyone know what needs to be changed in the response file itself to 
force a "full" installation (i.e. force the installation of all custom pieces) instead of just 
the default install? 
 
I think we should change install.sh to install everything and not just the default or at 
least add that as a command line switch. 
 
Thanks, 
 
Kevin 
 
 
 

Closed