Mounting files as file systems

QNX Newsgroups (Archives) qdn.public.qnxrtp.embedded
1

I have a miniature x86 based computer with a solid state IDE drive. This
computer can be the brain of several different products that my company
builds.

What I’d like to do is create a smallish boot image with just the necessary
boot files in it that I can put onto every computer and then place into
inventory. When the techs pull the bootable computers out of inventory to
plug into whatever system they are building I would like for them to be able
to boot the system and then copy a single file over the network to the IDE
drive that then “customizes” or gives a personality to that computer to
perform the proper task. This secondary image would contain my
task-specific programs and any other necessary files and would be mounted by
the boot image. So one boot-image plus one task-specific image would yield
a fully functional system without the potential error of copying whole
directory structures. Managing versions would be vastly easier, verifying
that the proper image was installed would be simple and the onus of insuring
that the image is correct is on me (where it belongs) and not my techs.

I’ve done some searching and have read up on mkifs, mkefs, etc. and what it
appears that I need to do to accomplish my task is to create a file (perhaps
with dd) that is large enough to accomodate my programs, data and necessary
files (say…5 megabytes). Then dinit this file and mount it. Once mounted
I can operate within this file as part of my development machines directory
structure, updating and manipulating its contents as I see fit. I then
umount the image and copy it to my embedded system, where upon boot the
startup script mounts the image…

I have mounted a few little files on my dev machine and messed around with
them and it seems like this scheme will work.

Question is: what am i missing? It is harder or easier than what I’ve
described?

Thanks,

Jason Farque

2

Hello Jason

What you want to do is easy. Option #1, can your solid state IDE drive be
partitioned?

If so, then the ‘file’ you are talking about if simply the block special
file that is that (second) partition. Your boot partition would not need
anything except the boot image.

If you are unable to partition the solid state drive then I believe QNX6
does have a utility that will ‘interpret’ a regular file as a QNX file
system. I.e. a filesystem within a file system. You simply give it the
name of the regular file and the name of the mount point of the new
filesystem.

“Jason Farque” <jasonf@pigging.com> wrote in message
news:aic9ij$nes$1@inn.qnx.com…

I have a miniature x86 based computer with a solid state IDE drive. This
computer can be the brain of several different products that my company
builds.

What I’d like to do is create a smallish boot image with just the
necessary
boot files in it that I can put onto every computer and then place into
inventory. When the techs pull the bootable computers out of inventory to
plug into whatever system they are building I would like for them to be
able
to boot the system and then copy a single file over the network to the IDE
drive that then “customizes” or gives a personality to that computer to
perform the proper task. This secondary image would contain my
task-specific programs and any other necessary files and would be mounted
by
the boot image. So one boot-image plus one task-specific image would
yield
a fully functional system without the potential error of copying whole
directory structures. Managing versions would be vastly easier, verifying
that the proper image was installed would be simple and the onus of
insuring
that the image is correct is on me (where it belongs) and not my techs.

I’ve done some searching and have read up on mkifs, mkefs, etc. and what
it
appears that I need to do to accomplish my task is to create a file
(perhaps
with dd) that is large enough to accomodate my programs, data and
necessary
files (say…5 megabytes). Then dinit this file and mount it. Once
mounted
I can operate within this file as part of my development machines
directory
structure, updating and manipulating its contents as I see fit. I then
umount the image and copy it to my embedded system, where upon boot the
startup script mounts the image…

I have mounted a few little files on my dev machine and messed around with
them and it seems like this scheme will work.

Question is: what am i missing? It is harder or easier than what I’ve
described?

Thanks,

Jason Farque

3

Bill Caroselli (Q-TPS) <QTPS@EarthLink.net> wrote in article <aicbtm$p5q$1@inn.qnx.com>…

Hello Jason

What you want to do is easy. Option #1, can your solid state IDE drive be
partitioned?

If so, then the ‘file’ you are talking about if simply the block special
file that is that (second) partition. Your boot partition would not need
anything except the boot image.

It’s good idea and it is very clear and understandable for another person who might maintenance the
system. But you have a choice :slight_smile:

