Installing 9front

[Uriel]

So I told cinap that if he got Go working on 9front I would install 9front.

And of course, in like 15min he had Go up and running.

So I had to install 9front.

Well, the installer sucks, it is much better than the old installer,
but still SUCKS.

1) Stupid shit like this: http://harmful.cat-v.org/_9front/config-config.png

config: config: config: config: config: config:?!? Really? WTF?

2) Too many questions, and worse, some of them have no defaults when
there is an obvious default, this is still much improved from the old
installer, and just pressing enter works *almost* all the time, there
is no reason to not finish this up. (Also, a 'quick install' option
might be a good idea, to spare you from pressing enter a hundred
times).

3) Not only are the disk space requirements are somewhat high, but you
get no warning if your disk is too small, you go all the way into
copydist, which barfs on disk full errors, but 'completes' anyway and
pretends it is done and that you can go on with the next install step.

At the very least we should warn if the disk is too small, and
probably we should fail before going into copydist.

4) Yes, there is disk size advice in the Wiki Install page, but why
should I look at the wiki? Anyway the install page is HUGE and is full
of useless screendumps from the installer. Most of the useful bits of
info from that page should just be incorporated into the installer
itself (which anyway already prints too much useless shit, like
endless streams of "config:").

All that said, I can't believe I'm in a Plan 9 system and I can do hg
inc and hg log and get meaningful information about changes!!!! I feel
like I must be dreaming.

Awesome.

Uriel

[s...@9front.org]

> 4) Yes, there is disk size advice in the Wiki Install page, but why
> should I look at the wiki? Anyway the install page is HUGE and is full
> of useless screendumps from the installer. Most of the useful bits of
> info from that page should just be incorporated into the installer
> itself (which anyway already prints too much useless shit, like
> endless streams of "config:").

The endless stream of "config:" is just output from the cwfs console
as it returns to the prompt ("config:") after each command is performed.
Perhaps the output could be run through sed or awk to remove things
we don't want to print on the screen.

The purpose of the wiki page is to demonstrate a typical install
and explain what each step of the process is doing. This is intended
to provide some insight for new users into how each necessary piece
of the system is configured. I agree, the portions that cover the installer
itself are too sparse in some places. If the installer were a bit clearer in
some places we could probably do without such an elaborate walkthrough.

I decided to include the complete text of the install because I couldn't
determine a good way to cut things out without potentially confusing
the reader. Which lines, specifically, should be removed? Keep in mind
that the purpose of the document is to walk through the install step-
by-step, providing some idea of what is happening. Also keep in mind
that edits are always welcome. Especially since you are coming to this
cold and can see gaps in the documentation we've all been taking as
givens.

The original wiki page had a bullet point list with six items that
essentially just said "insert the cd-rom and boot it and follow the
prompts." The complaints about that page were that it was too
short and didn't say enough.

-sl

[Matthew Veety]

On 7/30/12 7:09 AM, Uriel wrote:
> 3) Not only are the disk space requirements are somewhat high, but you
> get no warning if your disk is too small, you go all the way into
> copydist, which barfs on disk full errors, but 'completes' anyway and
> pretends it is done and that you can go on with the next install step.
>
> At the very least we should warn if the disk is too small, and
> probably we should fail before going into copydist.

I agree with you here, an option to use kfs would be awesome, especially
because cwfs is overkill for non-fileserver cases.

Also, I think work should be done to make cwfs a little more versatile
when it comes to disk size.

--
Veety

[Uriel]

On Mon, Jul 30, 2012 at 4:57 PM, <s...@9front.org> wrote:
>> 4) Yes, there is disk size advice in the Wiki Install page, but why
>> should I look at the wiki? Anyway the install page is HUGE and is full
>> of useless screendumps from the installer. Most of the useful bits of
>> info from that page should just be incorporated into the installer
>> itself (which anyway already prints too much useless shit, like
>> endless streams of "config:").
>
> The endless stream of "config:" is just output from the cwfs console
> as it returns to the prompt ("config:") after each command is performed.
> Perhaps the output could be run through sed or awk to remove things
> we don't want to print on the screen.
>
> The purpose of the wiki page is to demonstrate a typical install

