[9fans] plan9 iso image

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

Re: [9fans] plan9 iso image

[erik quanstrom]

On Fri Jun 28 12:27:26 EDT 2013, silicon.penguin67@gmail.com wrote:
> 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

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

Re: [9fans] plan9 iso image

[Gorka Guardiola]

On Jun 28, 2013, at 6:27 PM, Terry Wendt <silicon.penguin67@gmail.com> wrote:

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

Re: [9fans] plan9 iso image

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

Re: [9fans] plan9 iso image

[Gorka Guardiola]

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

Re: [9fans] plan9 iso image

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

On Fri, Jun 28, 2013 at 12:06 PM, Gorka Guardiola <paurea@gmail.com> wrote:
> On Jun 28, 2013, at 6:27 PM, Terry Wendt <silicon.penguin67@gmail.com> wrote:
>
>> 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?
>

Re: [9fans] plan9 iso image

[Paul A. Patience]

Terry Wendt <silicon.penguin67@gmail.com> wrote:

> 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

Re: [9fans] plan9 iso image

[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;
	}

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

Re: [9fans] plan9 iso image

[tlaronde]

On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote:
>
> 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.

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom <quanstro@quanstro.net>wrote:

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

[-- Attachment #2: Type: text/html, Size: 1804 bytes --]

Re: [9fans] plan9 iso image

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

On Fri, Jun 28, 2013 at 12:43 PM, Gorka Guardiola <paurea@gmail.com> wrote:
>
>
>
> On Fri, Jun 28, 2013 at 7:19 PM, erik quanstrom <quanstro@quanstro.net>
> wrote:
>>
>> > 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;
>>         }
>>
>
> 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.
>
>

Re: [9fans] plan9 iso image

[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

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

On Fri, Jun 28, 2013 at 7:38 PM, <tlaronde@polynum.com> wrote:

> On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote:
> >
> > 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.

[-- Attachment #2: Type: text/html, Size: 2452 bytes --]

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Fri, Jun 28, 2013 at 8:13 PM, Gorka Guardiola <paurea@gmail.com> wrote:

>
>
>
> On Fri, Jun 28, 2013 at 7:38 PM, <tlaronde@polynum.com> wrote:
>
>> On Fri, Jun 28, 2013 at 12:40:46PM -0400, erik quanstrom wrote:
>> >
>> > 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.

[-- Attachment #2: Type: text/html, Size: 1281 bytes --]

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

>
> the blocks 2M aligned you should be fine with most modern BIOSes.
>
>
I meant 2K aligned.


On Fri, Jun 28, 2013 at 7:50 PM, Terry Wendt <silicon.penguin67@gmail.com>
 wrote:

> 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

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

[-- Attachment #2: Type: text/html, Size: 1951 bytes --]

Re: [9fans] plan9 iso image

[erik quanstrom]

> On Fri, Jun 28, 2013 at 7:50 PM, Terry Wendt <silicon.penguin67@gmail.com>
>  wrote:
>
> > 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
>
> >>              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

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 583 bytes --]

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

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.






On Fri, Jun 28, 2013 at 8:57 PM, Gorka Guardiola <paurea@gmail.com> wrote:

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


--
- curiosity sKilled the cat

[-- Attachment #2: Type: text/html, Size: 3775 bytes --]

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 511 bytes --]

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

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

>  360.9 MB but the declared volume size
                ^^^
> as 721.7 GB.
                    ^^^

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

G.



On Fri, Jun 28, 2013 at 10:13 PM, Gorka Guardiola <paurea@gmail.com> wrote:

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


--
- curiosity sKilled the cat

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

Re: [9fans] plan9 iso image

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 41 bytes --]

I created the patch mkisovolsize.

G.

[-- Attachment #2: Type: text/html, Size: 174 bytes --]