NAME

novaboot - Boots a locally compiled operating system on a remote target or in qemu

SYNOPSIS

novaboot --help

novaboot [option]... [--] script...

./script [option]...

DESCRIPTION

Novaboot makes booting of a locally compiled operating system (OS) (e.g. NOVA or Linux) on remote targets as simple as running a program locally. It automates things like copying OS images to a TFTP server, generation of bootloader configuration files, resetting of target hardware or redirection of target's serial line to stdin/out. Novaboot is highly configurable and makes it easy to boot a single image on different targets or different images on a single target.

Novaboot operation is controlled by configuration files, command line options and by a so-called novaboot script, which can be thought as a generalization of bootloader configuration files (see "NOVABOOT SCRIPT SYNTAX"). The typical way of using novaboot is to make the novaboot script executable and set its first line to #!/usr/bin/env novaboot. Then, booting a particular OS configuration becomes the same as executing a local program – the novaboot script.

Novaboot uses configuration files to, among other things, define command line options needed for different targets. Users typically use only the -t/--target command line option to select the target. Internally, this option expands to the pre-configured options. Novaboot searches configuration files at multiple places, which allows having per-system, per-user or per-project configurations. Configuration file syntax is described in section "CONFIGURATION FILES".

Novaboot newcomers may be confused by a large number of configuration options. Understanding all these options is not always needed, depending on the used setup. The figure from the doc directory shows different setups that vary in how much effort is needed to configure novaboot for them. The setups are:

A: Laptop and target device only: This requires to configure everything on the laptop side, including a serial line connection ("--serial", "--remote-cmd", ...), power on/off/reset commands ("--reset-cmd", ...), TFTP server ("--copy", "--prefix"...), device IP addresses, etc.
B: Laptop, target device and external TFTP server: Like the previous setup, but the TFTP (and maybe DHCP) configuration is handled by a server. Novaboot users need to understand where to copy their files to the TFTP server ("--copy") and which IP addresses their target will get, but do not need to configure the servers themselves.
C: Novaboot server running novaboot-shell: With this setup, the configuration is done on the server. Users only need to know the SSH account ("--ssh") used to communicate between novaboot and novaboot server. The server is implemented as a restricted shell (novaboot-shell(1)) on the server. No need to give full shell access to novaboot users on the server.

Simple examples of using `novaboot`:

To boot Linux (files bzImage and rootfs.cpio in current directory), create mylinux file with this content:

#!/usr/bin/env novaboot
load bzImage console=ttyS0,115200
load rootfs.cpio

Booting an OS in Qemu can be accomplished by giving the --qemu option. Thus running
```
novaboot --qemu mylinux
```
(or ./mylinux --qemu as described above) will run Qemu and make it boot the configuration specified in the mylinux script. How is qemu started can be configured in various ways (see below).
Create a bootloader configuration file (currently supported bootloaders are GRUB, GRUB2, ISOLINUX, Pulsar, and U-Boot) and copy it with all other files needed for booting to a remote TFTP server. Then use a TCP/IP-controlled relay/serial-to-TCP converter to reset the target and receive its serial output.
```
./mylinux --grub2 --copy=192.168.1.1:/tftp --iprelay=192.168.1.2
```
Alternatively, you can put these switches to the configuration file and run:
```
./mylinux --target mytarget
```
Specifying all the options needed by novaboot to successfully control the target, either on command line or in configuration files, can be difficult for users. Novaboot supports configuring the target centrally via novaboot-shell(1) on a server. With such a configuration, users only need to use the --ssh option to specify where to boot their OS:
```
./mylinux --ssh myboard@example.com
```
Typically, the server is the computer connected to and controlling the target board and running the TFTP server.
Run DHCP and TFTP server on developer's machine to boot the target from it.
```
./mylinux --dhcp-tftp
```
This usage is useful when no network infrastructure is in place, and the target is connected directly to developer's box.
Create bootable ISO image.
```
novaboot --iso -- script1 script2
```
The created ISO image will have ISOLINUX bootloader installed on it, and the boot menu will allow selecting between script1 and script2 configurations.

