[9fans] plan9 iso image

[Terry Wendt]

I've downloaded the plan9.iso image twice from
http://plan9.bell-labs.com/plan9/download.html

Once about two weeks ago, once today. Both times I extracted the
plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a
cd, and both times the program(k3b) told me the image wasn't the same
size as the header suggests??

Upon trying to boot off the cd I get this:

boot from cd :
PBSR...EI
_ <----- blinking cursor

I've waited, nothing else happens
I hit enter, and my machine reboots back to the above "boot from cd : " message.

Any ideas? Different download site? Any advice?
Thanks in advance,
Terry.

[erik quanstrom]

Post by Terry Wendt
I've downloaded the plan9.iso image twice from
http://plan9.bell-labs.com/plan9/download.html
Once about two weeks ago, once today. Both times I extracted the
plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a
cd, and both times the program(k3b) told me the image wasn't the same
size as the header suggests??
PBSR...EI
_ <----- blinking cursor

these are two, unrelated issues.

the .iso size issue should not be a big deal. there appears to be some
accounting that's off for cd-roms in the plan 9 iso burning software.
(mk9660(8)).

the new boot process can sometimes fail on new hardware.
you might try the 9atom iso

hget http://ftp.9atom.org/other/9atom.iso.bz2

this iso uses the traditional el-torito method. unfortunately,
the installer is size-constrained (1.44MB) and doesn't support usb.

while the image

hget http://ftp.9atom.org/other/9atom.nboot.iso.bz2

has the new installer which uses bios to access the hard drive
without el-torito emulation, and thus has no size constraints.
while it does fail on more hardware, it does support usb during
the install.

the images

http://ftp.9atom.org/other/+9atom.nboot.iso.bz2
http://ftp.9atom.org/other/+9atom.nboot.iso.bz2

are untested, and shouldn't be used unless you wish to verify
they work. if you do, please let me know offlist what the
results are. i keep forgetting to do this.

- erik

[Terry Wendt]

Thank you for your response erik. The machine I'm trying to boot this
on is an "old" dell inspiron 530.

Processor - Intel Pentium Dual CPU E2140 @ 1.60 GHz
Ram - 1 GB

I just thought of something... The HD is on the primary cable, and a
DVD and CD are on the secondary. The DVD drive is the device setup as
a boot device in the BIOS. Anything? Not really, right?

Can I use any of the 9atom images on this PC? Are they only for
install, or can I use them as live CDs?
I'm downloading:
http://ftp.9atom.org/other/9atom.iso.bz2
http://ftp.9atom.org/other/9atom.nboot.iso.bz2
http://ftp.9atom.org/other/+9atom.nboot.iso.bz2

You included 2 links to that last one. I'll try burning one of each of
these and let you know how the process goes. I might not get back to
you until later... but I will get back. If you meant to include a
forth link, resend and I'll grab a copy of that and do the same.

Thanks,
Terry.

[Paul A. Patience]

Post by Terry Wendt
Thank you for your response erik. The machine I'm trying to boot this
on is an "old" dell inspiron 530.

9front runs fine on my dell inspiron 530. i have to
boot it with *acpi= in plan9.ini, though.

pap

[Gorka Guardiola]

Post by erik quanstrom
these are two, unrelated issues.
the .iso size issue should not be a big deal. there appears to be some
accounting that's off for cd-roms in the plan 9 iso burning software.
(mk9660(8)).

Wouldn't surprise me, but it seems to work for me. If anyone has a more detailed explanation of what is wrong where, I'll take a look at it.

Post by erik quanstrom
this iso uses the traditional el-torito method. unfortunately,
the installer is size-constrained (1.44MB) and doesn't support usb.
while the image
hget http://ftp.9atom.org/other/9atom.nboot.iso.bz2
has the new installer which uses bios to access the hard drive
without el-torito emulation, and thus has no size constraints.
while it does fail on more hardware, it does support usb during
the install.

I don't know much about how 9atom works, but the new plan 9 loader uses el-torito, but version 3 which lets you access the whole cd as an lba device.

G.

[erik quanstrom]

Wouldn't surprise me, but it seems to work for me. If anyone has a
more detailed explanation of what is wrong where, I'll take a look at
it.

we're now writing the nwa to disk. this calculation appears to be incorrect.
here's the check in cdfs:

/* reconcile differing nwas */
if (aux->mmcnwa != nwa) {
fprint(2, "%s: nwa from drive %,ld != computed nwa %,ld\n",
argv0, aux->mmcnwa, nwa);
fprint(2, "\tbe careful! assuming computed nwa\n");
/* the invisible track may still start at the old nwa. */
// aux->mmcnwa = nwa;
}

Post by erik quanstrom
has the new installer which uses bios to access the hard drive
without el-torito emulation, and thus has no size constraints.
while it does fail on more hardware, it does support usb during the
install.

I don't know much about how 9atom works, but the new plan 9 loader
uses el-torito, but version 3 which lets you access the whole cd as an
lba device.

9atom uses either 9load (and pre version 3 el torito) or cinap's bios loader.
(this is the .nboot. version of the iso) the cd appears as a bios disk. this is
likely el torito version 3 under the covers, but that's not the programming
interface.

you can look at the code online /n/atom/plan9/sys/src/cmd/boot/iplpxe/

- erik

[Gorka Guardiola]

Post by erik quanstrom

Wouldn't surprise me, but it seems to work for me. If anyone has a
more detailed explanation of what is wrong where, I'll take a look at
it.

we're now writing the nwa to disk. this calculation appears to be incorrect.
/* reconcile differing nwas */
if (aux->mmcnwa != nwa) {
fprint(2, "%s: nwa from drive %,ld != computed nwa %,ld\n",
argv0, aux->mmcnwa, nwa);
fprint(2, "\tbe careful! assuming computed nwa\n");
/* the invisible track may still start at the old nwa. */
// aux->mmcnwa = nwa;
}

Maybe I am not understanding. We were talking about mkisofs which generates
an iso file.
This is cdfs check for the first writable block of the track, which has to
do with burning it.
An iso is burnt inside a track and is mostly independent from the details
of what tracks exist.
Terry downloaded the iso, and tried to burn it in linux. If something is
wrong it would be
in the iso file generated, which does not have to do anything with cdfs.
G.

[Terry Wendt]

If its any help, when I select 9atom.nboot.iso within K3b to burn to
disc, it reports the filesize as 360.9 MB but the declared volume size
as 721.7 GB.

Interesting.
Terry.

Post by Gorka Guardiola

Post by erik quanstrom

Wouldn't surprise me, but it seems to work for me. If anyone has a
more detailed explanation of what is wrong where, I'll take a look at
it.

we're now writing the nwa to disk. this calculation appears to be incorrect.
/* reconcile differing nwas */
if (aux->mmcnwa != nwa) {
fprint(2, "%s: nwa from drive %,ld != computed nwa %,ld\n",
argv0, aux->mmcnwa, nwa);
fprint(2, "\tbe careful! assuming computed nwa\n");
/* the invisible track may still start at the old nwa. */
// aux->mmcnwa = nwa;
}

Maybe I am not understanding. We were talking about mkisofs which generates
an iso file.
This is cdfs check for the first writable block of the track, which has to
do with burning it.
An iso is burnt inside a track and is mostly independent from the details of
what tracks exist.
Terry downloaded the iso, and tried to burn it in linux. If something is
wrong it would be
in the iso file generated, which does not have to do anything with cdfs.
G.

[erik quanstrom]

generates an iso file. This is cdfs check for the first writable
block of the track, which has to do with burning it. An iso is burnt
inside a track and is mostly independent from the details of what
tracks exist. Terry downloaded the iso, and tried to burn it in
linux. If something is wrong it would be in the iso file generated,
which does not have to do anything with cdfs. G.

