Subject: install/11424: sysinst (i386) can umount wd0a (root) before unpacking sets
To: None <gnats-bugs@gnats.netbsd.org>
From: None <kre@munnari.OZ.AU>
List: netbsd-bugs
Date: 11/05/2000 02:16:10
>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: