Oliver Sinden <email@example.com> wrote:
firstname.lastname@example.org> > wrote in message news:9l4vua$em9$> email@example.com> …
I used to have the same problem, turns out some low level disk program I’d
used had left the partition in a state which qnx refused to use. It
wasn’t too difficult to fix in the end… Have you conversion, partition,
etc. programs on that drive?
No, there is only one partition, a FAT32 parition, created with Fdisk from
the Win98 CD. It has not been altered in any way.
But to get the system to boot you’ll need to use a different bootfile,
which will be a little difficult for you to change. Someone should make
an emergency boot disk that people could use in this sort of situation.
To be honest, I was surprised not to find an option to diasble automounting
in the boot options. There are so many other options - if automounting is
sometimes cause for crashes/hangs, then surely it could be added to the list
of processes that could be prevented form running in the space bar menu?
Perhaps somethign for the next version >
In your case it wouldn’t help, because with a Windows installation,
the drive that qnx was installed on has to be mounted.
When you say ‘a little difficult’, is that an understatement? >
It’s difficult because you need to find out what’s going wrong rather than
just skipping that drive. The only way I can think of is using a boot
disk and then running debv-eide with all the verbose options on, so
hopefully it would tell you what’s going wrong. In my case, I was able to
track down the problem and patch the partition directly with spatch.
On the other hand, you could run a program that would check the FAT32
filesystem and tell you if it found anything even slightly wrong. There’s
a qnx chkdosfs program which might do that…
I’ve already got a boot disk I made for someone else, so it’s no trouble
putting the chkdosfs program on it. So you can email me and i’ll send it
to you if you want.