[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Strange LMI installation failure under Windows 7 SP1: /cache_f
Re: [lmi] Strange LMI installation failure under Windows 7 SP1: /cache_for_lmi/downloads not found
Sun, 5 Oct 2014 00:13:35 +0200
First of al, sorry for the long and rambling email, I tried to condense it
by chopping off the various tangents that ended up being irrelevant, but
it's probably still too long. The summary is that I found the real problem
and the solution is in the last paragraph of this email, please skip
directly to it if this is all you want to know, the rest of the email just
retraces how I got there.
On Sat, 04 Oct 2014 15:53:27 +0000 Greg Chicares <address@hidden> wrote:
GC> Just to be sure...are you following the steps in 'INSTALL'?
Yes and I've just restarted from scratch from a saved VM checkpoint. And
I'm relieved to be able to say that I could reproduce the problem, mostly
because I would have been left feeling really stupid if I couldn't...
GC> Its first steps are:
GC> | Open a "Command Prompt" window, and enable pasting into it:
GC> | Copy and paste the following lines into the "Command Prompt" window:
GC> | C:
GC> | mkdir C:\cache_for_lmi
GC> By this point, 'C:\cache_for_lmi' must exist--unless msw 'mkdir' failed,
GC> but you would have noticed that.
GC> Then 'install_cygwin.bat' is run in that CMD session; one of its
GC> commands is:
GC> echo C:/cache_for_lmi /cache_for_lmi lmi_specific binary,user 0 0
The problem is here: "echo" writes to the wrong fstab. See below for my
explanation of why does it happen, but, regardless of the explanation, the
fact remains that after running install_cygwin.bat, I have fstab with this
and the other lines from install_cygwin.bat in C:\cache_for_lmi directory,
while the real fstab in C:\cygwin-lmi\etc is left unmodified.
And this happens because "start /wait" command doesn't actually wait until
the end of the Cygwin installation and because of this the line "cd
C:\cygwin-lmi\etc" tries to change to the non-existent directory, fails and
so the subsequent echoes write to the wrong file. If I apply this:
@@ -36,6 +36,8 @@ START "Installing Cygwin" /WAIT setup-x86 ^
--root C:/cygwin-lmi --packages ^
echo # >> fstab
echo C:/opt/lmi/MinGW-20090203 /MinGW_ lmi_specific binary,user 0 0 >>
echo C:/opt/lmi /opt/lmi lmi_specific binary,user 0 0 >>
change, then the output from the script is:
The system cannot find the path specified.
Press any key to continue . . .
Cygwin installation seems to have succeeded
It took me some time to find the reason for this weird behaviour, but
finally it turns out that this is due to something weird that Cygwin setup
program does: it seems to detect dynamically whether it needs to run with
"elevated" (i.e. administrator) rights or not and displays the UAC ("User
Account Control") dialog if it does and, crucially, launches another copy
of itself with elevated credentials when it's accepted. Because of this,
"start /wait" exits as soon as UAC dialog is accepted and not when the
setup really ends.
And this also gives the solution, or even two of them: we can use either
-B/--no-admin or -W/--wait option of Cygwin setup. These options are not
documented, but then so are all the other setup command line options (as
https://sourceware.org/cygwin-apps/setup.html notes, they are "really an
under-development feature" and the link provided there dating from March
2003 seems to be their latest available description), so I don't think this
should prevent us from using them. They are also only present in relatively
new versions of the setup: as it's impossible to view the setup repository
history online (the link to it at the above page is broken and I didn't
find any other place) and importing it into local git repository is still
not finished (after more than hour), I'm not sure when exactly was it added
but I know that 2.774 didn't have -B (and -W was added even later) while
2.831 did have it (FYI the current version is 2.850). But as the
instructions in the INSTALL file tell yo use the latest version anyhow,
this shouldn't be a problem.
The only remaining question is whether --wait or --no-admin should be
used. They both work in the sense that "start /wait" really waits for setup
to finish if either option is used, however they do quite different things:
the first one preserves the current behaviour, i.e. UAC dialog will still
be shown, and the process showing it will launch another version of setup,
but will just wait for its termination. While with --no-admin, UAC won't be
used at all, which means that installing would only work for the current
user and not all users.
My suggestion is to add --wait option for now as this won't change
anything at all, other than fixing the problem at hand. But if you also
want to allow users without administrative permissions to install LMI on
Vista and later versions of Windows, then you want to use --no-admin
Please let me know if there is anything else I can do to help with this,