setup-x86_64.exe --quiet-mode issues using Management Tools

[Brian Inglis]

On 2020-04-21 08:17, Bill Stewart wrote:
> On Tue, Apr 21, 2020 at 7:56 AM KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
>> Are you sure that a setup that is automated with a silent installation, but
>> it still displays a progress popup, it cannot fail if it is not able to
>> display that window when there is no user logged in? I am not, hence I
>> would prefer that setup could ensure a real background operation.
>>
>> An exception displaying the progress window could lead to the interruption
>> of the installation process. That is a blocking condition as well, even
>> though no input is required by the user.

> An exception during the installation would only block if it prevents the
> process from closing (i.e., if it displays a message box). That could happen
> in an installation even if the installer isn't displaying a GUI.
> 
> What I am saying is what's important about automated installation is that it
> not block (even in the case of an exception). Whether the installer displays
> a GUI or not is really irrelevant, particularly if the installation isn't
> running as the current user (in which case the current user doesn't see the
> GUI anyway).

One issue with the -M, --package-manager semi- and -q, --quiet-mode unattended
installs are that any errors are logged only in /var/log/setup.log.full, which
is overwritten by the next run, with only a summary log remaining at the end of
the cumulative /var/log/setup.log, and not all error or warning messages are
significant.

The is especially likely if *any* Cygwin processes are running when setup
starts, so you need to kill off any processes running any commands or using any
DLLs under the Cygwin root, before running setup.

You will have to manage the processes and error logs with your network install
wrapper, although some work could be delegated to permanent postinstall
[0z]p_...sh scripts in /etc/postinstall/.

The order of running postinstall script is alpha order, I believe under the
default/POSIX/C locale, with 0p_...sh scripts run before and zp_...sh scripts
run after all others.

It is *essential* that /etc/postinstall/0p_000_autorebase.dash always run first
and to completion without errors, as otherwise Cygwin DLLs could overlap,
especially under Cygwin 32 installs, and any program could fail, with a variety
of possible errors.

As part of my Cygwin profile, I check for any remaining files matching
	/etc/postinstall/[!0z][!pqrst][!_]*.*sh
or
	/{,usr/}{,*86*/**/}{*bin,lib}/*.{dll,exe}.new
as new exes and DLLs should replace the old files before postinstall scripts
run, and non-permanent package postinstall scripts should be renamed with .done
suffixed after execution, otherwise setup needs to be rerun with no Cygwin
processes running, or the system needs to be restarted, as Cygwin may have
created a Windows post-install script to complete the replacements.

You will also have to manage upgrades with -g, --upgrade-also to handle
upgrading to get security and other urgent regular base package maintenance
patches applied, for example Windows release support in Cygwin, and crypto,
ca-certificates, openssl, tzdata package upgrades.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.