Install Config

QNX Realtime Operating System
Installation and Conguration
For QNX 4.25
2005, QNX Software Systems
1996 2005, QNX Software Systems. All rights reserved. Printed under license by: QNX Software Systems Co. 175 Terence Matthews Crescent Kanata, Ontario K2M 1W8 Canada Voice: +1 613 591-0931 Fax: +1 613 591-3579 Email: info@qnx.com Web: http://www.qnx.com/
Publishing history June 1996 December 1997 First edition Second edition
Electronic edition published 2005.
Technical support options

To obtain technical support for any QNX product, visit the Technical Support section in the Services area on our website (www.qnx.com). Youll nd a wide range of support options, including our free web-based Developer Support Center.
QNX, Momentics, Neutrino, and Photon microGUI are registered trademarks of QNX Software Systems in certain jurisdictions. All other trademarks and trade names belong to their respective owners.
Contents
About This Guide 1 Basic Installation xi
xvii
Whats new online (as of August 05, 2005)
Installing QNX onto a hard disk 3 System requirements 3 Distribution media 3 CD-ROM distribution 4 Floppy diskette distribution 4 Installing additional software 5 If from CD-ROM. . . 5 If from oppies. . . 6 Installation procedure 6 The system initialization le 7 What happens when the system boots 7 Customizing the system initialization le 8 sysinit.node 8 sysinit 9 altsysinit 9 Using the system initialization le 10 Base-level services 10 Optional services 12 International keyboard support 15 Time zones and the realtime clock 15 Establishing the time zone 16
August 15, 2005
Contents
iii
Getting the date and time from the realtime clock
17
Building an OS Image
Introduction 21 Constructing a build le 21 Build le format 22 Setting heap sizes 23 Setting priorities 23 Where executables are stored 23 Selecting executables for an image Mandatory processes 24 Disk images 25 Network images 26 Embedded images 28
19
24
Setting up Filesystems
31
Introduction 33 Partitioning the pathname space 33 A hard disk and a oppy 34 Two hard disks (same node) 35 Multiple QNX partitions 35 Local and remote hard disks 35 Setting up a DOS lesystem 38 Invocation modes 39 Dosfsys 39 Starting Dosfsys name adoption 40 DOS devices 40 DOS version support 41 DOS text les 42 DOS binary les 43 QNX-to-DOS character and name mapping DOS volume labels 45 DOS-QNX permission mapping 45
43
iv
Contents
August 15, 2005
File ownership 46 47 Terminating Dosfsys Error codes returned by Dosfsys
47
Connecting Character Devices
49
Starting device drivers 51 Parallel devices 51 Single parallel port 52 Multiple parallel ports 52 Output buffers 52 Testing parallel drivers 52 Serial devices 53 Hardware adapters 53 The RS-232 serial protocol 55 Conguring serial ports 58 Connecting serial devices 60 Conguring serial lines for terminals and users Exclusive access to serial devices 64 Testing serial drivers 65 Troubleshooting serial device problems 65 Pseudo terminal devices 66 Console Devices 67
62
Licensing
69
Operating system licensing 71 Old- and new-style licenses 71 72 The /.licenses le 72 The etc/licenses directory Verifying your licenses 73 Adding licenses 73 New-style licenses 73 Old-style licenses 74 Activating licenses 74
August 15, 2005
Contents
Transferring a license to another node
74
Networking
77
Introduction 79 Logical node IDs 79 Logical network IDs 79 Physical node IDs 80 Boot servers and booting nodes 80 Network bridging between QNX LANs 81 Planning your network 81 One network or more? 82 Multiple network links 82 Setup considerations 83 Conguring a boot server 86 Step 1 Install the network card(s) 87 Step 2 Install your network licenses 87 Step 3 Start the Network Manager & network driver(s) 89 Step 4 Start nameloc 90 Step 5 Start netboot 91 Step 6 Modify the sysinit.node le 91 Step 7 Modify the netmap le 93 Step 8 Modify the netboot le Booting a node from a QNX network 96 Step 1 Insert the boot ROM 97 Step 2 Install the network card 97 Step 3 Construct the build le 97 98 Step 4 Modify sysinit.node Step 5 Boot the node 98 Booting a node using a BOOTP server 98 Booting a node from its own hard disk 99 Editing the nodes build le 99 Copying the netmap le to the node 100 Installing or transferring a license 100
87
vi
Contents
August 15, 2005
Multiple boot servers 100 Network examples 102 Adding several Ethernet nodes to an Arcnet network Setting up a fault-tolerant Ethernet network 104 Setting up a private network link 105 Network diagnostics 105
102
Setting up User Accounts 107

Starting a user session 109 Shell initialization 109 Setting environment variables 110 Security 110 Access control utilities 111 Deleting a user account 114 More about user and group IDs 114 File permissions 116 The password database 121 Default password les 125 Accounting le 125 Enabling accounting 125 Record format 126 Clearing the logle 127 Compressing the log le 128 Other log les 128
Setting up Terminals 131

Terminal capabilities 133 Setting the terminal type 133 A word about dial-up access 133 The termcap database 134 The terminfo database 135 Creating a terminfo le 135 Extended capabilities for mouse events
136
August 15, 2005
Contents
vii
For more information
137
Print Spooling 139

Introduction 141 Sharing resources on a network 141 Spoolers 141 Using the spool utilities 142 Starting the spooler 142 Submitting spool jobs 142 Querying spool jobs 143 Canceling spool jobs 143 Controlling the spool queues 144 Spooler architecture 144 The spool setup le 147 Syntax denitions 147 Global keywords 150 Variables 151 Default behavior 152 Using setup les 153 Queues and targets 153 Filters 154 Chaining queues 155 Accounting information 155 Input errors 156 Output errors 156 Example setup les 156 Multiple queues feeding a single target 156 Multiple queues feeding three targets 157 Accessing spoolers and queues 159 LPSRVR and LPDEST 160 Examples 160 Initialization les 162
viii
Contents
August 15, 2005
10
Making Backups 165

Introduction 167 When to back up 167 Backup formats 167 Archive backups 168 Filesystem backups 169 Backup media 169 Floppy 169 Tape 171 Removable disk 172 Fixed disk 172 Compression 172 Archive examples 173 Compressed oppy archive 173 UNIX-compatible oppy archive 174 Tape archive 174 Cartridge/optical 175
11
Disk & File Recovery 177

Introduction 179 Making a recovery oppy 180 Overview of QNX disk structure Partition components 182 Directories 185 Links 187 Extent blocks 188 Files 189 File maintenance utilities 190 fdisk 190 dinit 191 chkfsys 191 dcheck 191 zap 192
182
August 15, 2005
Contents
ix
192 Disk recovery procedures 192 Using chkfsys 192 Recovering from a bad block in the middle of a le What to do if your system will no longer boot 195 If the mount fails. . . 198 If the disk is unrecoverable 199 If the lesystem is intact 199 Recovering lost les and directories 200
spatch
195
QNX Console & Keyboard Conventions 201

Entering line-oriented input 203 Line-editing keys 203 Max length of an input line 204 Entering long input lines 205 Recalling commands 205 Switching virtual consoles 205 Using multiple consoles 206 Changing the console fonts 207 Suspending and resuming output 208 Killing a process 208 Invoking the system debugger 208 Rebooting 209 International keyboards 209 The keyboard at a glance 209
Where QNX Files Are Found 213

A typical directory structure 215 Summary of le locations 215
Index
217
Contents
August 15, 2005
About This Guide
August 15, 2005
About This Guide
xi
The Installation & Conguration guide accompanies the QNX operating system and is intended for both system administrators and end-users. It contains the information youll need to install, congure, and maintain a QNX system. The following table may help you nd information quickly: When you want to: Check software installation prerequisites Install the software onto a hard disk Inuence what happens when QNX boots Set up the initial working environment Learn about text-mode keyboard conventions Use virtual consoles Locate system les Learn about QNX modules and system services Assign initial priorities to system processes Select and change the services built into the OS Build a custom OS image Go to this chapter: Basic Installation
QNX Console & Keyboard Conventions Where QNX Files Are Found Building an OS Image
continued. . .
August 15, 2005
About This Guide
xiii
When you want to: Mount and unmount partitions as lesystems Delete block special devices and reinstall lesystem drivers Use prexes or symbolic links Set up a DOS lesystem Start serial and parallel device drivers Assign a driver to a parallel or serial port Congure hardware I/O addresses and interrupts Congure a modem to answer incoming calls Troubleshoot a serial connection problem Get information about installed licenses Add and activate new licenses Transfer a license from one node to another Plan your network Install network cards and drivers
Go to this chapter: Setting up Filesystems
Connecting Character Devices Licensing Networking
continued. . .
xiv
About This Guide
August 15, 2005
When you want to: Assign logical node and network IDs Congure a boot server Congure a machine equipped with a boot ROM Congure a machine to boot from its own hard disk Run network diagnostics Add new users to the system Set up working environment for users Control access to system resources Maintain user accounts Change information in the password database View and change user permissions Set up system accounting information and event logging Select a terminal type Change terminal capabilities
Go to this chapter:
Setting up User Accounts
Setting up Terminals
continued. . .
August 15, 2005
About This Guide
xv
When you want to: Create a custom terminfo le Share printer resources Set up and manage spooling services Set up a data-enqueuing facility Congure queues, lters, and targets Submit, query, suspend, or cancel spool jobs Plan your backup strategy Select suitable backup media and archive formats Compress and archive les Retrieve a set of archived les Maintain les Check data integrity Recover data Fix a system that wont boot Register your service plan and software
Go to this chapter: Print Spooling Making Backups
Disk & File Recovery
continued. . .
xvi
About This Guide
August 15, 2005
When you want to: Update your software Download free software Get technical support Find out about training
Go to this chapter:

Tape section in Making Backups chapter: Added note about the lesystems 512-byte record limit. Also, gave example of increasing the blocking factor when using the pax command and tape devices.
August 15, 2005
About This Guide
xvii
Chapter 1 Basic Installation In this chapter. . .

Installing QNX onto a hard disk 3 Installing additional software 5 The system initialization le 7 Using the system initialization le 10 Time zones and the realtime clock 15
August 15, 2005
Chapter 1 Basic Installation
Installing QNX onto a hard disk

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 inuence 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
System requirements vary, depending on which products you wish to install. For example, to install the base OS on your development system, youll 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 congure your target system to use only the modules actually required at run time.
Distribution media
QNX products may be shipped on either of these two media:
diskette CD-ROM
In both cases, youll 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 congured according to your input during the installation process. During the installation procedure, you may be prompted to conrm your hardware conguration. Make sure you have the correct information about your hardware before you begin:
August 15, 2005
hard disk size and partition(s) hard disk controller type (IDE, Adaptec 2940 SCSI, etc.) network card type and manufacturer (e.g. Ethernet Novell NE2000)
CD-ROM distribution
If your QNX software was shipped on a CD, the installation procedure is quite simple: 1 2 3 Insert the QNX boot diskette into the oppy drive. Insert the CD into the CD-ROM drive. Reboot your computer.
When your computer boots, simply follow the instructions on your screen.
Floppy diskette distribution

To install QNX from oppies, follow these steps: 1 Place the QNX boot diskette into the oppy 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.
If youd like information about the install options before you continue, type use install at the shell prompt. 2 To transfer the software from the diskettes to your hard disk, type the following command at the shell prompt:
install
Simply follow the instructions on your screen to set up your hard disk so it will boot QNX.
August 15, 2005
Installing additional software
Reboot from hard disk. Once all the les have been installed from the oppy diskettes, you should remove any diskettes and reboot your computer from hard disk. QNX should now be up and running. At this point, youll need to log in as root.
Youre now ready to install additional software, customize your installation, set up your network, etc.

There are three possible ways to install additional QSSL software products:
from CD-ROM from oppies
If from CD-ROM. . .
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, youll 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. 1 2 3 4 5 Insert the CD-ROM. Run the Package Installer. From the list of available products, click on the product you want to install. When prompted to do so, enter the appropriate license information for each product youre installing. Follow the instructions on your screen.
August 15, 2005
If from oppies. . .
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 oppy driver must be running. To check if the driver is running, type:
sin ver
If Floppy doesnt appear in the NAME column, type:

Fsys.floppy &
Installation procedure
To install your additional software, follow these steps: 1 2 Insert the products disk 1 in the oppy drive. At the shell prompt, type:
cd / /etc/install [drive]
where drive is the device from which the software is being installed. The default is the local oppy drive (/dev/fd0). Simply follow the instructions on your screen; the software will be installed onto your hard disk.
August 15, 2005
The system initialization le

What happens when the system boots
When QNX boots, an image composed of several QNX processes is loaded into main memory. The rst 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 le. This le the system initialization le (sysinit) contains commands that set up services for a machine. Its 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 benets of QNXs modular architecture. The booted image typically contains only the few essential services needed to start all other required services. When sinit runs, it rsts determines if the image its 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 le. During an alternate boot (from local disk only), sinit tries to boot from the /etc/config/altsysinit le. If it cant boot from either of those les, sinit will try to boot from the /etc/config/sysinit le.
August 15, 2005
If sinit cant nd or open a system initialization le, 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 le that sinit opened.
Customizing the system initialization le

Each system initialization le is simply an ASCII le that you can edit using a text editor (e.g. vi). Each of the three types serves a particular purpose:
sysinit.node node-specic le (where node is a value between 1 and the number of nodes in your network) sysinit default le if sinit cant nd a sysinit.node le altsysinit le thats run when booting an alternate OS from local disk
sysinit.node
If you wish to customize your installation, this is the le 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 le is always created by the install program. The les initial contents reect the installation parameters determined by the choices you made when you installed the software through install.
Customizing a nodes setup
To customize a machines setup, youll need to have a sysinit.node le on the boot server that boots the node youre customizing. You can start with the sysinit.node le for another node with a similar conguration, or you can simply make a copy of the default sysinit le, which you may then modify:
cp /etc/config/sysinit /etc/config/sysinit.node
August 15, 2005
Remember that the node sufx must be the logical node ID of the machine youre customizing.
If you change a machines logical node ID, the machine will look for the sysinit.node le that matches its new logical node ID.
sysinit
The sysinit le is executed when a sysinit.node le isnt present. This le is automatically put on your system during installation. We ship it as a generic le that should be able to boot any machine we recommend that you make few or no modications to this sysinit le.
altsysinit
This le serves as a safety net in case a modication to your sysinit.node le leaves the system in a state where you cant log in. The altsysinit le 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 le should always contain a backup of the last working copy of the sysinit.node le for a machine that boots from a local hard disk. So, before you make any changes to a working sysinit.node le that could prevent the machine from booting from hard disk, you should copy the /.boot le to /.altboot and copy the sysinit.node le to altsysinit:
cp /.boot /.altboot cp /etc/config/sysinit.node /etc/config/altsysinit
We recommend that you update the /.altboot and altsysinit les after all successful changes to your sysinit.node le.
August 15, 2005
Using the system initialization le

Base-level services
The contents of each machines sysinit le reect 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 les.
If several machines will be using a common set of commands, you can place the commands in a separate shell script and have the le executed via the . (dot) shell built-in. For example, lets say you create a le called techies containing commands to be used by all the machines in your Technical Department. The le could be executed from within the sysinit.node le of each machine in that department with the following command:
. /etc/config/techies
Youd add node-specic commands after this dot line. For more information on the dot command, see sh in the Utilities Reference.
Establishing the time zone

The following lines dene the time zone (EST in this case) and get the time from the realtime clock. These two lines should be the rst in the le 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.
Starting device drivers

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:
10
August 15, 2005
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 cant nd 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 conguration. For example, the following line changes the baud rate to 57600:
stty baud=57600 </dev/ser1
Starting the oating-point emulator

If your programs use oating point and you dont have a oating-point unit (FPU), youll need to start the oating-point emulator:
emu87 &
Loading node mappings

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 le, even if the node isnt 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 les shipped by QSSL.
August 15, 2005
11
Starting a name server

Every machine in the network must have access to the global name server. You could start the name server on this machine if it isnt 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. Its a good idea to run nameloc on two nodes in order to provide redundancy in case one node running nameloc fails.
We dont recommend running nameloc on every node on the network, as this causes unnecessary network trafc. For more information, see the nameloc utility in the Utilities Reference.
Starting a terminal daemon

The following line starts a login on the rst console and arms all other consoles:
tinit -T /dev/con* -t /dev/con1 &
While it isnt mandatory, almost all installations use the tinit utility. The sysinit les we provide contain tinit.
Optional services
You can add many other services to your sysinit le. 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.
12
August 15, 2005
Setting environment variables

Processes started in the sysinit le inherit their environment variables. The general syntax of an environment variable denition 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.
Starting a oppy driver

To start a local oppy driver, rst start the Filesystem Manager Fsys and then the driver itself as shown below. If the QNX lesystem is already running locally (as will be the case if the machine boots from disk), the Filesystem Manager will already be running and you wont have to include the rst line:
Fsys & Fsys.floppy &
If you want to access the oppy as a QNX lesystem, you must mount it as such:
mount /dev/fd0 /fd0
Starting a CD-ROM lesystem

To access les on a CD, youll need to run the Iso9660fsys lesystem manager, which supports the ISO standard for CD-ROM lesystems as well as the Rock Ridge extensions:
Iso9660fsys &
August 15, 2005
13
Starting a DOS lesystem

If you need to access DOS oppies and partitions, youll have to start a DOS lesystem (Dosfsys):
Dosfsys &
Starting TCP/IP
If you want to connect to a non-QNX machine (e.g. for Internet access), youll need to start the TCP/IP socket manager. For details, refer to the documentation for the TCP/IP for QNX package.
Starting a cron server

If the machine will rarely be rebooted, consider making it a cron server:
cron &
Starting a mouse driver (for console-based apps)

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), youll need to run the Mouse manager. Several mouse types are supported. The following command will detect and start the correct mouse driver:
mousetrap start
Starting the Photon microGUI

On some systems, the system initialization le launches the Photon windowing system for graphical applications. For more information, see the chapter on Photon in the QNX System Architecture manual.
14
August 15, 2005
Time zones and the realtime clock
International keyboard support

By default, the QNX console driver assumes a 101-key US keyboard layout. However, QNX provides a variety of congurations corresponding to the keyboards most commonly used throughout the world. If you need to select an alternate keyboard conguration, 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 machines sysinit.node le. If you subsequently set up other nodes, youll have to change their sysinit.node les to include this command. Note that you can also generate custom keyboard layouts with the
kedit utility.

Its important that the correct date, time, and time zone information be established early during initialization. These values should be set in the rst line of your sysinit le. 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 theres no way for the system to be upgraded or modied in the eld, youll 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 difculty 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
August 15, 2005
15
local time by using information from the time zone environment variable.
If the time zone environment variable TZ isnt 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 les to another system in a different time zone, the dates on the transferred le will appear to be shifted by the difference between the two time zones.
Establishing the time zone

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:
export TZ EST 5 EDT 4 M4.1.0/3 M10.5.0/3
shell command to set an environment variable name of variable Eastern Standard Time UTC - 5 daylight saving time UTC - 4 rst Sunday of April at 3am last Sunday of October at 3am
16
August 15, 2005
Getting the date and time from the realtime clock

If youre booting from disk, you should follow the time zone rules in your sysinit le 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:
setting the realtime clock to UTC setting the realtime clock to local time
We recommend that you set the time in the realtime clock to UTC. But if youre also running operating systems that assume the realtime clock is set to local time (e.g. DOS), youll 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, youll have to manually change the value in the realtime clock when you switch to and from daylight saving time in locales where its 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.
August 15, 2005
17
If youre booting over the network...

If you boot over the network, the booting machine will inherit the UTC time from its boot server. Therefore, you dont need to put this information in your sysinit le.
18
August 15, 2005
Chapter 2 Building an OS Image In this chapter. . .

Introduction 21 Constructing a build le 21 Where executables are stored 23 Selecting executables for an image
24
August 15, 2005
Chapter 2 Building an OS Image
19
Introduction
Introduction
QNX is a modular operating system composed of a microkernel and one or more processes that provide services. For example, the process named Fsys provides lesystem services, the process named Net provides network services, and so on. When you build an OS image, you select the services that you want to be available immediately after boot, and include the processes that provide those services into a custom-built OS. You create this image with the buildqnx utility. The image can be booted from disk by the QNX partition loader or booted over the network using the netboot utility.
Constructing a build le
The buildqnx utility produces a binary image le containing several processes as listed in an input text le called a build le. The build les are kept in the /boot/build directory; the image les are kept in the /boot/images directory. You can create an image for any node by invoking buildqnx directly or by using the make utility and the Makefile in the /boot directory. For example, you could enter either of the following commands to create an image le called hard.1 from the sample build le hard.1:
cd /boot buildqnx build/hard.1 images/hard.ata.1
OR
cd /boot make b=hard.ata.1
August 15, 2005
21
Constructing a build le
Build le format
Each program you want included in the created image is specied using three lines in the build le:
rst line the pathname of the program you want included second line starts with a $, followed by an initial heap size value of 1, followed by a command. third line must be blank to separate one entry from the next.
Relative pathnames are assumed to start at /boot. Heres the sample build le hard.ata.1:
sys/boot $ 1 boot -v sys/Proc32 $ 1 Proc32 -l 1 sys/Slib32 $ 1 Slib32 sys/Slib16 $ 1 Slib16 /bin/Fsys $ 1 Fsys /bin/Fsys.ata $ 1 Fsys.ata /bin/mount $ 1 mount -p /dev/hd0 /dev/hd0t77 / /bin/sinit $ 1 sinit TERM=ansi
22
August 15, 2005
Where executables are stored
Setting heap sizes

The number after the $ symbol sets the initial heap size. A value of 1 will cause the heap size to grow dynamically as needed.
Setting priorities
You can set the initial priority of a process by following the heap size value with an optional :nn argument, where nn is the desired priority in the range from 1 (the lowest) to 30 (the highest). For example, the following would start the oppy driver (Fsys.floppy) with a priority of 8:
/bin/Fsys.floppy $ 1:8 Fsys.floppy
Where executables are stored

Most QNX system executables are stored in the /bin directory. Some components are usable only as part of the boot image; these are stored in subdirectories under the /boot directories. The following table summarizes these conventions: To nd: system executables OS image Makefile build les to make images (the make utility reads these) OS image les system processes needed at boot time Look in:
/bin /boot /boot/build /boot/images /boot/sys
For more information on where les are stored in QNX, see Appendix B.
August 15, 2005
23
Selecting executables for an image

The processes you include in an OS image are determined by several factors. You can typically group images into three classications:
images loaded from disk images loaded over the network images loaded into embedded systems
The boot process (/boot/sys/boot) is always automatically inserted into the rst line of the generated image, even if it isnt explicitly specied. If you need to supply options to sys/boot, you must add the line sys/boot to the build le as the rst process. For images loaded from disk or over the network, you can start most processes after booting. You do so by placing their command lines in the system initialization le that QNX executes after boot (see The system initialization le in the Basic Installation chapter). This lets you keep the boot image small (< 512K) and simple.
The build le doesnt generally contain the Device Manager /bin/Dev. The Device Manager and its drivers are usually started in the system initialization le after the system boots. If the system initialization le isnt executed, the Device Manager will not be started. As a result, your keyboard and system console wont function.
Mandatory processes
When youre building an image, remember that there are two mandatory processes:
the Process Manager/Microkernel (/boot/sys/Proc32) the system shared library (/boot/sys/Slib32)

To run 16-bit programs, you must include the 16-bit shared library /boot/sys/Slib16.
24
August 15, 2005
Disk images
For hard disk booting, you need to include:
the two required system processes (Proc32 rst and Slib32 second) the Filesystem Manager (Fsys) the driver required to access the drive (Fsys.driver)
For more information, see buildqnx, Fsys*, Proc32, Slib*, and sinit in the Utilities Reference.
The Makefile for disk booting

The Makefile for building boot images (under the directory /boot) contains an entry for making a generic hard disk boot image. When you build the OS image, default parameter values are used unless you enter new values when you invoke the make utility. Heres a make example that will create a boot image called /boot/images/hard.1 using a build le called /boot/build/hard.1:
cd /boot make b=hard.1
Note that you can create images statically by invoking the buildqnx utility or dynamically by running the netboot utility. For details, see these utilities in the Utilities Reference. Heres an example of invoking buildqnx by hand this will create an image called /boot/images/ws32.ether1000 from a build le called /boot/build/ws32.ether1000:
cd /boot buildqnx build/ws images/ws32.ether1000
August 15, 2005
25
Copying an image to /.boot

Once youve built an image, it wont become the new boot image until you copy it to the /.boot le. However, before you do this, you should make a backup of the current /.boot le by copying it to the /.altboot le:
cp /.boot /.altboot
If for any reason your new image doesnt work properly, you can press Esc when prompted during the boot process and load the /.altboot le instead of the /.boot le. When you select the alternate boot image, the normal check for the /etc/config/sysinit.node le is replaced by a check for the /etc/config/altsysinit le. You should ensure that the altsysinit le contains the latest copy of your working sysinit le:
cp /etc/config/sysinit.node /etc/config/altsysinit
Network images
For network booting, you need to include:
the two required system processes (Proc32 rst and Slib32 second) the Network Manager (Net) the driver required to access the network hardware (Net.driver)
The build le for network booting

The following build le (/boot/build/ws.ether1000) contains parameter markers that inherit their values from the network environment:
26
August 15, 2005
sys/Proc32 $ 1 Proc32 -l $(lnode) -D sys/Slib32 $ 1 Slib32 sys/Slib16 $ 1 Slib16 /bin/Net $ 1 Net -m $(netmap) /bin/Net.ether1000 $ 1 Net.ether1000 /bin/sinit $ 1 sinit -r //$(bnode)/ sys/Debugger32 $ 1 Debug
TERM=qnx TZ=$(TZ)
The $(lnode) marker in the Proc32 command takes as its value the logical node ID of a booting machine. The logical node ID is determined by netboot and passed to buildqnx based on the Ethernet address of the booting machine and its mapping entry in the /etc/config/netmap le. The $(netmap) marker in the Net command tells Net the initial network mapping of the boot server so that the booting machine can start network communications with it. The $(bnode) marker in the sinit command represents the logical node ID of the boot server. The command sets the root (/) of the booting machines lesystem to the root of the boot server. The value of the $(TZ) marker is inherited from the boot server. The command sets the booting machines time zone information to match the current setting of the boot servers TZ environment variable.
August 15, 2005
27
If you must build a pre-built image for a node, dont use markers hardcode the required values directly into a custom build le instead. For more information, see buildqnx in the Utilities Reference as well as the Networking chapter in this guide. When you boot over the network, you have the option of loading a pre-built image or building one on the y. If you build an image on the y which is recommended then you wont need to build one manually as shown above. This option is specied in the /etc/config/netboot le and documented in the netboot utility man page.
When the netboot utility invokes buildqnx to build an image on the y, the image le is not written to disk.
Embedded images
An embedded image is required for embedded CPU systems. While the term embedded system has various meanings, QNX supports two general classications:
embedded PCs custom hardware
Embedded PCs
These are computerized controllers that behave just like a PC they can have keyboards, screens, disks, or network cards connected to them. Theyre typically used in process control applications. Some of these systems have a small amount of Flash memory available, either built into the CPU card (such as the Ziatech ZT8902) or available as a plug-in card (such as the Ampro MM/SSD). The QNX Embedded Kit supports various CPU cards and Flash cards. This support includes booting from the Flash card (usually via some BIOS hook) and using the Flash memory as a lesystem.
28
August 15, 2005
Custom hardware
These systems are custom designed to t one specic application. They usually have Flash memory, but no disk or network card. Most of these kinds of systems (e.g. Intel 386EX and AMD SC400 processors) have no keyboard or screen. The QNX Embedded Kit provides support for some of the commonly used processor evaluation boards.
Selecting processes for an embedded image

You can modify the QNX Embedded Kit to support your particular hardware. Your embedded image should contain only the processes required to run the system. This image would then have to be transferred to the embedded system (most likely in ROM).
August 15, 2005
29
Chapter 3 Setting up Filesystems In this chapter. . .

Introduction 33 Partitioning the pathname space 33 Setting up a DOS lesystem 38
August 15, 2005
Chapter 3 Setting up Filesystems
31
Introduction
Introduction
Each lesystem has its own root directory. This root is at the top of the directory hierarchy and is where QNX starts looking for other directories and les. The typical name for the root directory of the default lesystem on a hard disk is slash (/). A lesystem rooted at / may be composed of one or more physical lesystems grafted together. A physical lesystem can be a separate disk or partition. If a hard disk has more than one lesystem, their names might be
/hd2, /hd3, /home2, /home3, etc.
One of the physical lesystems is typically assigned to be the root (/), while the other lesystems are mounted as subdirectories. A prex tree maps pathnames to I/O managers and determines which disks and devices are accessed when a process opens a le. In all the examples in this chapter, the prex tree is used to partition the namespace. For more information about the prex tree, see the I/O Namespace chapter in System Architecture.
Partitioning the pathname space

The mount utility can be used to mount disk partitions as block special les, and to mount block special les as QNX lesystems. When you mount a block special le as a lesystem, its location in the pathname space is called a mount point. For example, given a QNX partition (type 77) on hard disk 0 (/dev/hd0), the following command would create the block special le /dev/hd0t77:
mount -p /dev/hd0
The following command would mount all partitions found on hard disk 0 and mount the QNX partition as the root:
mount -p /dev/hd0 /dev/hd0t77 /
August 15, 2005
33
The superuser, the owner, or anyone who has write permission to a device (e.g. disk) or partition can mount or unmount that device. For example, its a good idea to unmount oppy devices or other removable media before removing the disk from the drive. This will help prevent unusual errors or possible le corruption. For more information, see the description of umount in the Utilities Reference. The examples that follow should help clarify how the pathname space is partitioned. Well look at these congurations:
a hard disk and a oppy two hard disks multiple QNX partitions local and remote hard disks
In these examples, we assume that Fsys as well as the appropriate drivers are running, and that the mount -p command has been done on your hard disk.
A hard disk and a oppy

The hard disk is mounted as slash (/) and forms the root of the lesystem. The oppy is mounted as /fd0:
mount /dev/hd0t77 / mount /dev/fd0 /fd0
Any reference to a pathname starting with /fd0 will be directed to a QNX lesystem on the oppy. For example, to show all les on the oppy:
ls -aR /fd0
34
August 15, 2005
Two hard disks (same node)

The rst hard disk is mounted as slash (/) and forms the root of the lesystem. The second hard disk is mounted as /home2:
mount /dev/hd0t77 / mount /dev/hd1t77 /home2
Any reference to a pathname starting with /home2 will be directed to a QNX lesystem on the second hard drive. For example, to show all les on the second hard drive:
ls -aR /home2
Multiple QNX partitions

You can have up to four QNX partitions on a single hard drive. The primary partition should be type 77 (see the fdisk utility in the Utilities Reference). The rest should be assigned 78, 79, and 80. For example:
mount /dev/hd0t77 / mount /dev/hd0t78 /home2
Any reference to a pathname starting with /home2 will be directed to a QNX lesystem on the second partition. For example, to show all les on the second partition:
ls -aR /home2
Local and remote hard disks

In a network, you might have disks with QNX lesystems on more than one machine. You may congure the namespace for these lesystems to be:
independent
August 15, 2005
35
primary/secondary linked independent

In the following examples, youll notice that local lesystems are associated with block special les (e.g. /dev/hd0t77), while remote lesystems are associated with pathname prex mappings. This prex mapping redirects requests to a remote lesystem that will be associated with a remote block special le.
Independent
In this conguration, you treat each machine as an independent, self-contained lesystem. To access a le on a remote machine, youd precede a pathname with the remote machines node number. For example:
//10/etc/motd
The ability to specify a lesystem for a particular node will always work and is the most general mechanism for accessing remote les.
Primary/secondary
In this conguration, you treat one lesystem as the primary and you mount the second lesystem as a subdirectory under the primary. For example, assume node 1 has the primary and node 2 has the secondary mounted as /home2. Node 1 boots from hard disk and has its root set to its local disk by a mount utility built into the OS image (with Fsys and a driver). Its system initialization le would invoke the prefix utility to mount the remote lesystem as follows:
prefix -A /home2=//2/home2
Node 2 boots over the network from node 1 and has its lesystem root set to /=//1/ using the -r option of the sinit utility built into the OS. Its system initialization le would invoke the mount utility to mount the local lesystem as follows:
mount /dev/hd0t77 /home2
36
August 15, 2005
The Filesystem Manager (Fsys) and its driver may be built into the image, but theyre more likely started from the system initialization le. In other words, node 2 boots like a simple diskless machine, then starts its lesystem after booting. Both nodes 1 and 2 will access the lesystem on node 1 as / and the lesystem on node 2 as /home2.
Linked independent
In this conguration, you treat each machine as an independent self-contained lesystem, but you link portions of them together via the prefix utility. For example, assume that the lesystem on node 1 has a /home1 directory while the lesystem on node 2 has a /home2 directory. You could map each home directory into the other lesystems space as follows: On node 1:
On node 2:
Other than this link, each lesystem is self-contained with its own copies of /bin etc. The advantage is greater redundancy: if one department uses node 2, and node 1 goes down, the department using node 2 can continue to work (except that the les under /home1 wont be available). Alternatively, you could use symbolic links to access les in another lesystem. A symbolic link creates a special le that has a pathname as its data. To create a symbolic link, specify the -s option to the ln utility. Lets say theres a le called file1 in the /home1 directory on node 1. The following command would let the department using node 2 access file1 through the file2 symbolic link in the /home2 directory:
August 15, 2005
37
Setting up a DOS lesystem
ln -s /home1/file1 //2/home2/file2
This creates the symbolic link //2/home2/file2, which points to /home1/file1. You could display the contents of file1 within the /home2 directory on node 2 using the less utility as follows:
less file2
For more information about symbolic links, see the Filesystem Manager chapter in System Architecture.
Removing and reinstalling drivers

The superuser can delete (typically via the rm utility) block special devices. If all the devices that a driver is responsible for are deleted, the driver will terminate automatically. This allows users with the appropriate privileges to install, remove, and reinstall drivers in a running system.
For information about how to change user permissions, see the File permissions section in the chapter on Setting up User Accounts.

The Dosfsys lesystem manager provides access to DOS les and directories that reside on DOS disks or partitions. Dosfsys can support up to eight drives. You can create, read, write, and delete les and directories on DOS disks with most QNX programs and standard QNX utilities (such as mkdir, ls, and rmdir). Most QNX utilities will work with DOS les, provided the DOS le structure allows for the functionality required by the utility. Your own C programs will also be able to process DOS les just as they process QNX les, by using the standard I/O functions such as open(), read(), write(), close(), seek(), etc. When you read DOS directories, theyll be presented to you in QNX format.
38
August 15, 2005
Invocation modes
Dosfsys has four invocation modes:
Dosfsys [-S|-s] [-e] [-m] [-t] [dos drive=qnx drive[,R]]... & Dosfsys -i [-n node] [dos drive path]... Dosfsys -o [-n node] Dosfsys -x [-n node]
The -i option lets you get information about the currently adopted DOS drives. The -o option lets you see the names of any les currently open on each device. The -x option terminates the Dosfsys server. If you dont specify -i, -o, or -x, Dosfsys will start up and try to adopt the specied drives. To start or terminate the Dosfsys server, you must be logged in as the superuser (root).
Starting Dosfsys
When you start Dosfsys, it:
opens the specied drive(s) adopts the root DOS name (/dos) registers the name qnx/dosfsys with the local Process Manager
If no options have been specied, or if either -S or -s has been specied, Dosfsys scans the /dev directory for valid DOS drives to adopt. Unless otherwise specied on the command line, Dosfsys will adopt up to eight drives. DOS primary partitions (/dev/hd0t1, /dev/hd0t4, /dev/hd0t6, etc.) and extended partitions (/dev/hd0t1.1, /dev/hd0t1.2, etc.) are mounted starting at drive C (/dos/c). Floppy drives are mounted as follows:
August 15, 2005
39
/dev/fd0 /dev/fd1
/dos/a /dos/b
Dosfsys name adoption

The Dosfsys lesystem manager can adopt up to eight drives. As mentioned above, Dosfsys will adopt the name /dos as a system prex. It will also manage each specic drives name as /dos/a, /dos/b, etc. These names arent registered in the system prex tree but are kept internally by Dosfsys. This will be transparent to the user except for the fact that the user wont be able to create les or directories at the /dos root.
DOS devices
A DOS device could be one of the following:
a DOS partition on a hard disk a oppy diskette an image of a DOS partition or diskette
To create an image of a DOS diskette or DOS partition, you use the QNX cp utility. For example, to copy an image of a DOS oppy in your oppy drive 0, you could use the following:
cp /dev/fd0 /usr/qnx/dosa
and then invoke Dosfsys as follows:

Dosfsys a=/usr/qnx/dosa &
The same could be done with a hard disk partition. Dosfsys will handle these images just as it would the actual device. For all non-removable devices, Dosfsys immediately reads the DOS Boot Parameter Block (BPB) as well as part of the File Allocation Table (FAT) at startup. For removable devices, the BPB and the FAT are read only when the drive is being accessed.
40
August 15, 2005
When Dosfsys has a non-removable device open, the device is locked for WRITE so no other process can write to this device without going through Dosfsys. Removable devices are kept open and locked only during accesses (e.g. during reading or writing to the disk). Note that unless you specify the R option, all drives have READ/WRITE access.
DOS version support

The Dosfsys manager supports all DOS partitions formatted with DOS 2.1 or later, including standard primary DOS partitions, DOS large partitions (DOS 4.0 and DOS 5.0 > 32M), and DOS extended partitions (type 5). Hard disks, 5 oppies, and 3 oppies are supported.
DOS partition types

These are the standard DOS hard disk partition types: Type: 1 4 5 6 11 12 14 15 Description: DOS primary partition (12-bit FAT) DOS primary partition (16-bit FAT; 32M) DOS extended partition (DOS 3.3 or later) DOS primary partition (DOS 4.0 or later; > 32M) DOS 32-bit FAT; partitions up to 2047G Same as Type 11, but uses Logical Block Address Int 13h extensions Same as Type 6, but uses Logical Block Address Int 13h extensions Same as Type 5, but uses Logical Block Address Int 13h extensions
August 15, 2005
41
DOS text les

DOS uses a structure for text les thats different from the one used in QNX (by text les we mean line-oriented les containing lines of ASCII text separated by line-separator sequences). In DOS, each line of a text le is terminated with a carriage return/linefeed sequence (CR/LF); in QNX each line is terminated by a linefeed character (LF).
42
August 15, 2005
The Dosfsys manager doesnt translate these les. All les are treated as is. Therefore, you may need to use the QNX textto or tr utility to convert your text les before copying them to or from QNX and DOS disks. Note also that the text les created by some DOS programs may contain a SUB character (Z) as the last character of the le. This is also treated as is.
DOS binary les

Since Dosfsys doesnt translate the contents of les, binary les may be copied to or from the QNX/DOS partitions as is.
QNX-to-DOS character and name mapping

In DOS, your lenames are limited to the 8.3 convention (QNX has no such limitation). Also, you cant include any of these characters in a lename (although theyre perfectly valid in QNX):
/ \ [ ] : * | + = ; , ?
Nor can you use these lenames:
AUX CLOCK$ COM1 COM2 COM3 COM4 CON LPT1 LPT2 LPT3
August 15, 2005
43
NUL PRN
If you attempt to create a le that contains one of the invalid DOS characters or that has an invalid lename, youll be denied access. Since all DOS lenames and lename characters are allowed under QNX, no validation is required on these lenames. DOS also maps all alphabetical characters to uppercase, so Dosfsys maps these characters to uppercase when creating a DOS lename; it maps a lename to lowercase when returning the lename to a QNX application.
Translating QNX lenames

If you specify -t when starting Dosfsys, the server will translate and/or truncate any QNX lenames that dont conform to the DOS naming conventions. The following table describes how names are translated: If the QNX lename: starts with a dot (.) contains multiple dots has a prex longer than eight characters has a sufx longer than three characters
Dosfsys will:
change the . to a $ change all but the last dot to a $ truncate the prex to eight characters truncate the sufx to three characters
44
August 15, 2005
The Microsoft Windows 95 release has added support for long lenames that arent limited to the traditional DOS 8.3 lename convention. Dosfsys can read, but not create, long Windows 95 lenames. To have Dosfsys recognize long Windows 95 lenames, specify the -L option when starting Dosfsys. Here are some examples: QNX lename:
.profile a.b.c.d longfilename longfilename.extension a..b..c.def.g.h
DOS lename:
$profile a$b$c.d longfile longfile.ext a$$b$$c$.h
DOS volume labels

DOS uses the concept of a volume label, which is an actual directory entry at the root of a DOS lesystem. To distinguish between the volume label and an actual DOS le, Dosfsys places an equal sign (=) as the rst character of the volume label name. Dosfsys treats this directory entry as a zero-length, read-only le whose permissions cannot be changed.
DOS-QNX permission mapping

DOS doesnt support all of the permission bits that QNX does. The DOS attribute bits are as follows:
READ ONLY HIDDEN SYSTEM
August 15, 2005
45
VOLUME LABEL DIRECTORY ARCHIVE
Attribute-bit translations
Dosfsys uses the following mapping logic to handle the QNX-to-DOS attribute-bit translations:
If the entry is a directory, set the DOS DIRECTORY le bit If the entry is a le, and if all the QNX WRITE bits are off, set the DOS READ ONLY bit
Permission-bit translations
The following mapping logic is used to handle the DOS-to-QNX permission-bit translations:
Set the QNX READ permission bits for user, group, and other. If the entry isnt a volume label, and if the entry isnt read-only, set the QNX WRITE permission bits for user, group, and other. If the entry is a directory, set the QNX DIRECTORY and EXECUTE bits for user, group, and other. If the entry is a le, set the QNX REGULAR FILE bit.
If a le is written to, the DOS ARCHIVE bit will be set. If Dosfsys is started with the -e option, all DOS les and directories will have the QNX EXECUTE bits set for group/owner/other.
File ownership
Although the DOS lesystem doesnt support user IDs and group IDs, Dosfsys will not return an error code if an attempt is made to change the group ID or user ID with the chown utility or chown() library function. An error isnt returned because a number of utilities make
46
August 15, 2005
use of the chown() library function, which could result in many error messages being displayed. All les under Dosfsys are owned by the superuser (uid=0, group=0) with access to all.
Terminating Dosfsys
The -x option terminates the Dosfsys server. If you specify -x, no new open() requests will be accepted and the server will terminate once all active les (i.e. les still open) are closed.
Error codes returned by Dosfsys

If a request made to Dosfsys isnt supported, the EOPNOTSUPP error code will be returned to the application making the request. Examples of requests not supported by Dosfsys include:
LINK BLOCK READ BLOCK WRITE MOUNT PARTITION MOUNT RAMDISK PIPE DISK GET ENTRY RECORD LOCKING SYMBOLIC LINK
If Dosfsys detects a corrupt lesystem, it will return EBADFSYS, at which point you may wish to run the CHKDSK utility under DOS to correct the problem. The DOS lesystem structure is such that the root directorys size is xed at format time and cannot be resized. If it does become full, an error will be returned (ENOSPC).
August 15, 2005
47
Chapter 4 Connecting Character Devices In this chapter. . .

Starting device drivers Parallel devices 51 Serial devices 53 Pseudo terminal devices Console Devices 67
51 66
August 15, 2005
Chapter 4 Connecting Character Devices
49

A QNX system will usually contain one or more character devices. All such devices are managed by the Dev process. This process must be started rst (as root) before any device drivers are started:
/bin/Dev &
Once Dev has been started, one or more of the following device drivers may be started (as root):
/bin/Dev.con (QNX console device driver) /bin/Dev.par (parallel printer device driver) /bin/Dev.ser (serial device driver) /bin/Dev.pty (pseudo tty driver)
Each of these drivers is described in more detail in the Utilities Reference.
You may need to modify the Dev command in your sysinit.node le to support a larger number of devices than the default. For example, if you specify:
Dev [any other options] -n 64 &
then Dev will support 64 terminal devices (virtual consoles, serial terminals, and pseudo tty devices). For more information, see Dev in the QNX 4 Utilities Reference
Parallel devices
Parallel ports are normally used to communicate with parallel printers. Apart from starting up the driver, theres little work for you to do other than connect the printer to the machine. If your printers on a network, see the Print Spooling chapter to set up the printer as a shared resource.
August 15, 2005
51
Parallel devices
Single parallel port

If only one parallel port is available on a machine, then no parameters are required:
Dev.par &
Started this way, the parallel driver will create a device called /dev/par1, which corresponds to the rst parallel port found by the BIOS (LPT1).
Multiple parallel ports

If your machine has more than one parallel port, then youll need to start an additional Dev.par for each extra port. You must provide a unique name for the extra devices. For example:
Dev.par & Dev.par -b 2 -N laser &
These commands will create a device called /dev/par1 on LPT1, and a second device called /dev/laser on LPT2.
Output buffers
If you have the memory, you might nd that specifying large output buffers signicantly improves turnaround time when sending data to your printer. Heres an example of a parallel device created with a 30K output buffer:
Dev.par -O 30000 &
Testing parallel drivers

If youre having problems with your printer, you can test the basic operation of the driver using the cat utility. The cat utility writes the contents of a le to standard output. You can redirect the output to the printer to determine whether the parallel driver is working as expected:
52
August 15, 2005
Serial devices
cat myfile > /dev/par
For many printers, youll need to send a formfeed (Ctrl L) to cause the page to print.
Serial devices
In this section well look at serial hardware, the RS-232 protocol, and various conguration issues.
Hardware adapters
I/O addresses
The Dev.ser driver can support one or more serial ports. The hardware interface to the computer consists of a Universal Asynchronous Receiver/Transmitter (UART) for each serial port. The driver supports the 8250, 16450, and 16550 families of serial controllers. Each UART uses eight consecutive addresses in the I/O address space of the computer. The Dev.ser driver is informed of the I/O address range for each UART by command-line arguments when it is started.
Hardware interrupt
Just as important as the I/O address is the hardware interrupt generated by each UART. Most PCs provide several hardware interrupt signals on the bus, labeled IRQ2 through IRQ15 (except for interrupts 8, 9, and 13, which are used internally by the system motherboard). These interrupt signals are active-high TTL logic signals on ISA buses, which means that you can connect only one adapter card to any one interrupt signal. Serial adapter cards come in various congurations. Adapter cards with only one serial port typically offer only a limited set of choices for I/O address and hardware interrupt. The following table shows some commonly found combinations, but we recommend that you
August 15, 2005
53
Serial devices
read the hardware documentation carefully to discover the choices available on a given manufacturers adapter card: Name: COM1 COM2 COM3 COM4 Address:
3F8 2F8 3E8 2E8
Interrupt: IRQ4 IRQ3 varies varies
Multiport serial adapters

You can usually congure multiport serial adapters to respond to a wide range of I/O addresses. The adapters may also give you considerable exibility in selecting hardware interrupts. A good choice for I/O addresses is often the 280-through-2BF range.
Note that this discussion applies only to dumb serial cards. Smart cards are typically supported by drivers supplied by the hardware manufacturer refer to the docs that came with the card. Because of the limited number of hardware interrupts available, these cards will often OR the interrupt lines from the individual UARTs into a single interrupt connected to the bus.
QNX allows for many serial ports to share the same interrupt, since Dev.ser will check every UART that shares an interrupt.
Typical hardware installation

The following diagram shows a sophisticated conguration of serial adapter cards in a QNX system.
54
August 15, 2005
Serial devices
CPU bus
Adapter cards
Serial devices
3F8 IRQ4 COM1
Mouse
2F8 IRQ3
Modem COM2
280 288 290 2B8 IRQ5 8-port serial adapter card
Terminal(s)
For proper operation, each serial channel must have a unique I/O address, and each adapter card must use a unique hardware interrupt.
The RS-232 serial protocol

The RS-232C asynchronous communications protocol denes the electrical and physical interface between Data Terminal Equipment (DTE or terminals) and Data Communications Equipment (DCE or modems).
Electrical interface
The following gure shows the cabling assignments of an RS-232 connection.
August 15, 2005
55
Serial devices
(DTR) 20
2 (Tx) 3 (Rx) 4 (RTS) 5 (CTS) 6 (DSR) 7 (SGnd) 8 (CD)
(DTR) 20
2 (Rx) 3 (Tx) 4 (RTS) 5 (CTS) 6 (DSR) 7 (SGnd) 8 (CD)
(RI) 22
(RI) 22
25-pin DTE Interface (computer)
25-pin DCE Interface (modem)
(DSR) 6 (RTS) 7 (CTS) 8 (RI) 9 9-pin DTE Interface (computer)
1 (CD) 2 (Rx) 3 (Tx) 4 (DTR) 5 (SGnd)
(DSR) 6 (RTS) 7 (CTS) 8 (RI) 9 9-pin DCE Interface (modem)
1 (CD) 2 (Tx) 3 (Rx) 4 (DTR) 5 (SGnd)
The host computer is usually congured as a DTE, acting as a terminal device. We assume that the computer will be connected to a modem. The RS-232 signals have the following names: Signal: Tx Rx RTS Meaning: transmit data receive data request to send
continued. . .
56
August 15, 2005
Serial devices
Signal: CTS DSR DTR CD RI SGnd
Meaning: clear to send data set ready data terminal ready carrier detect ring indicator signal ground
Serial protocol
Data is transmitted asynchronously using a bit protocol as shown below:
1 1 0 D0 D1 D2 D3 D4 D5 D6 D7 Par 0 Space Mark
Start bit
Data bits
Parity bit
Stop bit(s)
Normally, an RS-232 data line is in the SPACE (0) condition. A transmitted character consists of bits in the following order:
START bit (always 1) 5 to 8 data bits (least-signicant bit rst) parity bit (optional) one or more STOP (0) bits
The duration of each bit is dened by the baud rate, which indicates the number of bits per second that can be transmitted. If you use the parity bit, it can be one of:
odd
sum of data bits plus parity bit is odd
August 15, 2005
57
Serial devices
even mark space
sum of data bits plus parity bit is even always 1 always 0
Session control
RS-232 uses the DTR and DSR lines to control communication sessions. The terminal raises DTR when it is powered up and available. Similarly, the modem raises DSR when it is powered up and available (but not necessarily connected to a remote modem). No communication is expected to occur unless both DTR and DSR are raised. A terminal indicates that it no longer wishes to communicate by dropping the DTR line, which causes most modems to hang up the telephone line, thus releasing the connection. A modem indicates that it has established a connection by raising CD. Some modems will also indicate that they have detected (but not yet answered) an incoming call by raising RI.
Flow control
The RTS and CTS lines control the ow of data between terminal and modem. The terminal raises RTS when it is capable of receiving data on the Rx line. Similarly, the modem raises CTS when it can accept data on the Tx line.
Conguring serial ports

You use the stty utility to set the four major parameters that dene an RS-232 link.
Data bits
QNX supports four character sizes. You choose the size of data character with the following stty command:
stty bits=n
58
August 15, 2005
Serial devices
where n can be 5, 6, 7, or 8 (the default). This parameter denes how many bits following the start bit will be used to form the character.
Stop bits
Its possible to transmit data that is followed by either one or two stop bits. Two stop bits are used only to slow down the overall transmission of data so that the remote end has a chance to keep up. Using stty, you specify one of these:
stty stopb=1 (the default)
OR
stty stopb=2
Parity
To disable the transmission of parity bits and suppress the checking (in hardware) of received parity bits, you specify:
stty par=none
Parity is disabled by default. If parity is used, you specify one of the following values:
stty stty stty stty par=odd par=even par=mark par=space
Baud rate
You can specify the baud rate with the baud=number option of the stty utility. For example:
August 15, 2005
59
Serial devices
stty baud=2400
The Dev.ser serial driver defaults to 9600 baud. Third-party drivers may have different defaults.
Connecting serial devices

High-speed ECC modems
High-speed, error-correcting modems are becoming very sophisticated they work best when all hardware handshaking signals are respected. These modems often communicate with the host computer at a xed high-speed baud rate (e.g. 115200 or 57600 baud) and use the RTS/CTS handshaking lines to regulate the actual ow of data over the communications link. QNX is ideally suited for communicating with such modems. A straight-through cable is used to connect the modem to the computer.
Tx Rx RTS CTS DSR Gnd CD DTR RI
Computer (DTE)
Modem (DCE)
Straight-through cable
Serial printers
Serial printers are usually bidirectional devices. Data ows from computer to printer as expected, but since printers cant keep up with the host computer, serial printers often use software ow control to regulate the ow of data. In other words, they transmit XON and XOFF characters back to the computer. Some printers use the
60
August 15, 2005
Serial devices
hardware handshaking lines for this purpose, some support both forms of ow control. To be safe, you should connect all nine signals, although printers that support only software ow control may function just as well with a three-wire cable (Rx, Tx, and Gnd). Also, since printers are usually congured as Data Terminal Equipment (DTE) just like the host computer you may need to use a null-modem cable.
Tx Rx RTS CTS DTR DSR CD Gnd RI Tx Rx RTS CTS DTR DSR CD Gnd RI
Computer (DTE)
Serial printer (DTE)
Null-modem cable
The actual wiring of the CD and RI pins may vary depending on the manufacturers cable.
If the printer uses: software ow control hardware ow control both software and hardware ow control
You use:
stty +osflow </dev/ser1 stty +ohflow </dev/ser1
both stty options
If your printers on a network, see the Print Spooling chapter to set up the printer as a shared resource.
August 15, 2005
61
Serial devices
Terminals
Terminals operate with or without ow control and at a xed baud rate. Unlike printers, terminals can usually keep up with the host computer at a supported baud rate. A simple three-wire cable may be sufcient, but we recommend a nine-wire cable. Like the host computer, terminals are normally congured as DTE devices, so a null-modem cable is usually required.
Tx Rx RTS CTS DTR DSR CD Gnd RI Tx Rx RTS CTS DTR DSR CD Gnd RI
Computer (DTE)
Terminal (DTE)
Null-modem cable
If your terminal supports software ow control (e.g. VT100), its a good idea to enable output software ow control and lock it on:
stty +osflow +lksflow </dev/ser1
You could also use the -x option when starting Dev.ser.
Conguring serial lines for terminals and users

QNX can be used as a full-function time-sharing system. Many users can be connected to some or all of the computers in a QNX network via hardwired terminals or through modem links to terminals at remote sites. Assuming that the terminal/modem is properly congured, youll also need to provide a mechanism for users to login.
62
August 15, 2005
Serial devices
Logging in
Assume a terminal, properly connected and congured, on the serial port /dev/ser1. The simplest way of allowing a user sitting at that terminal to log in is to use this command:
on -t /dev/ser1 login
The user will be able to log in and execute commands. However, when the user logs off, the shell session is terminated and the user wont be able to log back in. To give users a way to log in again, specify the -t option to the tinit utility when the terminal is initialized:
tinit -t /dev/ser1 /dev/ser2 &
Automating logins
You can use the tinit utility to automate the login process. When you start tinit with the -T option, this utility waits for a character to be sent from the terminal. You can specify (via the -c option) a command for tinit to execute when a key is pressed. By default, tinit starts the login utility. After the user logs off, tinit waits once again for a character to be sent. The following command starts login on two serial devices (/dev/ser1 and /dev/ser2) when a key is pressed:
tinit -T /dev/ser1 /dev/ser2 &
Launching custom applications

