Hello All,
I have a new QNX 4.5 installation and would like to know if it is
possible to install QNX 6.2 on the same partition as that of the QNX 4.5
installation ( I want to be able to use both OS’s but without creating a
new partition for QNX 6.2 installation ).
Please give me a brief procedure to go about it, as i am a newbie to this
OS.
Thanks in advance,
Nithin Dutt <ndutt@clemson.edu> wrote:
Hello All,
I have a new QNX 4.5 installation and would like to know if it is
possible to install QNX 6.2 on the same partition as that of the QNX 4.5
installation ( I want to be able to use both OS’s but without creating a
new partition for QNX 6.2 installation ).
In theory, I think you could do this. In practice, it will be tricky –
there are a lot of overlapping pathnames and other such conflicts.
Please give me a brief procedure to go about it, as i am a newbie to this
OS.
There is no brief procedure, sorry. This is like asking “can I install
Window 98 and Windows NT to the same partition and just run one or the
other at boot time.” Except, I think it actually is possible. 
As a newbie, I would strongly suggest NOT getting into this – this would
require an experienced user of QNX4 & QNX6 to setup and get working
properly.
An interesting thought, though. I’d attack it by have /.boot be one
OS and /.altboot be the other.
I’d probably do a QNX4 install, and copy the entire QNX4 tree to a
/qnx4 directory. I’d still have to have a /etc/config/sysinit.node in
the root path, since that will likely be looked for before I get anything
else going. In my boot image, I’d want to have sinit invoke /qnx4/bin/ksh
if I can…maybe a I could put a prefix in my image…not sure.
In the sysinit, I’d prefix /=/qnx4/, but have to explicitly run
/qnx4/bin/prefix, that should then get me up and running.
Oh ya, I’d also back up my /.boot, as the QNX6 install will overwrite
them. Once this is working, you can then clear out most of
/ – you’re going to need /etc/config/sysinit.$NODE, but I think
everything else SHOULD be able to go.
Then, do the QNX6 install, and HOPE it will install fine to the
existing dinited partition (haven’t tried that one), it may want
to (ugh) dinit the partition first. If I can do this, let the
QNX6 install run to completion. If it completes successfully,
then go and copy the QNX4 boot image back to /.altboot. (Or,
if I need a non-DMA IDE, copy the QNX4 image over /.boot.)
Now, I can (hopefully) select my image at boot time, and get
the correct OS up and running.
If QNX6 insists on diniting its partition, things get a bit messier.
I may have to use either a blank partition, or a spare hard-drive
during the install. (Since you don’t have a spare partition, it
would probably have to be a second hard drive borrowed from somewhere.)
Actually… if you can put in a second hard drive, that would be easier
than sharing a partition.
But, after the QNX4 install, once you have it successfully booting from
/qnx4, copy everything to the second hard drive. Do the QNX6 install,
after that has completed, copy everything back from the second hard
drive (/qnx4, /etc/config/sysinit.$NODE) and replace the appropriate
file of /.boot or /.altboot with your QNX4 boot image.
If you compare the cost of the hours it would take to do this, as
compared to the cost of a second hard drive, the 2nd hard drive starts
to look really in-expensive.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
David Gibbs <dagibbs@qnx.com> wrote:
There is no brief procedure, sorry. This is like asking “can I install
Window 98 and Windows NT to the same partition and just run one or the
other at boot time.” Except, I think it actually is possible. >As a newbie, I would strongly suggest NOT getting into this – this would
require an experienced user of QNX4 & QNX6 to setup and get working
properly.An interesting thought, though. I’d attack it by have /.boot be one
OS and /.altboot be the other.I’d probably do a QNX4 install, and copy the entire QNX4 tree to a
/qnx4 directory. I’d still have to have a /etc/config/sysinit.node in
the root path, since that will likely be looked for before I get anything
else going. In my boot image, I’d want to have sinit invoke /qnx4/bin/ksh
if I can…maybe a I could put a prefix in my image…not sure.
In the sysinit, I’d prefix /=/qnx4/, but have to explicitly run
/qnx4/bin/prefix, that should then get me up and running.
Oh ya, I’d also back up my /.boot, as the QNX6 install will overwrite
them. Once this is working, you can then clear out most of
/ – you’re going to need /etc/config/sysinit.$NODE, but I think
everything else SHOULD be able to go.Then, do the QNX6 install, and HOPE it will install fine to the
existing dinited partition (haven’t tried that one), it may want
to (ugh) dinit the partition first. If I can do this, let the
QNX6 install run to completion. If it completes successfully,
then go and copy the QNX4 boot image back to /.altboot. (Or,
if I need a non-DMA IDE, copy the QNX4 image over /.boot.)
Now, I can (hopefully) select my image at boot time, and get
the correct OS up and running.If QNX6 insists on diniting its partition, things get a bit messier.
I may have to use either a blank partition, or a spare hard-drive
during the install. (Since you don’t have a spare partition, it
would probably have to be a second hard drive borrowed from somewhere.)Actually… if you can put in a second hard drive, that would be easier
than sharing a partition.But, after the QNX4 install, once you have it successfully booting from
/qnx4, copy everything to the second hard drive. Do the QNX6 install,
after that has completed, copy everything back from the second hard
drive (/qnx4, /etc/config/sysinit.$NODE) and replace the appropriate
file of /.boot or /.altboot with your QNX4 boot image.If you compare the cost of the hours it would take to do this, as
compared to the cost of a second hard drive, the 2nd hard drive starts
to look really in-expensive.
Didn’t Neutrino v1.0 essentially do this?
Bill Caroselli <qtps@earthlink.net> wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
Didn’t Neutrino v1.0 essentially do this?
Well, kind of – but it was essentially a QNX4-hosted Neutrino target
development system – and when it booted Neutrino, it pointed /bin at
/x86/bin, and /usr/bin at /x86/usr/bin and so on. This was before we
had native/self-hosted QNX6 and before it tried to be a desk-top,
supplying a complete environment with its own self-hosted install.
Or, to put it another way, it was easier then. Now, the package
file system gets all involved, and well, you saw.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.