[9fans] new 9atom.iso

[9fans] new 9atom.iso

[erik quanstrom]

it contains all the changes from the last 10 days.
should fix all reported problems, except béla's.

- erik

Re: [9fans] new 9atom.iso

[Hector Oron]

Hello,

2009/8/26 erik quanstrom <quanstro@quanstro.net>:
> it contains all the changes from the last 10 days.
> should fix all reported problems, except béla's.

Could you post the link? I am new to this list and plan9, and i can
not find a 9atom.iso, but a plan9.iso.bz2 [1]
It would also be helpful for me reading some introductory material, i
guess i can find it, but if you know some reference i would appreciate
it.

Kind regards and thanks for the work :)

[1] http://plan9.bell-labs.com/plan9/download/plan9.iso.bz2


-- 
 Héctor Orón

Re: [9fans] new 9atom.iso

[erik quanstrom]

> 2009/8/26 erik quanstrom <quanstro@quanstro.net>:
> > it contains all the changes from the last 10 days.
> > should fix all reported problems, except béla's.
>
> Could you post the link? I am new to this list and plan9, and i can
> not find a 9atom.iso, but a plan9.iso.bz2 [1]
> It would also be helpful for me reading some introductory material, i
> guess i can find it, but if you know some reference i would appreciate
> it.

the link is
	ftp://ftp.quanstro.net/other/9atom.iso.bz2
	cf819b70c90cedc39e305fb57d38f5df37302f84	Aug 26 09:13 9atom.iso.bz2

just a point of clarification.  the purpose of 9atom.iso
is to help people get going who are having trouble with
various sata or pata chipsets.  i recommend using
the standard cd if it works for you.  applying the contrib
packages to an official cd makes more sense as i hope
that this one-off cd can go away in the future.

it has different kernels and 9loads than the distribution.
it also applies the ape strtod fix to awk, and doesn't use
floating point in venti or fossil to avoid rounding errors.
you can think of 9atom.iso as plan9.iso.bz2 +
	contrib quanstro/9load-e820	(binaries only)
	contrib quanstro/sd		(binaries only)
	/n/sources/patch/apestrtod		(awk binary only)
	/n/sources/patch/fossil-sleep-stress
					(venti moded, too)

for my own convienence, there are some kernel differences
not covered above.  they should be inconsequential.
but the source to that kernel is here
	ftp://ftp.quanstro.net/other/kernel.mkfs.bz2

- erik

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Thu, Aug 27, 2009 at 9:16 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > 2009/8/26 erik quanstrom <quanstro@quanstro.net>:
> > > it contains all the changes from the last 10 days.
> > > should fix all reported problems, except béla's.
> >
> > Could you post the link? I am new to this list and plan9, and i can
> > not find a 9atom.iso, but a plan9.iso.bz2 [1]
> > It would also be helpful for me reading some introductory material, i
> > guess i can find it, but if you know some reference i would appreciate
> > it.
>
> the link is
>         ftp://ftp.quanstro.net/other/9atom.iso.bz2
>         cf819b70c90cedc39e305fb57d38f5df37302f84        Aug 26 09:13
> 9atom.iso.bz2
>
> just a point of clarification.  the purpose of 9atom.iso
> is to help people get going who are having trouble with
> various sata or pata chipsets.  i recommend using
> the standard cd if it works for you.  applying the contrib
> packages to an official cd makes more sense as i hope
> that this one-off cd can go away in the future.
>
> it has different kernels and 9loads than the distribution.
> it also applies the ape strtod fix to awk, and doesn't use
> floating point in venti or fossil to avoid rounding errors.
> you can think of 9atom.iso as plan9.iso.bz2 +
>        contrib quanstro/9load-e820     (binaries only)
>        contrib quanstro/sd             (binaries only)
>        /n/sources/patch/apestrtod              (awk binary only)
>        /n/sources/patch/fossil-sleep-stress
>                                        (venti moded, too)
>
> for my own convienence, there are some kernel differences
> not covered above.  they should be inconsequential.
> but the source to that kernel is here
>        ftp://ftp.quanstro.net/other/kernel.mkfs.bz2
>
> - erik
>
>
I think there's work going on to use plan 9 to load plan 9 (maybe?) to
replace 9load.  However, is there any chance of getting your 9load in the
mainline if/once people determine it to support more hardware?

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

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 9:51 AM, David Leimbach<leimy2k@gmail.com> wrote:

> I think there's work going on to use plan 9 to load plan 9 (maybe?) to
> replace 9load.

It's a gsoc project for Iruata to which I just gave a passing grade.

it's doable. It needs a new PBS, which iruata wrote.

ron

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Thu, Aug 27, 2009 at 10:05 AM, ron minnich <rminnich@gmail.com> wrote:

> On Thu, Aug 27, 2009 at 9:51 AM, David Leimbach<leimy2k@gmail.com> wrote:
>
> > I think there's work going on to use plan 9 to load plan 9 (maybe?) to
> > replace 9load.
>
> It's a gsoc project for Iruata to which I just gave a passing grade.
>
> it's doable. It needs a new PBS, which iruata wrote.
>
> ron
>
> COOL!

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

Re: [9fans] new 9atom.iso

[erik quanstrom]

> > I think there's work going on to use plan 9 to load plan 9 (maybe?) to
> > replace 9load.
>
> It's a gsoc project for Iruata to which I just gave a passing grade.
>
> it's doable. It needs a new PBS, which iruata wrote.

is it small enough to pxe?

- erik

Re: [9fans] new 9atom.iso

[Uriel]

Er, it doesn't need a new PBS, booting Plan 9 from a Plan 9 kernel
already worked just fine with what russ did years ago.

uriel

On Thu, Aug 27, 2009 at 7:05 PM, ron minnich<rminnich@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 9:51 AM, David Leimbach<leimy2k@gmail.com> wrote:
>
>> I think there's work going on to use plan 9 to load plan 9 (maybe?) to
>> replace 9load.
>
> It's a gsoc project for Iruata to which I just gave a passing grade.
>
> it's doable. It needs a new PBS, which iruata wrote.
>
> ron
>
>

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 11:26 AM, Uriel<uriel99@gmail.com> wrote:
> Er, it doesn't need a new PBS, booting Plan 9 from a Plan 9 kernel
> already worked just fine with what russ did years ago.

Hi, to clear up the air, and correct this wrong comment:
we did a few things
- kill the FAT partition
- parse an a.out header, load the plan 9 kernel from partition blocks 2 and up

To do this requires a new pbs. I don't much care if you believe me,
perhaps you can implement this yourself first before you make such a
claim.

ron

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Thu, Aug 27, 2009 at 3:26 PM, Uriel<uriel99@gmail.com> wrote:
> Er, it doesn't need a new PBS, booting Plan 9 from a Plan 9 kernel
> already worked just fine with what russ did years ago.
>
> uriel
>

i heard that from you already. i just don't know why haven't you done it yet.

for the ones interested, the code is at http://src.oitobits.net/9null.
i'm writing a README explaining how to compile and install.

iru

Re: [9fans] new 9atom.iso

[Uriel]

Can it load and parse plan9.ini?

uriel

On Thu, Aug 27, 2009 at 8:40 PM, Iruata Souza<iru.muzgo@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 3:26 PM, Uriel<uriel99@gmail.com> wrote:
>> Er, it doesn't need a new PBS, booting Plan 9 from a Plan 9 kernel
>> already worked just fine with what russ did years ago.
>>
>> uriel
>>
>
> i heard that from you already. i just don't know why haven't you done it yet.
>
> for the ones interested, the code is at http://src.oitobits.net/9null.
> i'm writing a README explaining how to compile and install.
>
> iru
>
>

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Thu, Aug 27, 2009 at 3:48 PM, Uriel<uriel99@gmail.com> wrote:
> Can it load and parse plan9.ini?
>
> uriel
>

it can. can you?

iru

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 11:48 AM, Uriel<uriel99@gmail.com> wrote:
> Can it load and parse plan9.ini?

why do you want to do that? Just wondering.

ron

Re: [9fans] new 9atom.iso

[Uriel]

Because the whole point of the project was to replace 9load, and the
way plan9 systems tell 9load what kernel to load is using plan9.ini