You can start up any program using the -c option to tinit. You can even specify a different program on each device. In some environments, a canned application is always expected on a given terminal. For more information, see the documentation for tinit in the Utilities Reference.
August 15, 2005
63
Serial devices
Modem access
The modem utility is provided to respond to modems. Used in conjunction with tinit, the modem utility can provide excellent dial-up capabilities. A typical dial-up system using QNX might have several serial ports (/dev/ser1, /dev/ser2, etc.) and might use the following command to permit dial-up access:
tinit -c "modem -b 38400 -L" -t /dev/ser1 &
The tinit utility can launch modem on each of the serial lines. When communication is established, modem will:
answer the phone determine and set the proper baud exec into login
When the user either logs off or hangs up, tinit will once again launch a new modem, which will wait for another call. For more information, see modem in the Utilities Reference.
Exclusive access to serial devices

Multiple processes can open the same device; if they read from the device, their reads will be interleaved. This is generally undesirable. To keep this from happening, QNX maintains an open count. The open count, like locks, is advisory only. Programs that require exclusive use of a device should check the open count (through the dev info() routine) before reading from the device. An open count of one would indicate that your program is the only one with the device open. The modem and qtalk utilities make use of this facility so that you dont have to dedicate a serial line for incoming calls. The qtalk terminal emulator checks if the line is free, and if so, will connect underneath modem, allowing you to place an outgoing call. When the qtalk session in complete, modem will again be in control, waiting for incoming calls to arrive. For more information, see qtalk in the Utilities Reference.
64
August 15, 2005
Serial devices
Testing serial drivers

If youre having problems with a serial line, you can use the qtalk utility to verify that the serial driver is working as expected. Running qtalk lets you communicate with a connected system through a serial line. With qtalk running, you can relay the characters you type through the serial link. The following command would start a qtalk session with the system connected directly to a device:
qtalk -m device
Once in qtalk, your keystrokes will be sent through the serial line, and incoming data on the serial line will be displayed on your screen. If this doesnt happen, there could be a problem with the serial port conguration. To test for basic serial port functionality, connect a modem to the serial line and try to talk to the modem in its command mode.
Troubleshooting serial device problems

The following table describes the actions you can take if you encounter some of the common problems involved in connecting serial devices. Problem: No data can be sent or received Probable cause: Wrong cable Wrong I/O ports Remedy: Check cables; use null-modem if necessary Check hardware settings and verify correct parameters to Dev.ser Change interrupt on adapter card
Interrupt conict
continued. . .
August 15, 2005
65
Pseudo terminal devices
Problem: Data is received and transmitted only when another serial port is in use
Probable cause: Interrupt conict
Remedy: Check hardware interrupts and Dev.ser startup parameters; make sure that two serial adapters are not using the same IRQ Determine the type of ow control supported by the device and enable with stty (ihflow, ohflow, isflow, and osflow) Reduce baud rates and/or increase stop bits; if only received data is lost, specify larger input buffer to Dev.ser (-I option) Make sure cable is well grounded and not too long; also, verify that all RS-232 wires in the cable are connected Use stty to set the correct baud rate and/or parity Try different parity using
stty
Data is lost occasionally
Flow control supported, but not enabled
Flow control not supported
Cabling problems
Data characters are unrecognizable Some characters are ne, some arent
Wrong baud rate or parity
Wrong parity
Pseudo terminal devices

The Dev manager is responsible for managing all terminal devices, including pseudo terminal devices or ptys. Pseudo devices are allocated in pairs; the members of each pair are internally connected
66
August 15, 2005
Console Devices
to each other. Any data written to the master side (e.g. /dev/ptyp0) will be available for reading on the slave side (e.g. /dev/ttyp0). You may run into the common problem where Dev hits its maximum number of devices and rejects Dev.ptys attempt to register. If this happens, increase the value of Devs -n option. For example, to create 16 device pairs called /dev/ptyq0 through /dev/ptyqf and /dev/ttyq0 through /dev/ttyqf:
Dev.pty -n 16 -l q &
Console Devices
The display adapter, the screen, and the system keyboard are collectively referred to as the console in QNX. To let you interact with several applications all at once, QNX permits multiple sessions to be run concurrently on consoles by means of virtual consoles. These virtual consoles are usually named /dev/con1, /dev/con2, etc.
Dev manages consoles via its associated console I/O drivers Dev.con or Dev.ansi. Again, Dev itself must be running before any of its
drivers. To set the number of consoles for a machine, you use the console drivers -n option. For example, the following command starts the Dev.con driver with a maximum of 6 virtual consoles:
Dev.con -n 6 &
You can switch from one console to the next by using this simple keychord:
Ctrl Alt Enter
For more information, see the appendix on QNX Console & Keyboard Conventions.
August 15, 2005
67
Chapter 5 Licensing In this chapter. . .

Operating system licensing 71 Verifying your licenses 73 Adding licenses 73
August 15, 2005
Chapter 5 Licensing
69
Operating system licensing

QNX must be licensed for each computer it runs on. This is true whether youre using 10 standalone machines or 10 networked machines. In a network, each machine is referred to as a node and each node is assigned a logical node ID. Logical node IDs range from 1 to the number of nodes in the network. For example, a network licensed for three nodes would support logical node IDs 1, 2, and 3. The number of nodes in your network is determined by the number of licenses youve installed. You install old-style licenses by running the license utility or new-style licenses by adding them to the /.licenses le (see the Adding licenses section).
For licensing to work across a network, the boot server (the machine with the licenses) must be running the nameloc utility. If a machine boots from local hard disk (with licenses) but isnt on a network a portable, for example it must also run nameloc for licensing to work.
Old- and new-style licenses

QNX now supports two licensing schemes concurrently: old-style (earlier than QNX 4.23) and new-style (QNX 4.23 and later). All QNX 4 products released prior to QNX 4.23 use the old-style licensing scheme.
Old-style
Old-style licenses are kept in the /etc/licenses directory. Theres one le per license, and theyre always distributed on disk. Old-style licenses can be installed and transferred from disk to disk only by using the license utility.
August 15, 2005
Chapter 5 Licensing
71
New-style
New-style licenses are kept in the /.licenses le. They can be distributed on disk, but in most cases the license numbers are recorded on paper as a license certicate. New-style licenses on disk must be installed using the license utility, which appends them to the /.licenses le. You may add new-style licenses on certicate to the /.licenses le using any text editor. The /.licenses le can be transferred from disk to disk using the cat command (see the section on Transferring a license to another node in this chapter).
The /.licenses le
New-style licenses are maintained in the le /.licenses. The following shows the contents of a sample (i.e. bogus) /.licenses le. It contains licenses for six products, including the QNX OS:
qnx.00090209-02lg-0947-48g2-00p7-0044 qnx.00035882-02lg-0947-48g2-00p7-0044 wcc.00375634-0l04-4k0l-0x6l-6112-5409 phab.00006233-0040-0527-00l4-ji3g-1130 phrt.00006932-007l-8070-g140-l410-84n3 xrun.00004746-0l04-4l0k-0x7o-5514-8609 motif.00053489-00lk-0245-44e9-04i4-0004 (4 (4 (4 (4 (4 (4 (4 node) node) node) node) node) node) node)
The product name.nnnnnnnn item at the beginning of each line represents the serial number that belongs to the specied product. All QNX licensing is done on a per-node basis. In the example above, two QNX licenses are installed, and four concurrent QNX sessions can be run from each. This means that a maximum of eight copies of QNX can be running concurrently. If you try to run a ninth node, it wont be able to talk to the network.
The etc/licenses directory

Old-style licenses are kept in the /etc/licenses directory. Each license is an individual disk le that can be viewed using the ls command:
ls /etc/licenses
72
Chapter 5 Licensing
August 15, 2005
Verifying your licenses
QNX reports old-style license information in the following format:

qnx0000178n004
where qnx is the name of the product, 0000178 is the serial number, n is a separator, and 004 means that the le is for four nodes. If you installed other QNX applications (e.g. Watcom C), their licenses will also be displayed.
Verifying your licenses

The licinfo utility lets the superuser list all licenses that have been installed. You can specify command-line options to display information by node or by a particular product:
licinfo (lists all licenses in use in the network) licinfo -a (lists all licenses whether theyre in use or not) licinfo -l wcc (lists all C compiler licenses) licinfo -n 1 (lists all licenses on node 1)
Adding licenses
In a network, the licenses must be installed on the boot server. If you wish to boot some machines from their own hard disks, you must install all licenses on all those machines that will boot from hard disk. The newly installed licenses must be activated afterwards in order for QNX to honor them (see Activating licenses below).
New-style licenses
When you buy new software, your license(s) are supplied either on diskette or on a license certicate. Licenses on diskette are added to the /.licenses le automatically during the installation process. If you received a certicate, it will have new license number(s) on it. Youll need to add these license numbers to the /.licenses le manually using a text editor.
August 15, 2005
Chapter 5 Licensing
73
Adding licenses
Dont forget to activate the licenses on your boot server and on all nodes that boot from that server using license -r.
Old-style licenses
The following command installs the license from oppy drive 0 to your hard disk. Note that the oppy driver (Fsys.floppy) must be running:
license
Activating licenses
After you install a license (typically on the boot server), you must activate it. To do so, run license -r on the node (or boot server), which reads all licenses from /.licenses and /etc/licenses (if it exists) and places them in the machines in-memory license database. Nodes that boot over the network will inherit the licensing database from their boot server. You can run the following command to refresh a nodes license information from the boot servers in-memory license database:
license -R boot server node ID
Transferring a license to another node

Old-style licenses can be transferred from one location (or node) to another using the license command. For example, the following command would transfer all licenses from /etc/licenses on node 61 to /etc/licenses on node 71:
license //61/etc/licenses //71/etc/licenses
New-style licenses are kept in the /.licenses le. To copy this le from node to node, use cat (not cp) so that you wont inadvertently
74
Chapter 5 Licensing
August 15, 2005
Adding licenses
overwrite the contents of a le. For example, the following command will append the contents of node 1s /.licenses le to node 5s /.licenses le:
cat //1/.licenses >>//5/.licenses
CAUTION: You should protect your /.licenses le so that the system administrator is the only user with read-write access to the le: As root enter this command:
chmod 600 /.licenses
August 15, 2005
Chapter 5 Licensing
75
Chapter 6 Networking In this chapter. . .

Introduction 79 Planning your network 81 Conguring a boot server 86 Booting a node from a QNX network Booting a node using a BOOTP server Booting a node from its own hard disk Multiple boot servers 100 Network examples 102 Network diagnostics 105
96 98 99
August 15, 2005
Chapter 6 Networking
77
Introduction
Introduction
QNX is a network-distributed operating system. Each computer QNX runs on is called a node. A single computer can be considered a one-node network. The QNX Network Manager recognizes a wide range of protocol packets and passes them to their appropriate destinations transparently.
If you need full TCP/IP-based network communications between a QNX machine and a non-QNX machine, youll have to purchase and install TCP/IP for QNX.
Logical node IDs

All QNX nodes are assigned a unique logical node ID represented by a positive integer. The operating system uses these identiers to communicate with other nodes on a network. You should try to assign logical node IDs in an uninterrupted sequence starting at 1 (e.g. 1, 2, 3, 4, 5, ...). There are two reasons for this:
QNX licensing determines the total number of logical nodes in the network. A ve-node network license allows nodes 1 through 5 to communicate. A node 6 would be isolated and ignored, even if one of nodes 1 through 5 were omitted. A few important utilities (e.g. nameloc) attempt to communicate with each node of the network in turn. They do this by sending messages starting at node 1 and continuing up to node n, where n is the number of installed network licenses.
Logical network IDs

Nodes are connected via one or more physical networks. Each network in an installation is a separate communications link.
August 15, 2005
79
Introduction
Networks, like nodes, are assigned logical network IDs that must be unique. A single network (the most common case) will default to logical network ID 1. If you have a second network, assign it network ID 2.
Physical node IDs

Although QNX processes deal with logical node IDs, the network cards themselves communicate with physical node IDs. This physical ID is typically contained within the network card itself. The format of the physical ID depends on the network type (e.g. Ethernet, Arcnet, Token Ring) and is invisible to most applications. Physical IDs must be unique within a network, but they dont have to be unique across all networks in an installation.
Boot servers and booting nodes

A QNX LAN is essentially a peer-to-peer network that you set up in two phases:
conguring the boot server conguring the booting nodes

Any QNX node that has a hard disk may boot from its own hard disk. A boot server is simply a node that services boot requests from other nodes on a network. Usually a node is chosen to be a boot server because its rarely rebooted. When a node boots from the network, it obtains an OS image from the boot server. This boot image is loaded into memory at the booting machine, which typically inherits the following parameters from the downloaded boot image:
the time the global list of symbolic process names (see nameloc in Utilities Reference) its licensing capabilities
80
August 15, 2005
Planning your network
You can set up your network with multiple boot servers to provide fault-tolerance (in case your primary boot server becomes inoperative) and to distribute the boot resources to avoid boot bottlenecks (aka bootlenecks).
How network booting works

Network cards in a booting node issue boot requests by either:
sending a boot request to a specic boot server

OR
broadcasting a boot request to all nodes, expecting that a boot server will respond to the request
The QNX Arcnet card, which has nonvolatile RAM that can store the node ID of the server, uses the specic boot method. Most other network cards such as Ethernet and Token Ring dont have the means to store the physical node ID of the server, so they must use the broadcast method.
Network bridging between QNX LANs

Any QNX network node can act as a bridge between two different QNX networks, as long as theyre both IEEE 802-type networks. For example, QNX network bridging lets you connect an Ethernet network to a Token Ring network or to an FDDI network. This is possible because QNX uses the same packet format and protocol on all IEEE 802-based networks. All you have to do is connect two different networks to the same node. The node can be a boot server or simply a booting machine.
QNX cant create a bridge to an Arcnet network.
August 15, 2005
81
One network or more?

If youre setting up a small network, it will probably need only a single boot server, typically node 1. But if youre setting up a larger network that will span several departments, you should set up a boot server for each department. The users of each department will still be able to access les (subject to le permissions) in other departments. For example, lets assume you have three departments: R&D, Marketing, and Operations. You may elect to have each department boot from its own boot server, which could also act as the departments major le server. This setup creates a fault-tolerant environment a failure in one department wont stop another department from booting. For large numbers of nodes, this practice should also reduce the potential for a boot bottleneck when people in the ofce start work rst thing in the morning.
Multiple network links

As described in System Architecture, having more than one network link in a computer provides fault-tolerance and increased throughput.
Communicating across networks

In QNX, a node can communicate with multiple networks simultaneously. Consider the following diagram where four computers are linked via two networks:
Network 1 Network 2
Node 1
Node 2
Node 3
Node 4
In this fault-tolerant conguration, each of the four nodes can communicate directly with any other node through either network 1 or network 2.
82
August 15, 2005
Compare this to the following setup, where nodes 1 and 3 are connected to separate networks, and node 2 is common to both networks. Nodes 1 and 3 arent directly connected to each other, but they can both access node 2.
Network 1 Network 2
Node 1
Node 2
Node 3
If node 2 were connected to two IEEE 802-type networks, QNX network bridging would automatically bridge the two networks through node 2.
Setup considerations
You may want to prepare a diagram for your network, similar to the one below. This example diagram shows a network consisting of ve nodes. One of the nodes is the boot server and three are nodes that will boot from and obtain their les from the boot server. Node 5 boots from its own hard disk.
Token ring Ethernet
Node 1
Node 2
Node 3
Node 4
Node 5
Boot server
Bridge
Weve assigned a logical node ID to each node; the boot server is node 1. Note that node 4 will act as a bridge between the Ethernet
August 15, 2005
83
network (logical network ID 1) and the Token Ring network (logical network ID 2).
You cant boot across a bridge. In the previous diagram, for example, node 5 cant boot from node 1.
Network cards and drivers

Setting up a network typically involves installing a network card in your computer and connecting the card via a cable to other computers that have the same type of network card. Ethernet, Arcnet, and Token Ring are all popular network types. In addition to the network card, you need the QNX network driver that supports it. All QNX network drivers are documented in the Utilities Reference. Their names start with the prex Net. Cards from different vendors for the same network media (e.g. Ethernet) may require their own special drivers. But often a driver may support cards from more than one company if the cards provide a similar hardware interface.
For information on the hardware installation/conguration of a network card and the physical connection between network cards, see the docs provided with the card.
Determining physical node IDs

The method you use to determine the physical node ID of a network card depends on the type of card you have. In many cases, youll nd a label with the address of the card in the box. Sometimes switches or jumpers on the card determine the physical node ID of the card.
Ethernet & Token Ring
Every Ethernet or Token Ring card is shipped with its own physical node ID built into the card. This ID, which is unique worldwide, is 48 bits long in order to conform to the IEEE 802 standard.
84
August 15, 2005
On Ethernet cards, the ID may be printed on a label somewhere on the card or on the box. Typically, diagnostic software is used to display the label. The address format of the ID may vary. For example, the following are all identical:
0000c0 4a9330 0000c04a9330 00 00 c0 4a 93 30 00:00:c0:4a:93:30 0000 c04a 9330
Arcnet
Every Arcnet card requires that you program a physical node ID into the card. Depending on the manufacturer, this is done by a DIP switch or is congured in nonvolatile RAM through a menu-driven interface at boot time. The physical ID is 8 bits in length. You cant use physical ID 0, which is reserved. Since you can choose the physical node ID, we recommend that for a single Arcnet network, you make the physical node ID the same as the logical node ID. This will help keep things simple.
Assigning logical node and network IDs

Since QNX processes use logical IDs, the Network Manager (Net) must map these logical IDs to the physical IDs used by the hardware. This mapping is dened in the /etc/config/netmap le. Each line in this le denes a single-node mapping: the logical node and network IDs are followed by a physical node ID. For example, the following line would map logical node 8 on logical network 1 into a 48-bit physical ID of 0000c04a9330:
8 1 0000c0 4a9330
Physical node ID (hex) Logical network ID
Logical node ID
August 15, 2005
85
Conguring a boot server
You can separate the logical and physical IDs by Space or Tab characters. The logical IDs are in decimal, while the physical IDs are in hex, unless preceded by a t, in which case theyre also in decimal. For example, in the case of Arcnet, its convenient to express the physical node ID in decimal form:
15 1 t15
The physical ID cant exceed 48 bits. The network hardware determines the number of bits needed.

This section shows you how to set up a single boot server. Once youve set up a single server, you can set up the booting nodes. If your site requires additional boot servers, see Multiple boot servers.
This procedure assumes that youve already done the basic installation of QNX onto your machines hard disk as described in the Basic Installation chapter. Therefore, your machine has already been congured to boot from its own hard disk. Turning a QNX node into a boot server involves these steps:
installing the network card(s) installing your network licenses starting the Network Manager and the network driver(s) starting the nameloc utility starting the netboot utility modifying the sysinit.node le modifying the netmap le modifying the netboot le
86
August 15, 2005
Step 1 Install the network card(s)

Turn off the computer, then install your network card according to the instructions provided with the card. If you can, note the physical node ID of the card. When youre nished, reboot the computer.
If you werent able to note the physical node ID when installing the card, or if the ID wasnt on the card, running netmap without any options (after the network driver starts) will display the physical node ID.
Installing multiple cards

When you place two similar cards in the same machine, dont rely on the default autodetect for I/O ports, etc. Be sure to verify that the settings are unique you might have to specify some of this information using command-line options to the network driver. You must congure the cards such that they have no hardware conicts. Read the technical note for the type of card(s) youre installing before you install the card. The les in the /etc/readme/technotes directory contain useful tips, such as how to set hardware interrupts so that you can avoid potential conicts.
Step 2 Install your network licenses

Youll need a network license for each node in your network. When you installed QNX onto the hard disk initially, a license was installed for at least a single node. You can verify how many licenses were installed using the licinfo command. See the Licensing chapter for more information about installing and activating licenses.
Step 3 Start the Network Manager & network driver(s)

If you told install that this node is to be a boot server, the appropriate network services will have been started already. Skip this step and go to the next one.
August 15, 2005
87
Starting the Network Manager & one network driver

The Network Manager (Net) and the network driver for your network must be running to access logical network 1. The names for all network drivers are of the form Net.xxx, where xxx represents the appropriate driver. For example, if you have an NE2000-compatible Ethernet card, youd enter something similar to the following:
Net & Net.ether1000 &
To nd out which network drivers are available on your system, enter this command:
ls /bin/Net.*
Starting two or more network drivers

If you installed two network cards, youll have to start a driver for the second network. By default, all network drivers connect to logical network ID 1. When connecting multiple networks, you have to specify the -l (el) command-line option to have a driver connect to a network other than logical network 1. For example, the following three commands in the sysinit.node le of a boot server would start the Network Manager, an Ethernet driver on logical network 1, and a Token Ring driver on logical network 2:
Net & Net.ether1000 & Net.tr164a -l 2 &
Note that the Network Manager must be started with the -d option whenever three or more network drivers are started.
88
August 15, 2005
This command causes nettrap to scan the machine its running on for network cards:
nettrap
CAUTION: The nettrap utility reads and writes to I/O ports and to memory. This testing may cause unintentional side effects in other hardware residing at the tested memory and I/O addresses. If your system is set up to control external machinery, disconnect these devices before running nettrap. The nettrap utility can also be used to start Net along with the appropriate network drivers (and netmap -f):
nettrap start
Step 4 Start nameloc

The nameloc utility runs in the background and provides a network-wide naming service for all processes running under the OS. It must be running on at least one machine on the network even if its the only machine in a standalone network for licensed products to work:
nameloc &
Upon starting, nameloc polls each node in the network for its list of global symbolic process names. For more information, see the description of the nameloc utility in the Utilities Reference.
August 15, 2005
89
CAUTION: The machine running nameloc must be able to talk to every other machine on the network. Make sure the machine has a complete netmap le. If you run nameloc on a node (e.g. a portable) that doesnt have complete network access, youll run into all sorts of problems wrong licensing info, awed list of global names, malfunctioning network-wide utilities, etc.
Step 5 Start netboot

When a booting node starts up, its boot ROM sends a boot request to its boot server or it broadcasts the boot request to any boot server that has been congured to respond. When the Network Manager on the boot server receives a boot request, it forwards the request to the netboot utility. To start netboot, type :
netboot &
When responding to a boot request, the netboot utility accesses the /etc/config/netboot le to determine which build le can be used to generate the OS image for the requesting node.
Running netboot with the -v option (verbose mode) can be useful for troubleshooting. Multiple vs will increase the level of info you might consider directing the output to le or running it on its own console. You may run netboot with the -a option to help automate network mapping (see Step 7):
netboot -a &
In this case, if the /etc/config/netmap le doesnt contain a mapping assignment for the requesting node, netboot will automatically write the required mapping to the /etc/config/netmap le using the next available logical node ID and the logical network ID of the network the requesting node is connected to.
90
August 15, 2005
Step 6 Modify the sysinit.node le

Now that youve started all of the required network drivers and services, the node can function as a boot server. Once youve added the network startup commands to the boot servers sysinit.node le, theyll be started automatically whenever the node is rebooted. First, copy the boot servers sysinit.node le (e.g. sysinit.1) to altsysinit before you continue:
cp /etc/config/sysinit.1 /etc/config/altsysinit
This saves an alternate copy of the boot servers initialization le. Now add the required entries to /etc/config/sysinit.node. Entries similar to the following are required for a boot server:
Net & Net.ether1000 & nameloc & netboot &
Step 7 Modify the netmap le

The /etc/config/netmap le is the default node and network ID mapping le used by the netboot and netmap utilities. This le denes the physical node IDs, the logical node IDs, and the logical network IDs associated with each node. An example le is shipped with QNX. The le you use must contain the logical node and network IDs for the boot server and for all the networked nodes that must communicate with the boot server. The mapping entries in the le look something like this: Node ID 1 Network ID 1 Network Card Address boot server physical address
continued. . .
August 15, 2005
91
Node ID 2 3 4
Network ID 1 1 1
Network Card Address node2 physical address node3 physical address node4 physical address
Note that when you have a single network, the logical network ID is usually 1. All networked nodes must have a unique logical node ID. We suggest that you choose logical node ID 1 for your rst (primary) boot server. In the case of a node thats connected to two or more networks, the same logical node ID will have two entries, each with a unique logical network identier. You can edit the netmap le manually, or if you started netboot with the -a option, the system will write node mappings to the netmap le automatically the rst time you power on each node. The node you power on rst will be assigned the next available logical node ID, the correct logical network ID, and the correct physical address. If you specify the -A option, new nodes are assigned the lowest unassigned logical node ID and the correct physical address. If you have nodes that boot from their own hard disks, you can generate an updated master /etc/config/netmap le on node 1 as follows: 1 2 At all machines except node 1, create a local netmap le containing the logical-to-physical node mapping to node 1. At all nodes except node 1, type the following command to update the in-memory network mappings on node 1:
sin -n1
To save the in-memory network mappings to disk at node 1, type:

netmap > /etc/config/netmap
92
August 15, 2005
If you want to propagate the mappings to other nodes, you can copy the master le from node 1. For example, to copy the master le to node 2, type:
cp //1/etc/config/netmap //2/etc/config/netmap
Mapping multiple networks

To dene a node having more than one network card, you would add one entry to correspond with each network. Remember, the logical network IDs must be unique. For example, if your network had a fth node that was connected to two different networks, youd add two more entries to the netmap le: Node ID 5 5 Network ID 1 2 Network Card Address node5 physical address card1 node5 physical address card2
For more information about the netmap le, see the netmap utility in the Utilities Reference. For examples showing the mappings of multiple networks, see the Network examples section in this chapter.
Every time you edit the netmap le, you should update the in-memory network tables as well:
netmap -f
Step 8 Modify the netboot le

When a boot server receives a boot request from a node, the Network Manager forwards the request along with the nodes physical node ID and logical network ID to the netboot utility.
August 15, 2005
93
With this information, netboot accesses the network mapping le (/etc/config/netmap) to determine the nodes logical node ID. The utility then accesses the /etc/config/netboot le to determine which build le can be used to generate an OS image for the node. If youre using NE2000-compatible cards, your /etc/config/netboot le on the boot server could contain a line similar to the following:
* f=build/ws.ether1000
If you specied to install initially that this node is to be a boot server, your netboot le will already contain what you need. You can modify this f= entry if youd like QNX to use a custom build le. For example, if you copied one of the build les shipped with QNX, renamed it to ws.mybuild, and then dened additional services in this custom build le, you would change the entry so that it looks like this:
* f=build/ws.mybuild
If a number of nodes are equipped with the same kind of network card, a single entry can be used for all of these nodes. In the example entry above, all (*) nodes on the network would be booted from the same build le (ws.mybuild). If your boot server will be servicing boot requests from two or more different nodes and/or networks, you can specify different custom build les for some of your nodes. Weve provided generic build les suitable for building OS images for different network media such as Token Ring in the /boot/build directory. For example, lets say you have an eight-node, NE2000-compatible Ethernet network, and that these nodes boot from the netboot entry f=build/ws.ether1000. If you added three more nodes that will boot from the same server using custom build les, you could modify your /etc/config/netboot so that it looks something like this:
94
August 15, 2005
9 10 11 *
f=build/ether2100.node9 f=build/ws.tr16a f=build/mybuild.node11 f=build/ws.ether1000
In the example above, nodes 9, 10, and 11 use custom build les and all other nodes use the default network build le ws.ether1000.
Note that the position of the line with the * is important! Make sure its the last line in /etc/config/netboot, because the le will stop being processed when the rst match is found.
Setting up for broadcast booting

