[6052] in Release_7.7_team
Re: Can we make the Athena ATI support less fragile?
daemon@ATHENA.MIT.EDU (andrew m. boardman)
Fri Sep 5 17:06:40 2008
Message-Id: <200809052105.m85L5vQ6015331@pothole.mit.edu>
To: Bill Cattey <wdc@MIT.EDU>
cc: release-team@MIT.EDU
In-Reply-To: Your message of "Fri, 05 Sep 2008 15:19:51 EDT."
<1220642391.4302.9.camel@w20-575-56.mit.edu>
Date: Fri, 05 Sep 2008 17:05:57 -0400
From: "andrew m. boardman" <amb@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
I wrote a patch a while back that dealt with this problem for the
no-hesiod case. I'm opposed to actively ignoring cluster info under the
assumption that we know better than whoever set it. (Driver selection
can change depending on cluster info, so assuming there's one true driver
isn't the right thing.)
I *am* comfortable adding a hack to the installer such that, for initial
installs on affected hardware on PUBLIC=true machines, a copy of the
drivers is installed. The advantage of this approach is that I can
implement it easily and without a patch release. I'll submit a patch to
do so as time allows.
> While waiting for the hesiod requests that should have been made for
> these systems to be acted upon, I did the following kludge:
>
> Set PUBLIC=false
> create /etc/athena/cluster.local containing Linux cluster info.
> reboot
> Let X configure
> set PUBLIC=true
> reboot
You should be able to skip the reboots and just create cluster.local, run
/etc/athena/install-proprietary-x-drivers, and then blow away
cluster.local again.
In either case, though, this is only going to mask the problem until the
next patch release with a kernel update (which is almost all of them),
whereupon they lose again, except that instead of figuring it out at
install time, we find out at some undetermined time later when someone
might be relying on a working machine. Adding "bad hesiod info" warnings
at reactivate time (similar to the "an upgrade is available" messages)
might be a good way around this.