/sys/src/cmd/disk/9660/dump9660.c:316,326
if(mk9660){
/*
* Patch in root directories.
*/
setroot(cd, cd->iso9660pvd, iroot.block, iroot.length);

setvolsize(cd, cd->iso9660pvd, (vlong)cd->nextblock * Blocksize);

if(cd->flags & CDjoliet){
setroot(cd, cd->jolietsvd, jroot.block, jroot.length);
setvolsize(cd, cd->jolietsvd,
(vlong)cd->nextblock * Blocksize);
}

- erik

[t***@polynum.com]

Post by erik quanstrom
this iso uses the traditional el-torito method. unfortunately,
the installer is size-constrained (1.44MB) and doesn't support usb.

FWIW (I implemented El-Torito support for GRUB years ago), the image has
to be some floppy size, and 2.88MB is perfectly supported.

There is also hd emulation, but this it seems not to be widely
supported by BIOSes.

[Gorka Guardiola]

Post by t***@polynum.com

Post by erik quanstrom
this iso uses the traditional el-torito method. unfortunately,
the installer is size-constrained (1.44MB) and doesn't support usb.

FWIW (I implemented El-Torito support for GRUB years ago), the image has
to be some floppy size, and 2.88MB is perfectly supported.
There is also hd emulation, but this it seems not to be widely
supported by BIOSes.

There are various ways of booting with El-torito.

http://download.intel.com/support/motherboards/desktop/sb/specscdrom.pdf

One of the ways is non-emulation (I thought it had appeared in a later
version of El-torito,
but checking the spec it was already in version 1, 1995), the byte 1 in
page
19, description in page 16.

Mkisofs lets you create a non-emulation bootable image (see
/sys/src/cmd/disk/9660/boot.c:166, which is set with -B) or an emulation
image.
Emulation goes hand in hand with pbsraw.s.

It used to be that many BIOSes did not support non-emu, but that has not
been true
AFAIK for a long while (at least more than 10 years). As long as you have
the blocks 2M aligned you should be fine with most modern BIOSes.

I think the problem is that the Plan 9 iso is somewhat different than k3b
expects
and it is "fixing" it, although as I said, the iso format is complex enough
and has enough
variants that there may be some error somewhere or the BIOS may have a
bug...

G.

[erik quanstrom]

Post by Terry Wendt
If its any help, when I select 9atom.nboot.iso within K3b to burn to
disc, it reports the filesize as 360.9 MB but the declared volume size
as 721.7 GB.

This is very interesting because it is exactly double

Post by Terry Wendt

setvolsize(cd, cd->iso9660pvd, (vlong)cd->nextblock *

Blocksize);
Yes, the volume size is set here, but I don't see any at least obvious
error. Everything seems to
be counted rightly in 2K blocks. Are you pointing to an error? because I
cannot see it...

the original claim was, the size was not set by mk9660. i was
showing where it is set.

and yes, if this calculation is wrong, then here it is. perhaps volsize
is in kb. :-)

- erik

[Gorka Guardiola]

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf

page 19:


Volume Space Size (BP 81 to 88)
This field shall specify as a 32-bit number the number of Logical Blocks in
which the Volume Space of the
volume is recorded.
This field shall be recorded according to 7.3.3.

[Gorka Guardiola]

So, the proposed change would be to take out the *Blocksize from the last
parameter of setvolsize
in the calls. Can someone test it with, say... k3b and see if it improves
something?
I still don't understand why it would report a *2 difference...

G.

[Gorka Guardiola]

Agh, now I see it, I thought the units was the same, but it was actually 2K
the difference.

Post by Terry Wendt
360.9 MB but the declared volume size

^^^

Post by Terry Wendt
as 721.7 GB.

^^^

So all is explained.
Ok, I'll create a patch.

G.

Post by Terry Wendt
So, the proposed change would be to take out the *Blocksize from the last
parameter of setvolsize
in the calls. Can someone test it with, say... k3b and see if it improves
something?
I still don't understand why it would report a *2 difference...
G.

[Gorka Guardiola]

I created the patch mkisovolsize.

G.

[Gorka Guardiola]

So... looking at the standard, the problem may be that
the volume size is in bytes instead of in blocks?

When I xd a plan 9 image (bytes are represented in little and
big endian):

