Firmware (LuxOS)
Tools
LuxOS Config File
General configuration

General configuration

Application options

The first section is app, which control general options:

[app]
autosave = true
immersion = false

The autosave key controls wether the changes on the runtime made via API to the configuration will be saved or not. When enabled, every change triggers first a backup of the current TOML file (in the /config/backup directory, with the current UTC timestamp as suffix), and then save the new values on the existing files. Note that only certains commands trigger autosaving.

The immersion key indicates wether immersion mode is enabled or not. When enabled, this mode sets the fan speed to a fixed zero, and ignores the minimum number of fans check.

Logging

The logging configuration is stored in app.logging:

[app.logging]
level = "info"
file_level = "debug"

The level key controls the logging level on stdout. If you're not running the miner in you ssh session and looking at the live logs while your miner runs, you might as well leave it as off if you want.

The file_level is the logging level for file output. Each time luxminer is ran, a brand new /logs/<DATE>/luxminer.log file is created, and the previous file is kept in the same folder, with a timestamp suffix. Log file rolling happens every run, or when the file reaches around 50MB. Past log files are automatically discarded when the system is close to running out of space. Note that on NAND installs, the /logs directory might be redirected to the ramdisk (/mnt/ramdisk/logs) to avoid writing too much on NAND memory.

Both keys can accept either a single "level" value (error, warn, info, debug or trace), or a complex logging filter in the form of module=level, to use different levels for different pieces of the system.

💡

Logging and performance

Choosing the right level of logging depends on a multitude of scenarios like available disk space and being able to track down eventual failures. The correct logging level, will depend of your needs.

As a general rule, more verbose level incurs in more performance penalty, but allows for much more detail when troubleshooting. When requesting support help, try to do the minimun steps to reproduce the problem with file_level=trace.

API access

API access can be configured on the app.api section:

[app.api.tcp]
enabled = true
port = 4028
 
[app.api.http]
enabled = true
port = 8080

The "core" API is a TCP, CGMiner-like API, running on port 4028 by default. Additionally, an HTTP RPC layer on port 8080 is provided to make integration with different tools and languages easier. Any of them can be disabled by changing the enabled field.

It is recommended to leave the API ports on the default setting since they are used (or assumed) as default for most tools and scripts, so consider changing or disabling those ports only if you have a good reason to do so. For usage information and examples, check the API section of the documentation.

🚫

If you disable the HTTP layer, the built-in LUXminer UI won't be able to communicate with the miner.

Pool options

It is also possible to configure the pool connection switching with app.pool_options:

[app.pool_options]
smart_switch = true
smart_switch_secs = 60
timeout_secs = 5
max_errors = 5
backoff_on_error = true

The smart_switch, when enabled (default) will switch back to the main pool automatically when it becomes available again. The check is done every smart_switch_secs seconds. The maximum number of connctions before going to the next pool, and the timeout for each connection attemps are determined by max_errors and timeout_secs, respectively. The backoff_on_error field adds an incremental backoff on subsequent connection errors, which helps when the network struggles to connect to the pools.

Auto updates

The auto update configuration can be set with on the update key:

[update]
source = "https://storage.googleapis.com/luxor-firmware/stable"
timeout = 60
on_startup = "off"
on_timeout = "off"
on_user = "full"

The source points to the URL that is the source of updates, and points by default to the stable channel. The timeout and on_timeout triggers defined when the automatic update will trigger (in minutes), and what action will happen on that timeout. Since the action is off by default, nothing will happen and the miner won't be automatically updated. Likewise, on_startup is also off; if it is changed to full, update will be atempted every time the miner starts.

Only the on_user trigger is full by default. This is trigger is activated via UI, when the "Check for updates" button is clicked by the user.