[6053] in Release_7.7_team
Re: Can we make the Athena ATI support less fragile?
daemon@ATHENA.MIT.EDU (William Cattey)
Fri Sep 5 17:12:49 2008
In-Reply-To: <200809052105.m85L5vQ6015331@pothole.mit.edu>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <E4497478-2728-443E-8A57-09353017150C@MIT.EDU>
Cc: release-team@MIT.EDU
Content-Transfer-Encoding: 7bit
From: William Cattey <wdc@MIT.EDU>
Date: Fri, 5 Sep 2008 17:11:35 -0400
To: "andrew m. boardman" <amb@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
Yes, this seems like the best amendment going forward.
I agree that we don't want to presume Hesiod information
inappropriately, merely that
the hard-coded stuff that is hard to work around behaves gracefully
in the face of misconfigured Hesiod info.
Thank you!
-Bill
----
Important: IS&T IT staff will *NEVER* ask you for your password, nor
will MIT send you email requesting your password information. Please
continue to ignore any email messages that claim to require you to
provide such information.
----
William Cattey
Linux Platform Coordinator
MIT Information Services & Technology
N42-040M, 617-253-0140, wdc@mit.edu
http://web.mit.edu/wdc/www/
On Sep 5, 2008, at 5:05 PM, andrew m. boardman wrote:
>
> 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.
