This chapter covers the following topics:
Before you proceed with the installation, be sure to read the Release Notes and the System Architecture manual that come with the distribution software. The Release Notes contain important information that could influence the way you choose to install the software. The System Architecture manual explains the basic philosophy and operation of QNX. We assume you have this basic level of familiarity with QNX.
The QNX boot diskette contains an installation utility that installs QNX onto a hard disk. The install utility creates a directory structure, copies the software to your hard disk, and builds an OS boot image configured according to your input during the installation process.
During the installation procedure, the install utility determines what kind of hardware is available and prompts you to confirm the configuration it suggests. Make sure you have the correct information about your hardware before you begin:
Installing QNX involves three basic steps:
To install QNX, follow these steps:
Place the QNX boot diskette into the floppy drive and reboot the computer. You should see a spinning arrow or a series of dots in the top left corner of your screen, followed by the QNX logo, a welcome message, and a shell prompt.
At the shell prompt (#), type:
install
Simply follow the instructions on your screen to set up your hard disk so it will boot QNX.
Once installation is complete, you should remove any floppy diskettes and reboot your computer from hard disk. QNX should now be up and running. At this point, you'll need to log in as root.
All additional software packages supplied by QSSL for QNX come in a standard compressed format. You can install these packages with the /etc/install utility supplied with the OS — just follow the instructions below.
You might also be able to use this method to install packages from third-party vendors, but always check the instructions that come with each package before you proceed.
sin ver
If “Floppy” doesn't appear in the NAME column, type:
Fsys.floppy &
To install your additional software, follow these steps:
cd / /etc/install [drive]
where drive is the device from which the software is being installed. The default is the local floppy drive (/dev/fd0).
Simply follow the instructions on your screen; the software will be installed onto your hard disk.
When QNX boots, an image composed of several QNX processes is loaded into main memory. The first process is boot, which does real-mode initialization and then puts the machine into protected mode.
The second process in the image is the Process Manager (Proc32), which contains the Microkernel. The Process Manager performs processor initialization, and then schedules each process included within the image for execution.
The last process in the image is the sinit utility. The sinit utility initiates the second phase of system initialization by starting a shell that executes commands from a file. This file — the system initialization file (sysinit) — contains commands that set up services for a machine. It's a standard shell script that runs just like any other shell script except that breaks are disabled.
Being able to start system services after boot is one of the benefits of QNX's modular architecture. The booted image typically contains only the few essential services needed to start all other required services.
When sinit runs, it firsts determines if the image it's part of was booted from disk or from over the network. If the image was booted from disk, sinit checks to see if a normal boot or an alternate boot occurred.
During a normal boot (from disk or from the network), sinit attempts to open the file /etc/config/sysinit.node. During an alternate boot (from disk only), sinit attempts to open the file /etc/config/altsysinit. If this fails in either case, sinit tries to open the file /etc/config/sysinit.
If sinit can't find or open a system initialization file, it terminates without initializing the system. If the open succeeds, sinit replaces itself with the Shell (/bin/sh) and passes to it the name of the file that sinit opened.
Each of the system initialization files that may be executed by sinit serves a particular purpose:
The sysinit file is the default file used if sinit can't find the sysinit.node file or the altsysinit file (in the case of an alternate boot).
If you wish to customize your installation, this is the file you modify. It contains the custom commands needed to set up the environment and services for a machine. Every node in the network can have its own setup.
A sysinit.node file is always created by the install program. The file's initial contents reflect the installation parameters determined by the choices you made when you installed the software through install.
Nodes that boot over the network from a server (i.e. workstations) initially use the default sysinit file for booting. To customize a workstation's setup, you have to create a sysinit.node file on the boot server for that workstation.
You can start with the sysinit.node file for another node with a similar configuration, or you can simply make a copy of the default sysinit file, which you may then modify:
cp /etc/config/sysinit /etc/config/sysinit.node
Remember that the node suffix must be the logical node ID of the workstation you're customizing.
This file is executed when a sysinit.node file isn't present. It contains services that should work on any machine. QSSL ships a generic file that should be able to boot any machine. We recommend that you make few or no modifications to this file.
The sysinit file is automatically put on your system during the installation.
This file serves as a safety net in case a modification to your sysinit.node file leaves the system in a state where you can't log in.
The altsysinit file is executed only if you specify an alternate boot when booting from local disk (i.e. you press Esc when the boot loader prompts you for an alternate boot).
The altsysinit file should always contain a backup of the last working copy of the sysinit.node file for a machine that boots from a local hard disk. So, before you make any changes to a working sysinit.node file that could prevent the machine from booting from hard disk, you should copy the /.boot file to /.altboot and copy the sysinit.node file to altsysinit.
cp /.boot /.altboot cp /etc/config/sysinit.node /etc/config/altsysinit
We recommend that you update the /.altboot and altsysinit files after all successful changes to your sysinit.node file.
The contents of each machine's sysinit file reflect the hardware on that machine and the services it's to provide. The following describes a base set of services that will be in most sysinit files.
. /etc/config/techies
You'd add node-specific commands after this “dot” line. For more information on the dot command, see sh in the Utilities Reference.
The following lines define the time zone (EST in this case) and get the time from the realtime clock. These two lines should be the first in the file for machines that boot from hard disk. They are optional in a machine that boots over the network, since the machine inherits this information from its boot server.
export TZ=EST5EDT rtc hw
For more information, see the “Time zones and the realtime clock” section at the end of this chapter.
The following lines start the Device Manager (Dev) and the console driver (Dev.ansi) with eight virtual consoles, then instruct the Shell to reopen its standard I/O through the new console device:
Dev & Dev.ansi -n 8 & reopen //0/dev/con1
The following lines start the serial driver Dev.ser, which looks for COM1 and COM2, and the parallel driver Dev.par, which looks for LPT1 and LPT2. These drivers terminate if they can't find the necessary hardware.
Dev.ser & Dev.par &
If you started Dev.ser, you might need to use the stty utility to change the default line configuration. For example, the following lines change the baud rate to 57600:
stty baud=57600 </dev/ser1 stty baud=57600 </dev/ser2 etc...
If your programs use floating point and you don't have an 80x87 chip, you need to start the floating-point emulator:
emu87 &
When booting a node on a network, you must run the netmap utility, which informs the Network Manager (Net) of node ID mappings. You should place the following netmap command in the sysinit.node file, even if the node isn't currently running on a network (the command has no effect on a non-networked machine):
netmap -f
Note that this command is included in the standard sysinit files shipped by QSSL.
At least one machine in the network must run the global name server. You could start the name server on this machine if it isn't rebooted frequently:
nameloc &
The nameloc utility periodically communicates with each node in turn, starting with node 1 and continuing up to node n, where n is the number of installed network licenses. It's a good idea to run nameloc on two nodes in order to provide redundancy in case one node running nameloc fails.
The following line starts a login on the first console and arms all other consoles:
tinit -T /dev/con* -t /dev/con1 &
While it isn't mandatory, almost all installations use the tinit utility. The sysinit files we provide contain tinit.
You can add many other services to your sysinit file. You should add these services just before the line containing the tinit command. The examples below show some commonly used optional services. Note that these utilities typically support command-line options to modify their behavior — these options are explained in the Utilities Reference for each utility.
Processes started in the sysinit file inherit their environment variables. The general syntax of an environment variable definition is as follows:
export var=value
where var is the name of the environment variable (such as TERM for terminal type or TZ for time zone), and value is the setting. The export command is described further under the sh man page in the Utilities Reference.
To start a local floppy driver, first start the Filesystem Manager Fsys and then the driver itself as shown below. If the QNX filesystem is already running locally (as will be the case if the machine boots from disk), the Filesystem Manager will already be running and you won't have to include the first line:
Fsys & Fsys.floppy &
When a floppy driver is running, you can use the vol and pax utilities to access the block special file (e.g. /dev/fd0). If you want to access it as a QNX filesystem, you must mount it as such (we recommend you use pax to transport files between QNX filesystems):
mount /dev/fd0 /fd0
If you need to access DOS floppies and partitions, you'll have to start a DOS filesystem (Dosfsys):
Dosfsys &
Don't forget to start a driver for the floppy (as described above) and/or hard disk (if necessary) and to mount the associated device(s) afterwards.
If the machine will rarely be rebooted, consider making it a cron server:
cron &
By default, the QNX console driver assumes a 101-key US keyboard layout. However, QNX provides a variety of configurations corresponding to the keyboards most commonly used throughout the world. If you need to select an alternate keyboard configuration, use the kbd utility.
If you select a keyboard other than the US type when installing QNX on a machine that will boot from its own hard disk, the appropriate kbd command will be added to the machine's sysinit.node file. If you subsequently set up workstations, you'll have to change their sysinit.node files to include this command.
Note that you can also generate custom keyboard layouts with the kedit utility.
If a mouse is available, you'll have to start the Mouse Manager (Mouse). Several mouse types are supported. The following command will detect and start the correct mouse driver:
mousetrap start
To see a list of the supported mouse types and their default parameters, type:
mousetrap query
It's important that the correct date, time, and time zone information be established early during initialization. These values should be set in the first line of your sysinit file. The install program assumes that your hardware clock has a valid date and time and asks you for the time zone information.
Internally, QNX uses Coordinated Universal Time (UTC), which is often referred to as Greenwich Mean Time. Applications and utilities convert to local time by using information from the time zone environment variable.
The time zone information should be established before the current date and time is set. If the realtime clock in your computer has been set to local time, QNX needs the time zone information in order to establish UTC.
In the following example, the time zone and the time change rules are set for Eastern Standard Time in North America:
export TZ=EST5EDT4,M4.1.0/3,M10.5.0/3
where:
| export | Shell command to set an environment variable |
| TZ | Name of variable |
| EST | Eastern Standard Time |
| 5 | 5 hours before Greenwich Mean Time |
| EDT | Daylight saving time |
| 4 | 4 hours before Greenwich Mean Time |
| M4.1.0/3 | First Sunday of April at 3am |
| M10.5.0/3 | Last Sunday of October at 3am |
For more information about the time zone rules, see the timezone technote on QUICS.
If you're booting from disk, you should follow the time zone rules in your sysinit file with the rtc utility to establish the current date and time from the realtime clock. The following two lines would accomplish this:
export TZ=EST5EDT4,M4.1.0/3,M10.5.0/3 rtc hw
Note that there are two possible approaches to take when setting the realtime clock in your machine:
We recommend that you set the time in the realtime clock to UTC. But if you're also running operating systems that assume the realtime clock is set to local time (e.g. DOS), you'll want to use the rtc utility with the -l (“el”) option:
rtc -l hw
This invocation of rtc assumes that the realtime clock was set to local time. Note that when you use local time in the realtime clock, you'll have to manually change the value in the realtime clock when you switch to and from daylight saving time in locales where it's used.
If you boot over the network, the booting machine will inherit the UTC time and time zone environment variable from its boot server. Therefore, you don't need to put this information in your sysinit file.