BOOTING WITH PRIMARY FILESYSTEM ON PHYSICAL DRIVE 1



These are the instructions to follow to create a boot image that will load QNX, so that it uses a partition on physical drive 1 as the primary filesystem. This is sometimes necessary if you wish to install QNX on a computer with drive 0 already full. A program called Partition Magic, from PowerQuest is apparently able to alter the size of an existing Microsoft partition. I haven't used it personally, but some of my customers have reported good things about it. You can contact them at 1-800-379-2566 or www.powerquest.com.

To summarize the booting process:
1. Bios loads the primary boot loader from relative sector zero of hard drive 0 into memory and passes control to it.

2. Primary boot loader reads the partition table from hard drive 0. It selects the active partition (or allows you to choose one). Based on the information in the partition table, it reads the operating system specific boot loader from the partition into memory and passes control to it.

3. This secondary loader is operating system specific and reads the operating system image from the filesystem into memory and passes control to it. This O/S image contains the kernel and hard disk drivers. Other drivers are loaded later while executing the sysinit file.

The QNX primary boot loader does not have the capability to read the partition table of drive 1 or to load its secondary loader from drive 1. I don't know if the secondary loader is capable of reading from drive 1, it may be able to. If so, another primary loader could be used to boot QNX from drive 1. The alternative is to load the operating system image into memory another way. The practical method is to boot a special image from a 2M partition on drive 0, from a floppy or remotely via the network.

So there are two issues to solve. First the initial installation and second, making it boot. All of the instructions assume you are logged in as root.


INITIAL INSTALLATION

Installation can be done a few ways. The easiest is to physically change the hardware so that drive 1 is temporarily drive 0 and do a normal install from the floppy diskettes. Another is to install QNX into a partition and copy it all to drive 1. The third is to do the second, but across the network.

Assuming you have an installed QNX partition and want to copy it to the new partition you are creating on drive 1, this is what you do.

If required, start the driver for the disk controller card. This will be required if copying across the network, or you have an IDE and a SCSI drive in the machine. If you are using multiple controllers, you will need to name the partitions something other than hd for the second controller. Use the -nxx parameter when starting the driver. The driver will already be running if you have 2 drives connected to the same controller. See the documentation for the various Fsys drivers for details on how to start them.

Use fdisk to edit the partition table of drive 1. Create a type 77, which is the primary QNX partition. Note that if you change the size of an existing partition, its contents will likely be unusable.
fdisk /dev/hd1

Mount the partition:
mount -p /dev/hd1

Initialize a filesystem in the partition.
dinit -h /dev/hd1t77

Mount the new filesystem as a sub-directory of the main filesystem:
mount /dev/hd1t77 /hd1

You should be able to list all the files of the new partition:
ls /hd1
There are only a few.

Now you can copy the primary filesystem to the sub-directory filesystem:
cp -cLnOpR / /hd1