OPTIONS AND PHASES

Novaboot performs its work in several phases. Command line options described bellow influence the execution of each phase or allow their skipping. The list of phases (in the execution order) is as follows.

1. Configuration reading
2. Command line processing
3. Script preprocessing
4. File generation
5. Target connection
6. File deployment
7. Target power-on and reset
8. Interaction with the bootloader
9. Target interaction

Each phase is described in the following sections together with the command line options that control it.

Configuration reading phase

After starting, novaboot reads zero or more configuration files. We describe their content in section "CONFIGURATION FILES". By default, the configuration is read from multiple locations. First from the system configuration directory (/etc/novaboot.d/), second from the user configuration file (~/.config/novaboot) and third from .novaboot files along the path to the current directory. Alternatively, a single configuration file specified with the -c switch or with the NOVABOOT_CONFIG environment variable is read. The latter read files override settings from the former ones.

The system configuration directory is determined by the content of NOVABOOT_CONFIG_DIR environment variable and defaults to /etc/novaboot.d. Files in this directory with names consisting solely of English letters, numbers, dashes '-' and underscores '_' (note that dot '.' is not included) are read in alphabetical order.

Then, the user configuration file is read from $XDG_CONFIG_HOME/novaboot. If $XDG_CONFIG_HOME environment variable is not set ~/.config/novaboot is read instead.

Finally, novaboot searches for files named .novaboot starting from the directory of the novaboot script (or working directory, see bellow) and continuing upwards up to the root directory. The found configuration files are then read in the opposite order (i.e. from the root directory downwards). This ordering allows having, for example, a project specific configuration in ~/project/.novaboot.

Note the difference between ~/.config/novaboot and ~/.novaboot. The former one is always read, whereas the latter only when novaboot script or working directory is under the $HOME directory.

In certain cases, the location of the novaboot script cannot be determined in this early phase. This situation happens either when the script is read from the standard input or when novaboot is invoked explicitly as in the example "4." above. In this case, the current working directory is used as a starting point for configuration file search instead of the novaboot script directory.

-c, --config=filename: Use the specified configuration file instead of the default one(s).

Command line processing phase

--dump-config

Dump the current configuration to stdout end exit. Useful as an initial template for a configuration file.

-h, --help

Print short (-h) or long (--help) help.

-t, --target=target

This option serves as a user configurable shortcut for other novaboot options. The effect of this option is the same as specifying the options stored in the %targets configuration variable under key target. See also "CONFIGURATION FILES".

When this option is not given, novaboot tries to determine the target to use from either NOVABOOT_TARGET environment variable or $default_target configuration file variable.

--ssh=user@hostname

Configures novaboot to control the target via novaboot-shell running remotely via SSH.

Using this option is the same as specifying --remote-cmd, --remote-expect, --copy --rsync-flags, --prefix and --reset-cmd manually in a way compatible with novaboot-shell. The server can be configured to provide other, safe bootloader-related options, to the client. When this happens, novaboot prints them to stdout.

Currently, this in an initial experimental implementation. We plan to change/extend this feature soon!

Script preprocessing phase

This phase allows modifying the parsed novaboot script before it is used in the later phases.

-a, --append=parameters

Append a string to the first load line in the novaboot script. This option can be used to append parameters to the kernel's or root task's command line. This option can appear multiple times.

-b, --bender

Use Bender chainloader. Bender scans the PCI bus for PCI serial ports and stores the information about them in the BIOS data area for use by the kernel.

--chainloader=chainloader

Specifies a chainloader that is loaded before the kernel and other files specified in the novaboot script. E.g. 'bin/boot/bender promisc'.

--dump

Print the modules to boot and their parameters, after this phase finishes. Then exit. This is useful for seeing the effect of other options in this section.

-k, --kernel=file

Replace the first word on the first load line in the novaboot script with file.

--scriptmod=Perl expression

When novaboot reads the script, Perl expression is executed for every line (in $_ variable). For example, novaboot --scriptmod=s/sigma0/omega6/g replaces every occurrence of sigma0 in the script with omega6.