On Thu, Aug 27, 2009 at 8:57 PM, ron minnich<rminnich@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 11:48 AM, Uriel<uriel99@gmail.com> wrote:
>> Can it load and parse plan9.ini?
>
> why do you want to do that? Just wondering.
>
> ron
>
>

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 12:07 PM, Uriel<uriel99@gmail.com> wrote:
> Because the whole point of the project was to replace 9load, and the
> way plan9 systems tell 9load what kernel to load is using plan9.ini

no, the point of the project was to have a new way to load that did
not require 9load or 9fat or any legacy at all. I am surprised you
would tie yourself down to legacy that way. Or I'm not.

Do we stick with that file format forever? is it perfect and never to
be changed?

ron

Re: [9fans] new 9atom.iso

[Uriel]

On Thu, Aug 27, 2009 at 9:17 PM, ron minnich<rminnich@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 12:07 PM, Uriel<uriel99@gmail.com> wrote:
>> Because the whole point of the project was to replace 9load, and the
>> way plan9 systems tell 9load what kernel to load is using plan9.ini
>
> no,

yes.

> the point of the project was to have a new way to load that did
> not require 9load

Right.

>  or 9fat or any legacy at all.

Wrong.

> I am surprised you
> would tie yourself down to legacy that way. Or I'm not.

9fat might be 'legacy', but unlike 9load it causes no problems or
wasted duplicated efforts, is simple and reliable, it is convenient
because can be accessed from other OSes, and is used by most Plan 9
systems to store their kernels and plan9.inis

To replace 9fat we would need something that at least shared all its
advantages, and I have not seen any proposal that does.


> Do we stick with that file format forever? is it perfect and never to
> be changed?

plan9.ini is certainly not perfect, and I'm happy to see it changed
some day, but that was not what the project was about.

Anyway, it doesn't matter because apparently the bits I wanted have
been written (or so I'm told) and should work (if I'm not mistaken)
just fine in a backwards compatible fashion using russ' boot scheme.

uriel

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 12:27 PM, Uriel<uriel99@gmail.com> wrote:

> plan9.ini is certainly not perfect, and I'm happy to see it changed
> some day, but that was not what the project was about.

I'm glad to know you defined the project. I guess the guy who wrote the code
(Iruata) and the mentor (me) were just confused.

Anyway, anyone familiar with the situation understands your level of accuracy,
so the point is made.

ron

Re: [9fans] new 9atom.iso

[Uriel]

On Thu, Aug 27, 2009 at 9:34 PM, ron minnich<rminnich@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 12:27 PM, Uriel<uriel99@gmail.com> wrote:
>
>> plan9.ini is certainly not perfect, and I'm happy to see it changed
>> some day, but that was not what the project was about.
>
> I'm glad to know you defined the project. I guess the guy who wrote the code
> (Iruata) and the mentor (me) were just confused.

Yes, you were confused, and yes, the project was my idea (although
that was just a restatement of russ original suggestion).

But it doesn't matter because it seems eventually iru got around
writing the code needed to fulfill russ original idea, so I'm happy
because if I understood this correctly, it should be possible to put
that together with russ loader and have a backwards compatible
replacement for 9load.

uriel

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 1:35 PM, Uriel<uriel99@gmail.com> wrote:

> Yes, you were confused, and yes, the project was my idea (although
> that was just a restatement of russ original suggestion).

you mean it was russ' original idea which you misunderstood, I expect.
And it's hardly new: we were doing it at LANL 8 years ago when we put
Plan 9 in flash, and it was not new then.


> backwards compatible
> replacement for 9load.

Great. the code is there, we're waiting for you to finish it.

ron

Re: [9fans] new 9atom.iso

[Steve Simon]

9fat is also a pain in that the 9load file must be created with,
and retain its append only file, which has a special meaning to 9fat
telling it to create the file in sequential blocks.

This could (and has) caused problems if you access the 9fat partition
from os's other than plan9.

The only times I have had to change plan9.ini from somthing else
than the booted system (because I have broken the boot process)
I booted the plan9 live cdrom.

I would be happy if 9load and 9fat disappeared and it was
replaced with a plan9 bootstrap kernel and (say) an rc(1) script.

-Steve

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Thu, Aug 27, 2009 at 6:57 PM, Steve Simon<steve@quintile.net> wrote:
> 9fat is also a pain in that the 9load file must be created with,
> and retain its append only file, which has a special meaning to 9fat
> telling it to create the file in sequential blocks.
>
> This could (and has) caused problems if you access the 9fat partition
> from os's other than plan9.
>
> The only times I have had to change plan9.ini from somthing else
> than the booted system (because I have broken the boot process)
> I booted the plan9 live cdrom.
>
> I would be happy if 9load and 9fat disappeared and it was
> replaced with a plan9 bootstrap kernel and (say) an rc(1) script.
>

that's just what 9null is: new pbs, 9pcload (bootstrap kernel),
/boot/boot using rc(1) scripts.
instead of a 'root from' you may get a 'kernel is at' prompt to which
you can ask for a shell (!rc)

iru

Re: [9fans] new 9atom.iso

[Christopher Nielsen]

Nice work! I think this is great! Thanks for your efforts.

On Thu, Aug 27, 2009 at 15:05, Iruata Souza<iru.muzgo@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 6:57 PM, Steve Simon<steve@quintile.net> wrote:
>> 9fat is also a pain in that the 9load file must be created with,
>> and retain its append only file, which has a special meaning to 9fat
>> telling it to create the file in sequential blocks.
>>
>> This could (and has) caused problems if you access the 9fat partition
>> from os's other than plan9.
>>
>> The only times I have had to change plan9.ini from somthing else
>> than the booted system (because I have broken the boot process)
>> I booted the plan9 live cdrom.
>>
>> I would be happy if 9load and 9fat disappeared and it was
>> replaced with a plan9 bootstrap kernel and (say) an rc(1) script.
>>
>
> that's just what 9null is: new pbs, 9pcload (bootstrap kernel),
> /boot/boot using rc(1) scripts.
> instead of a 'root from' you may get a 'kernel is at' prompt to which
> you can ask for a shell (!rc)
>
> iru
>
>



--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] new 9atom.iso

[tlaronde]

On Thu, Aug 27, 2009 at 07:05:31PM -0300, Iruata Souza wrote:
>
> that's just what 9null is: new pbs, 9pcload (bootstrap kernel),
> /boot/boot using rc(1) scripts.
> instead of a 'root from' you may get a 'kernel is at' prompt to which
> you can ask for a shell (!rc)

Thank you for doing this.

I worked years ago to add El Torito and uncommon floppy formats to Grub
just to realize that adding fs drivers, ethernet drivers, shell like
scripting we were just reinventing the wheel i.e. a kernel, that was
never efficient enough to recover a system when there was a problem,
and generally too complex for normal use when it was just booting as
usual.

It is simpler to be fs agnostic and load a sequence of
sectors. (Just as a note, there was at some time a tarfs with some BSD
to have a kind of organized stream of sectors. No incentive or whatever,
just a note about the same kind of principles or tracks followed
somewhere else.)

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

Re: [9fans] new 9atom.iso

[Federico G. Benavento]

I solved this by deleting everything for the fat partition (which was a
fat16lba, not a 9fat) and then copy the files in the right order all this
done in vista

it worked

On Thu, Aug 27, 2009 at 6:57 PM, Steve Simon<steve@quintile.net> wrote:
> 9fat is also a pain in that the 9load file must be created with,
> and retain its append only file, which has a special meaning to 9fat
> telling it to create the file in sequential blocks.
>
> This could (and has) caused problems if you access the 9fat partition
> from os's other than plan9.
>
> The only times I have had to change plan9.ini from somthing else
> than the booted system (because I have broken the boot process)
> I booted the plan9 live cdrom.
>
> I would be happy if 9load and 9fat disappeared and it was
> replaced with a plan9 bootstrap kernel and (say) an rc(1) script.
>
> -Steve
>
>



--
Federico G. Benavento

Re: [9fans] new 9atom.iso

[erik quanstrom]

> I solved this by deleting everything for the fat partition (which was a
> fat16lba, not a 9fat) and then copy the files in the right order all this
> done in vista
>
> it worked

i believe io.sys in dos must be contiguous, too.
http://www.csulb.edu/~murdock/format.html
http://en.wikipedia.org/wiki/IO.SYS
http://support.microsoft.com/kb/66530/en-us

i had always wondered why plan9.ini was the way
it is.  i had not realized that it is compatable with config.sys
http://en.wikipedia.org/wiki/CONFIG.SYS

