Rebooting
From WPKG | Open Source Software Deployment and Distribution
WPKG can reboot the machine if needed. Rebooting can be defined in a package definition in two places:
- after a command exited with a given code,
- after all commands were executed.
command exited with a given code
Here, we schedule a reboot when the below command exited with code 3010. Note where 'reboot="true"' entry is located:
<install cmd='msiexec /qn /i "%SOFTWARE%\package.msi"' >
<exit code="3010" reboot="true" />
<exit code="0" />
</install>
<install cmd='%SOFTWARE%\fix_icons.bat' />
The reboot=true attribute on an exit code forces an immediate reboot. Unfortunately all following commands are skipped then. Sometimes (maybe even more often) you might like to just set the package reboot flag depending on a command exit code. Therefore, you can use reboot='delayed' within the command nodes. This allows to schedule a reboot instead of immediately executing it. The effect is the same as setting reboot='true' on package level (reboot after executing all commands. However it allows you to leave reboot='false' on package level and schedule a reboot based on command exit codes. Other possible values are reboot='postponed', reboot='false', and undefined, which defaults to 'false' - see down below for more details.
rebooting after executing all commands
To reboot after all commands were executed, define your package similarly to the one below. Note the 'reboot="true"' entry:
<package
id="sample_package"
name="This package will reboot after "
revision="1"
reboot="true">
<check type="uninstall" condition="exists" path="Sample entry in Add or Remove Programs" />
<install cmd='"%SOFTWARE%\sample\myprogram.exe" /silent'>
<install cmd='"%SOFTWARE%\sample\fixlinks.bat'>
<remove cmd='%PROGRAMFILES%\sample\uninst.exe -quiet' />
<upgrade cmd='"%SOFTWARE%\sample\myprogram.exe" /silent' />
<upgrade cmd='"%SOFTWARE%\sample\fixlinks.bat'>
</package>
"true", "false" and "postponed" are allowed as a value of the reboot attribute within the package node. The states have the following effect: "true" Immediate reboot after package installation. This will take precedence of any command-level reboot="postponed" attribute if present and reboot immediately after package installation. A reboot="true" attribute on command-level will still result in an immediate reboot. Resulting status depending on command-level reboot flag: "true" immediate reboot after command execution "delayed" reboot after package installation "postponed" reboot after package installation "false" reboot after package installation "postponed" Schedule reboot after installing all packages within this session, for example after synchronizing. Resulting status depending on command-level reboot flag: "true" immediate reboot after command execution "delayed" reboot after package installation "postponed" reboot after all actions are completed "false" reboot after all actions are completed "false" No reboot unless one is defined at command-level. or not set Resulting status depending on command-level reboot flag: "true" immediate reboot after command execution "delayed" reboot after package installation "postponed" reboot after all actions are completed "false" no reboot As a result there are four possibilities to schedule a reboot in order of precedence: immediate Command node specified reboot=true, immediate reboot takes place. package Reboot is issued right after installing: - package specifies reboot="true" OR - any command node specified reboot="delayed" postponed Reboot will take place after all packages have been applied. - package specifies reboot="postponed" OR - any command node specified reboot="postponed" none No reboot is issued by this package: - package does not specify reboot or specifies reboot="false" AND - no command node specified any form of reboot reboot This means that an immediate reboot always has the highest priority. You can just set "reboot markers" on a "timeline" on package and command level where the closest reboot marker will be executed: immediate => package => postponed => none Exit code 0 is not any more automatically regarded as "successful" value. Even code 0 is now evaluated by exit code nodes. If no node is found it is still assumed that the command was successful. This allows administrators to schedule a reboot (immediate/delayed/postponed) even on exit code 0.