The licenses are not copied properly, so delete them and use the license utility
to copy them:
rm /hd1/etc/licenses/*
license /etc/licenses /hd1/etc/licenses

Delete any licenses from /hd1/etc/licenses which should not be used with this
new installation. The QNX License Agreement permits use with only one CPU per
licence.


MAKING IT BOOT

A modified version of the boot image is required, so that the partition on drive 1 is mounted as the primary filesystem, rather than the one on drive 0.

This image is the same, no matter if the image is loaded via the network, from floppy or from a parition on drive 0. For this case, even if the image is loaded via the network, it is not really a network boot, since the image will mount the local hard drive, rather than mount the remote network filesystem.

Let's look at the build file for the operating system image for a standard installation which uses drive 0 as its primary filesystem. Change to the directory /boot/build and edit the file hard.1. It looks something like the following. Each pair of lines specifies an executable to be included in the image. The first line identifies the executable filespec. Some are relative filespecs, for example sys/Proc32, which are relative to the directory /boot, which should be the current directory when the buildqnx command is run to create the image. The second line starts with a dollar sign and specifies the command line, including some parameters, which are used to start the executable. Older versions included a heap size after the dollar sign, which is no longer required and should be removed.

sys/boot manages the startup of the executables
$ boot -v -v displays them

sys/Proc32 the microkernel itself
$ Proc32 -l 1
-l specifies the node number of this cpu many other
parameters tune memory usage

sys/Slib32 32 bit shared library
$ Slib32

sys/Slib16
16 bit shared library
$ Slib16
many utilities are still 16 bit, so you do need this

/bin/Fsys the POSIX filesystem
$ Fsys -c2M -r512K -A
-c specifies the size of the cache, -r the size of the ram disk and
-A removes the POSIX requirement to update the directory to indicate time of last read

/bin/Fsys.eide the driver for the ATAPI disk controller
$ Fsys.eide

/bin/mount read the partition table and mount the
$ mount -p /dev/hd0 /dev/hd0t77 / primary filesystem

/bin/sinit execute the file /etc/config/sysinit.NODE
$ sinit TERM=qnx

So, to change the system to mount the primary filesystem on drive 1 instead, change the mount line to:
$ mount -p /dev/hd1 /dev/hd1t77 /

The filenames of the images can be anything, so save the file with a different name. I will use d1boot for this example.

Change to the directory /boot and then create the image from this source file:
buildqnx build/d1boot images/d1boot

You can boot with this same image from a floppy, a small partition on drive 0, or via the network (you need a QNX Boot ROM for your network card). If you have a single machine, and temporarily switched drive 1 to be drive 0 to do the install, create a floppy boot disk before putting the drives back.


FLOPPY BOOT

Creating a QNX boot floppy is easy. Format a diskette:
fdformat -k0 -z2 /dev/fd0

Initialize a filesystem:
dinit /dev/fd0

Mount the new filesystem:
mount /dev/fd0 /fd

At this point, the sub-directory /fd appears and all files within it are the files on the floppy. Copy the operating system image to the floppy filesystem:
cp /boot/images/d1boot /fd/.boot

Note that when booting with this floppy boot method, the floppy driver is not started. The boot image is read using bios calls. You may want to start the floppy driver in your sysinit file.


DRIVE 0 BOOT

Similarly, you can create a small partition on drive 0 to boot from, so the hard disk acts like a fast floppy.

If you created your drive 1 partition by booting via the network, then it is easy. You will already have started the disk controller driver. Use fdisk to create a small partition on drive 0, minimum 2M. This will often be a single cylinder on large disks. Note that if you change the size of an existing partition, its contents will likely be unusable.
fdisk /dev/hd0
(also choose Boot to select the partition which is the default partition to boot and choose Loader to install the QNX partition loader)

Mount the disk 0 partitions:
mount -p /dev/hd0

Initialize a filesystem in the partition:
dinit -h /dev/hd0t77

Mount this filesystem as a sub-directory:
mount /dev/hd0t77 /bt

Copy the boot image to it:
cp //NODE/boot/images/d1boot /bt/.boot (where NODE is the other node number)

Note that the filesystem of the booting device was not mounted during booting, so that filesystem does not appear after the system has booted. The primary filesystem / is the QNX partition on drive 1. In your sysinit file, mount the drive 0 filesystem as a sub-directory, so you can update the boot image from time to time.

If you created the drive 1 partition by changing the hardware so drive 1 was drive 0 and then installed from floppies, create a floppy boot disk as described in the previous section. The QNX Boot diskette is unsuitable for this purpose. Then restore the hardware, so drive 1 really is. Use the floppy boot disk to boot. QNX will run and / will be the partition on drive 1.

Use fdisk to create a small partition on drive 0, minimum 2M. This will often be a single cylinder on large disks. Note that if you change the size of an existing partition, its contents will likely be unusable.
fdisk /dev/hd0
(also choose Boot to select the partition which is the default partition to boot and choose Loader to install the QNX partition loader)

Mount the disk 0 partitions:
mount -p /dev/hd0

Initialize a filesystem in the partition:
dinit -h /dev/hd0t77

Mount this filesystem as a sub-directory:
mount /dev/hd0t77 /bt

Copy the boot image to it:
cp /boot/images/d1boot /bt/.boot

Now when you boot from hard disk, you can select the 2M partition and it will appear to be booting from drive 1, since the primary filesystem / is the partition on drive 1.


NETWORK BOOT

Edit the file /etc/config/netboot. The f=parameter specifies the boot source file (not the image).

Note that with this method, unlike a normal network boot, Net and the network driver was not started. You may want to add the necessary commands to your sysinit file to access the network.

PRECAUTION

When you make changes to a boot image, as a precaution, first copy the original /.boot to /.altboot. This alternate image can be selected when the message "Press ESC to load alternate O/S" appears on the screen. In this case the file /etc/config/altsysinit is used if available. You might want to test this before changing your boot image.

Note: These instructions are for typical situations. Individual configuration may differ. If you have any questions, please contact us for assistance.

Copyright © 1998 Qenesis Inc. All rights reserved.