[3195] in Release_7.7_team

home help back first fref pref prev next nref lref last post

What is our installer strategy to be?

daemon@ATHENA.MIT.EDU (Bill Cattey)
Tue Mar 26 22:16:54 2002

From: Bill Cattey <wdc@MIT.EDU>
To: release-team@mit.edu, owls@mit.edu
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 26 Mar 2002 22:16:52 -0500
Message-Id: <1017199012.5247.251.camel@tokata.mit.edu>
Mime-Version: 1.0

The latest I have from the Etherboot developers is:

    Because of the way Etherboot has been written testing for the
    specifically affected chipset is very hard.
    Etherboot will NOT work for 3c905b systems (like our GX110's) unless
    the current code is used.
    
So we have the following situation:

    The officially supported Athena install floppy sets toxic 
    values to the EEPROM of Dell GX150's -- even if you just let it run
    to the first prompt for an IP address.
    
    That officially supported Athena install floppy sort of must be
    allowed to set those funky values on our GX110's
    
    We have a new install floppy that's almost ready to ship.
    
    We have a patch out in the release that is getting mixed reports of
    success and failure at remedying this situation.
    
What should we be doing?

Chatting with Lou Isgur, I heard the sensible suggestion that whatever
floppy is created that it work for ALL systems.

Chatting with Andrew before he went on vacation, he expressed the
opinion that fixing Etherboot is a waste of effort, and that we should
set the long-range goal of using the new anaconda-based install floppy.

I don't want to rush to deployment of something that's not had a lot of
testing, but I'm currently feeling VERY much in favor of expediting
deployment of the new floppy.

-wdc

P.S.  Did I mention that I burned Andrew's floppy into a CD and used it
to successfully do installs?



home help back first fref pref prev next nref lref last post