With a broadcasting boot ROM, netboot needs to know whether it should act as primary, secondary, or tertiary server with respect to each node. The utility nds out by reading an optional server mode parameter in the netboot le. The general syntax of the netboot entries is as follows:
logical node ID f=buildle | F=imagele [server mode]
where server mode species the role that netboot is to play with respect to a node. If server mode isnt specied, netboot will act as a primary boot server for the associated booting nodes.
The F=imagele option lets you name a custom pre-built OS image that can be downloaded to a node that boots from the network. By default, QNX builds an image on the y using the specied build le. For more information about transmitting a named OS image to the booting node instead, see the section on Booting a node from the network. The possible values for server mode are:
A
primary server (default)
August 15, 2005
95
Booting a node from a QNX network
B C
secondary server tertiary server
The following example tells netboot to be the primary boot server for all nodes except node 4, for which it will be a secondary boot server:
4 * f=build/ws.tr16a f=build/ws.ether1000 B A
For information about running netboot on multiple boot servers, see Multiple boot servers.

When a node that boots from a QNX network is powered on, the code in the QNX boot ROM on the machines network card is executed. At this point, either a specic boot server is contacted (if its a QNX Arcnet card) or a broadcast boot request is made. The netboot process on the responding boot server generates and downloads a boot image to RAM on the booting nodes network card. The sinit program will then run and begin launching the services listed in the nodes sysinit.node le. Conguring a node that boots from a QNX network involves these steps:
inserting the QNX boot ROM installing the network card constructing the build le modifying the sysinit.node le booting the node
96
August 15, 2005
Step 1 Insert the boot ROM

To boot QNX from an Ethernet or Token Ring card, you must install a QNX boot ROM in the ROM socket on the card as described in the cards documentation. Note that QNX Arcnet cards come with a special QNX boot ROM already installed. This boot ROM doesnt broadcast a boot request; instead, it contacts a specic boot server. All other QNX boot ROMs use the broadcast-boot method. When the ROM attempts to boot, it broadcasts a boot request to a server it symbolically refers to as server A (primary server). If it gets no response, the ROM will start broadcasting boot requests to server B (secondary server), and nally to server C (tertiary server). If two network cards with boot ROMs are installed in a node, the network card whose ROM resides at the higher memory address is the last one found during the Power On Self Test (POST) sequence performed by the BIOS. This card will usually be the one your node will use to send the boot request over the network.
Step 2 Install the network card

If you havent done so already, read the technical note that applies to the type of card youre installing (see /etc/readme/technotes). Follow the manufacturers installation instructions, and remember to note the physical node ID of the card(s). When booting, the QNX boot ROM will print out the physical node ID.
Step 3 Construct the build le

You can customize the services that each node inherits through its build le. All nodes can have a distinct build le, which can be precongured and stored on the boot server (in the /boot/build directory) or built on the y through the buildqnx utility. By default, images are based on the build les specied in the boot servers netboot le and are built on the y. When you create a
August 15, 2005
97
Booting a node using a BOOTP server
custom operating system image, an F=imagele entry must replace the standard f=buildle entry in the boot servers netboot le.
Net and its associated driver must be started in the build le for
booting nodes. If a node will need more than two network drivers, youll need to specify the -d option to Net in the build le. For details, see the Net documentation in the QNX Utilities Reference. If you choose to modify a nodes build le, you should make a copy of the default version and give the copy a meaningful name such as ws.eth1000 tr16a for a build le that will contain both Ethernet 1000 and Token Ring network drivers then modify the new le.
Step 4 Modify sysinit.node

If youd like to customize the services available to the node, create a sysinit.node le on the boot server for the node and add the required services (see The system initialization le in the Basic Installation chapter). Remember, the node sufx must be the logical node ID of the machine youre customizing.
Step 5 Boot the node

The node should now boot from the network. If you have any problems, specify the -v option to Net in the booting nodes build le. This will display network errors on the console. Its also a good idea to use the -v option for netboot and for the network drivers (Net.*) as well.
Booting a node using a BOOTP server

To boot a QNX system using the BOOTP Internet boot protocol, youll need a BOOTP ROM for your QNX client and a BOOTP server (bootpd) for your server. Since the TFTP protocol is used to move the image from the server to the client, youll also need a TFTP server this is usually provided with a BOOTP server on most systems
98
August 15, 2005
Booting a node from its own hard disk
(UNIX, Windows 95/NT). (Our QNX 4 TCP/IP runtime package includes the bootpd server and the tftpd server.) We support ROMs from Lanworks Technologies (www.lanworks.com). Weve tested Lanworks ROMs with the Win32 BOOTP server from Weird Solutions (www.weird-solutions.com) and the QNX 4 bootpd server. With the Lanworks BOOTP ROMs, the image is placed in memory at 0x10000, so youll need to run buildqnx with the -b option to specify the RAM address:
buildqnx -b 0x10000
For more information on setting up your QNX 4 BOOTP servers, see the bootpd man page in the TCP/IP for QNX Users Guide.
Booting a node from its own hard disk

Your network may include a node that will boot from its own hard disk. If this is the case, you must do the following before you can boot the node:
install the network card as explained previously edit the nodes build le copy the master netmap le to the node install or transfer a license to the nodes hard disk
Editing the nodes build le

The rst entries in a build le start the Process Manager (e.g. sys/Proc32) and set the options that Proc32 will assume. The -l (el) option to Proc32 assigns a logical node ID to the node. When you installed QNX on the hard disk of this node, a logical node ID of 1 was assumed. You must change the logical node ID associated with the -l option to match the node sufx of the nodes sysinit.node le.
August 15, 2005
99
Multiple boot servers
For more information about building a custom image for a node, see the Network images section in the chapter on building an OS image.
Copying the netmap le to the node

A machine that boots from its own hard disk needs a netmap le containing a logical-to-physical node mapping for all nodes that this machine must communicate with. You can generate an updated master /etc/config/netmap le on the boot server as described in Step 7 of the Conguring a boot server section.
Installing or transferring a license

In order for a node to boot from its own hard disk, a license must be present on the hard disk. If you installed a new-style QNX license from the distribution media, a license for the node will already be installed in the /.licenses le. If you received a license certicate, you must add the license number to the /.licenses le. Dont forget to activate new licenses (using license -r). For more information, see the Licensing chapter.

