[20814] in Athena Bugs
solaris install ^C with unknown disk fails
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Thu Sep 26 04:24:25 2002
Message-Id: <200209260824.EAA07218@bearing-an-hourglass.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: bugs@MIT.EDU, miki@MIT.EDU
Date: Thu, 26 Sep 2002 04:24:23 -0400
Two problems with the solaris install:
1) /sbin/athenainstall on the miniroot contains an RCS header that
says:
/afs/dev.mit.edu/source/repository/packs/install/platform/sun4/athe
(yes, it really cuts off at 80 chars like that), but that isn't the
location of the RCS file. (this implies to me that changes have
been made to this file without the benefit of version control.)
/mit/source/packs/install/os/solaris/athenainstall also exists and
is urelated to the version on the miniroot.
a) could the version of athenainstall on the miniroot be checked
into version control in some place and advertise that location
in the RCS header (or at the very least not advertise an
incorrect location)
b) if "some place" in "a)" above is not
/mit/source/packs/install/os/solaris/athenainstall, could that
file get cleaned up so that it doesn't hurt us later
2) When the install tries and fails to auto-partition a disk (in my
case, becasue the disk I was using didn't meet the
auto-partitioner's minimum size requirement) for which we haven't
supplied a partition table, it suggests that you can type ^C to get
a shell. Unfortunately, this doesn't work. I beleive that this is
because /sbin/startup in the miniroot traps and ignores ^C
(according to the trap manpage traping a signal that was trapped
and ignored when the current shell was started won't work).
Assuming I'm correct this can be fixed in one of two ways: Don't
trap and ignore ^C in /sbin/startup or have startup run
athenainstall and athenainstall run install1.sh using "." rather
than "sh" so they don't get run in a subshell. I don't have a
strong preference between these two,
Jonathon
