Shaun Jackman <email@example.com> wrote in article <firstname.lastname@example.org>…
Yes I see. The partition loader jumps to the OS loader, (the bootsector of
the partition), and it has to read and load the .boot which resides on that
partition. To do this it has to know which partition it’s loading. The
easiest way to do that is store that information in the OS loader itself. I
wonder if there’s some way for the partition loader to pass on this
information to the OS loader.
I saw resembling solutions, you could creat your custom couple of loaders with passing information.
But I think it’s bad idea. Currently in QNX, the partition and OS loaders are independed. So, you
can use another partition loader, more sophisticated LILO or ntldr for desktop system as an
example, or don’t use partition loader at all, if you don’t want partitioned drive in embedded
I think dloader should be as simple as ‘dd
if=/boot/sys/ipl-diskpc2 of=/dev/hd0t79 count=1’, but the fixup stage after
means it’s a little more complicated.
Yes, it’s more complicated. Because MBR (partition loader) includes data area to describe
partitions map and Bootsector (OS loader) includes data area to describe filesystem on partition.
Which tools are you speaking about?
Any number of tools. GNU’s parted for example does a great job of moving and
copying partitions. It could even just be dd though. If you do ‘dd
if=dev/hd0t79 of=/dev/hd1t77’, will you then be able to boot hd1t77
(assuming hd0t79 is a bootable QNX partition).
No. You have to repair the OS loader on /dev/hd1t77 partition, because it will look for .boot in
wrong place on wrong drive Doing this, the OS loader will output a lot of dots and hangs Be
carefull if you will try this experiment because highly probably the loader from hd1t77 will able
to find .boot on hd0t79 and you get the old system (you can get wrong assumption). If you remove
the drive hd0 it just hangs on a first dot, but some BIOSes highly sophistical deal with drive
numbers (in my system I tried to connect hard drive on first IDE channel, it was 0x80, also when I
reconnect the drive to second channel it was 0x80 anyway. And there was entirely another situation
when I played with two hard drives).
BTW, all tools for moving partitions should know enough about the file systems. That’s why
“Partition Magic” can’t move any unknowen partition. The reason is it must care about data area in
boot sectors and partitions records. Don’t trust if some tool says you “I’m able to move uknowen FS
where you want to”
This is nature of partitions, ‘dd’ can’t entirely substitute those highly intelligent programs
You could creat bootable image which runs that script and includes all
files, boot your systems
from that image, after executing of script, remove your installer and
This is a cyclic dependency > > The reason I’m doing this is to create a
bootable image. If to create a bootable image, I have to first create a
bootable image, then I’m really in trouble!
I meant bootable image on floppy, DOC, CD-ROM or any other media it depends on your hardware and
size of your system which you want to install, not a image file. I.e. bootable media. Sorry about
The assumption here is that the target node does not currently have QNX
installed. I might be booting with a rescue floppy, and dding the image from
a CDROM, or doing a netboot and pulling it from a server. Whatever process I
use, this is the ‘third party disk imaging software’ I’m speaking about.
Yes, I meant exactly this
BTW, I guess you could use ‘skip=1’ and ‘seek=1’ options in dd command to
prevent overwriting the
dinit /dev/hd0t79 (make partition bootable (or ‘dloader’?), then)
dd if=root.qfs of=/dev/hd0t79 bs=512 skip=1 seek=1
I expect that would work well too. It has the same effect as this:
dd if=root.qfs of=/dev/hd0t79
dloader /dev/hd0t79 pc2
In case above you creat partition and transfer your system, but prevent the bootsector for
overwriting. You don’t need dloader. BTW I never used dloader, is it similar ‘dinit -r’?
In case below you creat partition (it’s supposed since you already have /dev/hd0t79) and transfer
the custom system and after that you repair the bootsector.
Yes, effect should be the same.
which is what I ended up using in the end. This implies though that the
target already has dloader installed on it, which is not true (since the
node is not yet running QNX). Unless of course I use a QNX rescue floppy to
do the imaging. That’s actually probably the best way to go about this: a
QNX rescue floppy that pulls the image from CD or the net, and installs it
onto a fresh hard disk.
Heh, regardless of my poor english you catch the idea
ed1k at ukr dot net