headers
Julio Merino | 1 Feb 2003 12:11

Re: install/5050 - Fix for this PR?

Hello,

What about the following fix for this PR? This seems the best solution
imho, as we let the user choose how many chunks he wants (and lets him
write chunks of any size). As he will be writting disks, he will know
how many disks contain each set.

Just to say that the hardcoded number of floppies is out of sync with
reality. I tried to install 1.6 and had to figure which was the proper
chunk size to create each disk set (so they matched the value in sysint).

Here is the patch. Comments?

Index: menus.mi.en
===================================================================
RCS file: /cvsroot/src/distrib/utils/sysinst/menus.mi.en,v
retrieving revision 1.63
diff -u -u -r1.63 menus.mi.en
--- menus.mi.en	2003/01/22 05:59:07	1.63
+++ menus.mi.en	2003/02/01 10:37:57
 <at>  <at>  -329,6 +329,7  <at>  <at> 

 menu fdremount, title "What do you want to do?";
 	option "Try again", exit, action { yesno = 1; };
+	option "Set is finished", exit, action { yesno = 2; };
 	option "Abort install", exit, action { yesno = 0; };

 menu fdok, title "Hit enter to continue";
Index: msg.mi.en
===================================================================
(Continue reading)

Permalink | Reply | 501 comments |
headers
David Brownlee | 1 Feb 2003 19:17
Picon

Re: install/5050 - Fix for this PR?

On Sat, 1 Feb 2003, Julio Merino wrote:

> Hello,
>
> What about the following fix for this PR? This seems the best solution
> imho, as we let the user choose how many chunks he wants (and lets him
> write chunks of any size). As he will be writting disks, he will know
> how many disks contain each set.
>
> Just to say that the hardcoded number of floppies is out of sync with
> reality. I tried to install 1.6 and had to figure which was the proper
> chunk size to create each disk set (so they matched the value in sysint).
>
> Here is the patch. Comments?

	It would probably make sense to nuke fdlast from distinfo altogether.

	Thinking about it - sysinst should be able to tell when you hit the
	last disk:

	Suggestion (I):

	  Define a set of known disk sizes

	  When building sets:
	    - If its a single image and any of the known disk sizes, add a
	      null byte
	    - If the last disk in a set, and the same as the other disk
	      images, add a null byte
(Continue reading)

Permalink | Reply | 501 comments |
headers
John Hawkinson | 6 Feb 2003 19:23
Picon
Favicon

Criteria for TINY install media

Moved to tech-install; source-changes remains in the envelope.

David Brownlee <abs <at> netbsd.org> wrote on Thu,  6 Feb 2003
at 13:37:03 +0000 in <Pine.NEB.4.53.0302061336070.364 <at> dev.6nations.co.uk>:

> I think the criteria for TINY should be 'has a hope of working
> on 4MB machines', and as such any increase in size should be
> avoided whenever possible...

This seems reasonable criteria.
However there's no good way to do it with the current implementation.

One should be able to say "in all sets except TINY," or otherwise
usefully express exclusions. Would you care to implement [or suggest
implementation] of a good way to do that?

--jhawk

> Date: Thu, 6 Feb 2003 13:37:03 +0000 (GMT)
> From: David Brownlee <abs <at> netbsd.org>
> To: Luke Mewburn <lukem <at> netbsd.org>
> cc: John Hawkinson <jhawk <at> MIT.EDU>, source-changes <at> netbsd.org
> Subject: Re: CVS commit: src/distrib/utils/sysinst
> In-Reply-To: <20030122215951.GQ6481 <at> mewburn.net>
> Message-ID: <Pine.NEB.4.53.0302061336070.364 <at> dev.6nations.co.uk>
> 
> On Thu, 23 Jan 2003, Luke Mewburn wrote:
> 
> > On Wed, Jan 22, 2003 at 11:33:47AM -0500, John Hawkinson wrote:
> >   |
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Chacon | 7 Feb 2003 05:25
Picon

Re: Criteria for TINY install media

Well it mainly means that either TINY should be split out from including 
anything in the normal builds or the "standard" list really is pruned down
to just the essentials.

TINY is kind of a 1 off for x86. 

James

>
>Moved to tech-install; source-changes remains in the envelope.
>
>David Brownlee <abs <at> netbsd.org> wrote on Thu,  6 Feb 2003
>at 13:37:03 +0000 in <Pine.NEB.4.53.0302061336070.364 <at> dev.6nations.co.uk>:
>
>> I think the criteria for TINY should be 'has a hope of working
>> on 4MB machines', and as such any increase in size should be
>> avoided whenever possible...
>
>This seems reasonable criteria.
>However there's no good way to do it with the current implementation.
>
>One should be able to say "in all sets except TINY," or otherwise
>usefully express exclusions. Would you care to implement [or suggest
>implementation] of a good way to do that?
>
>--jhawk
>
>> Date: Thu, 6 Feb 2003 13:37:03 +0000 (GMT)
>> From: David Brownlee <abs <at> netbsd.org>
>> To: Luke Mewburn <lukem <at> netbsd.org>
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Laight | 7 Feb 2003 09:46
Picon

