mkxfs

QNX SDP8.0Utilities ReferenceUtilities

Make a filesystem image (QNX)

Syntax:

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

Runs on:

Linux, 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.

Note:

It's recommended to not use mkxfs and instead use the image-generating utilities dedicated to specific filesystem types. The mkxfs utility doesn't build images itself but instead looks for these other utilities to run. These other utilities are expected to be in a certain location on the host system; directly calling the type-specific image-generating utilities (e.g., mkqnx6fsimg) gives you more flexibility in where you place them on the host and saves you the overhead of running one program that just runs another one.

For information about the supported options and attributes for a given filesystem type, see the entry for the corresponding utility:


`image_type`	See:
fatfsimg	mkfatfsimg
ffs3	mkefs
ifs	mkifs
qnx6fsimg	mkqnx6fsimg
squash	mksquashfsimg

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.

Exit status:

0: Successful completion.
>0: An error occurred.
129: License not found.
130: Product is not covered under your license.
131: License expired.
132: License not activated.
133: Can't connect to the license server.

Page updated: December 04, 2024