![[Previous]](prev.gif) |
![[Contents]](contents.gif) |
![[Index]](keyword_index.gif) |
![[Next]](next.gif) |
|
|
|
|
This chapter covers the following topics:
Before you proceed with the installation, be sure to read the installation instructions as well as the Release Notes that came with your software. The Release Notes contain important information that could influence the way you choose to install your software.
You should also read the System Architecture manual, which explains the basic philosophy and operation of QNX. We assume you have this basic level of familiarity with the OS.
System requirements vary, depending on which products you wish to install. For example, to install the base OS on your development system, you'll need at least 14M free disk space. For more information, see the installation instructions that are shipped with each product.
 |
Your target system will likely require far less disk space (if it even has a disk!), RAM, etc. than your development system. Since QNX is a modular OS, you can easily configure your target system to use only the modules actually required at run time. |
QNX products may be shipped on either of these two media:
In both cases, you'll use a QNX installation program to install QNX onto your hard disk. The program 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, you may be prompted to confirm your hardware configuration. Make sure you have the correct information about your hardware before you begin:
If your QNX software was shipped on a CD, the installation procedure is quite simple:
When your computer boots, simply follow the instructions on your screen.
To install QNX from floppies, follow these steps:
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.
|
If you'd like information about the install options before you continue, type use install at the shell prompt. |
install
Simply follow the instructions on your screen to set up your hard disk so it will boot QNX.
Once all the files have been installed from the floppy diskettes, you should remove any 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.
There are three possible ways to install additional QSSL software products:
If you have a QNX Products CD-ROM, you can install whatever products are on the CD-ROM, provided you have the appropriate licenses.
In this procedure, you'll need to enter the license information that was included in the package you purchased.
|
You must be running Photon to do a CD-ROM install. |
All additional software products supplied by QSSL for QNX come in a compressed format. You can install these products with the /etc/install utility shipped 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.
|
Before installing your software, you must be logged in as the
superuser (root), and the floppy driver must be running. To
check if the driver is running, type:
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. For details, see the chapter on building an OS image.
|
You can optionally select an alternate boot by pressing Esc when prompted by the boot loader. |
During a normal boot, sinit tries to boot from the /etc/config/sysinit.node file. During an alternate boot (from local disk only), sinit tries to boot from the /etc/config/altsysinit file. If it can't boot from either of those files, sinit will try to boot from the /etc/config/sysinit file.
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 system initialization file is simply an ASCII file that you can edit using a text editor (e.g. vi). Each of the three types serves a particular purpose:
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 particular 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.
To customize a machine's setup, you'll need to have a sysinit.node file on the boot server that boots the node you're customizing.
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 machine you're customizing.
|
If you change a machine's logical node ID, the machine will look for the sysinit.node file that matches its new logical node ID. |
The sysinit file is executed when a sysinit.node file isn't present.
This file is automatically put on your system during installation. We ship it as a generic file that should be able to boot any machine -- we recommend that you make few or no modifications to this sysinit file.
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 will provide. The following describes a base set of services that will be in most sysinit files.
|
If several machines will be using a common set of commands,
you can place the commands in a separate shell script and have
the file executed via the . (dot) shell built-in.
For example, let's say you create a file called
techies containing commands to be used by all
the machines in your Technical Department. The file could be
executed from within the
sysinit.node file of each machine
in that department with the following command:
. /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. Note that the rtc line is optional for a machine that boots over the network.
export TZ=EST5EDT rtc hw
For more information, see "Time zones and the realtime clock" 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 serial port configuration. For example, the following line changes the baud rate to 57600:
stty baud=57600 </dev/ser1
If your programs use floating point and you don't have a floating-point unit (FPU), you'll 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 system initialization files shipped by QSSL.
Every machine in the network must have access to 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.
|
We don't recommend running nameloc on every node on the network, as this causes unnecessary network traffic. For more information, see the nameloc utility in the Utilities Reference. |
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 &
If you want to access the floppy as a QNX filesystem, you must mount it as such:
mount /dev/fd0 /fd0
To access files on a CD, you'll need to run the Iso9660fsys filesystem manager, which supports the ISO standard for CD-ROM filesystems as well as the Rock Ridge extensions:
Iso9660fsys &
If you need to access DOS floppies and partitions, you'll have to start a DOS filesystem (Dosfsys):
Dosfsys &
If you want to connect to a non-QNX machine (e.g. for Internet access), you'll need to start the TCP/IP socket manager. For details, refer to the documentation for the TCP/IP for QNX package.
If the machine will rarely be rebooted, consider making it a cron server:
cron &
Some text-based applications (e.g. vedit) let you use a mouse. When using these apps on a text-mode console (i.e. without Photon), you'll need to run the Mouse manager. Several mouse types are supported. The following command will detect and start the correct mouse driver:
mousetrap start
On some systems, the system initialization file launches the Photon windowing system for graphical applications. For more information, see the chapter on Photon in the QNX System Architecture manual.
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 other nodes, 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.
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.
Valid dates on a QNX system range from January 1970 to January 2038. The internal date and time representation reaches its maximum value in 2038. If your system must operate past 2038 and there's no way for the system to be upgraded or modified in the field, you'll have to take special care with system dates (contact us for help with this).
Some computer BIOSs, and certain earlier versions of the QNX rtc utility, have difficulty handling the transition between the year 1999 and the year 2000. Note also that 2-digit forms of years as input to programs may stop working in older programs when years 2000 or greater are represented this way.
Internally, QNX uses Coordinated Universal Time (UTC), sometimes called Greenwich Mean Time. Applications and utilities convert to local time by using information from the time zone environment variable.
|
If the time zone environment variable TZ isn't set, QNX assumes that your local time is the same as North American Eastern Standard Time with current Daylight Saving Time (EST5EDT). If you wish to transfer files to another system in a different time zone, the dates on the transferred file will appear to be shifted by the difference between the two time zones. |
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 derive 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:
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 the time in your hardware clock is incorrect (perhaps the battery has been replaced), you should set the system time using the date utility, then set the realtime clock using the rtc utility with the -s option. For details, see the documentation for these utilities in the Utilities Reference. |
If you boot over the network, the booting machine will inherit the UTC time from its boot server. Therefore, you don't need to put this information in your sysinit file.
|
|
|
|