mkxfs

Updated: October 26, 2022

Make a filesystem image (QNX)

Syntax:

mkxfs -t image_type -r path [options] [buildfile] [directory] [outputfile]

Runs on:

Linux, Mac, Microsoft Windows

Options:

-t image_type
Specify the type of filesystem image to create; see below.
-r path
Allows specifying a root path under which the tool should look for binaries.
The -r can be used multiple times to specify a number of different base search paths. Paths will be searched in the order in which they are specified.

Description:

The mkxfs utility generates a filesystem image, the type of which is governed by the -t option. This utility implements a number of related utilities; for information about the supported options and attributes, see the entry for the specific utility:

image_type See:
etfs mketfs
fatfsimg mkfatfsimg
ffs3 mkefs
ifs mkifs
qnx6fsimg mkqnx6fsimg

This program uses the OpenSSL library for cryptography services.

License checking

The mkxfs utility checks for a valid QNX license key before performing any operation. If the license check fails, the utility stops running and displays a diagnostic message. A license check may fail if the license key is expired, missing, or not currently activated, or if the key doesn’t contain the permissions needed to run the utility.

Processing of variables in input files

In mkxfs input files—build files, bootstrap files, startup script files, and booter (.boot) files, references to variables can be used. A reference must have the form ${variable-name} and will be replaced by the value of the named variable or by an empty string if the variable is undefined or empty.

The variable name may contain any 8-bit ASCII characters except '$' (dollar), '[' (opening square bracket), ']' (closing square bracket), '/' (forward slash), '\' (backslash), ' ' (space), LF (linefeed), TAB (horizontal tab), and '}' (closing curly brace).

Variable references may occur (and will be replaced) anywhere in the input files, except within inline files.

Variable references can be both nested and chained. For nested references, the name of a variable can be constructed from the value of another. For example, if a is x and xy is zzz, then ${${a}y} will expand to zzz.

For chained references, the value of a variable can in turn refer to another variable. For example, if a is x${b}z and b is y, then ${a} will expand to xyz. Chaining is especially useful in search path definitions. The environment variable MKIFS_PATH, for example, will usually chain to QNX_TARGET and CPU.

While the variable expansion itself supports nesting of variable references, nesting can (currently) not be used in the input files directly. So if NEST is ${${name}}, name is x, and x is aaa, then ${NEST} will work as expected, whereas ${${name}} won't.

Input file text can be quoted by embedding the text in a pair of double quotes ("..."). Inside quoted text, variables will not be expanded. Some special characters in the input file text can be escaped by placing a backslash ('\') in front. If a ${ is not meant to introduce a variable reference to be expanded by mkxfs, then it must be prefixed with a backslash, as follows: \${.

Note that inside variable names and values, quoting and escaping do not work.

The mkxfs utility also maintains an internal environment to which all variables defined as globals in the bootstrap or the script file are added. Variables from this internal environment can be accessed just like variables from the environment in which mkxfs runs, and will take precedence in cases of conflict. For example, if you have:
[virtual=x86_64,bios] .bootstrap={
   startup-apic
   xyz=foo
   uvw=bar procnto-smp-instr
}
then ${xyz} evaluates to foo and ${uvw} is undefined, because it was local to procnto-smp-instr.