>Number:         11424
>Category:       install
>Synopsis:       sysinst (i386) can umount wd0a (root) before sets are unpacked
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    install-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 05 02:16:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     Robert Elz
>Release:        NetBSD-current - 20001020 snapshot
>Organization:
	University of Melbourne
>Environment:
	
System: NetBSD brandenburg.cs.mu.OZ.AU 1.5_BETA NetBSD 1.5_BETA (GATEWAY) #2: Thu Oct 26 05:55:17 EST 2000 root@:/usr/src/sys/arch/i386/compile/GATEWAY i386


>Description:
	When installing, and telling sysinst to use the "whole disk"
	it installs the boot blocks (a welcome change from previous
	systems) then unmounts the root filesys (says it is doing so).
	Unfortunately it seems that later parts of sysinst assume that
	the new root filesys is mounted on /mnt and make sub-dirs there
	for /usr (/var ...) and then mount other partitions - but in this
	case with /mnt still being the md0a (in kernel) image.

	When unpacking starts, the first set unpacked is the kernel,
	which attempts to unpack into /mnt/netbsd which doesn't have
	nearly enough space...
>How-To-Repeat:
	Do an install using the 20001020 -current snapshot
	tell it to use the whole drive for NetBSD (and what other
	use could there be anyway!) and watch...
>Fix:
	Sorry, though I suspect this one is easy...

	The workaround is to suspend sysinst when this happens,
	umount everything mounted in /mnt, mount wd0a (the root)
	on /mnt, mkdir the directories needed for mounting stuff,
	mount all the other filesystems again, go and unpack the
	kern.tgz set manually, then resume sysinst

	Or it should be, and nearly is, unfortunately, sysinst sucks
	big time as soon as something has gone wrong - it has already
	decided that there's been a fatal error, hence doesn't bother
	to do the post-set installation tasks (like installing the
	fstab, or MAKEDEV).   Before fixing the above bug, it would be
	worthwhile for someone who understands sysinst to get it into
	this state, and attempt to actually make sysinst recover somehow
	(say unpack extra sets - which fails because that expects filesystems
	to be mounted, and after everything has been unpacked (12 our
	of 13 worked, 1 failed...) but they have been umounted.

	If you know this is going to happen, another workaround would be
	to stop sysinst after it umounted the root and just mount it
	again, before starting the unpack - but this only works if you
	are expecting the problem.
>Release-Note:
>Audit-Trail:
>Unformatted: