Bootable disk image

I’m trying to create a bootable disk image on a loopback mount.
Here’s what I’ve done.

dd if=/dev/zero of=root.qfs count=64260
(note 64260 blocks is 4 disk cylinders, 425563)
dinit -f mykernel.ifs root.qfs
mount root.qfs /mnt
tar -cC /image . | tar -xC /mnt
(/image contains all the files I want on my rootdisk image)
umount /mnt
dd if=root.qfs of=/dev/hd0t79
(hd0t79 is a 4 cylinder, 64260 block, disk partition, same as the image)
hd0 has the pc1 loader installed on it.
When I reboot I see the pc1 loader message (select partition)
Then I see the pc2 loader message (press esc for altboot)
Then nothing happens, it dies. I’d expect .boot to start loading.

Any thoughts on where I’ve gone wrong?

Thanks,
Shaun

I should mention that mykernel.ifs is known-good. I’ve used it in other
situations with no trouble. It looks as if it’s never being loaded, since I
don’t even see its first display_msg.

Cheers,
Shaun

I’ve found the problem.After dding the image to the hard drive partition,
dloader has to be rerun on that partition.
This does not work:
dloader root.qfs pc2
dd if=root.qfs of=/dev/hd0t79
This does work:
dd if=root.qfs of=/dev/hd0t79
dloader /dev/hd0t79 pc2
The partition is now bootable and happy!

A question for the brighter ones now…
Why doesn’t the first method work? Does dloader do anything tricky besides
simply copying the specified loader to the first block of the specified
partition?

Thanks,
Shaun

Hi Shaun!,
The first block of the specified partition (boot sector) consists of the executable code and some
data which describe the volume. Usually the first instruction is ‘jmp addressBootCode’ in order to
skip over the data, So, since boot sector of QNX partition starts from ‘jmp 27h’, the bytes from
0x02 to 0x26 are used for partition descriptor. Unfortunately, I have no any information about that
descriptor and can’t find this info on internet. I hope, someone from QSSL could be polite to write
here some information about that. In hacker’s way I found the drive number in BIOS form (0x80 -
first hard drive, 0x81 - second… etc.) is stored at offset 0x11 :wink: Sadly to have that way in
order to get the rest of info.
But to answer your question. I think dloader (and dinit) dinamicly fills out the descriptor in
accordance with concrete circumstances. Those circumstances were different for ‘root.qfs’ and
‘/dev/hd0t79’, this should explain your problem.
But just curious why you did thru image? Why you did not do ‘dinit -f mykernel /dev/hd0t79’ and
after that did directly copy your files from tarball on partition?
Best regards.

Eduard.
ed1k at ukr dot net

Shaun Jackman <sjackman@nospam.vortek.com> wrote in article <abs9p3$34h$1@inn.qnx.com>…

I’ve found the problem.After dding the image to the hard drive partition,
dloader has to be rerun on that partition.
This does not work:
dloader root.qfs pc2
dd if=root.qfs of=/dev/hd0t79
This does work:
dd if=root.qfs of=/dev/hd0t79
dloader /dev/hd0t79 pc2
The partition is now bootable and happy!

A question for the brighter ones now…
Why doesn’t the first method work? Does dloader do anything tricky besides
simply copying the specified loader to the first block of the specified
partition?

Thanks,
Shaun

I wonder why concrete circumstantial information like that has to be stored
in the header. This implies that a third party tool used to copy or move the
QNX paritition would cause it to be no longer bootable. At least, not until
you dloader it again.
One reason I did it like this, is because the image is not being built on
the same system it will be written to. The main reason I went through the
troubles I did is because this operation is going to be repeated on many
nodes. I wanted a disk image I could just blit directly to the disk. Plus,
if the image is ddable, I can use third party disk imaging software to set
up the node. If the image will always be going to the first block of the
first drive, I can probably patch up the image by hand to include this
information. It would be nice if the image was relocatable though.

Cheers,
Shaun

ed1k <ed1k@spamerstrap.com> wrote in message
news:01c1fbea$b0d73f20$106fa8c0@ED1K…

Hi Shaun!,
The first block of the specified partition (boot sector) consists of the
executable code and some
data which describe the volume. Usually the first instruction is ‘jmp
addressBootCode’ in order to
skip over the data, So, since boot sector of QNX partition starts from
‘jmp 27h’, the bytes from
0x02 to 0x26 are used for partition descriptor. Unfortunately, I have no
any information about that
descriptor and can’t find this info on internet. I hope, someone from QSSL
could be polite to write
here some information about that. In hacker’s way I found the drive number
in BIOS form (0x80 -
first hard drive, 0x81 - second… etc.) is stored at offset 0x11 > :wink:
Sadly to have that way in
order to get the rest of info.
But to answer your question. I think dloader (and dinit) dinamicly fills
out the descriptor in
accordance with concrete circumstances. Those circumstances were different
for ‘root.qfs’ and
‘/dev/hd0t79’, this should explain your problem.
But just curious why you did thru image? Why you did not do ‘dinit -f
mykernel /dev/hd0t79’ and
after that did directly copy your files from tarball on partition?
Best regards.

Eduard.
ed1k at ukr dot net

Shaun Jackman <sjackman@nospam.vortek.com> wrote in article <abu110$d1e$1@inn.qnx.com>…

I wonder why concrete circumstantial information like that has to be stored
in the header.

Just because the OS loader has to do search through the volume in order to find .boot (or .altboot)
file. Then the loader copies that image into RAM and passes control to your boot image. So, since
the loader uses BIOS int 0x13 calls for searching (you may want to write your custom IPL and don’t
use standard loader), it should know some information: I guess, it is the drive number, first
sector of volume and last sector (or number of sectors in volume), maybe additionly it should know
also some information about filesystem, such as claster size, quantity and size of the file
allocation table and other as it is in FAT FS . Please don’t missread my post, I repeat I don’t
know which information exactly is stored in data area of QNX partition, so the example above is
only to explain my understanding by my knowledge. I’m sorry nobody from QSSL didn’t jump in this
thread to explain QNX boot sector layout (or give a link to).

This implies that a third party tool used to copy or move the
QNX paritition would cause it to be no longer bootable. At least, not until
you dloader it again.

Which tools are you speaking about?

One reason I did it like this, is because the image is not being built on
the same system it will be written to. The main reason I went through the
troubles I did is because this operation is going to be repeated on many
nodes. I wanted a disk image I could just blit directly to the disk.

What about the small shell script? Something like:

Creat a 4 cylinders QNX partition

fdisk /dev/hd0…

Dinit it, maybe after waitfor (‘on -W’)

dinit -f mykernel.ifs /dev/hd0t79

Mount it and copy the rest files

mount /dev/hd0t79 /mnt
tar -cC /image . | tar -xC /mnt

and so on…

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 reboot.

But perhaps I misunderstood something because I can’t catch what you mean by ‘third party disk
imaging software’.

BTW, I guess you could use ‘skip=1’ and ‘seek=1’ options in dd command to prevent overwriting the
boot sector:
dinit /dev/hd0t79 (make partition bootable (or ‘dloader’?), then)
dd if=root.qfs of=/dev/hd0t79 bs=512 skip=1 seek=1
Cheers.

Eduard.
ed1k at ukr dot net


Plus,
if the image is ddable, I can use third party disk imaging software to set
up the node. If the image will always be going to the first block of the
first drive, I can probably patch up the image by hand to include this
information. It would be nice if the image was relocatable though.

Cheers,
Shaun

I wonder why concrete circumstantial information like that has to be
stored
in the header.

Just because the OS loader has to do search through the volume in order to
find .boot (or .altboot)
file. Then the loader copies that image into RAM and passes control to
your boot image. So, since
the loader uses BIOS int 0x13 calls for searching (you may want to write
your custom IPL and don’t
use standard loader), it should know some information: I guess, it is the
drive number, first
sector of volume and last sector (or number of sectors in volume), maybe
additionly it should know
also some information about filesystem, such as claster size, quantity and
size of the file
allocation table and other as it is in FAT FS . Please don’t missread my
post, I repeat I don’t
know which information exactly is stored in data area of QNX partition, so
the example above is
only to explain my understanding by my knowledge. I’m sorry nobody from
QSSL didn’t jump in this
thread to explain QNX boot sector layout (or give a link to).

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 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.

This implies that a third party tool used to copy or move the
QNX paritition would cause it to be no longer bootable. At least, not
until
you dloader it again.

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).

One reason I did it like this, is because the image is not being built
on
the same system it will be written to. The main reason I went through
the
troubles I did is because this operation is going to be repeated on many
nodes. I wanted a disk image I could just blit directly to the disk.

What about the small shell script? Something like:

Creat a 4 cylinders QNX partition

fdisk /dev/hd0… :wink:

Dinit it, maybe after waitfor (‘on -W’)

dinit -f mykernel.ifs /dev/hd0t79

Mount it and copy the rest files

mount /dev/hd0t79 /mnt
tar -cC /image . | tar -xC /mnt

and so on…

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
reboot.

This is a cyclic dependency :wink: 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!

But perhaps I misunderstood something because I can’t catch what you mean
by ‘third party disk
imaging software’.

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.

BTW, I guess you could use ‘skip=1’ and ‘seek=1’ options in dd command to
prevent overwriting the
boot sector:
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
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.

Cheers,
Shaun

Shaun Jackman <sjackman@nospam.vortek.com> wrote in article <ac0lmt$d74$1@inn.qnx.com>…
[x]

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
system :wink:

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.

[x]

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 :wink: Doing this, the OS loader will output a lot of dots and hangs :smiley: 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” :wink:
This is nature of partitions, ‘dd’ can’t entirely substitute those highly intelligent programs :wink:

[x]

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
reboot.

This is a cyclic dependency > :wink: > 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
that.

[x]

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 :wink:

BTW, I guess you could use ‘skip=1’ and ‘seek=1’ options in dd command to
prevent overwriting the
boot sector:
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 :wink:
Cheers,

Eduard.
ed1k at ukr dot net

[big clip]

BTW, I guess you could use ‘skip=1’ and ‘seek=1’ options in dd command
to
prevent overwriting the
boot sector:
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.

I don’t think it’s the same as ‘dinit -r’, but it should do the same as
‘dinit -b’ judging by the ‘use dinit’ screen. In practice though, I never
got ‘dinit -b’ to work. Eventually I found dloader though which does exactly
what I want and let’s you choose which loader you want to install.

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 > :wink:
Cheers,

Thanks for the chat; I understand much more about the boot process now. Now,
the only thing I want is the format of the partition boot block (nudge nudge
QNX guys).

Cheers,
Shaun