Re: [lmi] Strange LMI installation failure under Windows 7 SP1: /cache_for_lmi/downloads not found

[Greg Chicares]

On 2014-08-18 16:30Z, Vadim Zeitlin wrote:
> 
>  I've set up a fresh virtual machine with Windows 7 SP1 for LMI testing.
> Following the usual instructions, I've installed Cygwin without problems
> and launched install_msw.sh. After just a few minutes, the script
> terminated with "Finished building lmi." message but I quickly realized
> that actually LMI wasn't built and was nowhere to be found under /opt/lmi.

It's been a long while since I've run that script myself, or updated
Cygwin on my machine. They recently updated their coreutils binaries
after a long hiatus, so I wonder if that might be the cause somehow.

>  Examining the log file revealed surprising error messages: after setting
> up the mount points there is this:
> 
>       find /cache_for_lmi/downloads -type f | xargs md5sum
>       find: ‘/cache_for_lmi/downloads’: No such file or directory
>       d41d8cd98f00b204e9800998ecf8427e *-
> 
> This error happened in spite of successful execution of
> 
>       mkdir --parents /cache_for_lmi/downloads
> 
> at the very beginning of the script and in spite of the fact that the
> directory did exist after install_msw.sh termination.

I wonder whether splitting that up to avoid "--parents" would work:
  mkdir /cache_for_lmi
  mkdir /cache_for_lmi/downloads
But that seems wrong, because '/cache_for_lmi' must already exist:
that's a postcondition of 'install_cygwin.bat'. So, really, '--parents'
here should serve only to suppress an error message if the subdirectory
already exists.

> Also, further down in
> the log there is
> 
>       cd /cache_for_lmi/downloads && echo "6bba3bd1bf510d152a42d0beeeefa14d 
> *binutils-2.19.1-mingw32-bin.tar.gz" | md5sum --check
>       /bin/sh: line 0: cd: /cache_for_lmi/downloads: No such file or directory
>       install_mingw.make:251: recipe for target 
> 'binutils-2.19.1-mingw32-bin.tar.gz' failed
>       make: *** [binutils-2.19.1-mingw32-bin.tar.gz] Error 1
> 
> However the next command does find the directory successfully:
> 
>       cd /cache_for_lmi/downloads && echo "ada423c49bc5bfa7c3e7a80a711c2a1a 
> *mpatrol_1.4.8.tar.gz" | md5sum --check
>       mpatrol_1.4.8.tar.gz: OK

So 'cd' fails at first, but later succeeds with the same directory.
Maybe 'mkdir' functions in a "lazy" way due to caching?

>  I don't understand at all what's going on here. My hypothesis is that
> mounting C:/cache_for_lmi on /cache_for_lmi has somehow temporarily
> confused Cygwin but this seems pretty unconvincing even to me.

Me too. Could there have been a conflicting mount point for this
directory before the script was run? The script explicitly
contemplates that possibility, and tries to work around it; but
maybe the 'mount' command's behavior has changed. Does your
/etc/fstab offer any clue? Mine says:
  C:/cache_for_lmi          /cache_for_lmi lmi_specific binary,user 0 0

Do you have a directory (or other file) such as
  C:\cygwin-lmi\cache_for_lmi
in the Cygwin directory? That could cause confusion.

> After
> restarting the script the problem doesn't appear any more and I'm not sure
> if it's worth trying resetting the virtual machine and repeating everything
> from scratch if there is such a simple workaround. However I wanted to post
> it here just so that this remains in the archives and could be found if
> anybody else has this problem in the future.

I'll test it myself, but I won't have time for that until next month.

>  There is also clearly a problem with detecting the script success. IMO it
> shouldn't continue running if any of the steps failed, i.e. I'd just add
> "set -e" to the top of it. But if this is too extreme, it should at least
> exit with a clear error message if installing the compiler fails,
> continuing in this case just doesn't make any sense.

That's deliberate. Maybe not ideal, but deliberate. Perhaps there are
some commands whose failure may be tolerable, so that "set -e" would
cause the script to fail when it would otherwise work acceptably.