If you are unable to partition the solid state drive then I believe QNX6
does have a utility that will ‘interpret’ a regular file as a QNX file
system. I.e. a filesystem within a file system. You simply give it the
name of the regular file and the name of the mount point of the new
filesystem.

There is no any special utility, AFAIK.
creat a 4 Mb file

dd if=/dev/zero of=/systemX.qfs bs=1024 count=4096

creat a QNX file system inside the file

dinit /systemX.qfs

mount this file system

mount /systemX.qfs /systemX

work with files under /systemX/ like it is normal filesystem space :wink:
Note: in working system you could do read-only mounting if don’t need any writes here (protect
your binaries and creat dataX.qfs for writting to or use rest of disk space in ordinary way :slight_smile:),
…
grow up the image filesystem to 6 Mb for some reason in developing

umount /systemX

dd if=/dev/zero of=/systemX.qfs bs=1024 seek=4096 count=2048

dinit -r /systemX.qfs

chkfsys -u /systemX.qfs

fix here all errors

mount /systemX.qfs /systemX

…

Cheers

Eduard.
ed1k at ukr dot net





“Jason Farque” <> jasonf@pigging.com> > wrote in message
news:aic9ij$nes$> 1@inn.qnx.com> …
I have a miniature x86 based computer with a solid state IDE drive. This
computer can be the brain of several different products that my company
builds.

What I’d like to do is create a smallish boot image with just the
necessary
boot files in it that I can put onto every computer and then place into
inventory. When the techs pull the bootable computers out of inventory to
plug into whatever system they are building I would like for them to be
able
to boot the system and then copy a single file over the network to the IDE
drive that then “customizes” or gives a personality to that computer to
perform the proper task. This secondary image would contain my
task-specific programs and any other necessary files and would be mounted
by
the boot image. So one boot-image plus one task-specific image would
yield
a fully functional system without the potential error of copying whole
directory structures. Managing versions would be vastly easier, verifying
that the proper image was installed would be simple and the onus of
insuring
that the image is correct is on me (where it belongs) and not my techs.

I’ve done some searching and have read up on mkifs, mkefs, etc. and what
it
appears that I need to do to accomplish my task is to create a file
(perhaps
with dd) that is large enough to accomodate my programs, data and
necessary
files (say…5 megabytes). Then dinit this file and mount it. Once
mounted
I can operate within this file as part of my development machines
directory
structure, updating and manipulating its contents as I see fit. I then
umount the image and copy it to my embedded system, where upon boot the
startup script mounts the image…

I have mounted a few little files on my dev machine and messed around with
them and it seems like this scheme will work.

Question is: what am i missing? It is harder or easier than what I’ve
described?

Thanks,

Jason Farque


\

4

Well sure it can be partitioned but how do you get a block special file into
a non-partitioned space? And is that something that a computer challenged
assembly tech can do? I prefer a solution with minimal hand-holding.

My IDE flash drive is 32MB, so I plan on partitioning it as a single 32MB
partition, have a boot image of say 800k with basic utils such as device
drivers, ls, cp, fdisk, dinit, etc. in it. Once that’s booted up the techs
will simply copy the mountable file onto the 32M drive in a directory off
the root called ‘system’ or somesuch and reboot. This method can be done
through my SAMBA server from a Windows machine even.

One thing I’d like but haven’t given a lot of thought to yet is the ability
to name the mountable file with version numbers such as “sysfile-1.1.2” and
have the boot script be flexible enough to mount it even if the version
incremented to “sysfile-1.2.0” for instance. This would make keeping the
various versions of the system straight a bit simpler on the deployment
machines, but it’s not crucial to me as this can be achieved in other ways.

Jason

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aicbtm$p5q$1@inn.qnx.com…

Hello Jason

What you want to do is easy. Option #1, can your solid state IDE drive be
partitioned?

If so, then the ‘file’ you are talking about if simply the block special
file that is that (second) partition. Your boot partition would not need
anything except the boot image.