Since broadcasts are potentially seen by all nodes on the network, you can run netboot on several nodes, creating multiple boot servers. This lets you associate specic groups of nodes with different boot servers. Although every netboot process usually receives each broadcast boot request, the utility responds only in accordance with its own unique /etc/config/netboot le, which denes the relationship to each requesting node (e.g. I am node 5s secondary boot server). No two boot servers should have the same server mode entry for any given logical node ID. If this rule isnt followed, every boot server with the same server mode entry for a given logical node ID will respond to that nodes boot request.
100
August 15, 2005
Lets now look at a 15-node Ethernet network, with nodes 1 to 9 belonging to the tech department and nodes 10 to 15 belonging to the marketing department. If you wanted to make node 1 the primary server for tech, and node 10 the primary server for marketing, youd run netboot on both nodes, each with its own netboot le. On node 1 (//1/etc/config/netboot):
2 3 4 5 6 7 8 9 * f=build/al.1000 f=build/pat.1000 f=build/celeste.1000 f=build/robin.1000 f=build/vanessa.1000 f=build/sandy.1000 f=build/john.1000 f=build/bubba.1000 f=build/ws.ether1000 A A A A A A A A B
On node 10 (//10/etc/config/netboot):
10 f=build/andrew.1000 11 f=build/bob.1000 12 f=build/liz.1000 13 f=build/fred.1000 14 f=build/joe.1000 15 f=build/betty.1000 * f=build/ws.ether1000 A A A A A A B
In this case, youve also made node 10 the secondary boot server for tech, and node 1 the secondary server for marketing.
August 15, 2005
101
Network examples
CAUTION: Make sure the line beginning with * is the last line in /etc/config/netboot, because the le will stop being processed when the rst match is found. Also, remember that the server mode entry in the * line must specify a different role from that of all the other node entries for all the other netboots running on all the other nodes on the network.
Network examples
Now that weve discussed whats involved in setting up multiple network links, lets look at how to:
add several Ethernet nodes to an Arcnet network set up a fault-tolerant Ethernet network set up a private network link
Adding several Ethernet nodes to an Arcnet network

Lets assume the following network layout:
Network 1 (Arcnet) 1 2 3 4
Node 2
Node 3
Network 2 (Ethernet)
0000C0 0D9E40
0000C0 064A2D
0000C0 7B7113
Node 1
Node 4
Node 5
Boot server
As youll recall, the format of the /etc/config/netmap le is as follows:

logical node ID logical network ID physical node ID
102
August 15, 2005
Network examples
For this example, the netmap le would contain the following entries:
1 1 2 3 4 4 5 1 2 1 1 1 2 2 t1 0000C0 0D9E40 t2 t3 t4 0000C0 064A2D 0000C0 7B7113
Note that the logical node IDs are unique and consistent across all interconnected networks. In order to boot nodes on a QNX network, the netboot utility requires that each node have an associated OS image or build le. Note that nodes booting on the Arcnet network dont use the same build les as nodes booting on Ethernet. Consequently, the /etc/config/netboot le would contain the following entries:
2 3 4 5 f=build/ws.arcnet f=build/ws.arcnet f=build/ws.arc ether1000 f=build/ws.ether1000
Node 1 has no entry since it boots from its own hard disk. But its sysinit.node le must start both an Arcnet driver and an Ethernet driver. You could congure node 4 to boot from either Arcnet or Ethernet.
Which network node 4 boots from depends on which network card is found last during the ROM scan at powerup the highest addressed card is always found last and is the one the machine will boot from. In this example, assume we congured node 4 to boot over Arcnet by making sure the Arcnet boot ROM is at the highest address. Since node 4 is on both Arcnet and Ethernet, the nodes build le starts Net and both the Net.arcnet and Net.ether1000 drivers. This ensures the boot server can transmit the sysinit.node le on both networks.
August 15, 2005
103
Network examples
Most build les have to start the Network Manager (Net) and the associated network drivers. If you require three or more network drivers, youd have to specify the -d option to Net.
Setting up a fault-tolerant Ethernet network

Lets assume the following network layout:
Network 1 (Ethernet) 0000C0 0D9E40 0000C0 7B7113 0000C0 164C2D 0000C0 DC5E08
Network 2 (Ethernet)
0000C0 064A2D
0000C0 109E40
0000C0 5C9A40
0000C0 129E40
Node 1
Node 2
Node 3
Node 4
Boot server
The corresponding /etc/config/netmap le would contain the following entries:

1 1 2 2 3 3 4 4 1 2 1 2 1 2 1 2 0000C0 0000C0 0000C0 0000C0 0000C0 0000C0 0000C0 0000C0 0D9E40 064A2D 7B7113 109E40 164C2D 5C9A40 DC5E08 129E40
The corresponding /etc/config/netboot le would contain the following entry:

* f=build/ws.eth1000x2
Since an additional Ethernet driver is required, you need to create a custom build le (e.g. ws.eth1000x2) and add a second copy of the Net.ether1000 driver to the le, specifying the -l 2 option.
104
August 15, 2005
Network diagnostics
Setting up a private network link

If theres a lot of trafc between certain nodes on a network, you can set up those nodes with a private network link in order to ofoad the communication ow from the main network, as was done with nodes 2 and 3 in this example:
Network 1 (Ethernet) Network 2 (Ethernet) 0000C0 0D9E40 0000C0 7B7113 0000C0 164C2D 0000C0 DC5E08
0000C0 109E40
0000C0 5C9A40
Node 1
Node 2
Node 3
Node 4
Boot server
You may need to downgrade the Ethernet drivers bit-transmission rate used between node 2 and node 3 on LAN 1. To do this: On node 2 and on node 3, run the driver for LAN 1 with the -r media rate set to 100000 (the default is 10000000):
Net.ether1000 -l1 -r 100000 & Net.ether2100 -l2 &
Network diagnostics
The Network Manager maintains a circular buffer of signicant network runtime events. You can run the netinfo utility to display the most recent buffer. The output includes the time of the network event, the associated node number, the events numerical code, and a brief explanation of what the event means. For more information about these utilities, see their entries in the Utilities Reference.
August 15, 2005
105
Chapter 7 Setting up User Accounts In this chapter. . .

Starting a user session Security 110 Accounting le 125 Other log les 128
109
August 15, 2005
Chapter 7 Setting up User Accounts
107
Starting a user session
Starting a user session

The login utility controls user access to all QNX resources and system functions when a user attempts to login to the system. A user at a terminal /dev/ser1 can gain access to the system by entering correct responses to the following command:
on -t /dev/ser1 /bin/login
When invoked without options, the login utility prompts the user for a username and password. You can automate the login process through the tinit utility. To have tinit start the login process automatically at system startup, you would add the following entry to the nodes sysinit.node le:
tinit -t /dev/ser1 &
Shell initialization
The /etc/profile le is the rst le executed by the login shell (e.g. /bin/sh). Local conventions can be established through this le. The user-specic startup prole le, typically $HOME/.profile, is executed next. You can add any exported environment variables you need to this le. For example, if youd like to preserve your login shell settings whenever a process starts a new shell on your behalf, be sure to dene and export the ENV environment variable in your .profile le. For example:
export ENV=$HOME/.kshrc
This entry ensures that every time a new shell starts, the $HOME/.kshrc le will be executed. To display the values of all exported variables, type export -p.
August 15, 2005
109
Security
Setting environment variables

When a user starts a session, the login shell program (e.g. /bin/sh) is started. See the login and sh man pages in Utilities Reference for info on how the shell variables and defaults operate. Additional settings are retrieved from the users .profile le, if it exists. The shell may add some of the values it requires to the users .profile le automatically. For example, a users .profile le may include settings for the following environment variables: TERM denes the users terminal type (e.g. qnx or qansi for a list of the possible values, see the Setting up Terminals chapter) gives the location of temporary workspace that utilities and programs may use (e.g. /tmp) sets the time zone (e.g. TZ=EST5EDT4)
TMPDIR TZ
The set command can set (+) or unset (-) these shell options. To display a list of the variables that have been dened for your shell, youd type set at the shell prompt. To see the value of one variable, youd type echo $variable name at the shell prompt (e.g. echo $WORKDIR). For more information about these shell commands, see the sh utility in the Utilities Reference.
Security
QNX provides mechanisms to control access to resources and critical system functions. These mechanisms are based on the ability of the system to identify a particular user. When the system boots for the rst time (right after the initial installation), youre automatically logged in as the superuser (root). This username has access to every part of the system and doesnt require a password. To prevent unauthorized users from accessing the system, you should give root a password. You can create a new user account for yourself
110
August 15, 2005
Security
that you can use afterwards for your daily work. The passwd utility allows a login password to be changed; you can use the utility to create new usernames for yourself and others.
Access control utilities

The QNX access control utilities are:
login sign on to the system su temporarily become another user passwd create and maintain user accounts/change passwords
The login utility

The login utility may be started by tinit on tty devices. The utility demands a username and password, and veries them against the user database /etc/passwd before granting access to the system. If the username/password combination is incorrect, login displays a message to that effect and terminates. If the user enters the correct combination, login starts the login shell and loads that users environment.
The su utility
The su utility lets you temporarily have the privileges of another user. If a user ID isnt entered on the command line when you start su, the utility prompts for a password that must match the superusers password. Entering a valid access combination causes su to access the user database /etc/passwd and create a shell that has all the rights and privileges of the assumed user ID. Exiting from the shell returns you to your regular user ID.
The passwd utility

The passwd utility can be used to change passwords or to add a new user account to the system. Anyone can change their own password, but the superuser (root) is the only user who has the right to create or change other passwords. In both cases, the passwd utility locks
August 15, 2005
111
Security
access to the user password le /etc/passwd to prevent any other attempts to access the le while its being modied. If you are: a user
root
Then use this command:

passwd to change your password passwd username to create or change a password
Before you start creating user IDs, you might want to modify passwds behavior. The settings in the le /etc/default/passwd determine which local policies will be enforced by passwd, such as the stringency of passwords, user ID ranges, and so on. For more information about the options you can set, see the passwd utility in the Utilities Reference. The superuser can add a new account by invoking passwd with the new users username. The utility prompts for information that will control the new users environment, including access privileges. The account permissions to include are the users group ID membership and le permissions. For example, to create a new account with the username jsmith, the superuser would enter:
passwd jsmith
By default, passwd will then prompt for the following information:
user ID group ID membership users real name users home directory initial command (e.g. /bin/sh) initial password
112
August 15, 2005
Security
User ID number
By convention, user accounts have a user ID number 100. User ID numbers below 100 are often used by system processes. User ID ranges are set in the /etc/default/passwd le.
Group ID membership
If the group ID doesnt exist, the system will display a reminder to update the group le /etc/group. The /etc/group le grants privileges to all users who are members of a dened group. For example, the Finance department would be allowed access to the companys nancial records, but the Customer Support group would not. You can set up a group ID for Finance with the required access permissions, and then assign users to that group according to the privileges they require. The /etc/group le contains a list of users by group. Each line has the following general syntax: groupname::group ID:user1, user2, user3, ..., userN For example, the following entry denes the group maestri with group ID 123 and members alvivaldi, gfhandel, gptelemann, and jsbach:
maestri::123:alvivaldi, gfhandel, gptelemann, jsbach
Initially youd add groups that have no users, as in the following example:
docs::0: techies::1: support::2: marketing::3: finance::4:
When a user logs in, the value in the password database /etc/passwd will specify the default group ID a user has been assigned to (if any). Users who belong to a group are allowed to switch to the privileges of that group any time using the newgrp command.
August 15, 2005
113
Security
Home directory, initial command, and initial password
The home directory, initial command, and initial password items are optional. If you dont specify a value, the following defaults are used: home directory
/home/username is used (its created if it doesnt exist)
initial command the default shell startup command (/bin/sh) is executed immediately after the user logs in password the user account is created without a password
Deleting a user account

To delete an account, you must remove all of the following:
the user database entry from the /etc/passwd le the username from the corresponding group ID membership entry in the /etc/group le the corresponding encoded login password entry from /etc/shadow le. (optionally) the users home directory (optionally) the users mailbox (i.e. /usr/spool/mail/username)
More about user and group IDs

Upon logging in, a user is assigned two pieces of information: a user ID and a group ID. These are known as the users real user ID and real group ID. The user ID should be unique no two users should share the same ID. This rule can be enforced by the passwd utility, but the superuser can override the rule by editing the password le directly.
114
August 15, 2005
Security
The group ID allows several users to be associated with a group. This group mechanism lets a team of users share resources without making those resources available to the rest of the world. For more information about the /etc/group le and its contents, see the newgrp utility in the Utilities Reference.
Effective user and group IDs

Processes have two classes of user and group IDs: real and effective. When a process is created, it automatically inherits these four IDs from its parent (which is typically the login shell):
real user ID real group ID effective user ID effective group ID

The effective user and group IDs are used for permission checking. A process can change its effective user or group ID, or both, so that they differ from their real counterparts. Typically, this is done to gain access to resources that arent available to the real user and group IDs. To modify effective group and user IDs: from within C programs from within the shell for an executable on disk You use the: seteuid() and setegid() functions
su and newgrp utilities chgrp and chmod utilities (e.g.
to change the group ownership and permission bits for the mailx program:
chgrp mail /usr/bin/mailx chmod g+s /usr/bin/mailx)
August 15, 2005
115
Security
For more information on setuid and setgid bits, see the File permissions section.
The newgrp utility

The newgrp utility starts a new shell with different real and effective group IDs. When invoked without arguments, newgrp switches the group ID to the one identied in the password database for the current user. The password database controls the groups that a particular user may switch to.
File permissions
In QNX, each le has an associated set of permissions called mode bits. These mode bits, in conjunction with the les owner and group, control access to the le. When a process creates a le, the processs effective user ID and effective group ID become the les owner and group. A set of mode bits is also assigned to the le (this is described in the How mode bits are assigned section). There are three classes of mode bits:
owner group other

When a process tries to access a le, the Filesystem Manager honors the appropriate class of mode bits by performing a few comparisons in a specic order: 1 The effective user ID of the requesting process is compared to the owner of the le. If they match, the owner mode bits are honored. If the owner comparison fails, the requesting processs effective group ID is compared to the les group ID. If these group IDs match, the group mode bits are honored.
116
August 15, 2005
Security
If both the owner and group comparisons fail, the other mode bits are honored.
As root (uid 0), you can access any le for read/write regardless of the permissions, and you can execute any le that has at least one mode bit permitting execute access. The le mode bits are stored in the 16-bit st mode eld of the directory entry for the le; access is granted if a mode bit is set.
st_mode bits 0 through 15
15 14 13 12 11 su 10 sg 9 8 r 7 w 6 x 5 r 4 w 3 x 2 r 1 w 0 x
File type setuid
Owner Reserved setgid
Group
Other
As the following table shows, permissions affect regular les and directories differently: This bit:
r w
On les, affects: Reading the le Writing to the le
On directories, affects: Examining the names of les in the directory (e.g. via ls) Creating, removing, and renaming les within the directory, including subdirectories
continued. . .
August 15, 2005
117
Security
This bit:
x
On les, affects: Executing the le
On directories, affects: Searching the directory. This means you can change your current working directory to this directory. Also, you may include this directory within pathnames (e.g. in open(), stat(), etc.)
Execute permission has meaning only for directories and regular les; it doesnt apply to other le types.
Viewing permissions
You can use the ls -l (el) command to see a les permissions, owner, and group. The following ls -l output for the le alpha.c shows that the owner and anyone in the techies group may read and write to the le, while other users may only read it:
-rw-rw-r-1 mplanck techies 8475 Apr 1 1997 alpha.c
In the following example, the ls -ld output for the directory /bin shows that the owner and group members may read, write, and search the directory, while other users dont have write permissions and therefore cant add any new les to the directory:
drwxrwxr-x 2 root techies 2048 Sep 19 1990 bin
But note that other users may still list or execute les in /bin. Its possible though unusual to have read permission on a directory but not search permission. For example, ls could work (depending on the options you give it), but you wouldnt be able to access any le in the directory or do a cd to the directory.
118
August 15, 2005
Security
How mode bits are assigned

The permissions on a le are derived by combining the current umask of the creating process with that processs requested open()/creat() mode. The umask is a permission bit mask that indicates which permission bits are to be turned off if a process species default permission when a le, directory, or FIFO is created (see umask in the Utilities Reference). The mask is the logical AND of the mode and the complement of the umask. For example, if the mode requests read-write permission for everyone as follows: Binary 110 110 110 Octal 0666 Symbolic
rw- rw- rw-
and the umask indicates write permission for group and other: Binary 000 010 010 Octal 0022 Symbolic
--- -w- -w-
then the result is read-write permission for the owner, and read permission for everyone else: Binary 110 100 100 Octal 0644 Symbolic
rw- r-- r--
Changing permissions
You can change the permissions of a le with the following commands:
August 15, 2005
119
Security
To: change owner and group change access permissions; setuid and setgid mode bits set the le mode creation mask
Use:
chown and chgrp utilities or
chown() function (C programs)

chmod utility or chmod()
function (C programs)
umask utility
To modify the owner or access permissions of a le, your effective user ID must match that of the les owner. If you change the owner of the le to be other than yourself, youll no longer be able to change the permissions and ownership of the le. The superuser can modify the mode bits of any le, regardless of who owns the le.
setuid and setgid

To perform certain functions, a user must sometimes run a command pretending to be a different user or a member of a different group. Two le mode bits allow a user to do this:
setuid (set user ID) for example, the passwd utility must behave as if it were root so it could modify the passwd and shadow les on behalf of a user who ordinarily wouldnt have write access. (Mode bits for this command would look like this: -rwsrwxr-x) setgid (set group ID) for example, the mailx command allows a user to temporarily belong to the group mail, thus allowing the user to write to other users mailboxes, which are typically -rw-rw---- username mail. (Mode bits for this command would look like this: -r-xr-sr-x)
With these bits set, an executable le will run with the privileges of its owner and group rather than with the privileges of the process that invokes the executable. These mode bits apply only to executable regular les.
120
August 15, 2005
Security
When a le is loaded for execution and the setuid mode bit is set, the effective user ID of the new process becomes that of the les owner. Similarly, if the setgid mode bit is set, the effective group ID becomes that of the les group. To close a potential security hole, the setuid and setgid bits are cleared any time the le ownership (owner or group) is changed. This prevents users from writing an executable le to disk, setting the setuid bit, and then changing the ownership of the le to root, thereby gaining unlimited system access. The passwd, login, su, and newgrp utilities are all setuid to root; these programs therefore run with the permissions of the superuser. By convention, root is the only user with user ID zero, which yields superuser status. With respect to access control, you must ensure that only programs that can be trusted and absolutely need to be trusted are setuid to root. No special privileges are bestowed on a program when its setgid to root.
CAUTION: Since all programs setuid to root inherit superuser capabilities, you should make sure they do not have general write permissions so that only the superuser will be able to modify the programs.
The password database

These les collectively form the password database:
/etc/passwd /etc/group /etc/shadow /etc/.pwlock

The access permissions to these les should be set as follows:
August 15, 2005
121
Security
File:
/etc/passwd /etc/group /etc/shadow /etc/.pwlock
Owner:
root root root root
Group:
root root root root
Permissions:
rw- r-- r-rw- r-- r-rw- --- --rw- r-- r--
/etc/passwd
The /etc/passwd le contains a set of lines in the following format: username:haspw:userid:group:comment:homedir:shell where: username haspw login name of user if empty, user has no password; if x, users password is in the /etc/shadow le. An empty value or a value of x are the only permitted values. numeric user ID numeric group ID a free-form comment eld; must not contain : home directory of this user (default is /) initial command (and arguments) to start after login (default is /bin/sh)
userid group comment homedir shell
Heres an example /etc/passwd line:

bubba:x:290:120:Bubba L. Jones:/home/bubba:/bin/sh
122
August 15, 2005
Security
/etc/group
The /etc/group le contains lines in the following format: groupname::group ID:[user ID[,user ID]...] where: groupname group ID user ID name of the group numeric ID of the group one or more user IDs belonging to this group
Heres an example /etc/group line:

techies::123:bubba,charlie,sue,jake
/etc/shadow
The /etc/shadow le contains lines in the following format: user ID:password:0:0:0 where: user ID password name of this user encrypted password of this user
Heres an example /etc/shadow line:

bubba:SRjg51|weIJ[H:819388588:0:0
August 15, 2005
123
Security
/etc/.pwlock
The /etc/.pwlock le is created by passwd to indicate to other instances of passwd that the password le is currently being modied. When passwd nishes, the lock le is removed. You may notice from the above permission list that /etc/passwd is readable by anyone. This is to provide standard utilities with a simple mechanism to nd information about users. Since this le is readable, the encrypted password isnt stored in it. The encrypted password is stored in the /etc/shadow le, which is readable only by the superuser. This is to inhibit unauthorized attempts to decrypt the passwords. To protect the security of your user community, you should ensure that these permissions are maintained. QNX is shipped with a default password database that includes /etc/passwd and /etc/group. The /etc/shadow le isnt shipped, because the accounts initially dont have passwords associated with them.
CAUTION: If you must edit the /etc/passwd le on a live system (not generally recommended!), follow these precautions: 1 2 3 4 Run touch on the le to change its access time. Run ls -l to verify that you own the le youve just touched. Do your edits. Remove the /etc/.pwlock le.
Note that if someone else (or some utility like login, su) tries to access the password database while youre editing the /etc/passwd le, you could end up with a corrupt password database! Note also that if you remove a users password, you must also remove the corresponding entry from the /etc/shadow le.
124
August 15, 2005
Accounting le
Default password les

The default /etc/passwd le that was shipped with your QNX system contains the following:
root::0:0::/:/bin/sh
The default /etc/group le contains the following:

root::0:root
Accounting le
The login utility updates system accounting information, which is logged to the /etc/acclog le. If this le doesnt exist, all accounting information will be discarded this is the normal mode of operation after QNX has been installed. For most realtime systems, this default of not keeping accounting information is recommended. If you have a dial-up line to a computer or if you run QNX on a network of many users, you may wish to change this default by creating an empty /etc/acclog le.
Enabling accounting
To enable accounting, you create an empty /etc/acclog le. You can do this using the touch utility:
touch /etc/acclog chmod g=,o= /etc/acclog
Once this le is created, accounting information will be logged here. Note that only the superuser (user ID root) may create and modify this le.
August 15, 2005
125
Accounting le
Record format
Each record in the /etc/acclog le is of the form: tttttttttt cc data... where tttttttttt is the time in seconds since 1970 (in decimal). This is always followed by a single space. The time is followed by a two-character code cc. This code is then followed by a space and data specic to each code. Each line is terminated by a newline character. The following utilities write to the /etc/acclog le: Utility:
login login modem su tinit tinit
Purpose: user logged in login failed modem connect switch user start a command arm a device
Record: tttttttttt LO device uid gid uname tttttttttt LF device uname tttttttttt MO device baud tttttttttt SU device uid gid uname tttttttttt TS device command tttttttttt TA device
A typical accounting le might look like this:

670464500 670464545 670464550 670465824 TS MO LO TS //1/dev/ser1 //1/dev/ser1 //1/dev/ser1 //1/dev/ser1 modem -b 19200 -L 2400 100 101 steve modem -b 19200 -L
This record shows that tinit started a modem program to wait for calls. A call was received and answered at 2400 baud, and user ID steve logged in. Note that the log doesnt show a logout. The logout is inferred, because in the nal entry tinit starts another modem program. The total connect time for the user (from successful login) can be calculated like this: 670465824 - 670464550 = 1274 seconds
126
August 15, 2005
Accounting le
On a busy system, records from many devices will be interspersed throughout the accounting le. In order to match events keyed to each device, youll nd an associated node number that lets you track accounting records for all devices throughout a network in a single logle. Here are several common event sequences: Event sequence:
TS LO TS TS MO LO TS TA TS LO TA TS TS TS MO TS
Meaning: A login and logout on a dedicated line. A login and logout on a dial-up line. A login and logout on a dedicated line armed by a keystroke. An unsuccessful login on a dedicated line. An unsuccessful login on a dial-up line.
Clearing the logle

Once you create /etc/acclog, it will start to grow as records are appended to it. If left unmanaged, this le may grow to consume considerable disk space, so you should print or archive the information in this le on a regular basis. You may even want to automate this housekeeping job using the cron utility (see the Utilities Reference). The following commands will move the accounting le to a le named by year and month, and then create a new empty log:
mv /etc/acclog /etc/acclogs/9607 touch /etc/acclog chmod g=,o= /etc/acclog
August 15, 2005
127
Other log les
Compressing the log le

Since the data in this le is very regular, you may use the gzip compression utility, which will achieve very high rates of compression on the le. This can signicantly reduce disk space requirements if you keep the saved logs online or save them to a oppy.
CAUTION: Remember to move the le before compressing it. Never compress /etc/acclog directly. Heres an example of the recommended compression procedure:
mv /etc/acclog /etc/logs/9607 touch /etc/acclog chmod g=,o= /etc/acclog gzip /etc/logs/9607
Note also that other utilities (possibly third-party) may add their own accounting records to the /etc/acclog le.
Other log les

To have QNX start recording events in a log le, simply create an empty log le in the appropriate directory. You must use the lenames given below. QNX will start logging system events as soon as the associated log le exists.
/tmp/syslog
QNX utilities log problems or unexpected events to the /tmp/syslog le.
/usr/adm/syslog
The logger utility appends lines to the /usr/adm/syslog le. As long as a program has write access to this le, it can run logger as a setuid process owned by adm:adm.
128
August 15, 2005
Other log les
/usr/adm/lastlog
The login utility writes information to the /usr/adm/lastlog le (provided it exists). It can be used to track where and when a user last logged in. The finger utility can display information from the lastlog le by user.
$HOME/.lastlogin
The le $HOME/.lastlogin is created by login. It keeps track of the last time the user logged in, and from which device. The contents of this le are displayed when a user logs in. If a user hasnt logged in since the message of the day (motd) was last updated, the contents of the le /etc/motd (provided it exists) are printed to the users terminal.
/etc/nologin
The presence of an /etc/nologin le prevents anyone from logging in.
/etc/wtmp
The /etc/wtmp le maintains a list of who is currently on the system and how these users are logged in. TCP/IP for QNX uses this information.
/etc/utmp
The /etc/utmp le is updated by login. It contains login information in binary format and maintains a history of all changes to /etc/wtmp.
August 15, 2005
129
Chapter 8 Setting up Terminals In this chapter. . .

Terminal capabilities 133 Setting the terminal type 133 The termcap database 134 The terminfo database 135 Extended capabilities for mouse events
136
August 15, 2005
Chapter 8 Setting up Terminals
131
Terminal capabilities
Terminal capabilities
Two kinds of terminal capabilities les give programmers the freedom to write terminal-independent programs. Older full-screen programs rely on the control codes in the terminal capabilities le /etc/termcap to make use of a terminals capabilities. Newer programs and utilities query the terminfo capabilities database (under /usr/lib/terminfo).
Setting the terminal type

The TERM environment variable species a terminal type. Initially, a program queries the TERM environment variable to determine what kind of terminal its running on. Given a terminal type, the program would then look up the terminals capabilities either in the termcap le or in the applicable terminfo le. The terminal type setting is typically inherited from the environment through sinit immediately after boot:
sinit -r //$(bnode)/ TERM=qnx
As an alternative, the terminal type can be dened in a users .profile le. For hardwired terminals that run canned applications, you can preset the TERM environment variable when the application is launched:
TERM=vt100 on -t /dev/ser1 custom application
But you cant do that for users logging in via login through tinit. If the type of terminal is known, tinit can be told to dene the TERM environment variable before launching login:
tinit -c login -t /dev/ser1 TERM=ansi &
A word about dial-up access

Unless you restrict dial-up access to only a particular type of terminal, modem users will need to run the termdef utility to query for a terminal type. The termdef utility can display all of the supported terminal types and ask the user to select one:
August 15, 2005
133
The termcap database
tinit -c "modem -c termdef" -t /dev/ser1 &
Once a terminal type has been selected, termdef sets the TERM environment variable accordingly and presents the login prompt to the user.
The termcap database

Control codes in the QNX termcap le can dene the input and output capabilities of a number of terminal types, including:
Generic ANSI standard terminal (ansi) QNX console (qnx) QNX ANSI (qansi, qansi-g, qansi-t, qansi-m, or qansi-w) QNX terminal (qnxt) QNX terminal with mouse events (qnxm) QNX windows (qnxw) QNX monochrome terminal or console (qnxtmono) QNX 2.15 serial terminal (qnxt2 or qnxs2) VT100 with Auto-margin (vt100) VT102 (vt102 or vt102-plus) X-term terminal emulator (xterm, xterms, xterm-m, or xterm-q)
For a complete list of terminal types, see /etc/termcap. Each entry in the termcap le begins with a line of terminal aliases. The remaining sequence of control codes is a list of terminal capabilities. Each capability string can be identied by a two-character name. In general, a string describes the terminals behavior when the user presses a key, or the visual effect displayed through program control.
134
August 15, 2005
The terminfo database
If theres more than one entry for the same terminal type, the rst entry is used.
The terminfo database

The terminfo subdirectories /usr/lib/terminfo/... contain binary les. Each le in the terminfo database contains the capability denitions associated with a single terminal type. QNX is shipped with several of these les, including:
/usr/lib/terminfo/q/qnx (the QNX console) /usr/lib/terminfo/v/vt100 (a VT100 terminal) /usr/lib/terminfo/a/ansi (an ANSI terminal)
The corresponding source denitions for all QNX-supported terminal types are contained in /usr/lib/terminfo/terminfo.src. The termcap and terminfo source les are similar in that they both contain descriptions of terminal capabilities. However, the capability names in a terminfo le can be two to ve characters long. And because the terminfo les are compiled, they load and execute faster. If you need to convert from terminfo to termcap (as is the case for some older applications), the infocmp utility has a -C option that generates a termcap entry from an existing terminfo denition. If theres more than one entry for the same terminal type in a terminfo le, the last entry is used. If you dont have a terminfo le for your type of terminal, you could look for the appropriate terminfo le on any UNIX system, or create a new terminfo le through the infocmp and tic utilities.
Creating a terminfo le
To view or change the information in an existing terminfo capabilities le, you must rst decompile the le through the infocmp utility. To use a modied source le, you must recompile it into binary form using tic, the terminfo compiler utility.
August 15, 2005
135
Extended capabilities for mouse events
Applications can extract the capabilities they need for a given terminal directly from the compiled version.
You may want to choose capabilities from the higher-level library curses instead.

The QNX termcap and terminfo les support many of the standard terminal capabilities. In addition to these, QNX supports the following extensions to the string and numeric capabilities to handle mouse events.
termcap name terminfo name
Description:
micro down. Dont return
ZZ Za Zb Zd Zf Zg Zh Zi
mcud1 mcub1 mcuf1 mcuu1 mcud mcub mcuf mcuu
press.
micro left. Return mouse
movement.
micro right. Dont return
mouse movement.
micro up. Dont report
release.
parm down micro. Return ADJUST press. parm left micro. Return SELECT press. parm right micro. Return MENU press. parm up micro. Report
button release.
continued. . .
136
August 15, 2005
termcap name
terminfo name
Description:
enter micro mode. Report
ZJ ZT Yd
smicm rmicm maddr
screen size changes.

exit micro mode. Dont
report screen size changes.

max micro address.
Maximum value in micro ... address (a numeric capability).
For more information

For a complete list of capability names and their meanings, see the terminfo technote on QUICS. For more information about termcap and terminfo, we recommend termcap & terminfo, by Strang, Mui, & OReilly (ISBN 0-937175-22-6).
August 15, 2005
137
Chapter 9 Print Spooling In this chapter. . .

Introduction 141 Using the spool utilities 142 Spooler architecture 144 The spool setup le 147 Using setup les 153 Example setup les 156 Accessing spoolers and queues
159
August 15, 2005
Chapter 9 Print Spooling
139
Introduction
Introduction
Sharing resources on a network
QNX encourages the network-wide distribution of resources with few articial boundaries. Every device (disk, modem, printer, etc.) connected to a computer is, by default, a shared resource a program running on any computer has equal access to any device on the network, whether the device is connected to the same computer (local) or to another machine (remote). Although its easy for a user to transparently access any resource on the network, the system administrator may need to take steps to control access to certain types of resources. Most printers, for example, can be used by only one user at a time and therefore require some sort of enqueuing facility to avoid conicts. To allow convenient access to printers, QNX provides a set of spooling services.
Spoolers
A spooler is simply a mechanism that accepts requests for a resource and then allocates the use of the resource according to a set of specied rules. To understand how a spooler can be useful, lets look at how it controls access to a printer. A printer must be available at all times to users, yet it can print only one job at a time. If a spooler is present, users can send their data through the spooler rather than directly to the printer. Upon receiving data destined for the printer, the spooler writes this data into a temporary le instead of sending it immediately to the printer. Later, when the printer becomes available, the spooler will write the data to the printer. Thus, many users can freely submit print jobs to one physical printer. QNX implements spooling through the use of named queues that are referenced by the lp set of utilities; these queues also reside in the le namespace in the /dev/spool directory. Data written to a queue will be placed on an internal list and ultimately sent to a dened output device.
August 15, 2005
141
Using the spool utilities
The QNX spooling server (lpsrvr) can maintain many different spool queues. The following utilities operate on spool queues:
lp lprm lpc lpq
submit les to a spool queue remove jobs from a spool queue control spooler queue display spool queue status
For more information on these utilities, see the Utilities Reference. For information about how to queue print jobs to a printer on a TCP/IP network, see the chapter on remote printing in the TCP/IP for QNX Users Guide.

Starting the spooler
Before any spooling can occur in a QNX system, you must run lpsrvr:
lpsrvr &
To determine what resources it has available, and how its expected to manage them, the lpsrvr utility rst looks for a setup le called /etc/config/lpsrvr.node (where node is the node ID of the node lpsrvr is running on). If no setup le is found with a .node extension, lpsrvr will use the /etc/config/lpsrvr le.
Submitting spool jobs

The following lp command will cause the le report to be inserted into the default spool queue and ultimately printed:
lp report
For more information on the default queue, see The spool setup le in this chapter.
142
August 15, 2005
In systems where more than one spool queue is available, you can specify the queue name. The following command inserts report into a spool queue called txt:
lp -P txt report
You could also use a command that writes directly to the queue le:
cp report /dev/spool/txt
Querying spool jobs

To examine the spool queue, you can use the lpq utility. The following is a sample output from lpq:
1: 2: fred wilma [job #39] [job #42] 1400 bytes 2312 bytes lalist.doc netdrvr.c
This utility lets you determine when any submitted jobs have been completed; it also provides the spool job ID for use with other lp utilities.
Canceling spool jobs

The lprm utility lets you remove jobs from a spool queue. You can remove a job explicitly by specifying its job ID number. Given the state of the default queue shown above, freds job (#39) could be canceled with this command:
lprm 39
If job #39 is currently in progress, it will be abandoned. The success of abandoning current spool jobs may vary with the type of output device youre using some printers have large internal buffers. The superuser may also remove all jobs belonging to a particular user. For example, all of freds jobs can be canceled with the following command:
lprm fred
August 15, 2005
143
Spooler architecture
Controlling the spool queues

The lpc utility is a system administration tool for managing spoolers. It lets you perform many control functions, such as starting up or shutting down a queue. The following basic functions are provided:
suspend/resume enqueuing of jobs suspend/resume dequeuing of jobs suspend/resume the current job delete the current job rearrange the jobs in a queue move jobs to a different queue display the status of queues
Note that lpcs functionality overlaps that of lpq and lprm. This overlap is convenient, because unlike lpq and lprm, lpc can be used interactively.
The QNX spooling system is based on two objects: queues and targets. These work with each other to provide a exible method of controlling data transformations and queuing. A queue is an internal list of pending data to be sent to a target. As mentioned earlier, each queue is given a name that users specify when submitting jobs. A target is associated with the physical output device (e.g. a printer) and removes jobs from queues. You can connect the output of a queue to one or more targets or connect multiple queues to a single target. However, you can connect the output of a target to only one device. Queues can have optional attributes called lters, which are of two types:
144
August 15, 2005
copy-in (ci) lters, which perform operations on the data before its copied onto a queue copy-out (co) lters, which operate on the data after its removed from a queue.
For example:
ci=a2ps -H"$(file)" | awk /%%EndProlog/ { print "<< /Duplex \ true >> setpagedevice"; } { print $0; } co=echo $(username)"\n" "put" $(spfile) | SOCK=666 /usr/ucb/ftp net printer
Targets may have an optional control program (cp) that allows the output device to be initialized between jobs if required. For example, if a job were canceled and the device needed to be primed again, a device-specic control program could detect SIGTERM and take whatever action necessary to restore the device to a stable state. The following diagrams illustrate how queues, lters, and targets can be congured to work with each other.
One queue feeding a single target

The following conguration could be used where theres a single printer and where a single (or no) translation of the data is required:
ci co cp
device
Queue
Target
Multiple queues feeding a single target

Multiple queues may feed a single target, in which case the target will select the appropriate job from all the jobs in those queues based upon queue priority, then upon time of submission (i.e. the oldest pending job).
ci co cp
device
ci
co
August 15, 2005
145
At the end of this chapter, youll nd several example setup les. The above conguration is used in the example le in which one queue converts ASCII to PostScript, while the other is a direct PostScript queue. Both queues feed the same target, which sends the data to a PostScript printer.
One queue feeding multiple targets

If the output of a queue is sent to many targets, the spooler will select whichever target is available. The following conguration is useful if you have three printers side by side and it doesnt matter which one prints your job.
ci co cp
device
cp
device
cp
device
Multiple queues feeding multiple targets

The following conguration is a combination of the previous two examples. A third queue has a separate channel to one of the targets. This channel could be used to ensure that jobs requiring the third printer are always sent to that printer (e.g. the printer has color capabilities).
ci co cp
device
ci
co
cp
device
cp ci co
device
146
August 15, 2005
The spool setup le
Chaining queues
The output of a queue is usually sent to one or more targets, but its possible instead to chain the output into another queue. With chaining, the output of a queue is placed directly onto the destination queue, thus avoiding any possible copy-in operation on that queue. If the nal queue in a chain has a copy-out lter, the lter will be applied.
ci
ci
co
cp
device
The spool setup le

When started, the spooler accesses a le to get its conguration information. If no le is specied on the command line, the spooler uses the /etc/config/lpsrvr le. This le denes queues, targets, and the relationships between them.
Syntax denitions
Queues and targets have symbolic names as well as a set of attributes. Each entry in the setup le has the following format:
[name] attribute attribute . . .
The denition of a queue or target begins with a [name] directive and consists of all valid attribute specications until the next [name] directive. All leading white space is ignored. Comment lines start with a pound sign (#).
August 15, 2005
147
The spool setup le
To continue a single attribute beyond one line, you must put a backlash (\) right before the newline character. The name may be up to 48 characters long and may contain only alphanumeric characters. If the object being described is a target, the name must be preceded by a dash (-). The dash is for delineation only; it isnt considered part of the name. Each attribute consists of a two-letter key in one of the following forms:
key (Boolean) key#number (numeric) key=string (character)

All numbers are assumed to be decimal numbers, unless they start with a leading zero (meaning octal) or a leading 0x (meaning hex). All strings contain printable characters. The backslash (\) is a special character. It can be used to escape other characters. For example, a real backslash must be represented with: \\ The following table describes all dened keys, including the default used for each key if its corresponding attribute isnt specied. In the Use column, Q means queue, T means target, and G means global. Key:
ab=string
Description: Executed when target abandons command for any reason accounting f ile that commands may use
Default: nil; no command is executed
Use: T
af=string
accounting isnt performed (lpsrvr logging is unaffected)
continued. . .
148
August 15, 2005
The spool setup le
Key:
cd=string ci=string
Description: directory where temporary spool les are found copy-in command; used before placing the job on the queue copy-out command; used when removing job from queue device control program; used by the target device that the target uses minimum number of jobs for queue before ushing maximum number of jobs the queue will hold name; a string that describes the queue or target command executed when target completes normally priority to run this queue at (1-100); 100 is the highest queue to chain a despooled job onto retries when a job fails retry time; number of seconds or die
Default:
/usr/spool/lp
Use: G Q
binary copy-in of job; no transformation applied binary copy-out of job; no transformation applied binary copy of job; no transformation applied output is sent to standard output of lpsrvr
0; jobs are despooled ASAP
co=string
cp=string dv=string mn#numeric mx#numeric
T Q, T Q Q
no limit; queue limits are based on memory and disk space nil string nil; no action is performed 50 nil; delete job after despooling 0 forever
na=string ok=string pr#numeric qn=string re#numeric rt#numeric
Q, T T Q Q Q Q
continued. . .
August 15, 2005
149
The spool setup le
Key:
sp=string
Description: registered name of spooler maintaining this queue target to be associated with this queue wait this number of seconds before despooling each job
Default:
/qnx/spooler; registered
Use: G
only if no queue species a name output is sent to standard output of lpsrvr

0; jobs are despooled ASAP
ta=string wa#numeric
Q Q
Since the keys are case-sensitive, we reserve all keys formed by two lowercase letters. You can safely implement custom extensions by using uppercase or mixed-case keys. The spooler utilities will ignore any options they dont understand.
Global keywords
Two keywords, sp and cd, can dene global information for the spooler. To make them apply globally, you precede these keywords with a pair of empty brackets ([ ]).
Registering names sp
Since the spooler always adopts the /dev/spool le namespace, only one spooler may run on each node. You can run multiple spoolers on your network if each spooler registers a different global name. Otherwise, each spooler will attempt to register the same default global name /qnx/spooler. With multiple spoolers, you may wish to use names such as /qnx/spooler2, /qnx/spooler3, and so on. To specify the global name to be registered by a spooler, you use the sp command in the setup le. The name must always begin with a leading slash (/). If no sp keyword is specied, the default name /qnx/spooler is globally registered (i.e. network-wide).
150
August 15, 2005
The spool setup le
Specifying a temporary directory for spool les cd

The cd keyword lets you dene the directory to use for the creation of the spoolers temporary spool les. By default, temporary les are created in the /usr/spool/lp directory. These les get deleted when theyre no longer required. Any path you specify to the cd keyword should begin with a leading slash. Note that the specied directory must exist, with appropriate access rights assigned. The following example setup le informs the spooler to register the name /qnx/spooler2; it also places temporary les in the /tmp/spool2 directory:
# Global spooler variables [] sp=/qnx/spooler2 cd=/tmp/spool2 # Text queue [txt]....
Variables
The spooler will set the following variables appropriately when it encounters them: Variable: $(le) $(fname) $(sple) Description: the lename of the submitted le or --standard input-- if no name is provided the fully resolved pathname of the submitted le or --standard input-- if no name is provided the name of the spool data le
continued. . .
August 15, 2005
151
The spool setup le
Variable: $(username) $(userid) $(queue) $(target) $(device) $(ncopies) $(jobid) $(cile)
Description: the login name of the user who submitted the job the numeric user ID of the user who submitted the job the name of the queue the job currently belongs to the name of the target the job currently belongs to the name of the device the job is scheduled on the number of copies the user requested the job ID number of this job a temporary name that copy-in routines may use
In addition, all the keys dened above can be referenced as variables. For example, $(ci) will expand to the name of the copy-in command, ci=string.
Default behavior
The cat command is used as the default copy-in and copy-out lter commands. Also, unless otherwise specied in the setup le, the standard input and standard output of lter commands are automatically connected to default les or processes. The default for copy-in is as follows:
cat < $(fname) > $(spfile)
There are two possible defaults for a copy-out, depending on whether or not a control program (i.e. cp) is dened:
cat < $(spfile) > $(device) cat < $(spfile) | $(cp) > $(device)
For example, a setup le like this:

[txt]
152
August 15, 2005
Using setup les
ta=lpt ci=pr -f -h co=txt2ps cp=init printer [-lpt] dv=/dev/par
would result in the following substitutions:

pr -f -h < $(fname) > $(spfile) txt2ps < $(spfile) | init printer > /dev/par
Using setup les

Queues and targets
When you create a setup le, you specify each queue by giving it a name and an optional list of parameters; you specify each target by starting its name with a dash (-). To illustrate, heres a very simple setup le:
[txt] ta=lpt [-lpt] dv=/dev/par
In this le we have a queue called txt and a target called lpt. When data is sent to the txt spool queue, the data is saved in a temporary spool le and is known as a job. When the spooler removes that job from the queue, the job is placed on the target, lpt, which then directs the data to the parallel port, /dev/par.
August 15, 2005
153
Using setup les
Filters
Its often necessary to lter spooled data, so lpsrvr provides the copy-in and copy-out mechanisms. As mentioned earlier, copy-in is run before the data is placed on the queue, while copy-out is run after the data is removed from the queue. Note that if you have many queues feeding a single target and one of the queues has a copy-out lter that may take a long time to run, the target will be temporarily unavailable to the remaining queues if that queue is selected. (For more information, see the Example setup les section.)
Its good practice to put double quotes around variables to ensure theyre safe for the command.
Using copy-in
A good example of the use of a copy-in lter is to pass the data through pr to paginate it:
[txt] ci=pr -f -h "$(file)" ta=lpt [-lpt] dv=/dev/par
Using copy-out
You might use a copy-out lter, for example, when you have both a PostScript printer and an HP printer. You could have two copy-out lters to generate the proper output format. Lets say you have two programs: txt2ps, which generates PostScript, and txt2hpgl, which generates HPGL:
[ps] ta=lpt1 co=txt2ps
154
August 15, 2005
Using setup les
[hp] ta=lpt2 co=txt2hpgl [-lpt1] dv=/dev/ser [-lpt2] dv=/dev/par
Dont hardcode the output device in a copy-out denition; use targets for this purpose. Targets must have exclusive use of a device and should be the only means of accessing a device within the spooling system.
Chaining queues
Queues can be chained this moves the job from queue to queue. The following is a simple example of chaining onto a queue named tmp, which then sends the data to the lpt target:
[txt] qn=tmp [tmp] ta=lpt [-lpt] dv=/dev/par
Accounting information
The af keyword lets you specify a lename that the commands may access as $(af) so they can write any information they want to log.
August 15, 2005
155
Example setup les
Input errors
The invoking lp utility will report any errors that occur during the input of data into a queue. If you submit data by directly writing to the spool le in the /dev/spool directory, write errors will occur if something prevents a successful copy into the queue.
Output errors
You can use the ab keyword to specify a command to execute if a target abandons a job. The following would inform the invoking user of the error via a mail message:
ab=echo lpsrvr print job $(jobid), file $(file) failed \ | mailx $(username)
Example setup les

Multiple queues feeding a single target
The following example shows a set of queues that share a common target. The three queues are named:
txt (ASCII text les) ps (PostScript les) gif (Graphic Interchange Format les)
The conguration is as follows:

(txt) text2ps /dev/par (lpt)
(ps)
(gif)
gif2ps
Heres the le to set this up:
156
August 15, 2005
Example setup les
# ASCII to PostScript queue: [txt] ta=lpt ci=text2ps pr#50 # direct PostScript queue: [ps] ta=lpt pr#60 # GIF to PostScript queue: [gif] ta=lpt ci=gif2ps pr#5 # target printer: [-lpt] dv=/dev/par
In this example, users send les with the lp utility to the appropriate queue, which converts the le through a copy-in lter (except for the ps queue). The queue then sends the converted data to the target, /dev/par. Since the hypothetical lter programs text2ps and gif2ps may take a relatively long time to process a job, copy-in lters are used rather than copy-out lters. A copy-out lter will tie up the target, preventing other jobs from being dequeued while the lter is running. The chosen conguration allows other jobs to be sent to the target while the PostScript translation is being generated. Also, since GIF les tend to be large, theyre assigned a lower priority than the others.
Multiple queues feeding three targets

The following example is a further renement of the above setup, with some additional features required for a larger conguration. There are now three printers, all PostScript, located in different parts of the building (connected to //1/dev/ser1, //2/dev/ser1, and //3/dev/ser1). The conguration looks like this:
August 15, 2005
157
Example setup les
(txt)
text2ps
//1/dev/ser1 (lp1)
(ps)
//2/dev/ser1 (lp2)
(gif)
gif2ps
//3/dev/ser1(lp3)
Heres the le to set this up:

# ASCII to PostScript queue: [txt] ta=lp1,lp2,lp3 ci=text2ps pr#50 # direct PostScript queue: [ps] ta=lp1,lp2,lp3 pr#60 # GIF to PostScript queue: [gif] ta=lp1,lp2,lp3 ci=gif2ps pr#5 # target printers: [-lp1] dv=//1/dev/ser1 ok=echo file $(fname) sent to $(target) \ | mailx $(username) ab=echo file $(fname) did not get printed \ | mailx $(username) [-lp2] dv=//2/dev/ser1 ok=echo file $(fname) sent to $(target) \ | mailx $(username) ab=echo file $(fname) did not get printed \ | mailx $(username) [-lp3] dv=//3/dev/ser1 ok=echo file $(fname) sent to $(target) \ | mailx $(username) ab=echo file $(fname) did not get printed \ | mailx $(username)
158
August 15, 2005
Accessing spoolers and queues
The above conguration uses the same three queues described earlier (txt, ps, and gif) but they now feed three separate targets. The spooler selects the rst available target from the set of targets (lp1, lp2, lp3) and sends the data to its corresponding printer. Queue selection is based on priority rst, then on the age of the job. In this example, a mail message is sent to the submitter indicating whether or not the job completed normally.

Many spoolers may be present on a network; each of these can maintain multiple queues. To communicate with any given spooler, the lp utilities rst locate the spooler through the unique global name that the spooler registers (see the Global keywords section). When using any lp utility, you can:
omit both the spooler and the queue specify only the spooler specify only the queue specify both the spooler and the queue
If you dont specify the spooler on the command line, the utility checks the LPSRVR environment variable, which contains the name of the default spooler. However, if LPSRVR isnt dened, the utility will use the spooler that has registered the default global name /qnx/spooler. If the utility successfully locates a spooler, but you havent specied a queue on the command line, the utility will check the LPDEST environment variable, which contains the name of the default queue. However, if LPDEST isnt dened, the utility will use the rst queue entry in the setup le of the located spooler.
August 15, 2005
159
LPSRVR and LPDEST

The LPSRVR and LPDEST environment variables are used when the command-line information given to the lp utilities doesnt fully specify which spooler or queue to use.
LPSRVR
LPSRVR species the default spooler. The following setting of LPSRVR would indicate that the default spooler is the one with the name /qnx/spooler2:
export LPSRVR=/qnx/spooler2
The name specied in LPSRVR must always begin with a leading slash. LPSRVR must never contain the name of a queue.
LPDEST
LPDEST species the default queue. You can use LPDEST in two ways. You can specify a queue only:
export LPDEST=waybills
Or you can specify a spooler and a queue:

export LPDEST=/qnx/spooler2/waybills
Spooler Queue
If you specify a spooler in LPDEST, the LPSRVR variable is ignored, even if its dened.
For compatibility, the lp utilities look at the PRINTER environment variable if LPDEST isnt present.
Examples
Lets look at a few simple examples that show some of the ways you can specify spoolers and queues. For these examples, lets assume you have two spoolers on the network, each with two queues.
160
August 15, 2005
The rst spooler uses the default global name, /qnx/spooler; its queues are named txt and ps. The second spooler uses the name /qnx/spooler2; its queues are named checks and waybills. First spooler:
/qnx/spooler/txt /qnx/spooler/ps
Second spooler:
/qnx/spooler2/checks /qnx/spooler2/waybills
Naming neither a spooler nor a queue

Lets say you enter the following lp command, specifying neither a spooler nor a queue:
lp test.dat
The utility will rst try to locate a spooler by checking LPSRVR. If that variable isnt dened, the utility will locate the spooler with the default global name /qnx/spooler. The utility will then try to determine the queue by checking LPDEST. If that variable isnt dened, the utility will select the rst queue specied in the setup le of the located spooler.
Naming only the spooler

If you specify a string that begins with a leading slash, the string is always assumed to be a spooler name. Thus, if you enter the following command, the utility will treat /qnx/spooler2 as a spooler:
lp -P /qnx/spooler2 test.dat
Because the second spooler uses /qnx/spooler2 as its name, that spooler will be located. The utility will then try to use LPDEST as the default queue. If LPDEST isnt dened, the job is submitted to the queue checks, since thats the rst queue in the setup le of /qnx/spooler2.
August 15, 2005
161
Naming only the queue

If you specify a string that doesnt begin with a leading slash, the string is always assumed to be a queue name. Thus, if you enter the following command, the utility will treat txt as a queue:
lp -P txt test.dat
The utility will rst try to locate a spooler by checking LPSRVR. If that variable isnt dened, the utility will use the rst spooler, since that spooler has registered the default global name, /qnx/spooler.
Naming both the spooler and the queue

In the following example, both the spooler and the queue are named. Since the string begins with a leading slash, the utility will initially attempt to nd a spooler called /qnx/spooler2/waybills.
lp -P /qnx/spooler2/waybills test.dat
However, since the spooler /qnx/spooler2/waybills doesnt exist, the search will fail, at which point the utility will treat the specied string as a spooler name followed by a queue name. The spooler with the name /qnx/spooler2 will be located, and jobs will be submitted to the waybills queue on that spooler.
Initialization les
You might nd it useful to congure several default spoolers, if, for example, your marketing, sales, and R&D departments each has a spooler running:
LPSRVR=/qnx/spooler (marketing) LPSRVR=/qnx/spooler2 (sales) LPSRVR=/qnx/spooler3 (R&D)
You normally initialize environment variables beforehand in system initialization les. You may wish to use one of the following les to initialize the variables:
/etc/config/sysinit.node (run at boot time)
162
August 15, 2005
/etc/default/login (run at login time) /etc/profile (run by every login shell).
August 15, 2005
163
Chapter 10 Making Backups In this chapter. . .

Introduction 167 When to back up 167 Backup formats 167 Backup media 169 Compression 172 Archive examples 173
August 15, 2005
Chapter 10 Making Backups
165
Introduction
Introduction
This chapter deals with making a copy of your data to guard against hardware, software, or human error that may destroy the original. If your data is important to you, you should follow a backup routine that would allow you to restore lost data with minimal cost to you in time and money. Remember: hard disks do fail and people do make mistakes. Its too late to start a backup after your data is gone! You can back up an entire lesystem or only portions of it. Users may elect to back up their own les only, usually to oppies. To back up large portions of the lesystem with les owned by many users, youll need to have read permissions on these les. The superuser (root) has such privileges.
When to back up
You should back up often enough so that you can recover data thats still current or can be made current with minimal work. In a software development group, this may range from a day to a week. Each day of out-of-date backup will generally cost you a day of redevelopment. If youre saving nancial or point-of-sale data, then daily or even twice-daily backups are common. Its a good idea to maintain off-site storage.
Backup formats
QNX supports a variety of backup formats that can be classied into two groups:
archives regular lesystems

An archive consists of one or more les, merged into a single unit with its own directory of contents. This single unit can be saved either to a regular QNX le or to a raw block device like a oppy or tape.
August 15, 2005
167
Backup formats
Saving to a regular lesystem simply involves copying the les. In this case, the destination must be a device with a mounted QNX lesystem on it.
Archive backups
QNX supports three major archive utilities:
cpio tar pax

Both cpio and tar are implemented as links to pax, which is capable of reading and writing both cpio and tar formats. Both cpio and tar are common on UNIX systems. The pax utility is a cover utility for cpio and tar, so it doesnt support its own archive format. By default, pax will use the tar format when creating an archive. The pax utility will detect when youve reached the end of a disk or tape on a volume and will prompt you to insert the next volume to be used for the save. The result is a backup spanning several media (disks, tapes, etc.).
Naming volumes
Unfortunately, the tar/cpio format does not label the media with volume IDs. If you mixed up your media or inserted the wrong one out of order, you would end up restoring bad data. To safeguard against this possibility, QNX is shipped with the vol utility, which labels each disk volume with its sequence number and therefore prevents you from inserting out-of-sequence media.
The vol utility can be used with oppies or removable disks. This utility isnt for use with tape systems. The vol utility will, by default, step over block one of all media. This is important for oppy diskettes and cartridge disks that contain a QNX signature in block one. The signature contains the size of the
168
August 15, 2005
Backup media
diskette (360K, 1.2M, 1.4M, etc.) and allows for automatic remounting of removable media by the lesystem. We ship QNX distribution diskettes using pax to create an archive, freeze to compress the data, and vol to write to oppies.
If you wish to save data for restoration on a UNIX system, dont use freeze or vol: you wont nd those utilities to do the restore at that end. Instead, use pax to save and restore directly to the target media.
Filesystem backups
You back up to a lesystem by copying les, probably with the cp utility or with cpio -p. If your destination is a oppy, the cp utility will prompt you for more diskettes, but remember that no single le can be larger than the diskettes capacity. If you wish to back up to oppy, we recommended that you use one of the archive utilities.
Backup media
Your choice of backup media will be determined by available hardware and cost. Here are some common choices:
oppy tape removable disk xed disk

QNX provides drivers for several SCSI controllers. These drivers scan for hard disks, sequential-access tape units, WORM (write once/read multiple) devices, CD-ROM drives, and optical drives.
Floppy
Floppies are the most widely available device for personal backups. Their major shortcoming is their limited size. Since the QNX pax and vol utilities let you span media, your only concern will be having to
August 15, 2005
169
Backup media
feed several oppy diskettes into the drive. If you have to deal with more than four or ve oppies, this will make the procedure unpleasant enough that you may stop doing it regularly! You might want to consider compressing your data as described below. In order to back up/restore from a oppy diskette, you must make sure the oppy driver (Fsys.floppy) has been started (see Fsys.floppy in the Utilities Reference. The following command will start the oppy drive (assuming that Fsys is already running):
Fsys.floppy &
By default, Fsys.floppy creates a block special device for oppy drive 0 (/dev/fd0). If your machine has more than one oppy drive, Fsys.floppy creates a block special device for each. For example, drive 1 would map to /dev/fd1.
Archiving data to oppy

When you use an archive utility for your backups, it reads and writes directly to the rst block. Because tar writes archive data directly to the rst block, the rst block on the diskette will contain 512 bytes of raw data. This could pose a problem for Fsys.floppy, which attempts to read the rst block on all oppies for the QNX signature. To prevent unpredictable behavior when archiving data or restoring archived data from oppy diskette, run the lockfd utility before you start. The lockfd utility causes Fsys.floppy to lock the driver to a specic media size and suppresses the drivers attempt to read signature information from the rst block if the data has to be restored from oppy.
Copying les to oppy

You must format and initialize any unformatted diskettes before you can mount the oppy device and copy les to the oppy. The following example would initialize a high density 3 oppy diskette:
fdformat -s 1.4m /dev/fd0 dinit /dev/fd0
170
August 15, 2005
Backup media
To mount a lesystem on the block special device:

mount /dev/fd0 /fd0
You may now treat the oppy as a QNX lesystem mounted as /fd0. To copy les to the oppy, use the cp utility.
Tape
To back up/restore from tape, you must make sure the correct driver has been started. This will typically be one of the SCSI drivers described in the Utilities Reference. For example, if you have an Adaptec 1540-compatible SCSI controller with an attached tape drive, the following command will start the driver and register a sequential-access tape unit as /dev/tape1:
Fsys.aha4scsi fsys -n 1=tape
The archive utilities (e.g. tar, pax) will read and write directly to the tapes block special le. You cant mount a lesystem on this type of block special le.
Currently, the QNX 4 lesystem is limited to handling 512-byte records. To ensure proper streaming performance with tape devices, you may need to increase the blocking factor by using the -b blocking option to tar or pax. For example, the following command:
pax -w -b63b -t /dev/td0 .
performs a backup of the current directory to tape using the maximum blocking factor with pax. When the AHA 4 driver receives a request to read or write, it does so by starting at the current tape position. If youre starting a new backup, youll need to erase and rewind the tape.
August 15, 2005
171
Compression
A number of tape position and control functions are provided by the tape utility, which is described in the Utilities Reference. For example, the following command would rewind, erase, then rewind the tape in preparation for an archiving procedure:
tape rewind erase
Removable disk
Removable hard disks are popular in both magnetic and optical formats. Many units use a SCSI interface to the computer, so you may want to consider making your internal xed disk a SCSI drive (then you wont need a second controller and driver). Unlike oppies and tapes, a removable hard disk lets you avoid using the archive utilities like tar. Instead, youd likely use cp or pax -rwto copy your data to a real lesystem on the cartridge. This allows you to recover single les very easily and quickly.
Fixed disk
You can place a second hard disk in your machine for online backups. As an alternative, you could consider making backups to a hard disk on another machine in the network. However, backups across the network are slower than backups to a local hard disk. In this case, you might want to schedule all backups to be done as a cron job over night.
Compression
You can use a compression utility to reduce the amount of space required to store data. The amount of compression will depend on the nature of the data youre saving. Some databases containing large amounts of repetitive data may compress up to 90%. Other data might compress less than 10%.
172
August 15, 2005
Archive examples
CAUTION: Although compression saves media space, it has two undesirable side effects:
Compression requires a fair amount of computation and may slow down the process of saving the data. You might not be able to recover compressed data if a defect develops during the process. Potentially, all data following a bad block in one part of the compressed data could affect the rest of the data.
You may use the gzip or freeze utilities to compress your data and the gunzip or melt utilities to restore it. Both utilities will act on a stream of data as well as on les. This ability to act as a lter lets you connect them to one of the standard archivers via a pipe. For example, we distribute the QNX operating system in compressed form on oppies using pax, freeze, and vol.
Archive examples
Compressed oppy archive
Collect les under /home into a tar format archive, compress the archive, and then write it out to as many oppies as are needed, adding sequence numbers to the diskettes:
pax -w -x ustar /home | freeze | vol -w /dev/fd0
Read data off oppies, decompress it, and restore the les:
vol -r /dev/fd0 | melt | pax -r
August 15, 2005
173
Archive examples
UNIX-compatible oppy archive

Save les under /home/dino in a tar format archive for restoration on a UNIX system:
pax -w -t/dev/fd0 -xustar /home/dino
Save les under /home/dino in a cpio format archive for restoration on a UNIX system:
pax -w -xcpio -t/dev/fd0 /home/dino
Restore data in a tar or cpio format archive from another UNIX system and place all les under /usr/unix:
pax -r -s -t/dev/fd0 ",/,/usr/unix/,"
Tape archive
Start a new tape archive and save all les to tape:
tape rewind erase pax -w -t/dev/tp0 /
Append les that have changed since the date of the le lastsave to the end of an existing archive tape. After the save, update the time of lastsave:
tape forward touch newsave find / -newer lastsave | pax -w -t/dev/tp0 mv newsave lastsave
Restore all the les on a tape under the directory /home/dino:

tape rewind pax -r "/home/dino/*" -t/dev/tp0
174
August 15, 2005
Archive examples
Cartridge/optical
Copy all les from the lesystem on node 1 to the lesystem on node 2:
cp -Rp //1/ //2/
In the following example, the disk on node 2 is a very large optical. A full backup is done each Friday and a partial backup of modied les could be done each day of the week:
cp -Rp //1/ //2/fri cp -Rp -a date //1/ //2/mon cp -Rp -a date //1/ //2/tue . . .
You can also do this with cpio -p.
August 15, 2005
175
Chapter 11 Disk & File Recovery In this chapter. . .

Introduction 179 Making a recovery oppy 180 Overview of QNX disk structure 182 File maintenance utilities 190 Disk recovery procedures 192 What to do if your system will no longer boot Recovering lost les and directories 200
195
August 15, 2005
Chapter 11 Disk & File Recovery
177
Introduction
Introduction
The QNX lesystem achieves high throughput without sacricing reliability. Although the lesystem is designed to be as robust as possible, there will always be situations in the real world where disk corruption will occur. Hardware will fail eventually, power will be interrupted, and so on. The QNX lesystem has been designed to tolerate such catastrophes. It is based on the principal that the integrity of the lesystem as a whole should be consistent at all times. While most data is held in the buffer cache and written after only a short delay, critical lesystem data is written immediately. Updates to directories, inodes, extent blocks, and the bitmap are forced to disk to ensure that the lesystem structure on disk is never corrupt (i.e. the data on disk should never be internally inconsistent). If a crash occurs, you can use the following le maintenance and recovery utilities:
fdisk dinit chkfsys dcheck zap spatch

These utilities will let you determine whether any damage was done to les that were open for writing at the time of the crash. These same utilities can also x such damage, and in many cases will completely restore the lesystem. Sometimes the damage may be more severe. For example, its possible that a hard disk will develop a bad block in the middle of a le, or worse, in the middle of a directory or some other critical block.
August 15, 2005
179
Making a recovery oppy
Again, the utilities weve provided can help you determine the extent of such damage. You can often rebuild the lesystem in such a way as to avoid the damaged areas. In this case, some data will be lost, but with some effort, a large portion of the affected data may be recovered.

You should always have a recovery oppy on hand if, for whatever reason, a machine wont boot from hard disk.
This procedure applies only to QNX systems that were shipped on diskette. If your QNX system came on CD-ROM, refer to the technote in /etc/readme/technotes/qnx install, which documents a script for creating a boot oppy. Before you begin, make sure that youre logged in as root and that Fsys.floppy is running. Now follow these steps: 1 2 Insert a QNX boot disk in your oppy drive. Copy the image to a temporary le on your hard disk:
dd if=/dev/fd0 of=/tmp/floppy image
Insert a blank oppy in the drive. Format the oppy:

fdformat -k0 -z2 /dev/fd0
Copy the image (from your temp le) to the oppy:

dd if=/tmp/floppy image of=/dev/fd0
Run dcheck to check the new oppy:

dcheck /dev/fd0
If this fails, retry steps 3 and 4 (fdformat and dd); if it fails twice, try a new oppy.
180
August 15, 2005
Mount the oppy drive lesystem:

mount /dev/fd0 /fd
To make some room on the oppy, remove the following:
disktrap utility (14K):

rm /fd/bin/disktrap
All the disk drivers from /fd/bin that arent needed for this machine.
8 Now copy these useful utilities to /fd/bin:
cp cp cp cp cp cp cp /bin/sin /fd/bin/sin /bin/zap /fd/bin/zap /bin/rm /fd/bin/rm /bin/ls /fd/bin/ls /bin/spatch /fd/bin/spatch /bin/chkfsys /fd/bin/chkfsys /usr/bin/elvis /fd/bin/elvis
Create a /etc directory:

mkdir /fd/etc
10
Copy a termcap le:

cp /etc/termcap /fd/etc/termcap
You should also edit the termcap le and remove the entries you wont need. The only entry youll need is the one for QNX. 11 Now we need to create two links:
cd /fd/bin ln -s elvis vi ln -s fcat melt
12
Finally, youll need to modify the system initialization le (/fd/etc/config/sysinit) so that it now contains these lines:
August 15, 2005
181
Overview of QNX disk structure
Dev -n 10 & Dev.con -n 4 -O 256 & reopen /dev/con1 export PATH=/ram:.:/bin:/usr/bin export HOME=/ dinit /dev/ram mount /dev/ram /ram prefix -A /pipe=/ram prefix -A /tmp=/ram fcat /util.tar.F | pax -vr cp /bin/esh /ram/sh melt -z </etc/logo.F rtc hw echo Welcome to QNX 4.25 ontty /dev/con1 /bin/sh ontty /dev/con2 /bin/sh
Thats it! Keep your recovery oppy in a safe place. If and when you ever need to use it, simply insert the oppy in a dead machine and power on the machine will boot QNX from the oppy.

In this section, we describe how the QNX lesystem stores data on a disk. Reading this section should help you recognize and possibly correct lesystem damage if you ever have to rebuild a lesystem. If you have a C development package, the header le <sys/fsys.h> contains the denitions for all terms used in this section. For an overall description of the QNX lesystem, see the Filesystem Manager chapter in System Architecture.
Partition components
A QNX lesystem may be an entire disk (in the case of oppies) or it may be one of many partitions on a hard disk. Within a disk partition, a QNX lesystem contains the following components:
182
August 15, 2005
Loader Root
Bitmap
Root directory
Other data
The following blocks are always found, in this order, on a QNX disk partition:
loader root bitmap root directory other data
Loader block
The loader block is the rst block of a QNX partition. It contains the bootstrap loader that loads the QNX OS into memory.
Root block
The root block is the second block of a QNX partition. It contains the directory entry for the root (/), the inode entries for the inode le, and a label eld.
August 15, 2005
183
Bitmap blocks
Several consecutive blocks follow the root block. The bitmap blocks form the bitmap for the QNX partition. One bit exists for each block on the partition, thus one bitmap block will be used for every 4096 disk blocks (corresponding to 2M of disk space). If the value of a bit is zero, its corresponding block is unused. Unused bits at the end of the last bitmap block (for which there are no corresponding disk blocks) are turned on. Bit assignments start with the least-signicant bit of byte 0 of the rst bitmap block which corresponds to QNX block #1.
Root directory
The root directory follows the bitmap blocks. The root directory is a normal directory (see the Directories section). It is initially created by the dinit utility with enough room for 32 directory entries (4 blocks). As the following illustration shows, the root directory (/) contains directory entries for several special les that always exist in a QNX lesystem. The dinit utility creates these les when the lesystem is rst initialized.
/
. .. .bitmap
.inodes .boot .altboot
184
August 15, 2005
File:
/. /.. /.bitmap /.inodes
Description: A link to the / directory Also a link to the / directory Represents a read-only le consisting of the bitmap blocks. A normal le of at least one block on a oppy/RAM disk and 16 blocks on other disks, /.inodes is a collection of inode entries. The rst entry is reserved and used as a signature/info area. The rst bytes of the .inode le are IamTHE.inodeFILE. Represents an OS image le that will be loaded into memory during the standard boot process. This le will be of zero length if no boot le exists. Represents an OS image le that will be loaded into memory during the alternate boot process. This le will be of zero length if no alternate boot le exists.
/.boot
/.altboot
Directories
A directory is simply a le that has special meaning to the lesystem. A directory le contains a collection of directory entries as shown in the following illustration:
August 15, 2005
185
Offset
0
One physical block of a directory
di_fname [16]
d_size
16 20 28 32
di_first_xtnt di_xblk di_ftime di_mtime di_atime di_ctime

di_num_xtnts
0 1 2 3 4 5 6 7
36 40 44 48 50 52 54 56 58 62 63
di_mode
di_uid
di_gid di_nlink di_zero [4] di_type d_status
The type of directory entry is determined by the bits in the d status eld, as follows: Bit 3 ( FILE LINK) 0 0 1 Bit 0 ( FILE USED) 0 1 0 Comment: unused directory entry normal, used directory entry link to an entry in /.inodes (which should be used)
continued. . .
186
August 15, 2005
Bit 3 ( FILE LINK) 1
Bit 0 ( FILE USED) 1
Comment: invalid
The rst directory entry is always for the le . and includes a directory signature (IQNX). The hexadecimal equivalent of the character is 0x03. This entry refers to the directory itself by pointing to the entry within the parent directory that describes this directory. The second entry is always for the .. le. This entry refers to the parent directory by pointing to the rst block of the parent directory. Every directory entry either denes a le or points to an entry within the /.inodes le. Inode entries are used when the lename exceeds 16 characters or when two or more names are linked to a single le. The rst extent (if any) of a le is described in the directory/inode entry. Additional le extents require a linked list of extent blocks whose header is also in the directory/inode entry. Each extent block in the chain points to between 1 and 60 extents.
Links
Files with names greater than 16 characters and links to other les are implemented with a special form of directory entry. These entries are identied with the FILE LINK bit (0x08) of the d status eld being set. For these les, a portion of the directory entry is moved into the /.inodes le.
August 15, 2005
187
/.inodes entry
Directory entry
0
dl_fname [48] dl_inode_blk

dl_inode_ndx
0 16 20 28 32 36 40 44 48 50 52 54 56 58 62 63
i_reserved [16] i_size

i_first_xtnt
48
52
i_xblk i_ftime
i_mtime
53
63
dl_spare [10] d_status
i_atime i_ctime
i_num_xtnts
i_mode
i_uid
i_gid i_nlink i_zero [4] i_type i_status
Extent blocks
Extent blocks are used for any le that has more than a single extent. The directory entry di xblk points to one of these extent blocks, which in turn denes where the second and subsequent extents are to be found. An extent block is exactly one 512-byte disk block with the following form:
188
August 15, 2005
0
4 8 9 12
xblk_next_xblk xblk_prev_xblk xblk_num_xtnts xblk_spare [3] xblk_num_blocks
16
xblk_xtnts [0] xblk_xtnts [1]
24
488
xblk_xtnts [59]
496
504
xblk_signature
"lamXblk" (1st xblk only)
xblk_first_xtnt
Each extent block contains:
forward/backward pointers a count of extents a count of all the blocks in all the extents dened by this extent block pointers and block counts for each extent a signature (IamXblk)
The rst extent block also contains a redundant pointer to the rst le extent (also described within the directory/inode entry). This lets you recover all data in the le by locating this block alone.
Files
Files or le extents are groupings of blocks described by directory/inode entries; they have no structure imposed on them by the QNX lesystem. Most les in QNX have the following overall structure:
August 15, 2005
189
File maintenance utilities
Root
Signatures
I QNX In "dot" entry of each directory.
..
dir
IamXblk In header of each extent block.
dir
..
file
Extent blocks
0 0 #2 #3 #62 #63
#61 0
#n 0
Extent 1
Extent 2
Extent 3
Extent n

fdisk
The fdisk utility creates and maintains the partition block on a hard disk. This block is compatible with other operating systems and may be maintained by other OS versions of fdisk (although ours has the advantage of recognizing QNX-specic information). If the partition loader is missing or damaged, fdisk can create it.
We recommend you keep a hard copy of the partition table information for every disk in your network.
190
August 15, 2005
dinit
The dinit utility creates (but Fsys maintains) the following:
boot block root block bitmap blocks root directory /.inodes le
chkfsys
The chkfsys utility is your principal lesystem maintenance tool. This utility:
checks the directory structure of an entire disk partition, reports any inconsistencies, and xes them, if possible veries overall disk block allocation writes a new /.bitmap, upon your approval
The chkfsys utility assumes that the root block is valid. If the root block isnt valid, chkfsys will complain and give up youll need to try restoring the root block with the dinit utility.
dcheck
The dcheck utility veries that a disk has been correctly formatted by attempting to read every block on the drive. When the -m option is specied, dcheck removes any bad blocks from the disk allocation bitmap (/.bitmap). If the le /.bad blks is found, dcheck will update the bitmap and recreate the /.bad blks le. You can run dcheck a few times to increase your chances of bad blocks being recognized and added to the /.bad blks le.
August 15, 2005
191
Disk recovery procedures
zap
The zap utility lets root remove les or directories from the lesystem without returning the used blocks to the free list. You might do this for several reasons, including the following:
the directory entry is damaged two les occupy the same space on the disk (an error)
Recovering a zapped le
If you zapped a le in error, its sometimes possible to recover the zapped le using the zap utility with the -u option immediately after the deletion. You can recover a zapped le using zap under these conditions:
the directory entry for that (now deleted) le must not be reused the disk blocks previously used by the le must not be reassigned to another le
spatch
The spatch utility lets you browse the raw disk and patch minor problems. You can sometimes cure transient disk problems by reading and writing the failing block with spatch.

Using chkfsys
The chkfsys utility is your principal tool for checking and restoring a potentially damaged lesystem. It can identify and correct a host of minor problems as well as verify the integrity of the entire disk system as a whole. Normally, chkfsys requires that the lesystem be idle and that no les be currently open on that device. Youll have to shut down any processes that have opened les or that may need to open les while chkfsys is running.
192
August 15, 2005
To run chkfsys on a mount point, youd simply type:

chkfsys /
The utility scans the entire disk partition from the root down, building an internal copy of the bitmap and verifying the consistency of all les and directories it nds in the process. When it has nished processing all les, chkfsys compares the internal bitmap to the bitmap on the disk. If they match, chkfsys is nished. If any discrepancies are found, chkfsys will upon your approval rewrite the bitmap with data consistent with the les it was able to nd and verify. In addition to verifying block allocation (bitmap), chkfsys attempts to x any problems it nds during the scan. For example, chkfsys can:
unbusy les that were written during a crash x the le size in a directory entry to match the real data
When to run chkfsys

Its a good idea to run chkfsys as part of your regularly scheduled maintenance procedures this lets you verify that the data on your disk is intact. For example, you might consider running chkfsys on your network servers every time they boot. An automated check on the lesystem at boot time guarantees that chkfsys will attempt to x any problems it nds during the scan. To automate this process, add chkfsys to the servers sysinit.node le. Its especially important to run chkfsys after a system crash, power outage, or unexpected system reboot so that you can identify whether any les have been damaged. The chkfsys utility checks the clean ag on the disk to determine whether the system was in a consistent state at the time. The clean ag is stored on disk and is maintained by the system. The ag is turned off whenever a le is opened for update and is turned on after all open les have been closed and the associated data has been
August 15, 2005
193
ushed from cache to disk. When the clean ag is set, chkfsys assumes that the lesystem is intact. If chkfsys nds the clean ag off, it tries to x the problem. The chkfsys utility supports a -u option, which overrides a set clean ag and tells chkfsys to run unconditionally. You might want to override the clean ag when:
dcheck discovers bad blocks les have been deleted or zapped intentionally you want to force a general sanity check
Using chkfsys on a live system

The chkfsys utility normally requires exclusive use of the lesystem to provide a comprehensive verication of the disk.
CAUTION: There is some risk to running chkfsys on a live system both chkfsys and the lesystem are reading and possibly writing the same blocks on the disk. Also, the lesystem has internal cached data about les and directories that cant be updated when chkfsys makes a change. But static changes, in place, on les or directories that Fsys doesnt currently have opened will probably not cause problems. If youre running an application that cant afford downtime or you couldnt run chkfsys because les were open for updating, try to run chkfsys with the -f option:
chkfsys -f /dev/hd0t77
This invokes a special read-only mode of chkfsys. It will give you a feeling for the overall sanity of your lesystem.
194
August 15, 2005
What to do if your system will no longer boot
Recovering from a bad block in the middle of a le

Hard disks occasionally develop bad blocks as they age. In some cases, you might be able to recover most or even all the data in a le containing a bad block. Some bad blocks are the result of power failures or of weak media on the hard disk. In these cases, sometimes simply reading then rewriting a block will restore the block for a short period of time. This may allow you to copy the entire le somewhere else before the block goes bad again. This procedure certainly cant hurt, and is often worth a try. To examine the blocks within a le, you use the spatch utility. When you get to a bad block, spatch should report an error, but it may have actually read a portion of good bytes from that block. Writing that same block back will often succeed. At the same time, spatch will rewrite a correct CRC (Cyclic Redundancy Check) that will make the block good again (but with possibly incorrect data). You can then copy the entire le somewhere else, and then zap the previously damaged le. To complete the procedure, you mark the marginal block as bad (by adding it to the /.bad blks le), then run chkfsys to recover the remaining good blocks. If this procedure fails, you can use the spatch utility to copy as much of the le as possible to another le, and then zap the bad le and run chkfsys.

If a previously working QNX system suddenly stops working and will no longer boot, then one of the following may have occurred:
the hardware has failed or the data on the hard disk has been damaged
August 15, 2005
195
someone has either changed/overwritten the boot le or changed the system initialization le these are the two most common scenarios
The following steps can help you identify the problem. Where possible, corrective actions are suggested. Step 1 Try booting from oppy or across the network If you have a network to boot over, try booting your machine over the network. Once the machine is booted, youll need to log in as root and then start up a local lesystem:
Fsys &
If you dont have a network, youll need to boot from your recovery oppy (described earlier in this section) or from the QNX boot oppy that was used to install your system onto the hard disk. The lesystem will already be running in this case, and youll be logged in as root. Step 2 Start the hard disk driver You now have to start the appropriate hard disk driver. For example, to start a driver for an Adaptec series 4 SCSI adapter, you would type:
Fsys.aha4scsi &
If youre using another type of driver, enter its name instead. This should create a block special le called /dev/hd0 that represents the entire hard disk. Step 3 Run fdisk Running the fdisk utility will immediately give you useful information about the state of your hard disk. The fdisk utility might report one of several types of problems:
196
August 15, 2005
Problem: Error reading block 1
Probable cause: Either the disk controller or the hard disk itself has failed.
Remedy: If the disk is good, replacing the controller card might let you continue using the disk. Otherwise, youll have to replace the hard drive, reinstall QNX, and restore your les from backup. Rerunning the hardware setup procedure (or the programmable option select procedure on a PS/2) will normally clear this up. Of course, replacing the battery will make this a more permanent x. Use fdisk to recreate the correct partition information. Its a good idea to write down or print out a hard copy of the correct partition information in case you ever have to do this step.
Wrong disk parameters
Your hardware has probably lost its information about this hard drive likely because the battery for the CMOS memory is running low.
Bad partition information
If the disk size is reported correctly by fdisk, but the partition information is wrong, then the data in block 1 of the physical disk has somehow been damaged.
Step 4 Mount the partition and the lesystem At this point, you have veried that the hardware is working (at least for block 1) and that a valid partition is dened for QNX. You now need to create a block special le for the QNX partition itself and to mount the block special le as a QNX lesystem:
mount -p /dev/hd0 /dev/hd0t77 /hd
August 15, 2005
197
This should create a volume called /dev/hd0t77. Depending on the state of the QNX partition, the mount may or may not fail. If the partition information is correct, there shouldnt be any problem. Since the root (/) already exists (on a oppy or on a remote disk on the network), weve mounted the local hard disk partition as a lesystem with the name /hd. Your goal now would be to run the chkfsys utility on the disk to examine and possibly x the lesystem.
If you booted from oppy and you dont suspect theres any damage to the lesystem on your hard disk (e.g. the system was unable to boot because of a simple error introduced in the boot le or system initialization le), you can change the root prex to your hard disk partition at this point with the following command, which will resume normal operation of the system:
/hd/bin/prefix -R /=/hd/
If you run this command, you can skip the rest of this section.
If the mount fails. . .

If the mount fails, the rst portion of the QNX partition is probably damaged (since Fsys will refuse to mount what it considers to be a corrupted lesystem). In this case, you can use the dinit utility to overlay enough good information onto the disk to satisfy Fsys:
dinit -hr /dev/hd0t77
The -r option tells dinit to rewrite:
the root block the bitmap (with all blocks allocated) the constant portions of the root directory
198
August 15, 2005
You should now be able to reissue the mount command and once again try to create a mount point for a QNX lesystem called /hd. After doing this, youll need to rebuild the bitmap with chkfsys, even on a good partition. Step 5 Run chkfsys At least a portion of your QNX lesystem should now be accessible. You can use chkfsys to examine the lesystem and recover as much data as possible. If the hard disk is mounted as /hd (e.g. the machine boots from oppy), enter:
/hd/bin/chkfsys /hd
If the hard disk is mounted as / (e.g. a network boot), enter:

chkfsys /
In either case, you should make note of any problems reported and allow chkfsys to x as much as it can. What you do next depends on the result of running chkfsys.
If the disk is unrecoverable

If, for any reason, your disk is completely unrecoverable, read the next section, Recovering lost les and directories. In some cases, you may need to reinstall QNX from oppy and restore your disk from your backup les. If signicant portions of the lesystem are irreparably damaged, or important les are lost, then restoring from backup might be your best alternative.
If the lesystem is intact

If your lesystem is intact, yet the machine still refuses to boot from hard disk, then either of the following is probably damaged:
the partition loader program in physical block 1
August 15, 2005
199
Recovering lost les and directories
the QNX loader in the rst block of the QNX partition

To rewrite a partition loader, use fdisk:
fdisk /dev/hd0 loader
To rewrite the QNX loader, use dinit:

dinit -b /dev/hd0t77
You should now be able to boot your system.
Recovering lost les and directories

You may sometimes nd that les or directories have been completely lost due to disk corruption. If after running chkfsys you know that certain key les or directories were not recovered, then you might be able to use spatch to recover some or all of this data. Before attempting this, you should rst familiarize yourself with the details of a QNX lesystem (see Overview of QNX disk structure in this chapter). You should also study the documentation for the spatch utility in the Utilities Reference.
200
August 15, 2005
Appendix A QNX Console & Keyboard Conventions In this appendix. . .

Entering line-oriented input 203 Recalling commands 205 Switching virtual consoles 205 Using multiple consoles 206 Changing the console fonts 207 Suspending and resuming output 208 Killing a process 208 Invoking the system debugger 208 Rebooting 209 International keyboards 209 The keyboard at a glance 209
August 15, 2005
Appendix: A QNX Console & Keyboard Conventions
201
Entering line-oriented input
This appendix describes QNXs standard console and keyboard conventions in text mode. For information on the Photon graphical environment, see the Photon Users Guide. Note that some keys may behave differently from how theyre described here, depending on how your system has been congured. For details on the utilities that control QNX consoles, see the following in your Utilities Reference:
Dev Dev.ansi Dev.con sh stty

Line-editing keys
Many applications run in edited mode. If an application runs in this mode, you can use the following keys for entering line-oriented input: If you want to: Move the cursor left one position Move the cursor right one position Move the cursor to the beginning of the line Move the cursor to the end of the line Press this key: (left arrow key) (right arrow key)
Home End
continued. . .
August 15, 2005
203
If you want to: Delete the character to the left of the current cursor position
Press this key:

Backspace or Rubout or
(keypad arrow). Note that pressing this key generates a 7F hex (ASCII Rubout), not a 08 hex.
Del Ctrl U Ins
Delete the character at the current cursor position Delete all characters on the current line Toggle between insert mode and typeover mode (default is insert)
Note that if youre in typeover mode and you submit a line, youll be returned to insert mode.
Enter
Submit a line of input
The QNX shell has additional input editing commands. For more information, see sh in the QNX Utilities Reference. Note also that your keyboard may not behave as indicated if:
youre working with an application that has complex requirements for user interaction the application may take control over how the keyboard works youre working at an attached terminal the terminal may have keyboard limitations.
Max length of an input line

The maximum length of an input line is 256 characters. Application programs can impose lower limits.
204
August 15, 2005
Switching virtual consoles
Entering long input lines

If you enter a single line of input thats too long for your screen to display as a single line, the line may be displayed as several screen lines. But the line still behaves as a single input line when you use the standard line-editing keys. For more information on edited mode, see System Architecture, Chapter 6, The Device Manager.
Recalling commands
The shell lets you recall commands that youve previously entered, then re-execute them. These commands are maintained by the shell in a buffer. If you want to move: Backward through the buffer Forward through the buffer Press this key: (up arrow key) (down arrow key)
Switching virtual consoles

The display adapter, the screen, and the system keyboard are collectively referred to as the console. To let you interact with several applications all at once, QNX permits multiple sessions to be run concurrently on consoles by means of virtual consoles. These virtual consoles are usually named /dev/con1, /dev/con2, etc. Each virtual console can be running a different foreground application that uses the entire screen. The keyboard is attached to the virtual console thats currently visible. You can switch from one virtual console to another and thus from one application to another by entering the following keychords.
August 15, 2005
205
Using multiple consoles
If you want to see the: Next active console Previous active console
Press:
Ctrl Alt Enter or Ctrl Alt +
(keypad plus key)

Ctrl Alt - (keypad minus key)
You can also jump to a specic console using the Ctrl Alt n keychord, where n is the numeric digit that represents the console number of a virtual console. If you want to see:
/dev/con1 /dev/con2 (if available)
Press:
Ctrl Alt 1 Ctrl Alt 2
. . .
/dev/con10 (if available)
. . .
Ctrl Alt 0
You can disable keyboard console switching with the stty +noswitch command. For more information on the QNX console, see System Architecture, Chapter 6, The Device Manager.
Using multiple consoles

The system administrator can specify how many virtual consoles are supported on your machine by specifying an argument to the console driver process (Dev.con) when its started. The administrator can also specify the program if any thats initially launched on each console. By default, the terminal initialization utility (tinit) launches a login on the rst console only, but will be armed to launch a login on any other console on which you press a key. This means that while console 1 is always
206
August 15, 2005
Changing the console fonts
available, any other given console wont be used unless you specically switch to that console and press a key. To start a login on an unused console: 1 2 Switch to the unused console via Ctrl Alt n Press any key. A login will be launched.
You can now access the console via any of the cyclical console-switching keychords (e.g. Ctrl Alt +) described in the previous section. When you terminate the session by typing logout or exit, or by pressing Ctrl D, the console will once again be idle. It wont appear when you use any of the cyclical console-switching keychords. The exception is console 1, on which the system usually restarts a login.
Changing the console fonts

Depending on your video hardware, the console driver (Dev.con) may support a variety of screen fonts. The available fonts are numbered from 0 to n. When QNX boots, it denes font 0 as a 2580 text font. If youre using an EGA or VGA video adapter, QNX also denes font 1 as a 4380 text font (EGA) or a 5080 text font (VGA). To inform Dev.con about new fonts or to redene existing fonts, you use the cfont utility. You can use this utility to provide fonts of different sizes or fonts that contain alternate character sets. To change the font associated with the current console, use the following keychords: If you want to choose the: Next font (up to n) Previous font (down to 0) Press:
Ctrl Alt > Ctrl Alt <
August 15, 2005
207
Killing a process
QNX keeps track of the font being used by each console. All consoles initially display font 0. You can disable keyboard font changing with the stty +noresize command.
Suspending and resuming output

If you want to: Suspend the display of output Resume the display of output Press:
Ctrl S Ctrl Q
Killing a process
If you need to kill the process currently running on the console, press Ctrl C or Ctrl Break. The system will attempt to kill the process.
Invoking the system debugger

QNX comes with a low-level system debugger that lets you set breakpoints in programs, display and edit memory, disassemble code, and examine I/O ports. If it has been built into your OS image, you can invoke this debugger with the following keychord:
Ctrl Alt Esc
You can disable this keychord with the stty +nodebug command.
CAUTION: Dont use this debugger in a multiuser environment, because it disables interrupts and freezes the entire system its intended only for low-level debugging. For more information on this debugger, see Debugger in the QNX Utilities Reference. For information on general debugging, see the Watcom Debugger Users Guide.
208
August 15, 2005
Rebooting
Rebooting
To reboot your computer, use this keychord:
Ctrl Alt Shift Del
You can disable this keychord with the stty +noboot command.
CAUTION: Before entering this command, make sure that no applications or utilities are running on your computer. If there are, les may be left open. Moreover, if you reboot when a critical update is in progress, its possible that the lesystem would require maintenance (see the section on Filesystem robustness in System Architecture; see also the chapter on Disk & File Recovery in this guide).
International keyboards
Some keyboard layouts the French and German layouts, for example use accent keys which, by themselves, dont generate a character. QNX treats these keys as dead keys. Pressing a dead key, followed by a second key, modies the second key, creating an U accented character. For example, to create the character, you press followed by Shift U. This dead key processing provides typists with a familiar method of composing characters. Note that you can also generate composed characters by: 1 2 pressing and releasing Alt typing two characters.
The keyboard at a glance
August 15, 2005
209
If you want to: Move the cursor to the left Move the cursor to the right Move the cursor to the start of a line Move the cursor to the end of a line Delete the character left of the cursor Delete the character at the cursor Delete all characters on a line Toggle between insert/typeover modes Submit a line Recall a command Switch to the next virtual console Switch to the previous virtual console Switch to a specic console Choose the next font Choose the previous font Suspend display of output Resume display of output Attempt to kill a process
Press:
Home End Backspace or (keypad arrow
key)
Del Ctrl U Ins Enter
or
Ctrl Alt Enter or Ctrl Alt + Ctrl Alt Ctrl Alt n Ctrl Alt > Ctrl Alt < Ctrl S Ctrl Q Ctrl C or Ctrl Break
continued. . .
210
August 15, 2005
If you want to: Indicate end of input (EOF) Invoke the system debugger Reboot your computer
Press:
Ctrl D Ctrl Alt Esc Ctrl Alt Shift Del
August 15, 2005
211
Appendix B Where QNX Files Are Found In this appendix. . .

A typical directory structure 215 Summary of le locations 215
August 15, 2005
Appendix: B Where QNX Files Are Found
213
A typical directory structure
A typical directory structure

QNX modules are stored according to the kind of services they provide. The following diagram gives an overview of the general directory structure in a typical QNX installation:
/
bin
boot
etc
tmp
usr
home
config
build
images
sys
bin
include
lib
spool
Summary of le locations
To nd: system executables OS image Makefile build les to make images (the make utility reads these) OS image les system processes needed at boot time initialization and other les
sysinit and conguration les
Look in:
/bin /boot /boot/build /boot/images /boot/sys /etc /etc/config
continued. . .
August 15, 2005
215
Summary of le locations
To nd: software release information les technical notes default location for temporary les more executables header (*.h) les for the C compiler libraries for the C compiler terminal capabilities les work les for system spoolers and queues a users home directory
Look in:
/etc/readme /etc/readme/technotes /tmp /usr/bin /usr/include /usr/lib /usr/lib/terminfo /usr/spool /home/username
216
August 15, 2005
Index
!
. (dot) shell command 10 . le 187 .. le 187 .bitmap le, rewritten by chkfsys 191 .lastlogin le 129 .profile le 110
$(bnode) marker
27 starting node with sinit 133 $(lnode) marker 27 $(netmap) marker 27 $(TZ) marker 27 $HOME directory, selecting when account created 114 FILE LINK bit 187
setting TERM environment variable 133 / root directory 33 /.altboot le 9, 26, 184. See also booting loading alternate boot image 26 relationship to altsysinit le 26 /.bad blks le 191 /.bitmap le 184 /.boot le 9, 26, 184 copying to /.altboot 9 /.inodes le 184 /.licenses le 71 /bin/sh shell See shell /boot/build directory 97
A
access control directory permissions 36 le permissions 116 group privileges 113 login utility 111 newgrp utility 113, 116 passwd utility 111 running utilities with superuser permissions 121 su utility 111 system security 109 user access, limiting 121 user privileges 112
August 15, 2005
Index
217
Index
125 accounting le 125 clearing 127 compressing 128 creating 125 discarding information 125 record format 126 spooling commands 148, 155 superuser access 125 typical example 126 utilities writing to 126 accounts access privileges and le permissions 112 creating new 111, 112 default values 114 deleting 114 home directory 114 password 114 shell to start up 114 adapters connecting to ISA bus 53 multiport serial cards 54 single-port serial cards 54 addresses for serial COM ports 54 UART I/O address range 53 aliases, terminal 134 alternate boot 7. See also .altboot le selecting 7, 9 altsysinit le 7, 9, 91. See also system initialization le relationship to /.altboot le 26 ANSI terminal 10, . See also consoles 135
acclog le
applications, launching at start up 63 archives 168 appending les to tape 174 backing up/restoring from tape 171 compressing data 172, 173 cpio utility 168 examples 173 pax utility 168 tar utility 168 vol utility 169 Arcnet network adding Ethernet nodes 94 example 102 physical node ID of card 85 ASCII text les, printing 156
B
backups archives 168 as cron job 172 compressing data 172 copying /.boot to /.altboot 26 copying les to optical cartridge 175 lesystem 169 nding les according to date 174 xed disks 172 oppies 169 formats 167 media types 169
218
Index
August 15, 2005
Index
partial backup of modied les 175 removable disks 172 spanning several media 168 to SCSI device 171 when to do 167 bad blocks /.bad blks le 191 determining severity 179 removing 191 base-level services (sysinit le) 10 baud rate locking rate 64 specifying 11, 59 bitmap blocks 184 creating 191 bits FILE LINK 187 data 58 DOS lesystem attribute 46 le access mode 116 modem parity 59 modem stop 59 block special device, oppy 170 block special le creating 33 on oppy 13 blocks bad block in middle of le 195 bad block on backup media 173 bitmap blocks 184 boot block 191 DOS boot parameter block (BPB) 40 examining within a le 195
extent blocks 188 linked list of 187 les and le extents 189 key components on disk 182 loader block 183, 190 partition block 190 recovering blocks 191, 192 root block 183 verifying allocation (chkfsys) 191 boot image See images boot parameter block (DOS) 40 boot process 7 automatic insertion in image 24 boot ROM Ethernet & Token Ring cards 95 installing into network card 97 viewing physical node ID 97 boot server associating nodes with multiple servers 100 build les selecting 95 storing 97 conguring 86 dened 80 installing licenses 73, 87 installing network card 87 mapping logical & physical node IDs 91 modifying netboot le 95 modifying sysinit.node le 91 multiple 81, 100 nameloc, starting 89
August 15, 2005
Index
219
Index
netboot
as primary 96 starting 90 network services, starting 87 responding to boot requests 100 selecting 80, 81 booting See also images; network /.altboot le 26, 184 /.boot le 26, 184 alternate boot 7, 9 boot method 7 boot process in image 7 broadcast booting 100 netboot utility 95 QNX boot ROM 97 creating backup boot image 9 disk boot 7 diskless node 26 embedded image 24, 29 escape to alternate boot image 26 establishing time from network boot 18 Ethernet cards 95 ash memory 28 oppy 4 from hard disk 24, 25 getting time during hard disk boot 17 hard disk boot 10, 74 initial boot 7 Makefile for network booting 26 netboot le 9395 network boot 24, 26, 93, 95 network card used 97
newly built image 26 node 26, 93, 98 from its own hard disk 74, 99 image loaded when booting from network 81 nodes 8 normal boot from disk 7 from network 7 reducing bottleneck 81, 82 running chkfsys on servers 193 setting terminal type 133 specic boot method 81 Token Ring cards 95 troubleshooting 26, 195 BOOTP Internet boot protocol 98 bridging nodes on a network 81 broadcast booting 100 role of netboot utility 95 with QNX ROM 97 buffer, output for parallel port 52 build le See also images /boot/build directory 97 accessing via netboot 94 build directory 21 building OS images on the y 98 constructing 21 customizing network services 95, 97 embedded system 28 format 22 heap size, setting 23 including processes 21
220
Index
August 15, 2005
Index
markers and make options 26 process priority, setting initial 23 sample 21 buildqnx utility 21, 97 invoking via netboot 28 bus hardware interrupt signals 53 ISA bus and adapter cards 53
C
C programs, accessing DOS disks and les 38 capabilities (terminfo) converting terminfo and termcap 135 curses library 136 mouse events 136 string syntax 135 terminal 133 carriage return sequence (DOS) 42 case sensitivity, DOS-QNX 44 cat utility 52, 152 transferring new-style license 72 CD-ROM distribution installation procedure 3 certicate, new-style licenses 73 characters mapping DOS to QNX 44 mapping QNX to DOS 43 QNX-DOS case sensitivity 44 unrecognizable 65
valid & invalid DOS lenames 43 chgrp utility 120 CHKDSK utility (DOS) 47 chkfsys utility 191 overriding clean ag 193 read-only mode 194 recovering damaged lesystem 192 using on live system 194 when to run 193 chmod utility 120 chown utility 46, 120 clean ag (chkfsys) 193 clock See also time zones cron server 14 getting time from realtime 10, 17 COM ports 11 I/O addresses and hardware interrupts 54 command interpreter See shell commands . (dot) shell command 10 echo shell command 110 initial command at login 114 set shell command 110 shell scripts 10 stty shell command 11 communications across networks 81, 82 serial port 54, 58 compiling (terminfo) 136 compression archiving compressed data 173 freeze utility 173 gunzip utility 173
August 15, 2005
Index
221
Index
173 173 undesirable side effects 173 conguration le See system initialization le connecting serial devices 60 console drivers Dev.ansi 10 Dev.con 67 starting 10, 51 consoles See also keyboards; mouse driver; terminals qnx terminal type 135 starting 10 starting login 12 troubleshooting 24 controllers, serial hardware 53 Coordinated Universal Time (UTC) See time zones cp utility 40, 169 making backups 169 writing directly to queue le 143 cpio utility 168 cron server dealing with log les 127 making backups overnight 172 selecting machine as 14 curses terminal capabilities library 136 customizing services See images cyclic redundancy check 195
gzip utility melt utility
D
daemon, starting terminal 12 data bits 58 compressing 172 ensuring integrity of 179, 192 troubleshooting corrupted 200 troubleshooting serial transmission 65 date date utility 17 establishing 17 daylight saving time See also time zones changing to or from 17 dcheck utility 191 dequeuing print jobs 144 device drivers See also drivers Dev.ansi 10 Dev.con 51, 67 Dev.par 11, 51 Dev.pty 51 Dev.ser 11, 51, 53 starting 10, 51 Device Manager (Dev) 51 starting 10, 51 devices See also parallel devices; serial devices /dev/par (LPT1) 52 conguring parallel port 51 conguring serial port 53 connecting target output to printer 144 DOS 40 maintaining exclusive access 64
222
Index
August 15, 2005
Index
managed by Dev process 51 mounting 34 reinitializing printer between spool jobs 145 shared resources 141 starting LPT2 parallel port 52 tracking usage 127 troubleshooting 24 unmounting 34 dinit utility 170, 184, 191 directories See also les; root directory /boot/build 97 /etc/licenses 71 accessing on another node 36 checking structure 191 contents of root directory 184 creating, deleting, & reading DOS 38 dened 185 entries 185 st mode eld 117 type 186 for temporary spooler les 151 permissions 117, 119 QNX signature 187 recovering lost 200 removing without returning used blocks 192 root directory 33 selecting $HOME directory when account created 114 showing all les 34, 35 structure 185, 215 terminfo 135 disks See also partitions; oppies as backup media 169
backing up to or restoring from 169, 172 block allocation veried by chkfsys 191 browsing 192 determining if damaged 179 formatting 35 partitions 182 patching minor problems 192 recovery procedures 192 regular maintenance procedure 193 restoring bad blocks in middle of le 195 scanning and adopting DOS drives 39 sharing across network 36 space, allocating 35 structure 182 troubleshooting corrupted 200 ditto utility 105 DOS See also Dosfsys boot parameter block (BPB) 40 carriage return sequence 42 devices 40 directories 38 disks accessing via QNX 38 formats 41 drives accessing via QNX 40 currently adopted 39 default 39 root name 39 scanning and adopting 39 le allocation table (FAT) 40
August 15, 2005
Index
223
Index
lenames invalid characters 43 QNX/DOS character and name mapping 44 les accessing via QNX 38 binary 43 converting to QNX format 43 copying 40 ownership 46 text format 42 viewing open 39 lesystems attribute bits 46 oppies and partitions 14 limitations 40 permissions 46 recovering corrupted 47 setting up 38 volume labels 45 partitions formats 41 primary 39 types 41 versions 41 Dosfsys lesystem manager 14, 38 error return codes 47 invocation modes 39 name adoption 40 scanning and adopting drives 39 starting 39 in sysinit 14 terminating 39, 47 dot (directory link) 187
dot dot (directory link) 187 drivers See also device drivers console 51 Fsys.floppy 170 locking oppy driver to specic media size 170 mandatory for hard disk boot 25 mandatory for network boot 26 multiple network 88 network (nettrap) 89 parallel 51 pseudo tty 51 removing and reinstalling 38 serial 51 starting 51 testing parallel 52 serial 65 drives See disks DSR lines 58 DTR lines 58
E
Eastern Standard Time See also time zones changing to or from 16 effective group ID 115 effective user ID 115 embedded system computerized controllers 28 conguring serial driver 53 dened 28 hardware adapters 53
224
Index
August 15, 2005
Index
images 28 serial I/O addresses 53 starting serial driver 51 emu87 utility 11 emulator, starting oating-point 11 encrypted passwords 124 enqueuing print jobs 144 ENV environment variable 109 environment variables displaying exported values 109 ENV 109 exporting 110 initializing in shell 162 LPDEST 159, 160 LPSRVR 159, 160 PRINTER 160 setting 13, 110, 162 TERM 13, 110, 133 TMPDIR 110 TZ 10, 110 Esc key, causing alternate boot 7 Ethernet adding nodes to an Arcnet network 94 Arcnet/Ethernet example 102 broadcast booting 95 fault-tolerant network 104 physical node ID of card 84 events mouse 136 network diagnostic tools 105 system accounting information 125 tracking device usage 127 executables nding 215 owner & group privileges 120
execute permission 117 export shell command setting environment variables 13 time zone environment variable 16 extents locating extent blocks 187, 188 structure 189
F
FAT table (DOS) 40 fault-tolerance example of 104 network 81, 82 fdformat utility 170 fdisk utility 35, 190 reporting errors 196 FIFO permissions 119 le maintenance utilities 179 chkfsys 191, 192 dcheck 191 dinit 191 fdisk 190 spatch 192 zap 192 le mode creation mask, setting/changing 119 lenames DOS lename sufxes 44 longer than 16 characters 187 longer than 8 characters 44 mapping DOS to QNX 44 mapping QNX to DOS 43
August 15, 2005
Index
225
Index
maximum number of DOS characters 44 relationship to inode entries 187 translating QNX lenames via Dosfsys 44 valid & invalid DOS 43 les See also DOS; directories; extents; lenames . 187 .. 187 .lastlogin 129 .profile 110, 133 /.altboot 9, 26 /.bad blks 191 /.bitmap 184 /.boot 9, 26, 184 /.inodes 184 /.licenses 71, 72 /etc/profile 109 access mode bits 116 accessing by node and pathname 36 on oppy 13 problem with 120 remote lesystems 36 acclog 125 accounting le 125 altsysinit 7, 9 and /.altboot 26 for boot server 91 appending to archive tape 174 block special le 33 blocks, examining & restoring 195 build le 21 checking integrity 179, 193
compressing 172 copying to different time zone 16 to diskette 170 to optical cartridge 175 deleting without returning used blocks 192 DOS les 40, 43 converting to QNX 43 problem with creating 40 text format 42 executables, owner & group privileges of 120 extent blocks 188 extents 187 nding 215 according to date 174 fsys.h header le 182 group 113, 121 hard.1 build le 21 image le 21 installing compressed 6 lastlog 129 links 187 lpsrvr.node 142 mode creation mask 119 motd 129 mounting QNX lesystem from oppy drive 13 netboot 28, 90, 93 netmap 85, 91 nologin 129 owner and group 116 ownership (DOS) 46 passwd 112, 121 password les 125 permissions 116, 117, 119
226
Index
August 15, 2005
Index
adjusting (umask) 119 printing 142 recovering lost 200 recovering zapped 192 remapping bad disk blocks 191 setgid and setuid 120 shadow 121 showing all les on oppy diskette 34 hard disk partition 35 hard drive 35 structure 189 sysinit 7, 9 sysinit.node 7, 9 for boot server 91 syslog 128 termcap 133 terminfo 133 text le format (QNX) 42 utmp 129 writing to standard output 52 wtmp 129 lesystems See also DOS; partitions; pathname space; recovering access to DOS les 38 backups 169 congurations 36 copying image of DOS diskette or partition 40 dened 33 Dosfsys 38 increasing size of DOS 47 mandatory for hard disk boot 25 mounting 13, 33 QNX-DOS portability 43
restoring 192 running DOS 14 setting root to local lesystem 36 remote lesystem 36 starting 13 Fsys after booting 37 storing data on disk 182 structure 182, 215 system redundancy 37 lters queues and targets 145 spoolers and queues 145 xed disks See disks ash memory as lesystem 28 in embedded system 28 oating point emulator, starting (emu87) 11 oppies accessing QNX les on 13 as backup media 169 backing up to or restoring from 169 copying image of DOS diskette 40 device driver for Fsys.floppy 13 locking to specic media size 170 starting 13, 170 formatting and initializing 170 installation procedure 3 labeling 168 mounting 34 a DOS oppy drive 39 a formatted diskette 171
August 15, 2005
Index
227
Index
showing all les on 34 unmounting before removing 34 ow control (software), enabling & locking 62 freeze utility 169 Fsys 13 fsys.h header le 182 full-screen programs (terminfo database) 135
compressing accounting le 128
H
hardware conguring serial adapters 53 interrupts generated by serial device 53, 54 multiport serial adapters 54 header les, locating 215 heap size, setting in build le 23 home directory, selecting 114
G
global name server, selecting machine as 12 Greenwich Mean Time See time zones group changing 119 ID real 114 IDs 113, 114 changing 115, 116 effective 115 removing user account 114 support under DOS 46 switching to 113 mode bit accessing les via 116 privileges 113 group le 113, 121 assigning group privileges 113 general syntax of entries 113 gunzip utility 173 gzip utility 173
I
I/O addresses conguring serial interface 53 hardware adapters 54 multiport serial adapters 54 images See also system initialization le /boot/images directory 21 buildqnx utility 21 classication 24 constructing build le 21 copying to /.boot le 26 disk images 25 embedded system 24, 28, 29 how netboot selects build le 94 loading on the y 28 pre-built 28
228
Index
August 15, 2005
Index
21 for network booting 26 making hard disk boot image 25 network boot image 26 maximum size of image le 24 network images 26 selecting processes 24 setting initial process priority 23 transmitting to booting node 95 infocmp utility 135 initializing See also system initialization le; sinit utility oppy diskettes 170 root directory and directory entries 184 terminal 12 inodes /.inodes le 187 inode entries 187 install utility 4, 6 installing See also network additional QSSL software 6 before you begin 3 hardware prerequisites 3 new-style license from certicate 72 new-style license from disk 72 old-style license 71 QNX OS software 3 third-party software 6 integrity, ensuring on entire disk system 192 international keyboards 15
Makefile
interrupts generated by serial device 54 generated by UARTs 53 on serial bus 53 sharing serial interrupts 54
K
kbd utility 15 kedit utility 15
keyboards creating custom layout 15 international 15 troubleshooting 24
L
lastlog le 129 less utility 38
libraries including in build le 22 locating 215 license utility 71, 73 installing new-style license 72 transferring old-style license 71 licenses directory 71 licensing 71, 87 activating new licenses 74 booting node from its own hard disk 100 expanding your license 73 in-memory license database 74 license certicates 72
August 15, 2005
Index
229
Index
max. number of QNX nodes 71, 72, 79 nameloc utility 71, 89 old- and new-style dened 71 viewing information 72, 73 transferring old-style 71 licinfo utility 73, 87 line conguration, changing default 11 line separator characters 42 Linefeed character (QNX) 42 links 187 FILE LINK bit 187 creating to / directory 184 dot (directory link) 187 dot dot (directory link) 187 linking through prefix utility 37 symbolic links 37 ln utility 37 loader block 183 creating 190 lockfd utility 170 log les .lastlogin 129 lastlog 129 motd 129 nologin 129 syslog 128 tracking device usage 127 utmp 129 wtmp 129 logging in as another user 111 controlling access 109
default environment variables 110 selecting initial command executed 114 via termdef 134 logical network IDs assigning 79 multiple network links 88 must be unique 80, 93 logical node IDs accessed by netboot utility 94 assigning 79, 85, 91 effect of changing 9 value passed to Proc32 99 login utility 63, 111 automating login 63 starting in sysinit le 12 on all consoles 12, 63 via tinit 111 lp utility 142 reporting print spooling errors 156 lpc utility 144 LPDEST environment variable 159, 160 lpq utility 143 lprm utility 143 LPSRVR environment variable 159, 160 lpsrvr utility 142 lpsrvr.node le 142 general syntax of entries 147 LPT port naming and starting 52 setting up as target 159
230
Index
August 15, 2005
Index
starting 52 ls utility 34, 38, 118 le permissions, viewing 118 viewing old-style license information 72
M
make utility 21 Makefile See also images $(bnode) 27 $(lnode) 27 $(netmap) 27 $(TZ) 27
creating images 21 network booting 26 mappings See also network I/O managers, disks, and devices 33 logical and physical node IDs 11 multiple networks 93 pathname prexes 36 pathnames to I/O managers 33 QNX to DOS 43 memory output buffer for parallel port 52 UART I/O address range 53 Microkernel including in build le 22 mandatory process 24 mkdir utility 38 mode bits 116 assigning 119
classication for les 116 comparison by Filesystem Manager 116 le permissions, viewing 118 role of umask 119 modem utility 64 modems automating call answer 64 conguring serial driver 53 connecting/disconnecting 58, 60 detecting incoming call 58 ow control to terminal 58 high-speed, error-correcting 60 outgoing/incoming calls on same serial line 64 querying for terminal type 133 serial driver starting 51 testing 65 using locked baud rate 64 modules 215 motd le 129 mount utility 13, 33 mounting creating block special les 33 devices 34 DOS oppy drives 39 examples 33 lesystems 13, 33 oppy device 170 formatted oppy diskette 171 mount point 33 partitions 33, 35 DOS 39 subdirectories 33 using prefix utility 36
August 15, 2005
Index
231
Index
mouse events 136 mousetrap utility 14 multiple network links See also network Arcnet/Ethernet example 102 benets 82 card used for network booting 97 communicating across networks 82 Ethernet nodes, adding to Arcnet network 94 fault-tolerance 104 netboot le 93 netmap le 91, 102, 104 private network link 105 multiport serial adapters 54
N
name server selecting machine as 12 starting 11 nameloc utility 11, 89 required for licensing 71 namespace, partitioning 33 Net 11 starting 87 in a nodes build le 98 in boot servers sysinit.node le 98 using nettrap 89 netboot le 28, 90, 93
accessed by netboot utility 94 build les specied in 98 example 104 f=buildle entry 98 F=imagele entry 98 syntax of entries 95 netboot utility 21, 28, 90, 93. See also network acting as server 95 invoking buildqnx 28 running on multiple servers 100 netinfo utility 105 netmap le 85, 91 accessed by netboot utility 94 corresponding update to bridge table 93 editing and updating 92 example 104 netmap utility 11, 91 nettrap utility 89 network See also nodes Arcnet/Ethernet example 102 boot servers multiple 100 selecting 80, 81 booting 8, 24, 26, 93 Ethernet 95 Token Ring 95 bridging 81 in-memory bridge table 93 broadcast booting 95 build les markers for make options 26 selecting 94
232
Index
August 15, 2005
Index
cards Arcnet 85 booting when two installed 97 drivers 84, 87 Ethernet 84 installing multiple 81 scanning for (nettrap) 89 Token Ring 84 communicating across networks 82 conguring boot server 86 lesystem 35 large 81, 82 nodes 96 display errors on console 98 fault-tolerance 81, 82, 104 hardware 84 images 26 installing boot ROM on network card 97 network card 87 licensing 71, 79, 87, 89, 100 logical network IDs 79, 88 logical node IDs 79, 91 mapping automatically (netboot) 90 loading 11 logical and physical node IDs 85, 91, 102, 104 logical node and network IDs 85 multiple logical network IDs 93
nodes to multiple boot servers 100 nameloc utility 89 netboot le 9395 netboot utility 21, 28, 90 running on multiple servers 100 netmap le 85, 91, 102, 104 physical node IDs 80, 84 displaying 87 planning 81 private link 105 running chkfsys on servers 193 servers cron server 14 global name server 11 setup considerations 83 time values inherited via booting 18 troubleshooting 105 Network Manager (Net) mandatory for network boot 26 node ID mappings 11 starting 87 using nettrap 89 newgrp utility 113 nodes assigning logical node IDs 79 booting from own hard disk 99 over the network 8, 26, 93, 98 changing logical node ID in build le 99 conguring 96 customizing 8
August 15, 2005
Index
233
Index
customizing services 8 IDs See logical node IDs inheriting time and date values 18 installing license on hard disk 73 specifying keyboard for 15 starting lesystem after booting 37 transferring network licenses 100 transmitting boot image over network 95, 96 two network cards in same node 93 nologin le 129
DOS
46
P
parallel device drivers Dev.par 11 starting 11, 51 troubleshooting 52 parallel devices 51 printer as target 157 parallel port general conguration 51 LPT1 and LPT2 52 multiple parallel ports 52 single parallel port 52 specifying output buffers 52 parent directory 187 parity bits, modem 59 partitions See also pathname space blocks 183, 184, 190 checking directory structure 191 copying image of DOS 40 DOS types 41 oppy 34 hard disk 34, 35 key components on disk 182 loading boot image from disk 21 mounting 33 multiple 35 root directory 184 scanning for consistency 193 passwd le 112, 121 passwd utility 111
O
open count, processes accessing serial device 64 operating system building custom 21 selecting processes 24 other (mode bit), accessing les via 116 output buffers, specifying for parallel port 52 output, standard 52 owner (mode bit) accessing les via 116 changing 119 ownership of les See also permissions changing 119
234
Index
August 15, 2005
Index
modifying behavior 112 password database 121 /etc/.pwlock le 124 /etc/group le 123 /etc/passwd le 112, 122 /etc/shadow le 123 access permissions 121 default password les 125 removing user account 114 passwords changing 111, 112 entering at login 111 protecting encrypted passwords 124 setting stringency 112 specifying when account created 114 user ID ranges 112 pathname space oppy 34 hard disk 34, 35 partitions 33, 35 via symbolic links 37 pax utility 168 permissions accessing DOS devices 40 changing 119 directory access 117 DOS-QNX lesystem 45 effective user and group IDs 115 executables with owner & group privileges 120 execute bit 117 le access 116, 117, 119 le mode bits 116, 117, 119 creation mask 119
mounting/unmounting a device 34 read bit 117 setgid 120 setuid 120 superuser 117, 120, 121 umask (bit mask) 119 viewing 118 write bit 117 phoning incoming/outgoing calls on same serial line 64 user selecting terminal type 133 physical lesystem, dened 33 physical node IDs address formats 84 assigning 80 determining 84 displaying online 87 locating 80 on card 84 printed out by boot ROM 97 specifying in decimal 86 unique within each network 80 port parallel 51 serial 53 portability, QNX-DOS lesystems 43 PostScript les, printing 156 power outage, recovering from 193 pr utility 154 prex tree 33. See also lesystems DOS drive prex name 40 mapping pathnames to I/O managers 33
August 15, 2005
Index
235
Index
partitioning the namespace 33 prefix utility 36 PRINTER environment variable 160 printers as target 144 canceling print jobs 143 conguring parallel driver 51 connecting serial 60 examples 160 improving turnaround time 52 LPT1 52 LPT2 52 output buffer for parallel port 52 parallel driver 51 querying 143 redirecting output to console 52 reinitializing between spool jobs 145 serial driver 51 serial, ow control 60 troubleshooting driver operation 52 printing See also spooling generating correct output format 154 jobs selected on queue priority 145 lp command line 162 optimizing processing time 157 PRINTER environment variable 160 queuing print jobs to TCP/IP network 142
setting up pagination 154 setup les 153 starting spooling server 142 submitting jobs 142 utilities 141 priority, of process in build le 23 privileges See also permissions assuming another users 111 group 113 switching to group ID 113 user access by group ID 113 Proc32 7, 24 starting in build le 22 Process Manager, starting 7 processes boot 7 changing group ID 116 closing les while running chkfsys 192 counting access to a serial device 64 Dev 10, 51 displaying running 6 Dosfsys 38 Fsys 13 including in build le 21 initial priority 23 mandatory 24 Mouse 14 Net 11 Proc32 7 real and effective user/group IDs 115 role of umask on le creation 119 running with superuser permissions 121
236
Index
August 15, 2005
Index
selecting by path 215 for embedded image 29 for OS image 24 starting 24 startup order 23 user and group ID classes 115 profile le 109 pseudo tty driver, starting (pty) 51
Q
QNX 32-bit and 16-bit programs 24 basic philosophy and operation 3 boot diskette 3 console 135 disk structure 182 Embedded Kit 28 including Microkernel in build le 22 including shared library in build le 22 installation procedure 4 max. number of nodes running concurrently 72 modules 215 selecting processes 24 signature 169 suppressing read of 170 qtalk utility checking for free line 64 queues accessing 159
attributes 148 chaining 147, 155 conguring 147 controlling 144 default 159, 160 dened 144 lters 144, 154 bypassing copy-in 147 control program 145, 152 copy-in 145, 148, 154 copy-out 145, 154 default 152 input errors 156 jobs chaining despooled onto queue 148 ushing 148 forcing return 148 maximum number 148 prioritizing 145 removing 143 retrying 148 submitting 142 viewing spool queue 143 writing to queue le 143 locating 159, 160 queue entry 161 multiple 143, 145, 154 connecting to targets 144 feeding multiple targets 146 feeding single target 156 names 143 in /dev/spool directory 141 on lp command line 162 symbolic 147
August 15, 2005
Index
237
Index
PRINTER environment variable 160 priority 148 setup les 153 targets 145 abandoning 148 completing 148 connecting output to printer 144 multiple 146
R
raw disks, browsing 192 read permission 117 realtime clock See also time zones getting time from 10, 17 setting manually 17 rebooting See also booting recovering from unexpected 193 recovering a zapped le 192 blocks 191 data 192 after unexpected system failure 179 compressed 172 DOS lesystem 47 lost les/directories 200 recovery oppy 180 Release Notes, reading prior to installing QNX 3 remote lesystem 36 removable disks
as backup media 169 backing up to or restoring from 172 unmounting before removing 34 resources accessing via a spooler 141 controlling access 110 inheritance through session startup 109 sharing by group 114 restoring data xed disks 172 from oppy 169 compressed 173 problems recovering compressed 173 removable disks 172 tape 171 tar/cpio format 168 to UNIX system 174 rm utility 38 rmdir utility 38 ROM, broadcast booting 95 root See superuser root block 183 creating 191 restoring 191 root directory 33 /.bitmap le 184 /.inodes le 184 contents 184 creating 191 DOS 39 RS-232 cabling assignments 55
238
Index
August 15, 2005
Index
ow control, terminal and modem 58 serial protocol 57 session control 58 signal names 56 transmitted characters 57 rtc utility 17
S
scanning for consistent data (chkfsys) 193 scheduling processes for execution 7 security 110 access control utilities 111 default password les 125 le permissions 116 group IDs 114 limiting user access 121 login utility 111 newgrp utility 113, 116 passwd utility 111 password database 121 protecting encrypted passwords 124 restricting access to les 116 su utility 111 user IDs 114 utilities with superuser permissions 121 serial bus hardware interrupt signals 53 sharing interrupts 54 serial device drivers
11 starting 11, 51 testing operation 65 serial devices 53 conguring ports 58 connecting 60 modems 60 printers 60 terminals 62 exclusive access 64 hardware adapters 53 I/O hardware address 53 multiport adapters 54 printer as target 157 RS-232 serial protocol 55 single-port adapters 54 troubleshooting 65 typical installation 54 UART hardware interrupts 53 serial ports conguring 53, 58 data bits 58 I/O address and hardware interrupt 54 parity bits 59 sharing interrupts 54 specifying baud rate 11, 59 stop bits 59 servers boot server 80 cron server 14 global name server 11 running chkfsys on 193 spooling server 142 services See also images; system initialization le base-level 22
Dev.ser
August 15, 2005
Index
239
Index
customizing 8 in sysinit le 7 selecting modules 215 session, starting 109 setgid, changing 120 setuid, changing 120 sh shell program 10 shadow le 121 shared library 16-bit 24 including in build le 22 shell See also commands /bin/sh 8 echo command 110 environment variables 110 executing profile le 109 initialization 7 scripts 7 executing within sysinit.node le 10 selecting 114 set command 110 started by login utility 110 sin utility 6 sinit utility 7 shell startup 7 starting in build le 22 using to set terminal type 133 Slib16 24 Slib32 24 starting in build le 22 software installing 3, 4, 6, 7 spatch utility 192 examining blocks within a le 195 spooler
architecture 144 default 159 dened 141 les 215 locating 159, 161 multiple 150 names on lp command line 161 registering 148, 150 starting 142 spooling See also queues conguring 160 global keywords 150 jobs querying 143 selecting on queue priority 145 submitting 142 lp utility 142 lpc utility 144 LPDEST environment variable 159, 160 lpq utility 143 lprm utility 143 LPSRVR environment variable 159, 160 lpsrvr utility 142 lpsrvr.node le 142 named queues in le namespace 141 output device 148 PRINTER environment variable 160 queues and targets 144 recording accounting information 148, 155
240
Index
August 15, 2005
Index
reinitializing printer between jobs 145 reporting error messages 156 server, starting 142 setup le (lpsrvr) 142, 147 example 153, 156 temporary directory 148, 151 utilities 142 variables 151, 154 adding custom keys 152 wait before despooling 148 st mode eld, le access 117 standard input and output defaults 152 writing to standard output 52 standard time zone See also time zones dening 16 startup controlling order of processes 23 stop bits (modem) 59 stty command 11 su utility 111 SUB character (DOS) 43 superuser accessing accounting le 125 adding new accounts 112 changing le mode bits 120 Dosfsys le ownership 47 editing password le 114 permissions on les 117 symbolic links partitioning pathname space 37 sysinit le 7, 9. See also system initialization le
7, 9, 98. See also system initialization le syslog le 128 system accounting information 125 embedded systems 28 les in /boot/sys directory 24 including shared libraries in build le 22 initialization in build le 22, 110 limiting user access to 121 QNX software version (sin) 6 recovering data after crash 193 selecting processes by path 215 troubleshooting boot failure 195 System Architecture, reading prior to installing QNX 3 system initialization le 7 altsysinit 9 base-level services 10 contents 10 copying to altsysinit before changing 9 customizing for network node 98 establishing time zone 10 executing 10 shell commands in 10 rst command in le 10 oating-point emulator 11 getting time from realtime clock 10
sysinit.node le
August 15, 2005
Index
241
Index
hard disk booting 10 international keyboard support 15 last command in le 12 loading node mappings 11 making alternate copy 91 modifying for boot server 91 mounting local lesystem 36 remote lesystem 36 nameloc utility 12 optional services 12 placing commands in separate le 10 setting environment variables 13 setting up spoolers and queues 162 starting chkfsys 193 console driver 10 cron server 14 Device Manager 10 DOS lesystem driver 14 oppy driver 13 Fsys 37 login on all consoles 12 mouse driver 14 network services 87 parallel driver 11 serial driver 11 sysinit 9 sysinit.node 8, 9 system shared library, selecting processes from 24
T
tape appending les to archive 174 backing up to or restoring from 171 backup media 169 rewinding 174 SCSI tape controller 171 starting new tape archive 174 tape utility 172 tar utility 168 using with oppies 170 targets See also queues attributes 148 conguring 145, 147 control program 145, 148 dened 144 exclusive access to device 155 names in setup le 153 symbolic 147 output device 148 connecting to 144 selecting 146 technotes, locating 215 TERM environment variable 13, 110, 133 termcap le 133 converting terminfo entries 135 entries 134 termdef utility 133 terminals See also consoles; ansi terminal; serial devices aliases 134 capabilities 133, 135, 215
242
Index
August 15, 2005
Index
conguring serial link 62 connecting hardware 62 console driver 51 daemon 12 emulator (qtalk) 64 ow control 62 hardwired 133 initialization (tinit) 12, 63 launching custom applications via 63 logging in 63 automating (login) 63 via termdef 134 modems ow control 58 releasing connection to 58 setting TERM type 13, 22, 133 user selection (termdef) 133 troubleshooting serial link 65 terminfo database 135 accessing and creating les 135 terminfo les 133 text le See also les converting from DOS to QNX 43 DOS vs QNX formats 42 termination characters 42 textto utility 43 third-party software, installing 6 tic utility 135 time zones 15 coordinated universal time (UTC) 16 date and time 17
effects of not setting 16 establishing 10, 16 Greenwich Mean Time 16 overview 16 transferring les to different time zone 16 TZ environment variable 10, 16 tinit utility 12, 63, 64, 111 starting login 111 TMPDIR environment variable 110 Token Ring booting from network 95 physical node ID of card 84 touch utility 125 accounting le 128 tr utility 43 trafc, ofoading to private link 105 transmission, slowing down rate 59 troubleshooting access control 121 after unexpected system failure 193 boot failure 195 disks checking for corruption 180, 199, 200 patching minor problems 192 le access 118, 120 network errors 98, 105 parallel driver 52 print spooling errors 156 serial driver 65
August 15, 2005
Index
243
Index
utilities with superuser permissions 121 TTL logic, serial bus 53 tty device starting pseudo tty driver (pty) 51 terminal initialization and login 111 TZ environment variable 10, 110 establishing time from network boot 18 example 16
U
UARTs hardware interrupts generated 53 I/O address range 53 managed by Dev.ser 53 sharing interrupts 54 umask utility 119 assigning mode bits 119 permission bit mask 119 umount utility 34 undeleting a zapped le 192 unmounting devices 34 usage message example 4 user ID real 114 IDs 114 changing 115 effective 115 removing user account 114
support under DOS 46 switching to group ID 113 user IDs determining ranges 112 ranges 113 reserved range 113 setting ranges in passwd le 112 username 112 entering at login 111 users $HOME/.profile le 109 accounts 111 controlling access to session 109 to system 121 database le 111 granting access by group ID 113 password le 112 preferences 109 reading /etc/passwd le 124 removing user account 114 UTC See time zones utilities /etc/install utility 6 access control utilities 111 buildqnx 21, 97 cat 52, 152 chgrp 120 CHKDSK (DOS) 47 chkfsys 191, 192 chmod 120 chown 46, 120 cp 40, 169 cpio 168
244
Index
August 15, 2005
Index
cron 14 date 17 dcheck 191 dinit 170, 184, 191 ditto 105 emu87 11 fdformat 170 fdisk 35, 190 freeze 169, 173 gunzip 173 gzip 128, 173 infocmp 135 kbd 15 kedit 15 less 38 license 71 licinfo 73, 87 ln 37 lockfd 170
netmap 11, 91 nettrap 89 newgrp 113 passwd 111 pax 168 pr 154 prefix 36 rm 38 rmdir 38 rtc 17
logging information about users 124 login 63, 110, 111 lp 142 lpc 144 lpq 143 lprm 143 lpsrvr 142 ls 34, 38, 118 make 21 melt 173 mkdir 38 modem 64 mount 13, 33 mousetrap 14 nameloc 11, 89 netboot 21, 28, 90, 93 netinfo 105
running with superuser permissions 121 sin 6 sinit 7, 133 spatch 192 spooler and queue utilities 141 TCP/IP 142 su 111 tape 172 tar 168 termdef 133 textto 43 tic 135 tinit 12, 63, 64, 111 touch 125, 128 tr 43 umask 119 umount 34 using on DOS lesystem 38 vol 168 zap 192 utmp le 129
August 15, 2005
Index
245
Index
V
variables, setting environment 13 vol utility 168 volumes labels (DOS) 45 naming oppies or removable disks 168 VT100 terminal 135
W
write permission 117 utilities with superuser permissions 121 wtmp le 129
Z
zap utility
192
246
Index
August 15, 2005

Install Config

Uploaded by

Copyright:

Available Formats

Install Config

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Install Config

Uploaded by

Copyright:

Available Formats

QNX Realtime Operating System

Installation and Conguration

For QNX 4.25

2005, QNX Software Systems

Electronic edition published 2005.

Technical support options

Whats new online (as of August 05, 2005)

August 15, 2005

2005, QNX Software Systems

Getting the date and time from the realtime clock

August 15, 2005

2005, QNX Software Systems

File ownership 46 47 Terminating Dosfsys Error codes returned by Dosfsys

Connecting Character Devices

August 15, 2005

2005, QNX Software Systems

Transferring a license to another node

August 15, 2005

2005, QNX Software Systems

Setting up User Accounts 107

Setting up Terminals 131

August 15, 2005

2005, QNX Software Systems

For more information

Print Spooling 139

August 15, 2005

2005, QNX Software Systems

Making Backups 165

Disk & File Recovery 177

August 15, 2005

2005, QNX Software Systems

QNX Console & Keyboard Conventions 201

Where QNX Files Are Found 213

August 15, 2005

About This Guide

August 15, 2005

About This Guide

2005, QNX Software Systems

August 15, 2005

About This Guide

2005, QNX Software Systems

Go to this chapter: Setting up Filesystems

Connecting Character Devices Licensing Networking

About This Guide

August 15, 2005

2005, QNX Software Systems

Setting up User Accounts

August 15, 2005

About This Guide

2005, QNX Software Systems

Go to this chapter: Print Spooling Making Backups

Disk & File Recovery

About This Guide

August 15, 2005

2005, QNX Software Systems

Whats new online (as of August 05, 2005)

Whats new online (as of August 05, 2005)

August 15, 2005

About This Guide

Chapter 1 Basic Installation In this chapter. . .