Hi Havard,

> OK, than I think PR#22508 doesn't describe the same problem as the one
> you are experiencing -- the PR clearly says "sysinst fails".

You're right, and I realized that clearly on reading your response. I
move to remove the discussion of the PR from this thread :-)

(My apologies, too, as introducing it was my fault.)

> The problem you are having appears to be that if you want to use the
> system as a development platform and don't create a separate /tmp (use
> the default partitioning setup in sysinst), the amount of free space
> in the default sized root file systme is too small to allow the system
> to build itself.
> 
> Is that accurate?

It is accurate in describing what I have run into. However, this is also
only accurate if 32M is the default / size and /tmp is not separated
from it. In the install I have, /home and /root are also part of /, so
space quickly became an issue - which is why I started examining what
happened with the default partitioning scheme. The reason I am stating
these qualifiers is because a couple people have said the default
partition scheme is /+swap. I have two installs here, one an upgrade
from 1.6.2, and the other that has gone back and forth from NetBSD and
MacOS (full reformats and installs, not shared disks). Both disks ended
up with a 32M / after using the default partitioning scheme in sysinst.

I am checking on the macppc list to see if it is possible that due to
some overlap of disk formatting methods sysinst can pick up NetBSD
installs in a life prior to a MacOS HFS life.

Further discussion of this aspect of the thread is not relevant to this
list, so we can resume this on the macppc list, or offline :-)

> I think the current situation with sysinst is that it suggests the
> absolute minimum sized partitions.  This does not take into account
> any extraordinary needs, such as using it as a development system.
> Currently, the user installing a system which needs to to cater for
> particular needs must use his own experience when deciding on the
> partitioning.  Perhaps introducing "partition themes" (multiple
> selectable defaults) will make it easier for a novice user to get
> started with a partitioning scheme which later will not turn out to
> cause unforeseen problems.

I think that the idea of offering "themes" would be popular. I don't
think it'd be limited to novice users, either. There could be themes
that orient toward installs with high numbers of users, single users
that feel the multiple partitioning enhances security (those disagreeing
are free to choose other options), or particular services, like web or
mail servers.

So what are common partitioning schemes for tech-security list readers?

tim