0008000 01434430 30310100 504c414e 20392042
0008010 4f4f5420 49534f39 36363020 20202020
0008020 20202020 20202020 504c414e 2039202d
0008030 204d4159 20372032 30313220 32333a32
0008040 33202020 20202020 00000000 00000000
0008050 00305600 00563000 00000000 00000000
^^^^^^ ^^^^^^^
volume size in bytes (should this be in logical blocks?)

0008060 00000000 00000000 00000000 00000000
0008070 00000000 00000000 01000001 01000001
0008080 00080800 0a000000 0000000a c60a0000
^^^^^ ^^^^
Block size, 2K

0008090 00000000 00000ac7 00000000 2200c20a
00080a0 00000000 0ac20010 00000000 10007005
00080b0 07151737 00020000 01000001 01003956


The size of the iso given by ls is 5656576, 0x00565000
which is close enough to 0x563000 in bytes.

I xd a 90M linux iso I have and got:

0008000 01434430 30310100 4c494e55 58202020
0008010 20202020 20202020 20202020 20202020
0008020 20202020 20202020 4344524f 4d202020
0008030 20202020 20202020 20202020 20202020
0008040 20202020 20202020 00000000 00000000
0008050 fdb30000 0000b3fd 00000000 00000000
^^^^^^^^^^^^^^^^^

90M/2K

0008060 00000000 00000000 00000000 00000000
0008070 00000000 00000000 01000001 01000001
0008080 00080800 0a000000 0000000a 14000000
^^^^^^^^^
2K block size
0008090 00000000 00000016 00000000 22001800
00080a0 00000000 00180008 00000000 08006b05
00080b0 1808100a 20020000 01000001 01002020

So the size should be in Blocks and it is in bytes, this is why it is wrong.

I don't understand why k3b reports double the size because it
is much more. Unless I am not seeing something...

G.

Post by Gorka Guardiola
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf
Volume Space Size (BP 81 to 88)
This field shall specify as a 32-bit number the number of Logical Blocks
in which the Volume Space of the
volume is recorded.
This field shall be recorded according to 7.3.3.

[Gorka Guardiola]

Post by Gorka Guardiola
the blocks 2M aligned you should be fine with most modern BIOSes.

I meant 2K aligned.

Post by Gorka Guardiola
If its any help, when I select 9atom.nboot.iso within K3b to burn to
disc, it reports the filesize as 360.9 MB but the declared volume size
as 721.7 GB.

This is very interesting because it is exactly double

Post by Gorka Guardiola

setvolsize(cd, cd->iso9660pvd, (vlong)cd->nextblock *

Blocksize);

Yes, the volume size is set here, but I don't see any at least obvious
error. Everything seems to
be counted rightly in 2K blocks. Are you pointing to an error? because I
cannot see it...

G.

[Gorka Guardiola]

Post by Terry Wendt
I've downloaded the plan9.iso image twice from
http://plan9.bell-labs.com/plan9/download.html
Once about two weeks ago, once today. Both times I extracted the
plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a
cd, and both times the program(k3b) told me the image wasn't the same
size as the header suggests??

I'm confused. Why is the burning software looking inside the iso?

[Terry Wendt]

The file has an actual size on the file system, but the files header
tells the burning app that it has a different size.

This is my guess only...
Terry.

Post by Gorka Guardiola

Post by Terry Wendt
I've downloaded the plan9.iso image twice from
http://plan9.bell-labs.com/plan9/download.html
Once about two weeks ago, once today. Both times I extracted the
plan9.iso.bz2 file to plan9.iso. Both times I burned the image to a
cd, and both times the program(k3b) told me the image wasn't the same
size as the header suggests??

I'm confused. Why is the burning software looking inside the iso?

[Gorka Guardiola]

Post by erik quanstrom
this iso uses the tradition

Emulation goes hand in hand with pbsraw.s.

I mean emulation goes hand in hand with pbs.s (emulated, inside the floppy)
or pbsraw.s (non emulated,
used by the cd itself for booting).

G.