What exactly is an image? I know it is decompressed at boot-up and appears
as a small filesystem. Does it run in RAM or from the flash device (DOC in
my case). The literature seems to stress keeping the image file small and I
am wondering why. If the image filesystem resides in RAM after boot-up then
I see why small size is important.
If that is the case I guess I want partition my DOC so that I have the boot
image stored in one partion with just enough to get the system up and then
mount the other partion to find my executables and application code.
“Chris Rose” <rose_chris@excite.com> wrote in message
news:akpabo$7ma$1@inn.qnx.com…
What exactly is an image? I know it is decompressed at boot-up and appears
as a small filesystem. Does it run in RAM or from the flash device (DOC in
my case). The literature seems to stress keeping the image file small and
I
am wondering why. If the image filesystem resides in RAM after boot-up
then
I see why small size is important.
Yes it’s in RAM. In some cases it’s possible to have it in FLASH (eXecuting
In Place), but that’s usually done with FLASH mapped linearely in memory
(thus not applicable for DOC)
If that is the case I guess I want partition my DOC so that I have the
boot
image stored in one partion with just enough to get the system up and then
mount the other partion to find my executables and application code.
That’s ok, but why have two partitions?
I’ve done something similar to this in a single partition on an IDE disk.
If anyone has any advice about how to make this more elegant I’d sure like
to hear it.
I have a boot image (.boot) file with a minimal operating system in it, and
then have a .qfs file which I mount in my boot script that contains the rest
of the files for my system. This is great from a code maintenace standpoint
since you have only two files max that your service personnel must handle (a
boot img and a .qfs image). I’ve found a couple of problems with this
unfortunately. 1) if you mount the .qfs file on / as I do it has the effect
of expanding your filesystem with its contents (good), but you can no longer
write files into your system (bad) since the drive space that you have
available is now constrained to the unused space in your .qfs file and not
the available IDE drive space. This really hurts. 2) you cannot umount the
mounted .qfs file from / since it’s perpetually in use so the only way to
change your .qfs file image is to .altboot such that the .qfs isn’t mounted
and then overwrite the file. This also hurts.
Jason Farque
“Mario Charest” postmaster@127.0.0.1 wrote in message
news:aktqhg$dfs$1@inn.qnx.com…
“Chris Rose” <> rose_chris@excite.com> > wrote in message
news:akpabo$7ma$> 1@inn.qnx.com> …
What exactly is an image? I know it is decompressed at boot-up and
appears
as a small filesystem. Does it run in RAM or from the flash device (DOC
in
my case). The literature seems to stress keeping the image file small
and
I
am wondering why. If the image filesystem resides in RAM after boot-up
then
I see why small size is important.Yes it’s in RAM. In some cases it’s possible to have it in FLASH
(eXecuting
In Place), but that’s usually done with FLASH mapped linearely in memory
(thus not applicable for DOC)If that is the case I guess I want partition my DOC so that I have the
boot
image stored in one partion with just enough to get the system up and
then
mount the other partion to find my executables and application code.That’s ok, but why have two partitions?
\
jasonf@pigging.com sed in <alocps$sn9$1@inn.qnx.com>
unfortunately. 1) if you mount the .qfs file on / as I do it has the effect
of expanding your filesystem with its contents (good), but you can no longer
write files into your system (bad) since the drive space that you have
available is now constrained to the unused space in your .qfs file and not
the available IDE drive space. This really hurts.
Using a real partition will be also constrained to the available
partition space. watzdadifference?
- you cannot umount the
mounted .qfs file from / since it’s perpetually in use so the only way to
change your .qfs file image is to .altboot such that the .qfs isn’t mounted
and then overwrite the file. This also hurts.
If you’re using “diskboot” as the final hook,
you can drop in the new qfs into /boot/fs/qnxbase.qf0
and diskboot will automatically replace it to qnxbase.qfs and
use it. (Undocumented?)
–
kabe
If you’re using “diskboot” as the final hook,
Oof You said you mount it in boot script, not diskboot.
Well you may have to .altboot then.
Or, whip up a small C program which only does
if [ -r replacement.qfs ]; then
mv replacement.qfs installed.qfs
fi
and fire it up just before mount in the bootscript.
(is plain “mv” command sufficient for this?)
You can’t do ifs/predicates/loops in boot script so
you need some kind of a binary program.
kabe
I chose to test for a file called ‘nomount’ at a known location from my
bootscript and not mount the qfs if the file is present. So for me ‘touch
/updates/nomount’ and shutdown get the job done, but I can’t help but wish
that this were more convenient.
Jason
<kabe@sra-tohoku.co.jp> wrote in message news:am0h96$odp$2@inn.qnx.com…
If you’re using “diskboot” as the final hook,
Oof You said you mount it in boot script, not diskboot.
Well you may have to .altboot then.
Or, whip up a small C program which only does
if [ -r replacement.qfs ]; then
mv replacement.qfs installed.qfs
fi
and fire it up just before mount in the bootscript.
(is plain “mv” command sufficient for this?)You can’t do ifs/predicates/loops in boot script so
you need some kind of a binary program.kabe
Using a real partition will be also constrained to the available
partition space. watzdadifference?
Partitions don’t overlap one another on the disk, a mounted file does
overlap and take precedence over a partition. If I have a 40GB IDE drive
with a single partition and 37MB free and I mount a 1MB file with 200k free
on /, I now have 200k free on my drive and I can’t umount the file without
…altbooting or coming up with some other bootime contrivance (see my next
post).
If you’re using “diskboot” as the final hook,
you can drop in the new qfs into /boot/fs/qnxbase.qf0
and diskboot will automatically replace it to qnxbase.qfs and
use it. (Undocumented?)–
kabe
This I’m unaware of, I’ll check it out.
Jason