[3392] in SIPB_Linux_Development
Re: outstanding bugs
daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Tue Mar 20 01:09:57 2001
Message-Id: <200103200609.BAA14814@stratton-three-sixty-seven.mit.edu>
From: Jonathon Weiss <jweiss@MIT.EDU>
To: Garry Zacheiss <zacheiss@MIT.EDU>
to: alex_c@MIT.EDU, seph@MIT.EDU
cc: Jonathon Weiss <jweiss@MIT.EDU>, linux-dev@MIT.EDU
In-reply-to: Your message of "Mon, 19 Mar 2001 11:46:06 EST."
<200103191646.LAA19585@riff-raff.mit.edu>
Date: Tue, 20 Mar 2001 01:09:42 -0500
SHOWSTOPPER ISSUE COUNTER: 7
Alex, seph, there is a question addressed to each of you below.
> >> [3213] [3383] [3384]
> >> install lists bogus times in /etc/athena/version
> >> believed fixed, needs to be tested and propogated to charon
>
> Needs to be tested; currently only in AFS.
tested, confirmed fixed and propogated to charon
> >> [2955]
> >> Somehow, my kerberos realm defaulted to "EXAMPLE.COM".
> >> This prevents athena users from logging in with xlogin.
> >> I'm not sure who owns the /etc/krb5.conf file:
>
> Don't remember original problem report, but this is someone who
> either layered or did a custom install; The krb5-configs RPM is never
> installed by the normal install method. Not our problem.
OK, we can consider this part of the "we need to disable custom
install" issue.
> >> [2989]
> >> Currently we install a null release RPMs file.
>
> The release-rpms file gets populated with the contents of the rpms in
> the release when you take your first update, and I've verified in the
> past that updating from "8.4.0" to some patch release will remove RPMs
> that the release has removed. And we don't support the custom install
> option anyway.
I have verified the reverse of what you have verified, and the
installer disappeared in a puff of logic. More specifically, the
problem doesn't occur after the update from 8.4.0 to the current
version, but it can occur *during* that update. This is still a
serious problem.
The specific case I noted:
The gnorpm was removed between 8.4.15 and 8.4.17 (there was no 8.4.16)
For a period of time after 8.4.17 was released, our installer was
still installing 8.4.15 (or something a little earlier). gnorpm got
installed at install time. Then the machine updated from 8.4.0 to
8.4.17, and got the 8.4.17 rpmlist. However, since it started with a
blank release rpmlist, it assumed gnorpm had been added locally and
did not remove it.
> >> [3044] [3056] [3109] [3110] [3112] [3113] [3114]
>
> People like their vt's. If we turn this off, the net result will be
> increasing our support load by having people asking how to turn them
> back on. It should stay the way it is.
I can live with this, but someone should write up the info on how to
make and undo this change ans send it to Heather for the PWOG. I'd
really appreciate it if someone besides me (and Garry) could find the
time to do this. The reason it is encumbant upon us to deal is
because it is that release-team has requested that the sipb installer
to install machines with undocumented customizations, even if people
like them.
> >> [3048] [3051] [3052] [3055] [3058] [3059]
> >> AFSCLIENT AFSADJUST AFSSRV
>
> Adding a grep for the first two variables is easy, as is adding code
> to deal with the third one. I'll do that. If someone wants to figure
> out what's actually going on, they're welcome to.
I've added the grep, and the code to deal with AFSSRV, tested it and
propogated it to charon. I attempted to figure out what was the root
cause and determined that the RPMs are not being installed in the
order they are specified in the comps file. I don't know what is
re-ordering them. I'd still like to see this fixed, but at this point
it has been reduced to a non-showstoper.
NEW BUG: However, in looking over the install log (which is how i
determined that the install order was wrong) I noticed three errors
from athena-ws. Two of the three involved setting the hostname and
address and were already corrected by the post-install script. The
third error was due to the fact that athena-ws was installed before
isapnptools and prevented the install from properly configuring the
sound card, even though it was one of the supporeted ones. We need to
at least add a workaround to the post-install script, but I don't have
time to deal tonight.
> >> [3073]
> >> User with custom install problmes. Did we agree to and implement the
> >> removal of the custom install option?
>
> We haven't removed it. We either should or should document very
> clearly that if it breaks, you get to keep both pieces.
My personal preference is that we nuke it. Alex, any chance of you
working on this soon?
> >> [3316] [3317] 3318]
> >> fix pcitable on sipb-nfs (not really a show stopper, but a trivial
> >> file propogation from the floppy to charon as I understand it)
>
> Sounds dandy. Someone should do it.
This was nomnially waiting on bad card testing, but I've timed out on
that. can anyone give me the full path names to the relevant files?
seph?
> I don't have the time to work on anything below the level of what you
> consider showstoppers.
I wasn't really expecing them to get fixed in the short term, or for
anyone to work on them before we go to production, but I didn't want
them to get lost either.
NEW ISSUE: we need to remove the "BETA" from the install screen when
we go to production. Do we have an image without the "BETA" lying
around somewhere?
Jonathon
