While testing our system, we encounter a strange problem where all the files
are suddenly not accessable, including all the commands in /bin. The error
showed on the screen when we run cd is:
sh: cd: /root - no such file or directory
sh: pwd: can’t get current directory - no such file or directory
The only command that is runable is the csh commands, such as set, export,
etc. We suspect there is a problem with file system or somehow its memory is
corrupted. But we can’t do anything else during that situation because all
of the bin programs are not accessable. Has anybody encountered the same
problem here? We appreciate for any suggestion on what we should do to
detect where the problem is. This problem is intermitent and unproduceable,
thus we leave the machine as is until we can find any help. We still have a
couple of consoles which accept command line (only csh commands). We use
text mode only. Thanks.
Start swapping either hardware or software depending on which you think is more likely.
Having a second prototype system to verify the hardware is always a sensible move.
If the software had been running stable up till then then target the hardware. I’d start by swapping the HDD then the mobo.
If the software is in development then you might have to start chopping it up to isolate things while keeping in mind that the hardware can still be the cause. I’d start by building a separate test case that doesn’t do much other than stress the function in question. And doesn’t use any recent additions to the main code base or only uses one in particular.
Evan
We had the same problem on another machine, same brand but different model.
“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:ddj9hc$k49$1@inn.qnx.com…
Start swapping either hardware or software depending on which you think is
more likely.Having a second prototype system to verify the hardware is always a
sensible move.If the software had been running stable up till then then target the
hardware. I’d start by swapping the HDD then the mobo.If the software is in development then you might have to start chopping it
up to isolate things while keeping in mind that the hardware can still be
the cause. I’d start by building a separate test case that doesn’t do
much other than stress the function in question. And doesn’t use any
recent additions to the main code base or only uses one in particular.
Evan
JS wrote:
While testing our system, we encounter a strange problem where all the files
are suddenly not accessable, including all the commands in /bin. The error
showed on the screen when we run cd is:
sh: cd: /root - no such file or directory
sh: pwd: can’t get current directory - no such file or directory
The behaviour you’ve described is exactly what would happen if all the system files are mounted on fs-pkg and fs-pkg was no longer able to function.
If I’m reading all your hints correctly from other thread, you are using fs-pkg with it managing the bulk of files including /bin/* in a similar setup to the QNX Momentics 6.2.x default install. And you decided slaying fs-pkg was a good thing to do?!
Those files have to be managed by another filesystem, typically fs-qnx4, if you don’t want to use fs-pkg. To do this you have to individually copy all the needed files onto the boot partition instead of them all being stuffed inside of qnxbase.qfs
Evan
You are right. When we install the O/S, we use mostly the default settings
because “we thought that is the most commonly used setting and should give
us the less problem”. Unfortunately that is not the way the QNX thought. Any
idea why fs-pkg becomes malfunction? Is it a bug? Will that happen to
fs-qnx4?
“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:ddsa3o$607$1@inn.qnx.com…
JS wrote:
While testing our system, we encounter a strange problem where all the
files are suddenly not accessable, including all the commands in /bin.
The error showed on the screen when we run cd is:
sh: cd: /root - no such file or directory
sh: pwd: can’t get current directory - no such file or directory
The behaviour you’ve described is exactly what would happen if all the
system files are mounted on fs-pkg and fs-pkg was no longer able to
function.If I’m reading all your hints correctly from other thread, you are using
fs-pkg with it managing the bulk of files including /bin/* in a similar
setup to the QNX Momentics 6.2.x default install. And you decided slaying
fs-pkg was a good thing to do?!Those files have to be managed by another filesystem, typically fs-qnx4,
if you don’t want to use fs-pkg. To do this you have to individually copy
all the needed files onto the boot partition instead of them all being
stuffed inside of qnxbase.qfs
Evan
JS wrote:
idea why fs-pkg becomes malfunction? Is it a bug? Will that happen to
fs-qnx4?
You could try: chkfsys /
Is this the same problem as the “O/S hang?” thread?
Evan
We did run chkfsys / after reboot the system and recover the broken link.
We are not sure if this is the same problem or not, because in this case it
didn’t hang, we just couldn’t do anything with the filesystem.
“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:de1b7n$qe8$1@inn.qnx.com…
JS wrote:
idea why fs-pkg becomes malfunction? Is it a bug? Will that happen to
fs-qnx4?
You could try: chkfsys /Is this the same problem as the “O/S hang?” thread?
Evan