Rebooter Command Line Params / Config File

[wdsk]

Hi,

I saw other Rebooter-related posts here in the General forum, so here is where I'm posting mine.

Looking at the help, Rebooter can be invoked and have the following parameters passed to it:

-Reboot
Perform a reboot according to the parameters in the saved configuration file. The count down to a reboot will start immediately after the program has started. All buttons are disabled (as if the user had hit the Start Cycle button). The type of reboot / restart performed will be whatever was lasted saved in the configuration file.
Note: When Rebooter is started from BurnInTest, the Rebooter setting of "Auto load Rebooter at startup" is not applied. This allows BurnInTest to be setup as the auto restart program, and avoids the conflict of both BurnInTest and Rebooter auto starting after a reboot. This means that only a single reboot will be performed when rebooter is run from BurnInTest. To perform multiple reboots from within BurnInTest a script should be used with multiple REBOOT commands.
-Config
Allows the user to change and save the settings but not do a reboot. This is useful when Rebooter is integrated into another external application. The external application can call Rebooter with this option to allow the user to configure various parameters then call Rebooter once again with the –Reboot argument to effect the Reboot.
-p
Forces Rebooter to use the rebooter.exe directory rather than the User's personal directory for configuration and log files etc. This may be useful when running rebooter from a USB drive. Note: If BurnInTest is started with the -p command line parameter then BurnInTest will start rebooter with the -p command line parameter.
Example – Execute a reboot from the command line
rebooter -reboot"


Unfortunately, for what I'm trying to do, that's no good. I want to have a user set up and run a test remotely. They enter the input parameters in the test application (type of reboot, delay time, etc) and these parameters get passed to the script that invokes Rebooter. From there, the user doesn't need to look at the system until the test is complete.

I looked at the Sleeper implementation for the above scenario and it was pretty straightforward. But that's because Sleeper allows nearly all the test parameters to be passed to the application when it's invoked. Since Sleeper and Rebooter aren't all that different from a cursory viewpoint, I wanted to know why this was the case, and if there's any way to work around Rebooter's limitation.

Any information is appreciated, thank you.

[wdsk]

To put it more simply:


PassMark Sleeper allows you to enter all parameters from the command line. For example...


sleeper.exe -S0010 -D 1 -E -L C:\sleepertest\sleeper.log -N 1 -P 1 -R 300


...but Rebooter is not nearly as flexible. What's the reason behind this, and are there any future plans to allow for a more robust control of Rebooter settings from the command line?

[Ian (PassMark)]

I don't remember the specifics as to the reasons Sleeper has more command line parameters than Rebooter (maybe a company paid us to implement these).

There are currently no plans to modify Rebooter to support command line parameters to allow all of the configuration options to be controlled via the command line, such as, Maximum reboots, Reboot Type, Forced shutdown, delay, etc. You will need to pre-configure rebooter and use this configuration.

You could possibly work around this by creating multiple configuration files using the Rebooter user interface, then depending on the requirement, copy a specific configuration file into the rebooter documents directory (C:\Users\<user>\Documents\PassMark\Rebooter\Reboo terConfig.ini)

[wdsk]

You could possibly work around this by creating multiple configuration files using the Rebooter user interface, then depending on the requirement, copy a specific configuration file into the rebooter documents directory (C:\Users\<user>\Documents\PassMark\Rebooter\Reboo terConfig.ini)

The only problem is that the config file is coded, so it would take an extreme amount of time to figure out what 5 cycles, 10 cycles, 20 cycles, etc. translate to in the config language. Since I would want to give the user the option to set the cycles anywhere from 1-500, translating that many numbers just isn't practical.

[wdsk]

Truly though, it isn't important that I decipher the coded config file. As long as the settings are stored, I suppose I could create the config file, save it, file it with the appropriate label, and move on, from 1-500 cycles for both shutdown and reboot mode... it's just so tedious!

[Ian (PassMark)]

Yes, I was suggesting using Rebooter to create multiple configuration files, renaming them, and keeping a set of different configuration files. I would not suggest trying to reverse engineer the configuration file format and write your own config files.

If you really need to use over 500 configurations, then maybe it makes sense to get a quote from us to change Rebooter. If so, please send us an email: help [at] passmark [dot] com

[wdsk]

If you really need to use over 500 configurations, then maybe it makes sense to get a quote from us to change Rebooter. If so, please send us an email: help [at] passmark [dot] com

This might be a better solution. Thank you for the information.