[Fwd: Re: BIOS]

2007-08-09 Thread Carsten Aulbert

Sorry, used wrong from address (twice)

 Original Message 
Subject: Re: BIOS
Date: Thu, 09 Aug 2007 10:49:06 +0200
From: Carsten Aulbert <[EMAIL PROTECTED]>
Organization: Max Planck Institute for Gravitational Physics
To: linux-fai 
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>


Hi

Thomas Lange wrote:
> we are interested in flashing a BIOS image and in manipulating the NVRAM of the motherboard 
> automatically.

Wow. Do you really need this?


Unfortunately, it looks that way. Especially if a new BIOS version comes
out, which fixes a problem and you don't want to run around with a
USB-floppy drive - if that is supported at all.


You can boot a DOS or floppy image using PXE. This is how a
pxelinux.cfg looks like for booting a floppy image: 


default dos
label dos
 kernel memdisk
 append keeppxe initrd=floppy.img

But AFAIR I had no success, because the dos flashing utilities seems
to wanna have a real floppy, not a fake of a floppy.


That already works (thanks to Steffen G.'s work and testing). Most newer
BIOS tools seem work fine even from a RAM disk.

> Optimally, using the DOS environment flashes the BIOS, sets the 
> NVRAM and sends a message to the FAI server to prepare the next boot of the clients for the

> installation.
You could send a message to the faimond which can change the pxelinux 
configuration.


How would we do that? So far we have not yet succeeded in putting TCP/IP
into FreeDOS. But we are working on that.


> In the worst case, the DOS environment is working autonomously and the 
FAI server is 'guessing'
> whether the BIOS is flashed or not, e.g., by analyzing the DHCP logs, but 
this is not what we really want.

Guessing if something has changed could easily be done using dmidecode,
which will give you the version of the BIOS.


Yes, but it won't tell us if setting out wanted CMOS settings worked. On
certain SM boards (which apparently use 256 bytes for storing stuff)
they seem to keep also some dates in there, thus even a md5sum on
/dev/nvram would tell you if it worked. Even with a patched nvram kernel
module this would differ from one node to the other.

Cheers

Carsten



[Fwd: Re: BIOS]

2007-08-09 Thread Carsten Aulbert

again

 Original Message 
Subject: Re: BIOS
Date: Thu, 09 Aug 2007 11:29:40 +0200
From: Carsten Aulbert <[EMAIL PROTECTED]>
Organization: Max Planck Institute for Gravitational Physics
To: linux-fai@uni-koeln.de
References: <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>


Hi Tim,

Tim Cutts wrote:
RLX got around this with their blade deployment system in a very hacky 
way; the DOS image they used included the Windows for Workgroups TCP/IP 
stack, and therefore SMB support, and they used this to update a status 
file for the node being deployed back on the Control Tower DHCP server.  
Nasty, but it worked.


You make me shudder despite the not too cold weather ;)

We are currently looking into the package offered here:

http://www.bgnett.no/~giva/index.html

More to come.

Carsten



Re: [Fwd: Re: BIOS]

2007-08-09 Thread Steffen Grunewald
On Thu, Aug 09, 2007 at 11:45:43AM +0200, Carsten Aulbert wrote:
> We are currently looking into the package offered here:
> 
> http://www.bgnett.no/~giva/index.html

That's the 32-bit version of WatTCP, isn't it? I couldn't get a proper
documentation (and a binary build!) when I last looked... If you succeed, 
please share ...

Cheers
 Steffen