Hello I am a total newbie to qnx and having to deal with version 2.21 on an ancient piece of equipment. The hard drive and PC are both dieing slowly, we previously imaged the drive and reloaded onto a hard drive of the same size and it worked fine. The issue I am having now is I am trying to burn image onto compact flash, and when I try and boot on test pc I get, qnx loader boot partition 4 and nothing more.
The original hd was 630 meg. The compact flash is 1 gig. I was able to mount the 1 gig drive as a slave and run chkfsys +r and the only message was bitmap is smaller than current drive size. Otherwise all ran fine.
I am sure this is a simple problem to one well versed in qnx. Any help would be greatly appreciated.
You’ve come to the right place for help.
You will not be able to do an image copy from the old hard drive to the CF card for reasons that will appear below.
First a little background. You can skip this if you like, I’m putting it here for posterity.
The original drives used on IBM PC’s were Cylinder/Head/Sector devices.
Drives had some fixed number of sectors per track, a number of heads and some number of cylinders.
These values were entered in CMOS by the BIOS either by referencing a table number or by entering custom values.
Basically you had to have the numbers in CMOS correspond to the actual values on the disk, and furthermore the driver had to know what they were. There was a natural ordering of sectors that worked like this for S/H/C
Sector S/H/C
1 0/0/0
2 1/0/0
N N/0/0
N+1 0/1/0
etc.
The way QNX 2 booting dealt with this (approximately) is as follows. You would first have to have a system running with the hard drive mounted. The boot command would run and it would put an image of the current drivers data segment into a file on the drive. This file might also have included the code segment, I’m just not sure.
The OS loader (not the boot loader) would load in the OS, the driver, and this image file at boot time.
The important point is that the parameters being used by the driver at the time of running the boot command must correspond to the ones needed at boot time, and furthermore must be the same as the ones in the CMOS.
While these correspondences were necessary at the time, they are at the root off the problem of booting off of a modern EIDE drive, and the cause of most boot errors.
As time moved there were enhancements, part of the IDE, EIDE and ATAPI specifications.
First, the Sector/Head/Cylinder numbers no longer needed to correspond to the physical disk. The firmware in the drive simulated external values for these parameters and was free to use any internal physical parameters, hidden from the user. This was almost invisible unless the user was counting on finding seek delays between specific sectors.
Next, it became possible to configure the drive to have a specific external geometry. The drive would dutifully use this new configuration to access the internal geometry. I never saw the point of this.
Finally, there appeared an LBA (logical block address) option. You could access sectors in the most natural way, 0, 1, 2… N.
If you are using the the QNX supplied disk.at or disk.atc drivers then you were accessing the drive with Sector/Head/Cylinder numbers. BTW, the ‘c’ in disk.atc stands for caching. The disk.at drive would only read a single sector at time, a great waste. The disk.atc driver would instead read some larger number of sectors, eg. 8, and cache them in memory. It also could cache for writes.
If you are using the disk.ata driver, then the driver is using LBA numbers.
BTW, I wrote the disk.ata driver and if you can’t find it, I can provide it.
Ok, if you skipped forward, you will want to start reading here again.
The problem with a modern drive or a CF card is that it is an LBA drive internally. If it is a disk and has Sector/Head/Cylinder geometry, it would only be a coincidence that this geometry is visible.
So in order to properly set up a drive to boot, you must know what geometry it is showing through the BIOS calls.
This is not always easy to find out.
In the unrelated case of booting off of a SCSI drive, this geometry is specific to the boot rom. There is no visible geometry on a SCSI drive.
In some cases you can discover the geometry as follows.
If the BIOS you are using is modern, then you can install the drive, and let the BIOS detect the geometry.
You then boot off of a floppy, mount the disk.atc or disk.ata driver, and once mounted asked what these parameters are. The easiest way to ask is to use the fdisk command.
If this works, then you are pretty much set. You fdisk, dinit the drive, re-mount it as follows:
mount disk 3 d=3 pa=qnx +v
load the system files and run the boot command.
If this doesn’t work, then you have to figure out what the drives geometry is.
If it is a hard drive, you can try Googling the drive model to see if it is document.
You might try this with a CF card also.
Otherwise, it’s trial and error.
The good news is that you only have to guess how many sectors per track and how many head there are.
The number of cylinders is unimportant.
As an example, the CF card I’m using in the machine I still use as an answering machine, fdisk shows the following parameters:
H=16 T=286 N=63
This means 63 sectors per track, 16 heads and 286 cylinders.
Once you know the correct values, here is the step by step procedure to getting your system to boot QNX 2.
- Set the CMOS values correctly. This is important, you must do this first.
- Boot off of a floppy disk
- Mount your driver and specify the geometry, eg.
mount disk 3 /drivers/disk.ata h=16 t=286 n=63 +v
You should get two return codes of 00 when you use +v
-
run fdisk on drive. setup a QNX 7 partition and set the boot flag.
-
remount the partition
mount disk 3 d=3 pa=qnx h=16 t=286 n=63 +v
I’m not sure if you need to include the h/t/n parameters a 2nd time, but I would do it to be sure.
- dinit the drive
dinit 3 +h
- copy the os files to the hard drive. There are many ways to do this. The most basic
way is to copy from the installation diskettes. If the system is on a QNX network, you can
copy over the network. Come to think of it, if you are on a network, you could have
also booted over the network.
My own method is to mount my Iomega parallel port zip driver and use a Zip disk with QNX 2 backed up on it.
In your case, since you have an existing drive, you will want to install it as the slave. You should be able to mount it as follows:
mount disk 4 d=3 pa=qnx p=1 +v
The p=1 means physical drive 1 (starting at 0).
Then you can use backup:
backup 4:/ 3:/ +a -p
hard drive.
mount disk 3 3:/drivers/disk.ata h=16 t=286 n=63 +v
This might not always be necessary, but if the two drivers, the one on the floppy and the one copied to the hard drive
are not identical, then all will fail if you skip this step.
- Run the boot command. Here’s an example:
boot 3:/netboot/os.2.21atpb d=3:/drivers/disk.ata
If you created a sys.cfg file for your system, then you can include it with the c= parameter.
This is usually only needed if your serial and/or parallel ports are in weird locations.
Now you should be able to boot off of your hard drive.
Good luck
You’ve come to the right place for help.
First a little background. You can skip this if you like, I’m putting it here for posterity.
The original drives used on IBM PC’s were Cylinder/Head/Sector devices.
Drives had some fixed number of sectors per track, a number of heads and some number of cylinders.
These values were entered in CMOS by the BIOS either by referencing a table number or by entering custom values.
Basically you had to have the numbers in CMOS correspond to the actual values on the disk, and furthermore the driver had to know what they were. There was a natural ordering of sectors that worked like this for S/H/C
Sector S/H/C
1 0/0/0
2 1/0/0
N N/0/0
N+1 0/1/0
etc.
The way QNX 2 booting dealt with this (approximately) is as follows. You would first have to have a system running with the hard drive mounted. The boot command would run and it would put an image of the current drivers data segment into a file on the drive. This file might also have included the code segment, I’m just not sure.
The OS loader (not the boot loader) would load in the OS, the driver, and this image file at boot time.
The important point is that the parameters being used by the driver at the time of running the boot command must correspond to the ones needed at boot time, and furthermore must be the same as the ones in the CMOS.
While these correspondences were necessary at the time, they are at the root off the problem of booting off of a modern EIDE drive, and the cause of most boot errors.
As time moved there were enhancements, part of the IDE, EIDE and ATAPI specifications.
First, the Sector/Head/Cylinder numbers no longer needed to correspond to the physical disk. The firmware in the drive simulated external values for these parameters and was free to use any internal physical parameters, hidden from the user. This was almost invisible unless the user was counting on finding seek delays between specific sectors.
Next, it became possible to configure the drive to have a specific external geometry. The drive would dutifully use this new configuration to access the internal geometry. I never saw the point of this.
Finally, there appeared an LBA (logical block address) option. You could access sectors in the most natural way, 0, 1, 2… N.
If you are using the the QNX supplied disk.at or disk.atc drivers then you were accessing the drive with Sector/Head/Cylinder numbers. BTW, the ‘c’ in disk.atc stands for caching. The disk.at drive would only read a single sector at time, a great waste. The disk.atc driver would instead read some larger number of sectors, eg. 8, and cache them in memory. It also could cache for writes.
If you are using the disk.ata driver, then the driver is using LBA numbers.
BTW, I wrote the disk.ata driver and if you can’t find it, I can provide it.
Ok, if you skipped forward, you will want to start reading here again.
The problem with a modern drive or a CF card is that it is an LBA drive internally. If it is a disk and has Sector/Head/Cylinder geometry, it would only be a coincidence that this geometry is visible.
So in order to properly set up a drive to boot, you must know what geometry it is showing through the BIOS calls.
This is not always easy to find out.
In the unrelated case of booting off of a SCSI drive, this geometry is specific to the boot rom. There is no visible geometry on a SCSI drive.
In some cases you can discover the geometry as follows.
If the BIOS you are using is modern, then you can install the drive, and let the BIOS detect the geometry.
You then boot off of a floppy, mount the disk.atc or disk.ata driver, and once mounted asked what these parameters are. The easiest way to ask is to use the fdisk command.
If this works, then you are pretty much set. You fdisk, dinit the drive, re-mount it as follows:
mount disk 3 d=3 pa=qnx +v
load the system files and run the boot command.
If this doesn’t work, then you have to figure out what the drives geometry is.
If it is a hard drive, you can try Googling the drive model to see if it is document.
You might try this with a CF card also.
Otherwise, it’s trial and error.
The good news is that you only have to guess how many sectors per track and how many head there are.
The number of cylinders is unimportant.
As an example, the CF card I’m using in the machine I still use as an answering machine, fdisk shows the following parameters:
H=16 T=286 N=63
This means 63 sectors per track, 16 heads and 286 cylinders.
Once you know the correct values, here is the step by step procedure to getting your system to boot QNX 2.
- Set the CMOS values correctly. This is important, you must do this first.
- Boot off of a floppy disk
- Mount your driver and specify the geometry, eg.
mount disk 3 /drivers/disk.ata h=16 t=286 n=63 +v
You should get two return codes of 00 when you use +v
-
run fdisk on drive. setup a QNX 7 partition and set the boot flag.
-
remount the partition
mount disk 3 d=3 pa=qnx h=16 t=286 n=63 +v
I’m not sure if you need to include the h/t/n parameters a 2nd time, but I would do it to be sure.
- dinit the drive
dinit 3 +h
- copy the os files to the hard drive. There are many ways to do this. The most basic
way is to copy from the installation diskettes. If the system is on a QNX network, you can
copy over the network. Come to think of it, if you are on a network, you could have
also booted over the network.
My own method is to mount my Iomega parallel port zip driver and use a Zip disk with QNX 2 backed up on it.
hard drive.
mount disk 3 3:/drivers/disk.ata h=16 t=286 n=63 +v
This might not always be necessary, but if the two drivers, the one on the floppy and the one copied to the hard drive
are not identical, then all will fail if you skip this step.
- Run the boot command. Here’s an example:
boot 3:/netboot/os.2.21atpb d=3:/drivers/disk.ata
If you created a sys.cfg file for your system, then you can include it with the c= parameter.
This is usually only needed if your serial and/or parallel ports are in weird locations.
Now you should be able to boot off of your hard drive.
Good luck
Thanks for the quick response. I will try you suggestions tomorrow and will post on my results.
Finally got back to my QNX issue today. As previously mentioned I am trying to work with Image burned onto compact flash. I do not have the data backed up any other way, so i had to come up with a work around. Using a borrowed boot floppy I booted and mounted the CF with image on it. Using fdisk I was able to look at the CF and find the head cylinder and sector numbers. The partion was already showing and set to boot. I got out of fdisk and shut down then went into Bios and manually entered the disk data showing on Fdisk. Saved and exited bios and now the system boots fine off of the CF.
Thank you for you help with this issue I used to information you supplied to help me better understand the issue at hand.
The borrowed boot disk brings up a second less urgent issue. I tried to make a copy of the boot disk to keep for future use but it is apparently the oldest working floppy disk in texas, and I cannot copy it using dcopy 1 1 the disk is already a copy so I am sure it can be copied. It shows 1 Meg on the disk but when I try and copy it, it shows 720k but the copied disk fails all sectors corrupt. I tried formatting 1.44 disk to 1 meg no help.
Any help with this new issue would be appreciated as well.
Hurrah!
Hmmm, well what happens when you try? You did format the target floppy first?
I remember that the earliest versions of QNX supported that same DOS feature where the OS would prompt you to re-load floppy 1 or 2 when needed. I thought it went away in later versions but I haven’t tried in years.
In what way does it show 1Meg? “query ?”
If so, then the creator must have thought themselves clever. I believe fdformat lets you format less than 80 tracks, and dinit might let you specify a size. That would create a disk that doesn’t seem to be able to be copied. You might try formatting as 1.44 and seeing if dcopy has a sector limit you can set.
But there’s a better solution. If you have a working QNX 2 system that boots off the hard drive, you can create your own boot floppy manually. Here are some things you need to do.
-
fdformat the floppy
-
dinit the floppy
-
create /cmds, /config, /drivers directories on the floppy
-
copy an os file to the floppy
-
copy some useful commands to 1:/cmds
sh, login and mount are probably the minimum you need.
Things like fdformat, dinit, fdisk, cp, ls are useful if you are trying to init a hard drive.
A 1.44 floppy will hold a lot of stuff, but not all. As long as the hard drive boots, you can use trial and error to see what you need. -
create a sys.init file in /config, it can probably be empty
-
put the required hard disk driver in /drivers
When you boot off of it, a login should come up. At the shell you would run the
mount command to mount the hard drive.
From there you can reference off the hard drive to get going, eg.
$ 3:/cmds/search 3 1