[530] in athena10
cluster-software install problem analysis
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Mon Sep 22 13:49:17 2008
Date: Mon, 22 Sep 2008 13:47:34 -0400 (EDT)
From: ghudson@MIT.EDU
Message-Id: <200809221747.m8MHlYiV012689@outgoing.mit.edu>
To: athena10@mit.edu
Bill and Alex both ran into some pretty severe problems with the
Athena 10 installer script when they selected "yes" to the cluster
software package. I've temporarily disabled that option while I look
into the failures.
This is what I have been able to uncover so far:
1. The sun-java-* packages fail to install with the non-interactive
front end, because they cannot present their license.
2. There is an odd error message during installation:
dpkg: libzephyr3: dependency problems, but removing anyway as you request:
libpurple0 depends on libzephyr3
This is perplexing because libzephyr3-krb provides libzephyr3, so
the dependency should not be broken.
3. In my test, but possible not Bill's and Alex's, a bunch of texlive
packages failed to install with messages like:
Setting up texlive-humanities-doc (2007.dfsg.1-1) ...
update-updmap: cannot read /etc/texmf/updmap.d/00updmap.cfg
Some latex packages failed for a different reason but I've lost the
output file I was combing.
4. When all was said and done, only two debathena-* packages were
installed, even though the debathena-* packages install just fine
by themselves. Also, libpurple0 remained broken, suggesting that
libzephyr3-krb wasn't successfully installed.
My wild speculation to explain (2) and (4) is that aptitude decided to
split up the dpkg operations into steps (the first of which was
inconsistent with regard to libzephyr3 and libpurple0), and it gave up
after one of the steps. I don't know. I am conducting an install
test with two changes to the install script:
1. Install the main metapackage (e.g. debathena-workstation) by itself
first, and then follow up separately with debathena-debian-dev and
debathena-cluster-software if selected.
2. Use DEBIAN_FRONTEND=noninteractive for the main metapackage, but
use DEBIAN_PRIORITY=critical for the other two metapackages if
selected, so that those packages can ask critical questions such as
the Java license.
I'll see what this turns up. The tex package install issues are still
a mystery, and I didn't necessarily find all of the problems in the
output file I examined. (I didn't exercise perfect care in my last
install test because I was getting sick and there was other
troubleshooting going on at the same time.)
The eventual cluster installer will have to deal with the Java package
issue in another way. One option is to seed the debconf database to
indicate that the license has already been accepted. The legal
ramifications of such a workaround are fascinating, I'm sure, but in
this case the installer of the machine's software and the user of that
software are different, so there's not much point in asking the former
to accept a license intended for the latter.