does anyone know the reason for this?

- erik

Re: [9fans] new 9atom.iso

[erik quanstrom]

> Do we stick with that file format forever? is it perfect and never to
> be changed?

would it be fair to ask a the same question from a little
different perspective?

could someone explain what the disadvantages and problems
with 9fat are?  i'm asking out of ignorance, since 9fat hasn't
been a problem for me.

- erik

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 1:14 PM, erik quanstrom<quanstro@coraid.com> wrote:

> could someone explain what the disadvantages and problems
> with 9fat are?  i'm asking out of ignorance, since 9fat hasn't
> been a problem for me.

8.3. It's burned me time and again.

ron

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Thu, Aug 27, 2009 at 5:14 PM, erik quanstrom<quanstro@coraid.com> wrote:
>> Do we stick with that file format forever? is it perfect and never to
>> be changed?
>
> would it be fair to ask a the same question from a little
> different perspective?
>
> could someone explain what the disadvantages and problems
> with 9fat are?  i'm asking out of ignorance, since 9fat hasn't
> been a problem for me.
>

9fat serves only two purposes: a) be a home for plan9.ini, b) be a
home for some kernels. in the actual state of affairs, you must have
9fat and it must reside at the very beginning of the Plan 9 slice on
the disk.

9null (the project we're talking about) doesn't require any of it, but
allows it. you can have a fat partition with plan9.ini and, say, 9pcf.
but it can't reside at the very beginning of the disk. in fact, you
should be able to have plan9.ini and kernels anywhere you want:
fossil, kfs, ext2, iso9660, &c.

the Plan 9 slice layout used by 9null is:
sector 0: pbs
sector 1: Plan 9 partition table
sector 2..k: 9pcload kernel
sector k..n: data

iru

Re: [9fans] new 9atom.iso

[erik quanstrom]

> 9null (the project we're talking about) doesn't require any of it, but
> allows it. you can have a fat partition with plan9.ini and, say, 9pcf.
> but it can't reside at the very beginning of the disk. in fact, you
> should be able to have plan9.ini and kernels anywhere you want:
> fossil, kfs, ext2, iso9660, &c.
>
> the Plan 9 slice layout used by 9null is:
> sector 0: pbs
> sector 1: Plan 9 partition table
> sector 2..k: 9pcload kernel
> sector k..n: data

is there a 9pxenull?  that is a PXE-loadable 9null.
all machines here except the auth and file servers
PXE boot.

- erik

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Thu, Aug 27, 2009 at 6:41 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>> 9null (the project we're talking about) doesn't require any of it, but
>> allows it. you can have a fat partition with plan9.ini and, say, 9pcf.
>> but it can't reside at the very beginning of the disk. in fact, you
>> should be able to have plan9.ini and kernels anywhere you want:
>> fossil, kfs, ext2, iso9660, &c.
>>
>> the Plan 9 slice layout used by 9null is:
>> sector 0: pbs
>> sector 1: Plan 9 partition table
>> sector 2..k: 9pcload kernel
>> sector k..n: data
>
> is there a 9pxenull?  that is a PXE-loadable 9null.
> all machines here except the auth and file servers
> PXE boot.
>

i didn't take a look at pxe booting yet, but i'd be happy to have it working.

iru

Re: [9fans] new 9atom.iso

[Uriel]

On Thu, Aug 27, 2009 at 10:14 PM, erik quanstrom<quanstro@coraid.com> wrote:
>> Do we stick with that file format forever? is it perfect and never to
>> be changed?
>
> would it be fair to ask a the same question from a little
> different perspective?
>
> could someone explain what the disadvantages and problems
> with 9fat are?  i'm asking out of ignorance, since 9fat hasn't
> been a problem for me.

It has not been a problem for anyone I know. It might not be perfect
or beautiful, but I have yet to hear any suggestion for a replacement
that has all the advantages of 9fat (simple, reliable, easily
accessible from other systems, etc.)

uriel

Re: [9fans] new 9atom.iso

[Tim Newsham]

> It has not been a problem for anyone I know. It might not be perfect
> or beautiful, but I have yet to hear any suggestion for a replacement
> that has all the advantages of 9fat (simple, reliable, easily
> accessible from other systems, etc.)

I think "easily accessible from other systems" should be removed
from the list.  There are alternatives, such as booting a live cd.
Many other operating systems also keep their kernels on native
filesystems and do not suffer because of it.

> uriel

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] new 9atom.iso

[erik quanstrom]

> > It has not been a problem for anyone I know. It might not be perfect
> > or beautiful, but I have yet to hear any suggestion for a replacement
> > that has all the advantages of 9fat (simple, reliable, easily
> > accessible from other systems, etc.)
>
> I think "easily accessible from other systems" should be removed
> from the list.  There are alternatives, such as booting a live cd.
> Many other operating systems also keep their kernels on native
> filesystems and do not suffer because of it.

i have found it convienent to be able to update a kernel
from linux, osx, windows.  i would imagine this is important
for vm solutions, too.  do you think it's preferable to build
a live cd for this including the little bit prepared in another
os?  i've found live cds to be pretty annoying to maintain.

- erik

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Thu, Aug 27, 2009 at 6:38 PM, erik quanstrom<quanstro@quanstro.net> wrote:
>> > It has not been a problem for anyone I know. It might not be perfect
>> > or beautiful, but I have yet to hear any suggestion for a replacement
>> > that has all the advantages of 9fat (simple, reliable, easily
>> > accessible from other systems, etc.)
>>
>> I think "easily accessible from other systems" should be removed
>> from the list.  There are alternatives, such as booting a live cd.
>> Many other operating systems also keep their kernels on native
>> filesystems and do not suffer because of it.
>
> i have found it convienent to be able to update a kernel
> from linux, osx, windows.  i would imagine this is important
> for vm solutions, too.  do you think it's preferable to build
> a live cd for this including the little bit prepared in another
> os?  i've found live cds to be pretty annoying to maintain.
>

as i said early in this thread, with 9null you kernel may live in any
fs you like as long as Plan 9 has can read it.

Re: [9fans] new 9atom.iso

[Tim Newsham]

> i have found it convienent to be able to update a kernel
> from linux, osx, windows.  i would imagine this is important
> for vm solutions, too.  do you think it's preferable to build
> a live cd for this including the little bit prepared in another
> os?  i've found live cds to be pretty annoying to maintain.

Can you explain the "VM solutions" point further?

The current plan 9 install CD is already a live CD.  I don't imagine this
places an extra burden on whoever maintains it. Once you have a live CD
that works with your system (ie. the same one you installed with), you
don't really need to update it unless you change to a new filesystem not
supported by the CD.

> - erik

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] new 9atom.iso

[Federico G. Benavento]

the problem comes when you just can't boot the CD!

last month when erik and I got Plan 9 booting on this machine
it was really convenient just to be able to copy 9load to a
fat partition while I was running windows, reboot and see if
it worked, I didn't even tried to load a kernel at that point
because 9load didn't even see the disks.

so, yes, 9fat helped, not because the kernel or Plan 9 lived there
but because I could just copy the loader (9load) really fast.

I talked some weeks ago about this with iru, because I really didn't
see the point in getting rid of 9fat.

I could achieve the same as I did by doing "copy 9load E:" on windows
with this new approach, but I'd need to boot some linux live CD
and dd my way out to put the new loader there which I'll be too
hacky and I'd probably need a version of prepdisk for linux
on that live cd as well, if I got it right.


On Thu, Aug 27, 2009 at 6:49 PM, Tim Newsham<newsham@lava.net> wrote:
>> i have found it convienent to be able to update a kernel
>> from linux, osx, windows.  i would imagine this is important
>> for vm solutions, too.  do you think it's preferable to build
>> a live cd for this including the little bit prepared in another
>> os?  i've found live cds to be pretty annoying to maintain.
>
> Can you explain the "VM solutions" point further?
>
> The current plan 9 install CD is already a live CD.  I don't imagine this
> places an extra burden on whoever maintains it. Once you have a live CD that
> works with your system (ie. the same one you installed with), you don't
> really need to update it unless you change to a new filesystem not supported
> by the CD.
>
>> - erik
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>



-- 
Federico G. Benavento

Re: [9fans] new 9atom.iso

[ron minnich]

Nothing prevents anyone from using 9fat or building on or changing
iruatas work. It is there so go forth and hack. What is nice is his
new pbs goes to 32 bit mode right away so hacking is easier than
before.

Ron

On 8/27/09, Federico G. Benavento <benavento@gmail.com> wrote:
> the problem comes when you just can't boot the CD!
>
> last month when erik and I got Plan 9 booting on this machine
> it was really convenient just to be able to copy 9load to a
> fat partition while I was running windows, reboot and see if
> it worked, I didn't even tried to load a kernel at that point
> because 9load didn't even see the disks.
>
> so, yes, 9fat helped, not because the kernel or Plan 9 lived there
> but because I could just copy the loader (9load) really fast.
>
> I talked some weeks ago about this with iru, because I really didn't
> see the point in getting rid of 9fat.
>
> I could achieve the same as I did by doing "copy 9load E:" on windows
> with this new approach, but I'd need to boot some linux live CD
> and dd my way out to put the new loader there which I'll be too
> hacky and I'd probably need a version of prepdisk for linux
> on that live cd as well, if I got it right.
>
>
> On Thu, Aug 27, 2009 at 6:49 PM, Tim Newsham<newsham@lava.net> wrote:
>>> i have found it convienent to be able to update a kernel
>>> from linux, osx, windows.  i would imagine this is important
>>> for vm solutions, too.  do you think it's preferable to build
>>> a live cd for this including the little bit prepared in another
>>> os?  i've found live cds to be pretty annoying to maintain.
>>
>> Can you explain the "VM solutions" point further?
>>
>> The current plan 9 install CD is already a live CD.  I don't imagine this
>> places an extra burden on whoever maintains it. Once you have a live CD
>> that
>> works with your system (ie. the same one you installed with), you don't
>> really need to update it unless you change to a new filesystem not
>> supported
>> by the CD.
>>
>>> - erik
>>
>> Tim Newsham
>> http://www.thenewsh.com/~newsham/
>>
>>
>
>
>
> --
> Federico G. Benavento
>
>

-- 
Sent from my mobile device

Re: [9fans] new 9atom.iso

[Federico G. Benavento]

hola,

> Nothing prevents anyone from using 9fat or building on or changing
> iruatas work. It is there so go forth and hack.

I really don't get this, I didn't criticize iru's work, I was just pointing how
being able to put the loader in a fat partition was convenient to me,
just that.


--
Federico G. Benavento

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 10:08 PM, Federico G.
Benavento<benavento@gmail.com> wrote:

> I really don't get this, I didn't criticize iru's work, I was just pointing how
> being able to put the loader in a fat partition was convenient to me,
> just that.

I did not take it that way. Your point is a very important one.

Thanks

ron

Re: [9fans] new 9atom.iso

[ron minnich]

On Thu, Aug 27, 2009 at 6:54 PM, Federico G.
Benavento<benavento@gmail.com> wrote:

> I could achieve the same as I did by doing "copy 9load E:" on windows
> with this new approach, but I'd need to boot some linux live CD
> and dd my way out to put the new loader there which I'll be too
> hacky and I'd probably need a version of prepdisk for linux
> on that live cd as well, if I got it right.

yep, this is a good point. It's the same reason that Peter Anvin
argued against using linux as a boot loader in place of grub or pxe or
whatever. There are simple standards on booting PCs, and if you
conform to them, you are more going to work in all cases. If you don't
conform to them, there are more cases where you can't work. Your Vista
example is a good case study.

So the FAT partition is good when you want to interoperate. But as you
point out, it's kind of 1/2 of a real fat partition, which means
sometimes, even if it looks ok in vista or whatever, it's not really
ok. It's not really possible to fit a true FAT file system handler in
a 512 byte pbs. The Plan 9 pbs (and I assume most of them)  are really
a "find a file by name, get the offset, and just start loading
contiguous data form whatever is at that offset in the partition until
done". That's why there are things like install_grub, or lilo, or
other such tools. If you delete and replace 9load and it ends up
discontiguous, well, you may not be able to boot, hence the need to
sometimes remove and replace all the files in the FAT.

There are a number of reasons to like using a plan 9 kernel to boot
your machine: drivers, native file systems, and so on. Interoperation
with vista is not one of them. It may well be in the long term that
the best way to remove 9load is to make Plan 9 grub-bootable.

But 9null is a pretty interesting experiment, all things considered.
And, it's there to hack. Grab the code and have it, maybe make it
better or fit what you want better or show us all a better way to do
things.

ron

Re: [9fans] new 9atom.iso

[matt]

>the best way to remove 9load is to make Plan 9 grub-bootable.
>
>
I don't know much about this subject but I already boot Plan9 using grub.

You mean something more specific than chainloading I presume.

Re: [9fans] new 9atom.iso

[Uriel]

On Fri, Aug 28, 2009 at 7:23 AM, ron minnich<rminnich@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 6:54 PM, Federico G.
> Benavento<benavento@gmail.com> wrote:
>
>> I could achieve the same as I did by doing "copy 9load E:" on windows
>> with this new approach, but I'd need to boot some linux live CD
>> and dd my way out to put the new loader there which I'll be too
>> hacky and I'd probably need a version of prepdisk for linux
>> on that live cd as well, if I got it right.
>
> yep, this is a good point. It's the same reason that Peter Anvin
> argued against using linux as a boot loader in place of grub or pxe or
> whatever. There are simple standards on booting PCs, and if you
> conform to them, you are more going to work in all cases. If you don't
> conform to them, there are more cases where you can't work. Your Vista
> example is a good case study.
>
> So the FAT partition is good when you want to interoperate. But as you
> point out, it's kind of 1/2 of a real fat partition, which means
> sometimes, even if it looks ok in vista or whatever, it's not really
> ok. It's not really possible to fit a true FAT file system handler in
> a 512 byte pbs. The Plan 9 pbs (and I assume most of them)  are really
> a "find a file by name, get the offset, and just start loading
> contiguous data form whatever is at that offset in the partition until
> done". That's why there are things like install_grub, or lilo, or
> other such tools. If you delete and replace 9load and it ends up
> discontiguous, well, you may not be able to boot, hence the need to
> sometimes remove and replace all the files in the FAT.
>
> There are a number of reasons to like using a plan 9 kernel to boot
> your machine: drivers, native file systems, and so on. Interoperation
> with vista is not one of them. It may well be in the long term that
> the best way to remove 9load is to make Plan 9 grub-bootable.

You try to present this as if using a Plan 9 kernel to boot somehow
precludes the use of the existing 9fat setup, this is not true, and
the whole point of the original GSoC project was precisely that: to
boot using a kernel without changing anything about 9fat and plan9.ini
so we could have a drop in replacement for 9load.

And given that such a setup would have all the advantages you list
here, plus would retain the advantages people enjoy from 9fat, it is
hard to understand why doing something else is such a great idea.

uriel


>
> But 9null is a pretty interesting experiment, all things considered.
> And, it's there to hack. Grab the code and have it, maybe make it
> better or fit what you want better or show us all a better way to do
> things.
>
> ron
>
>

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Fri, Aug 28, 2009 at 8:06 AM, Uriel<uriel99@gmail.com> wrote:
> On Fri, Aug 28, 2009 at 7:23 AM, ron minnich<rminnich@gmail.com> wrote:
>> On Thu, Aug 27, 2009 at 6:54 PM, Federico G.
>> Benavento<benavento@gmail.com> wrote:
>>
>>> I could achieve the same as I did by doing "copy 9load E:" on windows
>>> with this new approach, but I'd need to boot some linux live CD
>>> and dd my way out to put the new loader there which I'll be too
>>> hacky and I'd probably need a version of prepdisk for linux
>>> on that live cd as well, if I got it right.
>>
>> yep, this is a good point. It's the same reason that Peter Anvin
>> argued against using linux as a boot loader in place of grub or pxe or
>> whatever. There are simple standards on booting PCs, and if you
>> conform to them, you are more going to work in all cases. If you don't
>> conform to them, there are more cases where you can't work. Your Vista
>> example is a good case study.
>>
>> So the FAT partition is good when you want to interoperate. But as you
>> point out, it's kind of 1/2 of a real fat partition, which means
>> sometimes, even if it looks ok in vista or whatever, it's not really
>> ok. It's not really possible to fit a true FAT file system handler in
>> a 512 byte pbs. The Plan 9 pbs (and I assume most of them)  are really
>> a "find a file by name, get the offset, and just start loading
>> contiguous data form whatever is at that offset in the partition until
>> done". That's why there are things like install_grub, or lilo, or
>> other such tools. If you delete and replace 9load and it ends up
>> discontiguous, well, you may not be able to boot, hence the need to
>> sometimes remove and replace all the files in the FAT.
>>
>> There are a number of reasons to like using a plan 9 kernel to boot
>> your machine: drivers, native file systems, and so on. Interoperation
>> with vista is not one of them. It may well be in the long term that
>> the best way to remove 9load is to make Plan 9 grub-bootable.
>
> You try to present this as if using a Plan 9 kernel to boot somehow
> precludes the use of the existing 9fat setup, this is not true, and
> the whole point of the original GSoC project was precisely that: to
> boot using a kernel without changing anything about 9fat and plan9.ini
> so we could have a drop in replacement for 9load.
>

there was no 'without changing' anything. it was just to replace
9load. the project proposal was accepted without touching the 9fat
subject. if it's not specified, it's open to discussion.

>
> And given that such a setup would have all the advantages you list
> here, plus would retain the advantages people enjoy from 9fat, it is
> hard to understand why doing something else is such a great idea.
>

this has been explained already: 9null does not care about the
filesystem where the kernel lives, as long as Plan 9 knows how to
mount it.
if you like fat because of interoperability, that's ok, we have dossrv
and 9null can use it. we simply don't require it. i don't see how
fgb's solution would not work with 9null.

i myself have setup a fossil disk for testing outside of the Plan 9
machine with 9null and it booted just fine. it would have been the
same if i had setup a fat partition outside.

iru

Re: [9fans] new 9atom.iso

[blstuart]

> with vista is not one of them. It may well be in the long term that
> the best way to remove 9load is to make Plan 9 grub-bootable.

The -H5 option to 8l will generate an ELF image.  I've
used that to boot Inferno using pxelinux/mboot.  I'm
pretty sure a Plan9 image built using -H5 would be
grub-bootable.

BLS

Re: [9fans] new 9atom.iso

[Venkatesh Srinivas]

Did you use the plan 9 kencc to build that inferno kernel? As I
understand, inferno's 8c doesn't have the H5 option...

-- vs

Re: [9fans] new 9atom.iso

[Brian L. Stuart]

> Did you use the plan 9 kencc to build
> that inferno kernel? As I
> understand, inferno's 8c doesn't have the H5 option...

I used the versions with Inferno, except that I borrowed
a couple files from Plan9's 8l to get the H5 support.

And in case anyone's curious, I booted it with grub a
little earlier today.  So leaving aside the question
of whether it's desirable, it's easily doable.

BLS

Re: [9fans] new 9atom.iso

[Noah Evans]

Can you get a native kernel working with qemu or parallels?the latest
osx versions crash on inferno for me.

Sent from my iPhone

On Aug 28, 2009, at 8:02 PM, "Brian L. Stuart"
<blstuart@bellsouth.net> wrote:

>> Did you use the plan 9 kencc to build
>> that inferno kernel? As I
>> understand, inferno's 8c doesn't have the H5 option...
>
> I used the versions with Inferno, except that I borrowed
> a couple files from Plan9's 8l to get the H5 support.
>
> And in case anyone's curious, I booted it with grub a
> little earlier today.  So leaving aside the question
> of whether it's desirable, it's easily doable.
>
> BLS
>
>

Re: [9fans] new 9atom.iso

[blstuart]

> Can you get a native kernel working with qemu or parallels?the latest
> osx versions crash on inferno for me.

I don't have parallels available, but I have run it in qemu.
However, it's been a while.  Qemu is one of the "platforms"
I used to test my native install CD image.  I did find a few
caveats.  They're listed on:

https://umdrive.memphis.edu/blstuart/htdocs/inf_nat_inst.html

BTW, I hope to have another version available soon that
includes pretty good USB support and some limited graphics.

BLS

Re: [9fans] new 9atom.iso

[erik quanstrom]

> So the FAT partition is good when you want to interoperate. But as you
> point out, it's kind of 1/2 of a real fat partition, which means
> sometimes, even if it looks ok in vista or whatever, it's not really
> ok. It's not really possible to fit a true FAT file system handler in
> a 512 byte pbs. The Plan 9 pbs (and I assume most of them)  are really
> a "find a file by name, get the offset, and just start loading
> contiguous data form whatever is at that offset in the partition until
> done". That's why there are things like install_grub, or lilo, or
> other such tools. If you delete and replace 9load and it ends up
> discontiguous, well, you may not be able to boot, hence the need to
> sometimes remove and replace all the files in the FAT.

two points, the contiguous requirement is part of the microsoft
standard:
http://support.microsoft.com/kb/66530/en-us
so i think it's a bit unfair to say this is "1/2 of a real fat partition".

also, with dossrv, chmod +al will, if possible convert any file
into a bootable file.

removing all the files is somewhat of a hacky workaround, and
dos format kind of beats around the bush.  you tell it how
much system space to reserve, rather than which files are
system files.

> It may well be in the long term that
> the best way to remove 9load is to make Plan 9 grub-bootable.

that doesn't sound very appealing.  what advantages does grub have?
would you require linux to have plan 9?

- erik

Re: [9fans] new 9atom.iso

[Tim Newsham]

> I could achieve the same as I did by doing "copy 9load E:" on windows
> with this new approach, but I'd need to boot some linux live CD
> and dd my way out to put the new loader there which I'll be too
> hacky and I'd probably need a version of prepdisk for linux
> on that live cd as well, if I got it right.

You could just dd or rawrite from windows, as well.

> Federico G. Benavento

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] new 9atom.iso