If you are unable to partition the solid state drive then I believe QNX6
does have a utility that will ‘interpret’ a regular file as a QNX file
system. I.e. a filesystem within a file system. You simply give it the
name of the regular file and the name of the mount point of the new
filesystem.

“Jason Farque” <> jasonf@pigging.com> > wrote in message
news:aic9ij$nes$> 1@inn.qnx.com> …
I have a miniature x86 based computer with a solid state IDE drive.
This
computer can be the brain of several different products that my company
builds.

What I’d like to do is create a smallish boot image with just the
necessary
boot files in it that I can put onto every computer and then place into
inventory. When the techs pull the bootable computers out of inventory
to
plug into whatever system they are building I would like for them to be
able
to boot the system and then copy a single file over the network to the
IDE
drive that then “customizes” or gives a personality to that computer to
perform the proper task. This secondary image would contain my
task-specific programs and any other necessary files and would be
mounted
by
the boot image. So one boot-image plus one task-specific image would
yield
a fully functional system without the potential error of copying whole
directory structures. Managing versions would be vastly easier,
verifying
that the proper image was installed would be simple and the onus of
insuring
that the image is correct is on me (where it belongs) and not my techs.

I’ve done some searching and have read up on mkifs, mkefs, etc. and what
it
appears that I need to do to accomplish my task is to create a file
(perhaps
with dd) that is large enough to accomodate my programs, data and
necessary
files (say…5 megabytes). Then dinit this file and mount it. Once
mounted
I can operate within this file as part of my development machines
directory
structure, updating and manipulating its contents as I see fit. I then
umount the image and copy it to my embedded system, where upon boot the
startup script mounts the image…

I have mounted a few little files on my dev machine and messed around
with
them and it seems like this scheme will work.

Question is: what am i missing? It is harder or easier than what I’ve
described?

Thanks,

Jason Farque

\

5

ed1k,

dd if=/dev/zero of=/systemX.qfs bs=1024 count=4096

dinit /systemX.qfs

mount /systemX.qfs /systemX

Yes this is exactly what I meant. Works just fine so far.

It’s good idea and it is very clear and understandable for another person
who might maintenance the
system. But you have a choice > :slight_smile:

Yes I like it because it’s clear and obvious how to manipulate the system
from a high level perspective. Copying directory structures and/or
manipulating individual files is very tedious and extremely error prone.
Configuring this system won’t be fool-proof but it will be… uhh…
fool-resistant.

Jason

…
grow up the image filesystem to 6 Mb for some reason in developing

umount /systemX

dd if=/dev/zero of=/systemX.qfs bs=1024 seek=4096 count=2048

dinit -r /systemX.qfs

chkfsys -u /systemX.qfs

fix here all errors

mount /systemX.qfs /systemX

…

Cheers

Eduard.
ed1k at ukr dot net

6

“ed1k” <ed1k@spamerstrap.com> wrote in message
news:01c239fb$b458fae0$106fa8c0@ED1K…

Bill Caroselli (Q-TPS) <> QTPS@EarthLink.net> > wrote in article
aicbtm$p5q$> 1@inn.qnx.com> >…

There is no any special utility, AFAIK.
creat a 4 Mb file

dd if=/dev/zero of=/systemX.qfs bs=1024 count=4096

creat a QNX file system inside the file

dinit /systemX.qfs

WARNING! Don’t try this under QNX4. dinit will reinitialize the whole
partition that file systemX.qfs is on.

7

6.2.0 PE here, but thanks for the warning.

Jason Farque

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:aied1a$aub$1@inn.qnx.com…

“ed1k” <> ed1k@spamerstrap.com> > wrote in message
news:01c239fb$b458fae0$106fa8c0@ED1K…
Bill Caroselli (Q-TPS) <> QTPS@EarthLink.net> > wrote in article
aicbtm$p5q$> 1@inn.qnx.com> >…

There is no any special utility, AFAIK.
creat a 4 Mb file

dd if=/dev/zero of=/systemX.qfs bs=1024 count=4096

creat a QNX file system inside the file

dinit /systemX.qfs

WARNING! Don’t try this under QNX4. dinit will reinitialize the whole
partition that file systemX.qfs is on.