Hello John,
Thank you for answering… it helps me (and I hope an others) to understand things right 
John Garvey <jgarvey@qnx.com> wrote in article <ak3qb4$brk$1@nntp.qnx.com>…
ed1k <> ed1k@spamerstrap.com> > wrote:
it was at offset 0x11 in QNX6.1.
Yep, my mistake, was looking at the wrong structure and confusingly my
t79 partition is at offset xxxxxx80 sectors :-/
Ok, but why this information (structure of bootsector) isn’t documented anywhere? Or point me,
please, the appropriate document on the web/QNX6NCsystem. Such information is well knowen for FAT
and, I believe, other file systems. It might clear up the things and help to understand what’s
wrong if there is problem with booting.
Does dinit really write 0x81 while initializing second hard drive?
Wishful thinking, I see it only writes 0x00 or 0x80 (based on guesswork
or command-line overrides). Mind you, I don’t think there is a way for it
to know, devb-eide doesn’t export information on target/path/lun (which
may provide a means to make a better guess).
But devb-eide uses this information for naming:
dinit (dloader) [options] /dev/fd0 means drive# 0x00
dinit (dloader) [options] /dev/fd1 means drive# 0x01
dinit (dloader) [options] /dev/hd0* means drive# 0x80
dinit (dloader) [options] /dev/hd1* means drive# 0x81
No? Also I believe it’s a good idea to overwrite this guessing by some option of dinit/dloader.
But then again, a lot of
people (recklessly, IMHO) seem to set up a bootable drive as a secondary
on an existing system with the express intent of making it the primary
on a new system, so automatic guessing would cause as much / more trouble
than it would solve … > 
Yes, I agree. I suppose option (see above) will good for such trick. And they must use that option,
it should be well documented. But I don’t understand how does work the primary loader which
supports loading from different drives… Beat me, I thought it reads MBR of second drive and
passes control to that startup, of course, if second drive is selected for booting… Then MBR on
second drive looks for active partition, looads bootsector to memory and just passes control to
that bootsector. But it’s wrong… Ok, the primary loader can itself parse through partition table
of second drive’s MBR, then load selected bootsector to memory and jumps into it. But it’s also
wrong… In this way system will hang because the bootsector includes wrong drive number… What
I’m missing ?
I have seen a lot of reports on newsgroups about the next trouble: during
installation of QNX (incl.6.2) onto second hard drive the resulting drive
number in loader (bootsector) is 0x80 (it’s unexpected by any 3rd
multisystem loader)…
The secondary loader? You’re saying that some things do actually expect
0x81?
Yes, look at
From: Flynn <flynnieboySPAMISLAME@yahoo.com>
Newsgroups: qdn.public.qnxrtp.installation
Subject: Dual boot Win2000/QNX 6.2
Date: 13 Aug 2002 01:02:03 GMT
X-Trace: inn.qnx.com 1029200523 9870 217.128.131.133 (13 Aug 2002 01:02:03 GMT)
NNTP-Posting-Date: 13 Aug 2002 01:02:03 GMT
User-Agent: Xnews/5.04.25
Xref: inn.qnx.com qdn.public.qnxrtp.installation:5325
Discussed there tool ‘bootpart’ allows to read/pass control to any bootsector in windows NT system
as to boot alternative operation system. ntldr uses files (images) of bootsectors, so it can be
easily edited by hex editor (but there is no documentation where is drive number in bootsector)…
But I know one loader at least which reads selected bootsector (even if it’s in extended
partition:) and just jumps into it.
I can add another flag to dinit/dloader to allow explicit passing
of the boot source, which may help some people (but refer again to above
comments re hazards of auto-guessing) …
Installation procedure will much more smoothly But only if non-QNX primary loader is used… I
don’t know which trick the new “multidisk” QNX loader is doing. Or it just does not work? LOL, I
never used it to boot system from second drive.
Cheers,
Eduard.
ed1k at ukr dot net
But, if I was