[matt]

Tim Newsham wrote:

>
> You could just dd or rawrite from windows, as well.

iirc you need to be an administrator and can turn on raw disk access,
for which you get v. scary dialog boxes warning you not to do it

that was on xp, I expect newer trash will be the same / worse

Re: [9fans] new 9atom.iso

[Federico G. Benavento]

that's what I said... it's in the fragment you quoted

anyways, I'm glad that iru heard what we had to say and
we found a solution

On Fri, Aug 28, 2009 at 1:43 PM, Tim Newsham<newsham@lava.net> wrote:
>> I could achieve the same as I did by doing "copy 9load E:" on windows
>> with this new approach, but I'd need to boot some linux live CD
>> and dd my way out to put the new loader there which I'll be too
>> hacky and I'd probably need a version of prepdisk for linux
>> on that live cd as well, if I got it right.
>
> You could just dd or rawrite from windows, as well.
>
>> Federico G. Benavento
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
>
>



--
Federico G. Benavento

Re: [9fans] new 9atom.iso

[Gorka Guardiola]

On Thu, Aug 27, 2009 at 10:14 PM, erik quanstrom<quanstro@coraid.com> wrote:
>> Do we stick with that file format forever? is it perfect and never to
>> be changed?
>
> would it be fair to ask a the same question from a little
> different perspective?
>
> could someone explain what the disadvantages and problems
> with 9fat are?  i'm asking out of ignorance, since 9fat hasn't
> been a problem for me.
>