A typical install should be: press enter repeatedly until you are done.

And we are already quite close to that.

As for explaining what is happening in each step, the installer should
be self-documenting and tell you what it is doing.

The install guide should cover things that are technically hard to
cover in the installer itself, like perhaps how to setup network
booting, what to do if something goes wrong or if you can't even get
the installer started, and things like that.

But probably the most important is we need an easy way to test changes
to the installer, building a new iso and then re-installing in a vm is
not practical for little script changes.

Maybe we could have a 'fake' install environment somehow that is easy
to reset and where you can run the whole installer system inside a rio
window. Not sure how practical and difficult this could be to arrange,
but seems like it should be feasible and should make it much easier to
polish the installer script(s).

Uriel

[Uriel]

I'm not convinced that adding extra complexity to save some Gb is
worth it, it creates a very different kind of system to test.

I'd rather handle properly the situations where there is no enough
space, and trim the system where it is reasonable (maybe look into a
way to 'clip' the hg history?)

Uriel

[Julius Schmidt]

> I agree with you here, an option to use kfs would be awesome, especially
> because cwfs is overkill for non-fileserver cases.
>
> Also, I think work should be done to make cwfs a little more versatile when
> it comes to disk size.

i'm working on an fs which "does both".

[s...@9front.org]

> But probably the most important is we need an easy way to test changes
> to the installer, building a new iso and then re-installing in a vm is
> not practical for little script changes.
>
> Maybe we could have a 'fake' install environment somehow that is easy
> to reset and where you can run the whole installer system inside a rio
> window. Not sure how practical and difficult this could be to arrange,
> but seems like it should be feasible and should make it much easier to
> polish the installer script(s).

This is not a bad idea. The current installer is simply modified from
the Bell Labs scripts.

-sl

[Matthew Veety]

I'm very interested in that. Code?

[Julius Schmidt]

> I'm very interested in that. Code?

will be released when it's in an anywhere near usable state.

[Matthew Veety]

On 7/30/12 7:14 PM, Julius Schmidt wrote:
>> I'm very interested in that. Code?
>
> will be released when it's in an anywhere near usable state.

Well I don't give a shit about usable, I wanna help.

[Ethan Grammatikidis]

On Mon, 30 Jul 2012 13:09:42 +0200
Uriel <ur...@berlinblue.org> wrote:

> So I told cinap that if he got Go working on 9front I would install 9front.
>
> And of course, in like 15min he had Go up and running.

*grin* I'm not surprised, somehow.

I just wanted to +1 everything in this mail, but I've feeling like a
human being again for the first time in weeks. I'll try to have a look
at the installer (and the rest of the thread) after catching up with
some other crap.

--
This is obviously some strange usage of the
word "simple" that I was previously unaware of.

[Ethan Grammatikidis]

No need, you can run a dump-free cwfs. Making the installer support (and explain) that should be quite trivial.

[Ethan Grammatikidis]

On Mon, 30 Jul 2012 20:30:05 +0200
Uriel <ur...@berlinblue.org> wrote:

> Maybe we could have a 'fake' install environment somehow that is easy
> to reset and where you can run the whole installer system inside a rio
> window. Not sure how practical and difficult this could be to arrange,
> but seems like it should be feasible and should make it much easier to
> polish the installer script(s).

Wat? The installer already runs in a rio window on a normal (I think)
live-CD system. I'm fairly confident I could pull the install scripts
onto my running system and use them to, say, install to a USB drive or
whatever. Hm... I think if you wanted the option of killing the
installer to get a completely fresh start you'd just have to clean up
some scripts in /tmp.

[Steven Ruckdashel]

I think most people that would benefit from the streamlined installer
are trying to install within QEMU. Maybe making an install option for
this and having the installer do a complete setup with no additional
input.