When this option is present, it overrides $script_modifier variable from the configuration file, which has the same effect. If this option is given multiple times all expressions are evaluated in the command line order.

File generation phase

In this phase, files needed for booting are generated in a so-called build directory (see "--build-dir"). In most cases configuration for a bootloader is generated automatically by novaboot. It is also possible to generate other files using heredoc or "<" syntax in novaboot scripts. Finally, novaboot can generate binaries in this phases by running scons or make.

--build-dir=directory

Overrides the default build directory location.

The default build directory location is determined as follows: If the configuration file defines the $builddir variable, its value is used. Otherwise, it is the directory that contains the first processed novaboot script.

Target connection check

In this phase novaboot connects to target's serial port (if it has one). If another novaboot user/instance occupies the target, novaboot exits here with an error message.

--amt="[user[:password]@]host[:port]

Use Intel AMT technology to control the target machine. WS management is used to powercycle it and Serial-Over-Lan (SOL) for input/output. The hostname or (IP address) is given by the host parameter. If the password is not specified, environment variable AMT_PASSWORD is used. The port specifies a TCP port for SOL. If not specified, the default is 16992. The default user is admin.

--iprelay=addr[:port]

Use TCP/IP relay and serial port to access the target's serial port and powercycle it. The addr parameter specifies the IP address of the relay. If port is not specified, it defaults to 23.

Note: This option is supposed to work with HWG-ER02a IP relays.

--iprelay-cmd=command

Similar to --iprelay but uses command to talk to the iprelay rather than direct network connection.

-s, --serial[=device]

Target's serial line is connected to host's serial line (device). The default value for device is /dev/ttyUSB0.

The value of this option is exported in NB_NOVABOOT environment variable to all subprocesses run by novaboot.

--stty=settings

Specifies settings passed to stty invoked on the serial line specified with --serial option. If this option is not given, stty is called with raw -crtscts -onlcr 115200 settings.

--remote-cmd=cmd

Command that mediates connection to the target's serial line. For example ssh server 'cu -l /dev/ttyS0'.

--remote-expect=string

Wait for reception of string after establishing the remote serial line connection. Novaboot assumes that after establishing the serial line connection, the user running novaboot has exclusive access to the target. If establishing of the serial line connection happens asynchronously (e.g. running a command remotely via SSH), we need this option to wait until the exclusive access is confirmed by the remote side.

Depending on target configuration, this option can solve two practical problems: 1) Overwriting of files deployed by another user currently using the target. 2) Resetting the target board before serial line connection is established and thus missing bootloader interaction.

Example of usage with the sterm tool:

--remote-cmd='ssh -tt example.com sterm -v /dev/ttyUSB0' --remote-expect='sterm: Connected'

--remote-expect-silent=string

The same as --remote-expect except that the remote output is not echoed to stdout while waiting for the string. Everything after the matched string is printed to stdout, so you may want to include line end characters in the string as well.

--remote-expect-timeout=seconds

Timeout in seconds for --remote-expect or --remote-expect-seconds. When negative, waits forever. The default is -1 seconds.

File deployment phase

In some setups, it is necessary to copy the files needed for booting to a particular location, e.g. to a TFTP boot server or to the /boot partition.

-d, --dhcp-tftp

Turns your workstation into a DHCP and TFTP server so that the OS can be booted via PXE BIOS (or similar mechanism) on the test machine directly connected by a plain Ethernet cable to your workstation.

The DHCP and TFTP servers require root privileges and novaboot uses sudo command to obtain those. You can put the following to /etc/sudoers to allow running the necessary commands without asking for a password.

Cmnd_Alias NOVABOOT = /bin/ip a add 10.23.23.1/24 dev eth0, /bin/ip l set dev eth0 up, /usr/sbin/dhcpd -d -cf dhcpd.conf -lf dhcpd.leases -pf dhcpd.pid, /usr/sbin/in.tftpd --listen --secure -v -v -v --pidfile tftpd.pid *, /usr/bin/touch dhcpd.leases, /usr/bin/pkill --pidfile=dhcpd.pid, /usr/bin/pkill --pidfile=tftpd.pid
your_login ALL=NOPASSWD: NOVABOOT

--tftp

Starts a TFTP server on your workstation. This is similar to --dhcp-tftp except that DHCP server is not started.

The TFTP server requires root privileges and novaboot uses sudo command to obtain those. You can put the following to /etc/sudoers to allow running the necessary commands without asking for a password.

Cmnd_Alias NOVABOOT =  /usr/sbin/in.tftpd --listen --secure -v -v -v --pidfile tftpd.pid *, /usr/bin/pkill --pidfile=tftpd.pid
your_login ALL=NOPASSWD: NOVABOOT

--tftp-port=port

Port to run the TFTP server on. Implies --tftp.

--netif=network interface

Network interface used to deploy files to the target. This option influences the configuration of the DHCP server started by --dhcp-tftp and the value that $NB_MYIP get replaced with during U-Boot conversation. The default value is $netif variable from configuration files, which defaults to eth0.

--iso[=filename]

Generates the ISO image that boots NOVA system via GRUB. If no filename is given, the image is stored under NAME.iso, where NAME is the name of the novaboot script (see also --name).

--server[=[[user@]server:]path]

Alias of --copy (kept for backward compatibility).

--copy[=[[user@]server:]path]

Copy all files needed for booting to another location. The files will be copied (by rsync tool) to the directory path. If the path contains string $NAME, it will be replaced with the name of the novaboot script (see also --name).

--rsync-flags=flags

Specifies flags to append to rsync command line when copying files as a result of --copy option.

--concat

If --copy is used and its value ends with $NAME, then after copying the files, a new bootloader configuration file (e.g. menu.lst) is created at path-wo-name, i.e. the path specified by --copy with $NAME part removed. The content of the file is created by concatenating all files of the same name from all subdirectories of path-wo-name found on the "server".

--ider

Use Intel AMT technology for IDE redirection. This allows the target machine to boot from novaboot created ISO image. Implies --iso.

The experimental amtider utility needed by this option can be obtained from https://github.com/wentasah/amtterm.

Target power-on and reset phase

At this point, the target is reset (or switched on/off). There are several ways how this can be accomplished. Resetting a physical target can currently be accomplished by the following options: --amt, --iprelay, --reset-cmd and --reset-send.

--on, --off: Switch on/off the target machine and exit. The script (if any) is completely ignored. Currently, it works only with the following options: --iprelay, --amt, --ssh.
-Q, --qemu[=qemu-binary]: Boot the configuration in qemu. Optionally, the name of qemu binary can be specified as a parameter.
--qemu-append=flags: Append flags to the default qemu flags (QEMU_FLAGS variable or -cpu coreduo -smp 2).
-q, --qemu-flags=flags: Replace the default qemu flags (QEMU_FLAGS variable or -cpu coreduo -smp 2) with flags specified here.
--reset-cmd=cmd: Runs command cmd to reset the target.
--reset-send=string: Reset the target by sending the given string to the remote serial line. "\n" sequences are replaced with the newline character.
--no-reset, --reset: Disable/enable resetting of the target.

Interaction with the bootloader on the target

--uboot[=prompt]

Interact with U-Boot bootloader to boot the thing described in the novaboot script. prompt specifies the U-Boot's prompt (default is "=> ", other common prompts are "U-Boot> " or "U-Boot# ").

--no-uboot

Disable U-Boot interaction previously enabled with --uboot.

--uboot-stop-key=key

Character, which is sent as a response to U-Boot's "Hit any key to stop autoboot" message. The default value is newline, but some devices (e.g. TP-Link TD-W8970) require a specific key to be pressed.

--uboot-init

Command(s) to send the U-Boot bootloader before loading the images and booting them. This option can be given multiple times. After sending commands from each option novaboot waits for U-Boot prompt.

If the command contains string $NB_MYIP then this string is replaced by IPv4 address of eth0 interface (see also --netif). Similarly, $NB_PREFIX is replaced with prefix given by --prefix.

See also uboot keyword in "NOVABOOT SCRIPT SYNTAX").

--uboot-addr name=address

Load address of U-Boot's tftpboot command for loading name, where name is one of kernel, ramdisk or fdt (flattened device tree).

The default addresses are ${name_addr_r}, i.e. U-Boot environment variables used by convention for this purpose.

--uboot-cmd=command

Specifies U-Boot command used to execute the OS. If the command contains strings $kernel_addr, $ramdisk_addr, $fdt_addr, these are replaced with the addresses configured with --uboot-addr.

The default value is

bootm $kernel_addr $ramdisk_addr $fdt_addr

or the UBOOT_CMD variable if defined in the novaboot script.

Target interaction phase

In this phase, target's serial output is redirected to stdout and if stdin is a TTY, it is redirected to the target's serial input allowing interactive work with the target.

--exiton=string

When the string is sent by the target, novaboot exits. This option can be specified multiple times, in which case novaboot exits whenever either of the specified strings is sent.

If the string is -re, then the next --exiton's string is treated as a regular expression. For example:

--exiton -re --exiton 'error:.*failed'

--exiton-re=regex

The same as --exiton -re --exiton regex.

--exiton-timeout=seconds

By default --exiton waits for the string match forever. When this option is specified, "exiton" timeouts after the specified number of seconds and novaboot returns non-zero exit code.

-i, --interactive

Setup things for the interactive use of the target. Your terminal will be switched to raw mode. In raw mode, your local terminal does not process input in any way (no echoing of entered characters, no interpretation of special characters). This, among others, means that Ctrl-C is passed to the target and does not interrupt novaboot. To exit from novaboot interactive mode type "~~.".

--no-interaction, --interaction

Skip resp. force target interaction phase. When skipped, novaboot exits immediately after the boot is initiated.

--expect=string

When the string is received from the target, send the string specified with the subsequent --send* option to the target.

--expect-re=regex

When target's output matches regular expression regex, send the string specified with the subsequent --send* option to the target.

--expect-raw=perl-code

Provides direct control over Perl's Expect module.

--send=string

Send string to the target after the previously specified --expect* was matched in the target's output. The string may contain escape sequences such as "\n".

Note that string is actually interpreted by Perl, so it can contain much more that escape sequences. This behavior may change in the future.

Example: --expect='login: ' --send='root\n'

--sendcont=string

Similar to --send but continue expecting more input.

Example: --expect='Continue?' --sendcont='yes\n'

--final-eol, --no-final-eol

By default, novaboot always prints an end-of-line character at the end of its execution in order to ensure that the output of programs started after novaboot appears at the beginning of the line. When this is not desired --no-final-eol option can be used to override this behavior.

NOVABOOT SCRIPT SYNTAX

The syntax tries to mimic POSIX shell syntax. The syntax is defined by the following rules.

Lines starting with "#" and empty lines are ignored.

Lines that end with "\" are concatenated with the following line after removal of the final "\" and leading whitespace of the following line.

Lines of the form VARIABLE=... (i.e. matching '^[A-Z_]+=' regular expression) assign values to internal variables. See "VARIABLES" section.

Otherwise, the first word on the line defines the meaning of the line. The following keywords are supported:

load