That it is too complicated to pares in 512 bytes.

-- 
- curiosity sKilled the cat

Re: [9fans] new 9atom.iso

[Gorka Guardiola]

On Fri, Aug 28, 2009 at 9:59 AM, Gorka Guardiola<paurea@gmail.com> wrote:
>> could someone explain what the disadvantages and problems
>> with 9fat are?  i'm asking out of ignorance, since 9fat hasn't
>> been a problem for me.
>>
>
> That it is too complicated to pares in 512 bytes.
>

s/pares/parse/

-- 
- curiosity sKilled the cat

Re: [9fans] new 9atom.iso

[hiro]

perhaps we should try to boot plan 9 from a linux kernel? Sounds great to me...

this probably makes me a troll...

Re: [9fans] new 9atom.iso

[Venkatesh Srinivas]

On Fri, Aug 28, 2009 at 4:54 AM, hiro<23hiro@googlemail.com> wrote:
> perhaps we should try to boot plan 9 from a linux kernel? Sounds great to me...
>
> this probably makes me a troll...
>

I hear ron minnich did that with his lguest port. Does that make him a troll?

-- vs

Re: [9fans] new 9atom.iso

[matt]

Venkatesh Srinivas wrote:

>On Fri, Aug 28, 2009 at 4:54 AM, hiro<23hiro@googlemail.com> wrote:
>
>
>>perhaps we should try to boot plan 9 from a linux kernel? Sounds great to me...
>>
>>this probably makes me a troll...
>>
>>
>>
>
>I hear ron minnich did that with his lguest port. Does that make him a troll?
>
>-- vs
>
>
>
yes, he got us interested in something vicariously and then cast it aside :)

What you gonna do when MS knocks on the door for their FAT patent
license fee

http://arstechnica.com/microsoft/news/2009/02/microsoft-sues-tomtom-over-fat-patents-in-linux-based-device.ars


though maybe the inability to do fat32 will save you.

Editing plan9.ini on dos has saved me more than once, but back when I
was using a floppy (a BSDi labelled one at that)  and its small size has
also hurt me before now too.

I like the sound of the sector 1 idea, I'm sure making a tool to r/w it
in Linux / whatever can't be hard.

Re: [9fans] new 9atom.iso

[erik quanstrom]

> What you gonna do when MS knocks on the door for their FAT patent
> license fee
>
> http://arstechnica.com/microsoft/news/2009/02/microsoft-sues-tomtom-over-fat-patents-in-linux-based-device.ars

i love it.  we have complaining that fat doesn't do more
than 8.3 and trolling that there's a patent liability for
doing more than 8.3 within 24 hrs.

just to be clear.  fat itself is not patented.  just some
particular aspects of a 8.3 workaround.

> though maybe the inability to do fat32 will save you.

dossrv and 9load both read fat32.

> I like the sound of the sector 1 idea, I'm sure making a tool to r/w it
> in Linux / whatever can't be hard.

i think that's the point of using fat.  no tools required.
you're already in a pickle if you've gotten to this point.
consider the acer inspire machine this week that

- erik

Re: [9fans] new 9atom.iso

[matt]

erik quanstrom wrote:

>i love it.  we have complaining that fat doesn't do more
>than 8.3 and trolling that there's a patent liability for
>doing more than 8.3 within 24 hrs.
>
>
thanks but I'm not trolling, not complaining

>just to be clear.  fat itself is not patented.  just some
>particular aspects of a 8.3 workaround.
>
>
>
>>though maybe the inability to do fat32 will save you.
>>
>>
>
>dossrv and 9load both read fat32.
>
>
I was refering to format not dossrv

  BUGS
          Format can create FAT12 and FAT16 file systems, but not
          FAT32 file systems.  The boot block can only read from FAT12
          and FAT16 file systems.

>
>
>>I like the sound of the sector 1 idea, I'm sure making a tool to r/w it
>>in Linux / whatever can't be hard.
>>
>>
>
>i think that's the point of using fat.  no tools required.
>
>
No tools except a second OS installed on your machine / one you can plug
your disk in to

>you're already in a pickle if you've gotten to this point.
>consider the acer inspire machine this week that
>
>
but as you say here, if you're having trouble, you need something to
help you. The great help you've been giving people here was via iso files

Anyway, there are good arguments on both sides. There's only one way to
solve this :

FIGHT

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Fri, Aug 28, 2009 at 9:50 AM, matt<maht-9fans@maht0x0r.net> wrote:
> erik quanstrom wrote:
>
>> i love it.  we have complaining that fat doesn't do more
>> than 8.3 and trolling that there's a patent liability for
>> doing more than 8.3 within 24 hrs.
>>
>
> thanks but I'm not trolling, not complaining
>
>> just to be clear.  fat itself is not patented.  just some
>> particular aspects of a 8.3 workaround.
>>
>>
>>>
>>> though maybe the inability to do fat32 will save you.
>>>
>>
>> dossrv and 9load both read fat32.
>>
>
> I was refering to format not dossrv
>
>  BUGS
>         Format can create FAT12 and FAT16 file systems, but not
>         FAT32 file systems.  The boot block can only read from FAT12
>         and FAT16 file systems.
>
>>
>>>
>>> I like the sound of the sector 1 idea, I'm sure making a tool to r/w it
>>> in Linux / whatever can't be hard.
>>>
>>
>> i think that's the point of using fat.  no tools required.
>>
>
> No tools except a second OS installed on your machine / one you can plug
> your disk in to
>
>> you're already in a pickle if you've gotten to this point.
>> consider the acer inspire machine this week that
>
> but as you say here, if you're having trouble, you need something to help
> you. The great help you've been giving people here was via iso files
>
> Anyway, there are good arguments on both sides. There's only one way to
> solve this :
>
> FIGHT
>