Clean installation problems

I've just done a clean, default, install and found a few little problems
that would certainly put off a naive user.

Everything went swimmingly until I rebooted of the hard disk.
At this point we find:

1) init has to create a mfs /dev because /dev/console is absent.
   There are two problems:
   a) There are chgrp and chown calls in MAKEDEV, but these program
      are in /usr/sbin so are not available.
   b) It is impossible to unmount /dev in order to run MAKEDEV in the
      root filesystem itself.  The filesystem is always busy.

2) Because /etc/rc.conf still contains 'rc_configured=NO' the system
   immediately drops into single user mode.
   At this point you have problems because:
   a) /usr isn't mounted so the useful programs are absent
   b) / is still readonly so you can't modify any files and no one
      can make any temporary files
   c) TERM is unset so editors like 'vi' wont work.
   d) On some systems (eg sparc) stty rows and columns are both zero.
      So if your TERM type is one that expects a variable sized screen
      (eg xterm froma serial console) then you can't run vi (etc).

	David

--

-- 
David Laight: david <at> l8s.co.uk
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Brownlee | 7 Feb 2003 11:06
Picon

Re: Criteria for TINY install media

On Thu, 6 Feb 2003, James Chacon wrote:

> Well it mainly means that either TINY should be split out from including
> anything in the normal builds or the "standard" list really is pruned down
> to just the essentials.
>
> TINY is kind of a 1 off for x86.

	Though the same constraints apply to other ports, where less
	memory is a more common occurence.

--

-- 
		David/absolute          -- www.netbsd.org: No hype required --
Permalink | Reply | 0 comments |
headers
David Brownlee | 7 Feb 2003 11:31
Picon

Re: Criteria for TINY install media

On Thu, 6 Feb 2003, John Hawkinson wrote:

> Moved to tech-install; source-changes remains in the envelope.
>
> David Brownlee <abs <at> netbsd.org> wrote on Thu,  6 Feb 2003
> at 13:37:03 +0000 in <Pine.NEB.4.53.0302061336070.364 <at> dev.6nations.co.uk>:
>
> > I think the criteria for TINY should be 'has a hope of working
> > on 4MB machines', and as such any increase in size should be
> > avoided whenever possible...
>
> This seems reasonable criteria.
> However there's no good way to do it with the current implementation.
>
> One should be able to say "in all sets except TINY," or otherwise
> usefully express exclusions. Would you care to implement [or suggest
> implementation] of a good way to do that?

	Currently sysinst conditionally checks for dhclient, which is
	omitted on tiny. The same could be done for progress, though
	that would involve adding 'PROG    usr/bin/progress' to N
	different list.* files.

	A while back I had a look at merging the various .list files
	across different architectures by passing it through m4 first.
	The same could be done with an extra option for 'TINY'...

--

-- 
		David/absolute          -- www.netbsd.org: No hype required --
(Continue reading)

Permalink | Reply | 0 comments |
headers
Perry E. Metzger | 7 Feb 2003 18:44
Gravatar

Re: Clean installation problems


David Laight <david <at> l8s.co.uk> writes:
> I've just done a clean, default, install and found a few little problems
> that would certainly put off a naive user.
> 
> Everything went swimmingly until I rebooted of the hard disk.
> At this point we find:
> 
> 1) init has to create a mfs /dev because /dev/console is absent.
>    There are two problems:

That happened on a clean default install on an x86? I've done several
of these recently and although I've had issues, that wasn't one of
them.

Perry
Permalink | Reply | 6 comments |
headers
David Laight | 7 Feb 2003 19:03
Picon

Re: Clean installation problems

> > 1) init has to create a mfs /dev because /dev/console is absent.
> >    There are two problems:
> 
> That happened on a clean default install on an x86? I've done several
> of these recently and although I've had issues, that wasn't one of
> them.

It was, it may be that I managed to abort it slightly early.
The CD image I was using was missing the X sets.
I rebooted (from the menu) at the point where IIRC there was
a question about configuring the network - that system doesn't
have a network card.

I also ended up without a root password....

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 5 comments |
headers
Perry E. Metzger | 7 Feb 2003 19:18
Gravatar

Re: Clean installation problems


David Laight <david <at> l8s.co.uk> writes:
> > > 1) init has to create a mfs /dev because /dev/console is absent.
> > >    There are two problems:
> > 
> > That happened on a clean default install on an x86? I've done several
> > of these recently and although I've had issues, that wasn't one of
> > them.
> 
> It was, it may be that I managed to abort it slightly early.

Running MAKEDEV is one of the last things that happens, so it isn't
surprising.

The mfs /dev/ hack was designed to allow booting on FAT file systems
and other systems where there is no ability to build device nodes --
it isn't really intended that people run into this ordinarily...

--

-- 
Perry E. Metzger		perry <at> piermont.com
Permalink | Reply | 4 comments |

Gmane