[9fans] a problem I don't understand on a reinstall

[9fans] a problem I don't understand on a reinstall

[ron minnich]

I had a T21, with partitions:
9fat
fs
swap

I booted the install cd, and using prepdisk I delete swap and fs, then
added
fossil
arenas0
arenas1
isect0
isect1
swap

Then I installed. Once done, it would not boot. Plan9.ini was rewritten by
the install, but set up with the local file system as local!#S/sdC0/fs,
not local!#S/sdC0/fossil.

Booted CD, ran 9fat:, changed it to fossil, instead of fs, it still
wouldn't boot. 9load complains that it can't find any partitions other
than 9fat.

reinstalled. No good. On the reinstall the 9fat was not updated, so still
had the identical plan9.ini.

Reinstalled, but this time using prep I deleted all partitions, including
9fat, then added them back, resizing them for good measure.

Still failed to boot, it's still trying to find 'fs', not 'fossil'.

ARG!

Found on booting cdrom to look around that 9fat, though resized, was
unchanged: plan9.ini was the same as before the delete all partitions,
reallocate all partitions step.

Well, what's going on here? how do I get this cd to wipe everything down
to completely clean state when it installs? Should I run fdisk/mbr from
the boot cd, then try it? It's as though too much state is being saved in
the boot info somewhere, across installs. Is it not setting up 9load
correctly? Is it not replacing 9load with a new one?

ron

Re: [9fans] a problem I don't understand on a reinstall

[Russ Cox]

> Well, what's going on here? how do I get this cd to wipe everything down
> to completely clean state when it installs? Should I run fdisk/mbr from
> the boot cd, then try it? It's as though too much state is being saved in
> the boot info somewhere, across installs. Is it not setting up 9load
> correctly? Is it not replacing 9load with a new one?

first, use the bleeding-edge cd-rom,
just in case it has a fix that you need.
(but i doubt it does).

when you get into the install at the beginning,
draw a new window and

	cp /dev/zero /dev/sdC0/data

and then wait a few seconds and hit delete.
that should clear things pretty good.

russ

Re: [9fans] My Eu paper, mark 2

[John DeGood]

Geoff Collyer <geoff@collyer.net> wrote:

> And MIPS's compilers are elephantine, so it's likely that
> they had armies working on them.

Below is a response from Steve Correll <sjc@pobox.com>,
a member of the original MIPS compiler team.

John

 > You're welcome to attribute this to me if you want to post a followup.
 >
 > Today's MIPS compilers may be the product of an army, but for version
 > 1.0 there was just a platoon (benefiting, of course, from the AT&T
 > compiler front ends, Berkeley dbx, and various Stanford research
 > projects):
 >
 > Fred Chow - optimizer
 > Steve Correll - assembler, prof
 > Kevin Enderby - ld
 > Steve Hanson - f77, cc
 > Mark Himelstein - dbx
 > John Ho - codegen
 > Earl Killian - codegen, pixie
 > Larry Weber - assembler

Re: [9fans] a problem I don't understand on a reinstall

[ron minnich]

On Thu, 16 Oct 2003, Russ Cox wrote:

> first, use the bleeding-edge cd-rom,
> just in case it has a fix that you need.
> (but i doubt it does).

No, I was using that CDROM and still saw the 'historical partitions'.


> when you get into the install at the beginning,
> draw a new window and
>
> 	cp /dev/zero /dev/sdC0/data

That did it. There's nothing like splating the disk with zeros to clean up
things. Nice, clean oxide oersteds.

ron