i fought myself.
pbs32 (9null's pbs) now works with 9fat without caring about it.
it loops reading a block and checking for the a.out(8) signature. if
the 9pcload is on 9fat, not a problem anymore.

iru

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Fri, Aug 28, 2009 at 11:54 AM, Iruata Souza<iru.muzgo@gmail.com> wrote:
> On Fri, Aug 28, 2009 at 9:50 AM, matt<maht-9fans@maht0x0r.net> wrote:
>> erik quanstrom wrote:
>>
>>> i love it.  we have complaining that fat doesn't do more
>>> than 8.3 and trolling that there's a patent liability for
>>> doing more than 8.3 within 24 hrs.
>>>
>>
>> thanks but I'm not trolling, not complaining
>>
>>> just to be clear.  fat itself is not patented.  just some
>>> particular aspects of a 8.3 workaround.
>>>
>>>
>>>>
>>>> though maybe the inability to do fat32 will save you.
>>>>
>>>
>>> dossrv and 9load both read fat32.
>>>
>>
>> I was refering to format not dossrv
>>
>>  BUGS
>>         Format can create FAT12 and FAT16 file systems, but not
>>         FAT32 file systems.  The boot block can only read from FAT12
>>         and FAT16 file systems.
>>
>>>
>>>>
>>>> I like the sound of the sector 1 idea, I'm sure making a tool to r/w it
>>>> in Linux / whatever can't be hard.
>>>>
>>>
>>> i think that's the point of using fat.  no tools required.
>>>
>>
>> No tools except a second OS installed on your machine / one you can plug
>> your disk in to
>>
>>> you're already in a pickle if you've gotten to this point.
>>> consider the acer inspire machine this week that
>>
>> but as you say here, if you're having trouble, you need something to help
>> you. The great help you've been giving people here was via iso files
>>
>> Anyway, there are good arguments on both sides. There's only one way to
>> solve this :
>>
>> FIGHT
>>
>
> i fought myself.
> pbs32 (9null's pbs) now works with 9fat without caring about it.
> it loops reading a block and checking for the a.out(8) signature. if
> the 9pcload is on 9fat, not a problem anymore.
>

a.out(6), sorry

Re: [9fans] new 9atom.iso

[Dave Eckhardt]

> pbs32 (9null's pbs) now works with 9fat without caring about it.
> it loops reading a block and checking for the a.out(8) signature.
> if the 9pcload is on 9fat, not a problem anymore.

Tweeeet!  5-yard penalty for making something work better instead of
complaining!

Dave Eckhardt

Re: [9fans] new 9atom.iso

[Uriel]

On Fri, Aug 28, 2009 at 4:54 PM, Iruata Souza<iru.muzgo@gmail.com> wrote:
> On Fri, Aug 28, 2009 at 9:50 AM, matt<maht-9fans@maht0x0r.net> wrote:
>> FIGHT
>>
>
> i fought myself.
> pbs32 (9null's pbs) now works with 9fat without caring about it.
> it loops reading a block and checking for the a.out(8) signature. if
> the 9pcload is on 9fat, not a problem anymore.

Wonderful!

Seems that everyone won the fight in the end.

Perhaps fighting is not as useless as some make it?

Peace

uriel

Re: [9fans] new 9atom.iso

[Noah Evans]

One way of phrasing it:

"I usually need 9fat to choose which kernel I'm going to use depending
on the circumstances, is there anyway that I could reincorporate 9fat
or something like it? What do I need to do to make it possible?"

another way:

"You losers never do anything right, where's my 9fat?"

Which is more productive?

On Sat, Aug 29, 2009 at 1:40 AM, Uriel<uriel99@gmail.com> wrote:
> On Fri, Aug 28, 2009 at 4:54 PM, Iruata Souza<iru.muzgo@gmail.com> wrote:
>> On Fri, Aug 28, 2009 at 9:50 AM, matt<maht-9fans@maht0x0r.net> wrote:
>>> FIGHT
>>>
>>
>> i fought myself.
>> pbs32 (9null's pbs) now works with 9fat without caring about it.
>> it loops reading a block and checking for the a.out(8) signature. if
>> the 9pcload is on 9fat, not a problem anymore.
>
> Wonderful!
>
> Seems that everyone won the fight in the end.
>
> Perhaps fighting is not as useless as some make it?
>
> Peace
>
> uriel
>
>

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Fri, Aug 28, 2009 at 1:54 AM, hiro <23hiro@googlemail.com> wrote:

> perhaps we should try to boot plan 9 from a linux kernel? Sounds great to
> me...
>
> this probably makes me a troll...
>

I'm pretty sure Ron has done that too... from LinuxBIOS.

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

Re: [9fans] new 9atom.iso

[erik quanstrom]

> I'm pretty sure Ron has done that too... from LinuxBIOS.

i'm pretty sure that coreboot neé linuxbios is not linux.

- erik

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Fri, Aug 28, 2009 at 8:19 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > I'm pretty sure Ron has done that too... from LinuxBIOS.
>
> i'm pretty sure that coreboot neé linuxbios is not linux.
>

Could be, I've never had the luxury of trying it all out... however I
thought a minimal linux from coreboot/linuxbios (I think it was called
linuxbios when this was tried) could kexec plan 9.  I may be remembering
incorrectly though (as usual).

Dave


>
> - erik
>
>

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

Re: [9fans] new 9atom.iso

[ron minnich]

On Fri, Aug 28, 2009 at 8:24 AM, David Leimbach<leimy2k@gmail.com> wrote:

> Could be, I've never had the luxury of trying it all out... however I
> thought a minimal linux from coreboot/linuxbios (I think it was called
> linuxbios when this was tried) could kexec plan 9.

Actually i wrote something in 1999 called lobos that preceded kexec,
and maybe even /dev/reboot (not sure).

I still recall a linux groupie telling me that "Linus would never
accept linux rebooting linux into the kernel" ... ha!

I've got a reasonable summary article of kernels booting kernels --
all 5 versions of them -- in some cluster 200x paper. It concluded
that Plan 9 was the cleanest of the lot. Surprise!

ron

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Fri, Aug 28, 2009 at 8:33 AM, ron minnich <rminnich@gmail.com> wrote:

> On Fri, Aug 28, 2009 at 8:24 AM, David Leimbach<leimy2k@gmail.com> wrote:
>
> > Could be, I've never had the luxury of trying it all out... however I
> > thought a minimal linux from coreboot/linuxbios (I think it was called
> > linuxbios when this was tried) could kexec plan 9.
>
> Actually i wrote something in 1999 called lobos that preceded kexec,
> and maybe even /dev/reboot (not sure).
>
> I still recall a linux groupie telling me that "Linus would never
> accept linux rebooting linux into the kernel" ... ha!
>
> I've got a reasonable summary article of kernels booting kernels --
> all 5 versions of them -- in some cluster 200x paper. It concluded
> that Plan 9 was the cleanest of the lot. Surprise!


Did that pre-date the "two kernel monte" that used to be used on Scyld's
"Beowulf" thing?

Also, Eric, the 9atom.iso works on my older AMD machine for installation!
 THANKS! :-)


>
>
> ron
>
>

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

Re: [9fans] new 9atom.iso

[erik quanstrom]

> Also, Eric, the 9atom.iso works on my older AMD machine for installation!
>  THANKS! :-)

hey!  back to the original story line.  that's great, and
you're welcome.  i'd encourage anyone to report on
your success or failure with 9atom offline.
the goal is to get everything that should work working.

- erik

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Fri, Aug 28, 2009 at 8:46 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Also, Eric, the 9atom.iso works on my older AMD machine for installation!
> >  THANKS! :-)
>
> hey!  back to the original story line.  that's great, and
> you're welcome.  i'd encourage anyone to report on
> your success or failure with 9atom offline.
> the goal is to get everything that should work working.
>
> - erik
>
>
To further report the machine seems to be running after installation quite
"snappily" though I seem to have messed something up and get a lot of
messages about failed venti writes, due to a lack of a connection.

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

Re: [9fans] new 9atom.iso

[matt]

>
> To further report the machine seems to be running after installation
> quite "snappily" though I seem to have messed something up and get a
> lot of messages about failed venti writes, due to a lack of a connection.
>
>
>

venti=/dev/sdC0/venti
or
venti=#S/sdC0/venti

in plan9.ini
not sure which is best, I have the former and it works but the latter
was already in my plan9.ini and that didn't work but that might be
something else and I've never experimented after it worked :)

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Fri, Aug 28, 2009 at 9:37 AM, matt <maht-9fans@maht0x0r.net> wrote:

>
>
>> To further report the machine seems to be running after installation quite
>> "snappily" though I seem to have messed something up and get a lot of
>> messages about failed venti writes, due to a lack of a connection.
>>
>>
>>
>>
> venti=/dev/sdC0/venti
> or
> venti=#S/sdC0/venti
>
> in plan9.ini
> not sure which is best, I have the former and it works but the latter was
> already in my plan9.ini and that didn't work but that might be something
> else and I've never experimented after it worked :)
>

Thanks with 9atom, I just re-installed and installed a venti+fossil :-).
 That got rid of the messages, and I think I wanted to have venti anyhow.

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

Re: [9fans] new 9atom.iso

[erik quanstrom]

> > venti=/dev/sdC0/venti
> > or
> > venti=#S/sdC0/venti
> >
> > in plan9.ini
> > not sure which is best, I have the former and it works but the latter was
> > already in my plan9.ini and that didn't work but that might be something
> > else and I've never experimented after it worked :)
> >
>
> Thanks with 9atom, I just re-installed and installed a venti+fossil :-).
>  That got rid of the messages, and I think I wanted to have venti anyhow.

great!  just as an aside, 9load-e820 contains a hack which
allows one to use bootdev and bootpath as replaceable
parameters.  if venti is on your boot disk, you could say

	venti=bootpath/venti

the mechanism behind this needs to be fixed, but i've
enjoyed not working about which sata port the cdrom
or boot disk is plugged into.

- erik

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Fri, Aug 28, 2009 at 9:23 AM, David Leimbach <leimy2k@gmail.com> wrote:

>
>
> On Fri, Aug 28, 2009 at 8:46 AM, erik quanstrom <quanstro@quanstro.net>wrote:
>
>> > Also, Eric, the 9atom.iso works on my older AMD machine for
>> installation!
>> >  THANKS! :-)
>>
>> hey!  back to the original story line.  that's great, and
>> you're welcome.  i'd encourage anyone to report on
>> your success or failure with 9atom offline.
>> the goal is to get everything that should work working.
>>
>> - erik
>>
>>
> To further report the machine seems to be running after installation quite
> "snappily" though I seem to have messed something up and get a lot of
> messages about failed venti writes, due to a lack of a connection.
>

Now that I've had a chance to really examine the system, I'm noticing a
rather high interrupt count (1584), and I'm not exactly sure how to figure
out what's triggering them.

I did not install venti.  I just configured my ip address for DHCP, and I've
got aux/timesync running (I think that was suspect before for some reason).
 Stats shows interrupts as a solid rectangle of activity all the time.

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

Re: [9fans] new 9atom.iso

[erik quanstrom]

> Now that I've had a chance to really examine the system, I'm noticing a
> rather high interrupt count (1584), and I'm not exactly sure how to figure
> out what's triggering them.

i set HZ=1000.  so that accounts for 1000 of them.  i've also modified
/dev/irqalloc to count up the interrupts, so you should get a rough idea
of which irqs are responsible.  i say rough because chaned interrupts
can confuse the matter a bit.

> I did not install venti.  I just configured my ip address for DHCP, and I've
> got aux/timesync running (I think that was suspect before for some reason).
>  Stats shows interrupts as a solid rectangle of activity all the time.

i get that too from stats.  it's just tuned to HZ=100.  the reason for the
increase is so that millisecond sleeps can work a bit better.  on all the
systems i use, the overhead is not worth worring about.

