Customizing the QNX Amazon Machine Image

The QNX AMI is a reference image generated by the QNX Image Filesystem (IFS) for developers to leverage the QNX Neutrino RTOS or the QNX OS for Safety as Amazon EC2 instances. The reference image does not contain all the libraries or binaries found on a non-AMI QNX system, and can’t support the full range of functions and features found on a standard QNX target. You can’t customize or tailor the QNX IFS that generates the QNX AMI reference, but the QNX AMI environment provides several customization options, including:

managing user accounts, passwords, and groups
adding files
adding storage and partitioning
extending the boot

To save your customized QNX AMI, follow the Amazon EC2 User Guide at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html.

Managing user accounts, passwords, and groups

When the QNX AMI instance first boots, it prompts you to input new passwords for the root account and the qnxuser account. Once complete, you can login as either root or qnxuser.

Like any QNX-based system, you can also add users or groups you want to the system. For detailed steps, see “Managing User Accounts” in the QNX Neutrino User's Guide at https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.user_guide/topic/about.html.

Adding files

Like any QNX system, you can use the Momentics IDE or the scp utility to copy or upload files from the host to the AMI instance, or vice versa. See the scp entry in the Utilities Reference at https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/about.html.

Currently, the QNX AMI instance has two writeable partitions. To display partition information, run mount in the QNX instance terminal. For example:

# mount
/dev/nvme0t178 on / type qnx6
ifs on / type ifs
/dev/nvme0t179 on /data type qnx6

The first partition /dev/nvme0t178 is a 256MB “system” partition union mounted at / (slash), where you can upload (via Momentics or scp) your own libraries, binaries, and so on.

CAUTION:

Do not change the permissions of the directories under this partition. If they are changed, users will no longer be able to log in.

You can add your own update management software as appropriate. As this partition is small, it should be reserved for “system” libraries and binaries and not the application-level libraries and binaries.

The second partition /dev/nvme0t179 is a 2.8GB writable partition mounted at /data. Run ls to list the directory content of / (e.g., ls /):

# ls /
bin     dev     home    proc    sbin    usr
data    etc     lib     root    tmp     var

This partition should serve as the general integration point for any or all customizations to the application-level support files such as binaries, libraries, data files, config files, and so on. Again, you can use Momentics or scp to upload files to this partition.

The environment variables PATH and LD_LIBRARY_PATH are set to include certain directories in the /data mountpoint in addition to the standard system paths, ensuring that any customizations done within the /data mountpoint will get picked up during the boot sequence. To view what directories are set, run echo with $PATH or $LD_LIBRARY_PATH in the QNX instance terminal.

For example:

# echo $PATH
/proc/boot:/sbin:/bin:/usr/bin:/usr/sbin:/usr/libexec:/data/bin:/data/sbin:/data/usr/bin:/data/usr/sbin
# echo $LD_LIBRARY_PATH
/proc/boot:/lib:/usr/lib:/lib/dll:/lib/dll/pci:/data/lib:/data/lib/dll:/data/usr/lib

Adding more storage

Initially, there is one NVME device (nvme0) associated with the AMI. In the QNX instance terminal, run ls /dev to view the devices:

# ls /dev
bpf           nvme0t179     ptyp3         shmem         tty           ttyp7
console       pci           ptyp4         slog          ttyp0         tymem
io-sock       pf            ptyp5         slog2         ttyp1         urandom
mem           pfil          ptyp6         socket        ttyp2         zero
mqueue        pipe          ptyp7         stderr        ttyp3
null          ptyp0         random        stdin         ttyp4
nvme0         ptyp1         sem           stdout        ttyp5
nvme0t178     ptyp2         ser1          text          ttyp6

To attach an additional volume to an instance, follow the steps in “Attach an Amazon EBS volume to an instance”" at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html.

When the volume is attached to the QNX instance, in the QNX instance terminal, run shutdown to reboot the instance.

After the instance reboots, the additional associated volume appears as the next NVME device nvmeN, where N is the next available number (e.g., nvme1).

# ls /dev
bpf           nvme0t179     ptyp1         sem           stdout        ttyp5
console       nvme1         ptyp2         ser1          text          ttyp6
io-sock       nvme1t179     ptyp3         shmem         tty           ttyp7
mem           pci           ptyp4         slog          ttyp0         tymem
mqueue        pf            ptyp5         slog2         ttyp1         urandom
null          pfil          ptyp6         socket        ttyp2         zero
nvme0         pipe          ptyp7         stderr        ttyp3
nvme0t178     ptyp0         random        stdin         ttyp4

Partitioning and formatting your storage

To partition a volume (e.g., nvme1), follow these steps:

Run:
```
fdisk /dev/nvme1 add -t178
```
which creates a type 178 partition in nvme1.
Reboot the instance with shutdown, then run ls /dev to confirm that the nvme1t178 partition is added.
To format nvme1t178, run:
```
mkqnx6fs /dev/nvme1t178
```
To mount nvme1t178 to a path, run:
```
mount /dev/nvme1t178 /pathname
```
where pathname is any name you want. The mounted path is now available for use.

The QNX AMI instance can mount as many disk volumes as required.

For more on QNX IFS, see “Working with Filesystems” in the QNX Neutrino User's Guide at https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.user_guide/topic/fsystems.html.

Extending the boot

As mentioned previously, the IFS is not customizable. However, the QNX AMI environment provides two methods to extend the boot process:

startup script

The startup process looks for the existence of the script /var/start_script.sh. The IFS executes the script, integrating its code into the boot process.
System Launch and Monitor (SLM) configuration file

The startup process also looks for the existence of an SLM configuration file /etc/slm/slm.conf. The SLM uses this configuration file to start and manage any custom components to run during boot. See the slm entry in the Utilities Reference at https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.neutrino.utilities/topic/about.html.

All extension options can be as complex or simple as you would like. If the user has their own software lifecycle management tool (to manage their application-level software), either the start_script.sh or SLM can be called to simply launch those custom processes such as starting the customer-specific process for the lifecycle management.