[Fwd: Re: BIOS]

[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 <carsten.aulbert at aei.mpg.de>
Organization: Max Planck Institute for Gravitational Physics
To: linux-fai <linux-fai at uni-koeln.de>
References: <20070809073702.GA1419 at gretchen.aei.uni-hannover.de> 
<18106.54145.29471.791888 at kueppers.informatik.uni-koeln.de>

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