- erik

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Sat, Aug 29, 2009 at 10:25 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Now that I've had a chance to really examine the system, I'm noticing a
> > rather high interrupt count (1584), and I'm not exactly sure how to
> figure
> > out what's triggering them.
>
> i set HZ=1000.  so that accounts for 1000 of them.  i've also modified
> /dev/irqalloc to count up the interrupts, so you should get a rough idea
> of which irqs are responsible.  i say rough because chaned interrupts
> can confuse the matter a bit.
>
> > I did not install venti.  I just configured my ip address for DHCP, and
> I've
> > got aux/timesync running (I think that was suspect before for some
> reason).
> >  Stats shows interrupts as a solid rectangle of activity all the time.
>
> i get that too from stats.  it's just tuned to HZ=100.  the reason for the
> increase is so that millisecond sleeps can work a bit better.  on all the
> systems i use, the overhead is not worth worring about.
>

Ah, I see so these are just normal interrupts of a healthy beating heart of
a system.  :-)

I was a little concerned I had configured something incorrectly.

Thanks for the explanation.


>
> - erik
>
>

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

Re: [9fans] new 9atom.iso

[ron minnich]

On Fri, Aug 28, 2009 at 8:37 AM, David Leimbach<leimy2k@gmail.com> wrote:

> Did that pre-date the "two kernel monte" that used to be used on Scyld's
> "Beowulf" thing?

I think Eric Hendriks and I started development at the same time, but
mine was working first. No longer sure.

But Biederman's code won out, and is in the kernel.

ron

Re: [9fans] new 9atom.iso

[ron minnich]

On Fri, Aug 28, 2009 at 8:19 AM, erik quanstrom<quanstro@quanstro.net> wrote:
>> I'm pretty sure Ron has done that too... from LinuxBIOS.
>
> i'm pretty sure that coreboot neé linuxbios is not linux.

it was. It is not any longer. But for the first year of our existence,
1999-2000, linuxbios really was linux. But then linux got big, and
that was that.

ron

Re: [9fans] new 9atom.iso

[ron minnich]

On Fri, Aug 28, 2009 at 8:31 AM, ron minnich<rminnich@gmail.com> wrote:

> it was. It is not any longer. But for the first year of our existence,
> 1999-2000, linuxbios really was linux.

plus some special extra bits, of course ...

ron

Re: [9fans] new 9atom.iso

[erik quanstrom]

> > it was. It is not any longer. But for the first year of our existence,
> > 1999-2000, linuxbios really was linux.
>
> plus some special extra bits, of course ...

even in those days, linux was quite large.  wasn't most
of it just dead weight?

- erik

Re: [9fans] new 9atom.iso

[Tim Newsham]

> for the ones interested, the code is at http://src.oitobits.net/9null.
> i'm writing a README explaining how to compile and install.

Are there plans for this to get folded into the mainline?

> iru

Tim Newsham
http://www.thenewsh.com/~newsham/

Re: [9fans] new 9atom.iso

[Iruata Souza]

On Thu, Aug 27, 2009 at 4:07 PM, Tim Newsham<newsham@lava.net> wrote:
>> for the ones interested, the code is at http://src.oitobits.net/9null.
>> i'm writing a README explaining how to compile and install.
>
> Are there plans for this to get folded into the mainline?
>

I wrote it with the hope of getting it into the mainline, so the
choice is up to people with access to the labs.

iru

Re: [9fans] new 9atom.iso

[erik quanstrom]

> I think there's work going on to use plan 9 to load plan 9 (maybe?) to
> replace 9load.  However, is there any chance of getting your 9load in the
> mainline if/once people determine it to support more hardware?

i would hope so.  it's pretty closely tied to the sd stuff i've been
working on.

it does have a few other things, too.  the nifty trick is to be
able to automaticly remember the bootdev so that bootdev
can be used as a replacable parameter.  this allows a single
plan9.ini to be able to boot from sdC0 sdD0 sdE1 or whatever.

- erik

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Thu, Aug 27, 2009 at 9:16 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> > 2009/8/26 erik quanstrom <quanstro@quanstro.net>:
> > > it contains all the changes from the last 10 days.
> > > should fix all reported problems, except béla's.
> >
> > Could you post the link? I am new to this list and plan9, and i can
> > not find a 9atom.iso, but a plan9.iso.bz2 [1]
> > It would also be helpful for me reading some introductory material, i
> > guess i can find it, but if you know some reference i would appreciate
> > it.
>
> the link is
>         ftp://ftp.quanstro.net/other/9atom.iso.bz2
>         cf819b70c90cedc39e305fb57d38f5df37302f84        Aug 26 09:13
> 9atom.iso.bz2


I really don't understand why, from home or work, I can't download this
thing...

cf819b70c90cedc39e305fb57d38f5df37302f84

Is the checksum I'm getting.

When I download via a web browser it gets to the last bit of the data, and
craps out.  When I use an ftp client, it claims it is complete, but then
gets the wrong checksum.

I'm totally baffled.  Is there somewhere else I can try to pull this from?

Dave

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

Re: [9fans] new 9atom.iso

[erik quanstrom]

> I really don't understand why, from home or work, I can't download this
> thing...
>
> cf819b70c90cedc39e305fb57d38f5df37302f84
>
> Is the checksum I'm getting.

that's the same checksum i posted.  i guess i don't understand
the problem.  the file size is 88153831.

> When I download via a web browser it gets to the last bit of the data, and
> craps out.  When I use an ftp client, it claims it is complete, but then
> gets the wrong checksum.
>
> I'm totally baffled.  Is there somewhere else I can try to pull this from?

no alternate locations.  sorry.

- erik

Re: [9fans] new 9atom.iso

[Lyndon Nerenberg]

> no alternate locations.  sorry.

You sure you don't want me to mirror this stuff?

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Thu, Aug 27, 2009 at 1:20 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > I really don't understand why, from home or work, I can't download this
> > thing...
> >
> > cf819b70c90cedc39e305fb57d38f5df37302f84
> >
> > Is the checksum I'm getting.
>
> that's the same checksum i posted.  i guess i don't understand
> the problem.  the file size is 88153831.


Yeah, I realized that after I posted I sent the wrong checksum.
e4441484b67be72ad0fd62cc828052f6 9atom.iso.bz2

is what I got.


>
>
> > When I download via a web browser it gets to the last bit of the data,
> and
> > craps out.  When I use an ftp client, it claims it is complete, but then
> > gets the wrong checksum.
> >
> > I'm totally baffled.  Is there somewhere else I can try to pull this
> from?
>
> no alternate locations.  sorry.
>
> - erik
>
>

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

Re: [9fans] new 9atom.iso

[erik quanstrom]

> Yeah, I realized that after I posted I sent the wrong checksum.
> e4441484b67be72ad0fd62cc828052f6 9atom.iso.bz2
>
> is what I got.

that's the proper md5sum.  i posed the sha1sum.
maybe i didn't make that clear.

- erik

Re: [9fans] new 9atom.iso

[David Leimbach]

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

On Thu, Aug 27, 2009 at 1:59 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Yeah, I realized that after I posted I sent the wrong checksum.
> > e4441484b67be72ad0fd62cc828052f6 9atom.iso.bz2
> >
> > is what I got.
>
> that's the proper md5sum.  i posed the sha1sum.
> maybe i didn't make that clear.
>
> - erik
>
> argh... :-(

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

Re: [9fans] new 9atom.iso

[Lyndon Nerenberg]

There is a searchable mailing list archive at
http://9fans/net/archive that's quite useful.

--lyndon

Re: [9fans] new 9atom.iso

[erik quanstrom]

> great!  just as an aside, 9load-e820 contains a hack which
> allows one to use bootdev and bootpath as replaceable
> parameters.  if venti is on your boot disk, you could say
>
>         venti=bootpath/venti
>
> the mechanism behind this needs to be fixed, but i've
> enjoyed not working about which sata port the cdrom
> or boot disk is plugged into.

the mechanism has now been fixed and all assignments
in plan9.ini become replacable parameters.  a $ is used to
indicate a variable indirection.  9load will assign bootdev
and bootpath automaticly as a convience.  e.g. sdE0 and
#S/sdE0.  our previous example should now read
	venti=$bootpath/venti
(the previous example will temporarly be accepted.)

there are a few other things along for the ride.

if you are using 9load menus, you can add 9load variables
by typing them in like this at the menu prompt.
	a console=0 b19200
one could remove the debug option from the 9atom cd
knowing that one could always enter
	a *debug=1
at the menu.

added bonus: small corrections to the e820 scan.

- erik