i’m about to implement a startroutine for a qnx-host.
I got problems if qnx shuts down by powerloss or something like that,
so i included into my startscript to check the filesystem before doing
something else, BUT:
everything work fine on my development pc, but on the target pc with that
little compactFlash card as hd it went bad:
After running chkfsys (it terminates without any errors (exept the fixable
problems on disk))
no command is accepted any longer from qnx. Everything is commented with:
sh: ls: no such device or address (for example when calling ls)
? I’m hanging! Does someone know what i might try?
Is this a problem of compactFlash, or is my qnx-installation bad, or …
what could it be?
There are some very potential problems if you run chkfsys after the
filesystem has been mounted. I found out that the safest way is to run
chkfsys from the kernel boot script before any filesystems are mounted.
i’m about to implement a startroutine for a qnx-host.
I got problems if qnx shuts down by powerloss or something like that,
so i included into my startscript to check the filesystem before doing
something else, BUT:
everything work fine on my development pc, but on the target pc with that
little compactFlash card as hd it went bad:
After running chkfsys (it terminates without any errors (exept the fixable
problems on disk))
no command is accepted any longer from qnx. Everything is commented with:
sh: ls: no such device or address (for example when calling ls)
? I’m hanging! Does someone know what i might try?
Is this a problem of compactFlash, or is my qnx-installation bad, or …
what could it be?
There are some very potential problems if you run chkfsys after the
filesystem has been mounted. I found out that the safest way is to run
chkfsys from the kernel boot script before any filesystems are mounted.
Jens
oh!
OK, i will try this!
Actually i start it on mounted filesystems!
i’m about to implement a startroutine for a qnx-host.
I got problems if qnx shuts down by powerloss or something like that,
so i included into my startscript to check the filesystem before doing
something else, BUT:
everything work fine on my development pc, but on the target pc with
that
little compactFlash card as hd it went bad:
After running chkfsys (it terminates without any errors (exept the
fixable
problems on disk))
no command is accepted any longer from qnx. Everything is commented
with:
sh: ls: no such device or address (for example when calling ls)
? I’m hanging! Does someone know what i might try?
Is this a problem of compactFlash, or is my qnx-installation bad, or …
what could it be?
I have experienced something similiar with CF. After some heavy access to CF
I couldn’t access files on CF anymore. From my experience it seems that the
problem manifests itself sooner with some brands of CF, with other brands
later.
I have written ‘fsysinfo’ program for QNX6, sometimes it reports physical IO
errors before CF card stops working. But after reset I can’t find any
problems on the given card with dcheck (QNX6) or scandisk (MS).
i’m about to implement a startroutine for a qnx-host.
I got problems if qnx shuts down by powerloss or something like that,
so i included into my startscript to check the filesystem before doing
something else, BUT:
everything work fine on my development pc, but on the target pc with that
little compactFlash card as hd it went bad:
After running chkfsys (it terminates without any errors (exept the fixable
problems on disk))
no command is accepted any longer from qnx. Everything is commented with:
sh: ls: no such device or address (for example when calling ls)
? I’m hanging! Does someone know what i might try?
Is this a problem of compactFlash, or is my qnx-installation bad, or …
what could it be?
There are some very potential problems if you run chkfsys after the
filesystem has been mounted. I found out that the safest way is to run
chkfsys from the kernel boot script before any filesystems are mounted.
Jens
UPS!
Can you tell me how i can start chkfsys before fs are mounted?
Docs don’t tell me something!
And if i try it in /etc/rc.d/rc.sysinit
it fails so that the boot fails completly now!
There are some very potential problems if you run chkfsys after the
filesystem has been mounted. I found out that the safest way is to run
chkfsys from the kernel boot script before any filesystems are mounted.
Jens
UPS!
Can you tell me how i can start chkfsys before fs are mounted?
Docs don’t tell me something!
And if i try it in /etc/rc.d/rc.sysinit
it fails so that the boot fails completly now!
I have experienced something similiar with CF. After some heavy access to CF
I couldn’t access files on CF anymore. From my experience it seems that the
problem manifests itself sooner with some brands of CF, with other brands
later.
I have written ‘fsysinfo’ program for QNX6, sometimes it reports physical IO
errors before CF card stops working. But after reset I can’t find any
problems on the given card with dcheck (QNX6) or scandisk (MS).
There were some problems with CF in 6.1a, 6.2 fixes some mapping errors
with flash devices. Can’t recall the exact problems, and could not find the
release notes for 6.2. Anyone know where they are?
I have had big problems when running chkfsys in any of the /etc/rc.d/*
files. The only way I have found that is safe is to build a dedicated kernel
image, where chkfsys is run before any start up scripts are run.
The way I ended up doing above was to tell diskboot not to run sysinit with
the -s option.
There are some very potential problems if you run chkfsys after the
filesystem has been mounted. I found out that the safest way is to run
chkfsys from the kernel boot script before any filesystems are mounted.
Jens
UPS!
Can you tell me how i can start chkfsys before fs are mounted?
Docs don’t tell me something!
And if i try it in /etc/rc.d/rc.sysinit
it fails so that the boot fails completly now!
I have had big problems when running chkfsys in any of the /etc/rc.d/*
files. The only way I have found that is safe is to build a dedicated kernel
image, where chkfsys is run before any start up scripts are run.
The way I ended up doing above was to tell diskboot not to run sysinit with
the -s option.
The problem running chkfsys from one of the start up scripts is that you are
repairing a file system, from which you also are executing a script from.
So, when you run it at the command prompt, you are running it
from a shell that was executed from the disk. On QNX4 the
chkfsys would not run if there were any files open, not sure if
it is the same in QNX6 or not, but that would be my guess.
Anyway, all of the developement machines here run chkfsys in
rc.d/rc.local, and they clean up after smbd’s log and lock
files. The one embedded machine that is still running the
enumerators has it in there as well.
I glad to hear that it is currently working for you, but I used do the same
thing and I would often end up with problems script execution problems.
I think the difference between running chkfsys from the shell which is on
the file system that you are cleaning up, and running chkfsys from a
script - is that the system during script execution has a open file to the
script, and if that section of the file system where the script is located
gets moved around - I think your script execution fails. At least that is my
theory on why you sometimes end up with problems when executing chkfsys in a
script - perhaps someone from QSSL can correct me if I am wrong.
Jens H Jorgensen <> jhj@remove-nospam-videk.com> > wrote:
I have had big problems when running chkfsys in any of the /etc/rc.d/*
files. The only way I have found that is safe is to build a dedicated
kernel
image, where chkfsys is run before any start up scripts are run.
The way I ended up doing above was to tell diskboot not to run sysinit
with
the -s option.
The problem running chkfsys from one of the start up scripts is that you
are
repairing a file system, from which you also are executing a script
from.
So, when you run it at the command prompt, you are running it
from a shell that was executed from the disk. On QNX4 the
chkfsys would not run if there were any files open, not sure if
it is the same in QNX6 or not, but that would be my guess.
Anyway, all of the developement machines here run chkfsys in
rc.d/rc.local, and they clean up after smbd’s log and lock
files. The one embedded machine that is still running the
enumerators has it in there as well.
I glad to hear that it is currently working for you, but I used
do the same thing and I would often end up with problems script
execution problems.
I think the difference between running chkfsys from the shell
which is on the file system that you are cleaning up, and
running chkfsys from a script - is that the system during
script execution has a open file to the script, and if that
section of the file system where the script is located gets
moved around - I think your script execution fails. At least
that is my theory on why you sometimes end up with problems
when executing chkfsys in a script - perhaps someone from QSSL
can correct me if I am wrong.
Honestly, I can’t see where having a file open for read only
should cause a problem with the chkfsys.
Just tried it on my 6.1a box, had a file open for write and
chkfsys did not complain. And none of my open files had any
problems, at least 2 elvis processes running with no effect. I
am sure if I increased the size then I would get a bitmap error.
chkfsys, will just scan the raw partition for errors.
Are you running chkfsys in the start or the end of rc.local?
If you do at the last thing then try to move it to the beginning.
What I think is happing is that the shell is executing the script by reading
line by line from the script with a file pointer point to a certain area of
the file system. If then chkfsys moves that section of the file system the
file pointer is going to point to the wrong place on the file system and
your script execution is going to try to execute what ever the file pointer
is pointing at.
The problem I was seeing in my rc.local was that the script execution would
abort/error out right after chkfsys was executed. So for instance:
rc.local:
#stuff before chkfsys
…
chkfsys -qPr #stuff after chkfsys
…
rc.local would never make it to “stuff after chkfsys”
I glad to hear that it is currently working for you, but I used
do the same thing and I would often end up with problems script
execution problems.
I think the difference between running chkfsys from the shell
which is on the file system that you are cleaning up, and
running chkfsys from a script - is that the system during
script execution has a open file to the script, and if that
section of the file system where the script is located gets
moved around - I think your script execution fails. At least
that is my theory on why you sometimes end up with problems
when executing chkfsys in a script - perhaps someone from QSSL
can correct me if I am wrong.
Honestly, I can’t see where having a file open for read only
should cause a problem with the chkfsys.
Just tried it on my 6.1a box, had a file open for write and
chkfsys did not complain. And none of my open files had any
problems, at least 2 elvis processes running with no effect. I
am sure if I increased the size then I would get a bitmap error.
chkfsys, will just scan the raw partition for errors.
Are you running chkfsys in the start or the end of rc.local?
If you do at the last thing then try to move it to the beginning.
What I think is happing is that the shell is executing the script by
reading
line by line from the script with a file pointer point to a certain area
of
the file system. If then chkfsys moves that section of the file system the
file pointer is going to point to the wrong place on the file system and
your script execution is going to try to execute what ever the file
pointer
is pointing at.
The problem I was seeing in my rc.local was that the script execution
would
abort/error out right after chkfsys was executed. So for instance:
rc.local:
#stuff before chkfsys
…
chkfsys -qPr #stuff after chkfsys
…
rc.local would never make it to “stuff after chkfsys”
I glad to hear that it is currently working for you, but I used
do the same thing and I would often end up with problems script
execution problems.
I think the difference between running chkfsys from the shell
which is on the file system that you are cleaning up, and
running chkfsys from a script - is that the system during
script execution has a open file to the script, and if that
section of the file system where the script is located gets
moved around - I think your script execution fails. At least
that is my theory on why you sometimes end up with problems
when executing chkfsys in a script - perhaps someone from QSSL
can correct me if I am wrong.
Honestly, I can’t see where having a file open for read only
should cause a problem with the chkfsys.
Just tried it on my 6.1a box, had a file open for write and
chkfsys did not complain. And none of my open files had any
problems, at least 2 elvis processes running with no effect. I
am sure if I increased the size then I would get a bitmap error.
chkfsys, will just scan the raw partition for errors.