These lines represent modules to boot. The word after load is a file name (relative to the build directory (see --build-dir) of the module to load and the remaining words are passed to it as the command line parameters.

When booting Linux, the first load line usually refers to the kernel image and its command line parameters (unless you use some special pre-loader). Other load lines may refer to an initramfs image and/or a device tree blob. Their order is not important, as the device tree is recognized as the file name ending with .dtb.

When the load line ends with "<<WORD" then the subsequent lines until the line containing solely WORD are copied literally to the file named on that line. This is similar to the heredoc feature of UNIX shells.

When the load line ends with "< CMD" then command CMD is executed with /bin/sh and its standard output is stored in the file named on that line. The SRCDIR variable in CMD's environment is set to the absolute path of the directory containing the interpreted novaboot script.

copy

These lines are similar to load lines. The file mentioned there is copied to the same place as in the case of load (e.g. tftp server), but the file is not used in the bootloader configuration. Such a file can be used by the target for other purposes than booting, e.g. at OS runtime or for firmware update.

chld

Chainload another bootloader. Instead of loading multiboot modules identified with load keyword, run another bootloader. This is currently supported only by pulsar and can be used to load e.g. Grub as in the example below:

chld boot/grub/i386-pc/core.0

run

Lines starting with run keyword contain shell commands that are run during file generation phase. This is the same as the "< CMD" syntax for load keyboard except that the command's output is not redirected to a file. The ordering of commands is the same as they appear in the novaboot script.

uboot

These lines represent U-Boot commands that are sent to the target if --uboot option is given. Having a U-Boot line in the novaboot script is the same as giving --uboot-init option to novaboot. The following syntax variants are supported:

uboot[:<timeout>] <string> [> <file>]
uboot[:<timeout>] < <shell> [> <file>]

string is the literal U-Boot command.

The uboot keyword can be suffixed with timeout specification. The syntax is uboot:Ns, where N is the whole number of seconds. If the U-Boot command prompt does not appear before the timeout, novaboot fails. The default timeout is 10 seconds.

In the second variant with the < character the shell code is executed and its standard output is sent to U-Boot. Example:

uboot < printf "mmc write \$loadaddr 1 %x" $(($(/usr/bin/stat -c%s rootfs.ext4) / 512))

When > file part is present, the output of the U-Boot command is written into the given file.

Example (Linux):

#!/usr/bin/env novaboot
load bzImage console=ttyS0,115200
run  make -C buildroot
load rootfs.cpio < gen_cpio buildroot/images/rootfs.cpio "myapp->/etc/init.d/S99myapp"

Example (NOVA User Land - NUL):

#!/usr/bin/env novaboot
WVDESC=Example program
load bin/apps/sigma0.nul S0_DEFAULT script_start:1,1 \
                         verbose hostkeyb:0,0x60,1,12,2
load bin/apps/hello.nul
load hello.nulconfig <<EOF
sigma0::mem:16 name::/s0/log name::/s0/timer name::/s0/fs/rom ||
rom://bin/apps/hello.nul
EOF

This example will load three modules: sigma0.nul, hello.nul and hello.nulconfig. sigma0 receives some command line parameters and hello.nulconfig file is generated on the fly from the lines between <<EOF and EOF.

Example (Zynq system update via U-Boot):

#!/usr/bin/env novaboot

uboot dhcp

# Write kernel to FAT filesystem on the 1st SD card partition
run mkimage -f uboot-image.its image.ub
copy image.ub
uboot:60s tftpboot ${loadaddr} $NB_PREFIX/image.ub
uboot fatwrite mmc 0:1 ${loadaddr} image.ub $filesize
uboot set bootargs console=ttyPS0,115200 root=/dev/mmcblk0p2

# Write root FS image to the 2nd SD card partition
copy rootfs/images/rootfs.ext4
uboot:60s tftpboot ${loadaddr} $NB_PREFIX/rootfs/images/rootfs.ext4
uboot mmc part > mmc-part.txt
uboot < printf "mmc write \$loadaddr %x %x" $(awk '{ if ($1 == "2") { print $2 }}' mmc-part.txt) $(($(/usr/bin/stat -L --printf=%s rootfs/images/rootfs.ext4) / 512))

UBOOT_CMD=boot

VARIABLES

The following variables are interpreted in the novaboot script:

BOOT_METHOD: Specifies the way GRUB2 boots the kernel. For kernels with multiboot support use multiboot method (the default). For Linux kernel use linux method.
BUILDDIR: Novaboot chdir()s to this directory before file generation phase. The directory name specified here is relative to the build directory specified by other means (see "--build-dir").
EXITON: Assigning this variable has the same effect as specifying "--exiton" option.
INTERACTION: Setting this variable to zero is the same as giving "--no-interaction", specifying to one corresponds to "--interaction".
HYPERVISOR_PARAMS: Parameters passed to the hypervisor. The default value is "serial", unless overridden in the configuration file.
KERNEL: The kernel to use instead of the hypervisor specified in the configuration file with the $hypervisor variable. The value should contain the name of the kernel image as well as its command line parameters. If this variable is defined and non-empty, the variable HYPERVISOR_PARAMS is not used.
NO_BOOT: If this variable is 1, the system is not booted. This is currently only implemented for U-Boot bootloader where it is useful for interacting with the bootloader without booting the system - e.g. for flashing.
QEMU: Use a specific qemu binary (can be overridden with -Q) and flags when booting this script under qemu. If QEMU_FLAGS variable is also specified flags specified in QEMU variable are replaced by those in QEMU_FLAGS.
QEMU_FLAGS: Use specific qemu flags (can be overridden with -q).
UBOOT_CMD: See "--uboot-cmd".
WVDESC: Description of the WvTest-compliant program.
WVTEST_TIMEOUT: The timeout in seconds for WvTest harness. If no complete line appears in the test output within the time specified here, the test fails. It is necessary to specify this for long running tests that produce no intermediate output.

CONFIGURATION FILES

Novaboot can read its configuration from one or more files. By default, novaboot looks for files in /etc/novaboot.d, file ~/.config/novaboot and files named .novaboot as described in "Configuration reading phase". Alternatively, configuration file location can be specified with the -c switch or with the NOVABOOT_CONFIG environment variable. The configuration file has Perl syntax (i.e. it is better to put 1; as the last line) and should set values of certain Perl variables. The current configuration can be dumped with the --dump-config switch. Some configuration variables can be overridden by environment variables (see below) or by command line switches.

Supported configuration variables include:

$builddir

Build directory location relative to the location of the configuration file.

$default_target

Default target (see below) to use when no target is explicitly specified with the --target command line option or NOVABOOT_TARGET environment variable.

$netif

Default value for the --netif option. If not specified, it defaults to eth0.

%targets

Hash of target definitions to be used with the --target option. The key is the identifier of the target, the value is the string with command line options. For instance, if the configuration file contains:

$targets{'mybox'} = '--copy=boot:/tftproot --serial=/dev/ttyUSB0 --grub',

then the following two commands are equivalent:

./myos --copy=boot:/tftproot --serial=/dev/ttyUSB0 --grub
./myos -t mybox

ENVIRONMENT VARIABLES

Some options can be specified not only via config file or command line but also through environment variables. Environment variables override the values from the configuration file and command line parameters override the environment variables.

NOVABOOT_CONFIG: Name of the novaboot configuration file to use instead of the default one(s).
NOVABOOT_CONFIG_DIR: Name of the novaboot configuration directory. When not specified /etc/novaboot.d is used.
NOVABOOT_TARGET: Name of the novaboot target to use. This overrides the value of $default_target from the configuration file and can be overridden with the --target command line option.
NOVABOOT_BENDER: Defining this variable has the same effect as using --bender option.

AUTHORS

Michal Sojka <sojka@os.inf.tu-dresden.de>

Latest novaboot version can be found at https://github.com/wentasah/novaboot.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

README.pod

README.pod

NAME

SYNOPSIS

DESCRIPTION

Simple examples of using `novaboot`:

OPTIONS AND PHASES

Configuration reading phase

Command line processing phase

Script preprocessing phase

File generation phase

Target connection check

File deployment phase

Target power-on and reset phase

Interaction with the bootloader on the target

Target interaction phase

NOVABOOT SCRIPT SYNTAX

VARIABLES

CONFIGURATION FILES

ENVIRONMENT VARIABLES

AUTHORS

Files

README.pod

Latest commit

History

README.pod

File metadata and controls

NAME

SYNOPSIS

DESCRIPTION

Simple examples of using novaboot:

OPTIONS AND PHASES

Configuration reading phase

Command line processing phase

Script preprocessing phase

File generation phase

Target connection check

File deployment phase

Target power-on and reset phase

Interaction with the bootloader on the target

Target interaction phase

NOVABOOT SCRIPT SYNTAX

VARIABLES

CONFIGURATION FILES

ENVIRONMENT VARIABLES

AUTHORS

Simple examples of using `novaboot`: