We have QNX 4.25 running on several Dell Optiplex 170L PCs. I believe the chipset is Intel 82801EB. I am trying to get an image from those machines to run on an Optiplex 210L with an Intel 82801FB chipset. Both machines use SATA hard drives. I’m using Ghost to make the image. It works fine as long as I leave the partition size the same on the new drive. On the new box, Fsys.atapi terminates on boot with SIGSEGV at 0005:0000F091 whether normal or alt boot. I thought the device ID might have something to do with it, so I put the drive in the old box and changed it in /boot/build/install.# and ran make. That didn’t have any affect on the new box, and that drive could still boot on the old box.
QNX doesn’t care about chipset. The IDE controler shouldn’t matter. However making a image with Ghost is not recommanded ( Ghost doesn’t know about QNX filesystem and cannot rebuild the filesystem if layout has changed. But you say the cloned drive works in the old box, so I it probably not a ghost issue. Still it’s safer to use a script to copy the HD, I have seen a few around these forum.
Note that some BIOS will not properly enable IDE emulation of SATA drive ( Fsys.atapi doesn’t support native SATA). Also BIOS many not report the same geometry ( but I’ve never seen it cause a SIGSEGV). You could try Fsys.eide if the HD isn’t too big.
It seems we’ve had a lot of questions on copying hard drives lately.
Ghost is a bad choice. It can only do a raw copy of the drive. That’s why it only works when the partition size is the same: the .bitmap and .inodes files are drive and partition specific. Overwriting means Bad Things Happen. This is also why you shouldn’t use dd.
Copying the drive in QNX is pretty easy. If you’re booted in 4.2x, fdisk, dinit, and mount the new partition (let’s say as /hdnew) and then copy using:
cp -cpvLR -P!/.bitmap -P!/.inodes / /hdnew
cp /.boot /hdnew/.boot
cp /.altboot /hdnew/.boot
-James Ingraham
Sage Automation, Inc.
A differing opinion. When Ghost doesn’t understand a partition, it does a sector by sector copy.
Copying a QNX partition to a bigger partition doesn’t hurt, but it doesn’t get you any more room.
Copying to a smaller partition is dangerous. It might be possible to do a dcheck and find the failed (missing) sectors.
A cloned partion of a QNX 4 hard drive should work fine. The only likely problem is if the target drive has bad sectors. I haven’t seen a bad sector on a new drive in over a decade, so this is unlikely.
On the other hand, a sigsegv on Fsys.atapi is disturbing. I would proceed as follows.
- Clone the disk
- Create a boot floppy with Fsys.atapi on the diskette.
- Boot the system
- Manually start Fsys.atapi and attempt to mount and access the hard disk
You may find that you need some parameters for the driver to make it work.
I’m quite skeptical of getting any SATA drive running for QNX 4, but it is worth
a try.
You may find that you need some special
The problem with sector by sector copy is that it will work only if the BIOS LBA logic of the other machine behaves the same. I have seens BIOSes/Fsys.atapi come up with different number of total sectors because of rounding error in the detected disk geometry. That is why for some people Ghost doesn’t work.
SATA for QNX4 works fine as long as the chipset proviced IDE emulation (most Intel Chipset). QSS has native SATA driver for QNX4 in the pipe
So we could be dealing with an issue in the way the BIOS handles the drive. That would explain why the ghosted drives work fine in other machines of the same type. (and yes, we have SATA drives running on 4.25 on the other machines ok)
Crud…I think we had an issue running more than one SATA drive at a time, though. I’ll check. There are other issues eating my lunch at the moment. (and my dinner and breakfast)
That being said I never saw any hardware issue caused Fsys.atapi to crash ( but Fsys.atapi doesn’t have as much mileage as Fsys.eide )
following webpage is somewhat misleading
qnx.com/developers/hardware_ … ry=FileSys
82801ER ICH5R (SATA) Fsys.atapi x86 QNX4 4.25
Released
82801ESB C-ICH (SATA) Fsys.atapi x86 QNX4 4.25
Released
82801FB ICH6 (SATA) Fsys.atapi x86 QNX4 4.25
Released
82801FBM ICH6M (SATA) Fsys.atapi x86 QNX4 4.25
Released
82801FR ICH6R (SATA) Fsys.atapi x86 QNX4 4.25
Released
I didn’t realise it was only supporting them in IDE emulation mode… I thought that as it had (SATA) that meant it would support it in Native mode. Could cause us some problems as it is hard to find modern PCs with IDE support today.
The Dell PCs we’re loading on have IDE emu for SATA. Dell calls it “compatible”, like they call every lower-performance option. But we’re running fine in regular SATA mode.
According to the latest post on the qnx4 newsgroups Fsys.atapi does support native SATA for some chipsets
[i]The QNX 4.25 RTOS Fsys.atapi Block Driver update available from the myQNX
download site does contain support for native SATA controllers. Please refer
to the release notes, linked below, for a list of supported SATA
controllers.
qnx.com/developers/articles/rel_1351_1.html
This list will be updated later this year as we port the additional SATA
support from QNX6.3.0 SP3 back to QNX4. While I do not have a firm date at
this time, it is intended that this port will be available later this year.
As well QSS will continue to back port QNX6 drivers to QNX4, specifically
targeting newer graphics (Photon drivers), Ethernet and hard disk
controllers.
Thanks,
Dave Nickerson
QNX Software Systems[/i]