Re: BIOS
> On Thu, 9 Aug 2007 09:37:02 +0200, Henning Fehrmann <[EMAIL PROTECTED]> > said: > we are interested in flashing a BIOS image and in manipulating the NVRAM of the motherboard > automatically. Wow. Do you really need this? > Unfortunately, using certain vendors, the access to the NVRAM is not straightforward. > These vendors are offering DOS tools only, to write in the NVRAM, hence, we have to boot > a DOS image and here starts the trouble. 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. > 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. > 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. -- regards Thomas
Re: BIOS
On Thu, Aug 09, 2007 at 10:42:41AM +0200, Thomas Lange wrote: > > On Thu, 9 Aug 2007 09:37:02 +0200, Henning Fehrmann <[EMAIL PROTECTED]> > > said: > > > we are interested in flashing a BIOS image and in manipulating the > NVRAM of the motherboard > > automatically. > Wow. Do you really need this? > > > Unfortunately, using certain vendors, the access to the NVRAM is not > straightforward. > > These vendors are offering DOS tools only, to write in the NVRAM, > hence, we have to boot > > a DOS image and here starts the trouble. > 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. It worked here, but I think that's something Henning has got running too. The problem is to tell the server to swap its PXE config file for this particular machine *after* the flash has been completed but *before* rebooting (automatically or by power cycle/IPMI reset). It'd be necessary to send some kind of "signal" to the server (a dummy tftp request is what I've done in the past, at least from a tomsrtbt image I used to perform some partitioning magic). Therefore, it would be nice to have a network stack under freedos (which the BIOS flash disks nowadays are based on). > > 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. That's the problem: to get a reasonable message *somewhere* you'd need a TCP/IP stack. Or am I missing something? Cheers, Steffen
Re: BIOS
On 9 Aug 2007, at 10:03 am, Steffen Grunewald wrote: On Thu, Aug 09, 2007 at 10:42:41AM +0200, Thomas Lange wrote: On Thu, 9 Aug 2007 09:37:02 +0200, Henning Fehrmann <[EMAIL PROTECTED]> said: we are interested in flashing a BIOS image and in manipulating the NVRAM of the motherboard automatically. Wow. Do you really need this? Unfortunately, using certain vendors, the access to the NVRAM is not straightforward. These vendors are offering DOS tools only, to write in the NVRAM, hence, we have to boot a DOS image and here starts the trouble. 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. It worked here, but I think that's something Henning has got running too. The problem is to tell the server to swap its PXE config file for this particular machine *after* the flash has been completed but *before* rebooting (automatically or by power cycle/IPMI reset). It'd be necessary to send some kind of "signal" to the server (a dummy tftp request is what I've done in the past, at least from a tomsrtbt image I used to perform some partitioning magic). Therefore, it would be nice to have a network stack under freedos (which the BIOS flash disks nowadays are based on). 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. Tim -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Re: BIOS
> On Thu, 9 Aug 2007 11:03:10 +0200, Steffen Grunewald <[EMAIL PROTECTED]> > said: > That's the problem: to get a reasonable message *somewhere* you'd need a TCP/IP > stack. Or am I missing something? No, you are right. TCP/IP is needed. -- regards Thomas
Re: BIOS
Hi, Flashing a large number of BIOSes is done regularly by members of the linuxbios (http://linuxbios.org)or openbios(www.openbios.org) project. I think Stefan Reinauer ([EMAIL PROTECTED]) can answer you a lot of your questions. Hth and kind regards, Oliver * Thomas Lange <[EMAIL PROTECTED]> [070809 10:42]: > > On Thu, 9 Aug 2007 09:37:02 +0200, Henning Fehrmann <[EMAIL PROTECTED]> > > said: > > > we are interested in flashing a BIOS image and in manipulating the > NVRAM of the motherboard > > automatically. > Wow. Do you really need this? > > > Unfortunately, using certain vendors, the access to the NVRAM is not > straightforward. > > These vendors are offering DOS tools only, to write in the NVRAM, > hence, we have to boot > > a DOS image and here starts the trouble. > 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. > > > > 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. > > > > 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. > > -- > regards Thomas -- * Oliver Osburg - Administrator E-lingo PH Freiburg * * email: [EMAIL PROTECTED] phone: +49761682164 * * note: All above is my opinion unless said otherwise* * One Unix to rule them all, One Resolver to find them, * * One IP to bring them all and in the zone bind them.*
Re: BIOS
Am Donnerstag, 9. August 2007 11:26:05 schrieb Tim Cutts: > On 9 Aug 2007, at 10:03 am, Steffen Grunewald wrote: > > On Thu, Aug 09, 2007 at 10:42:41AM +0200, Thomas Lange wrote: > >>> On Thu, 9 Aug 2007 09:37:02 +0200, Henning Fehrmann > >>> <[EMAIL PROTECTED]> said: > >>> > >>> we are interested in flashing a BIOS image and in manipulating > >>> the NVRAM of the motherboard > >>> automatically. > >> > >> Wow. Do you really need this? > >> > >>> Unfortunately, using certain vendors, the access to the NVRAM is > >>> not straightforward. > >>> These vendors are offering DOS tools only, to write in the NVRAM, > >>> hence, we have to boot > >>> a DOS image and here starts the trouble. > >> > >> 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. > > > > It worked here, but I think that's something Henning has got > > running too. > > The problem is to tell the server to swap its PXE config file for > > this particular > > machine *after* the flash has been completed but *before* rebooting > > (automatically > > or by power cycle/IPMI reset). It'd be necessary to send some kind > > of "signal" > > to the server (a dummy tftp request is what I've done in the past, > > at least from > > a tomsrtbt image I used to perform some partitioning magic). > > Therefore, it would > > be nice to have a network stack under freedos (which the BIOS flash > > disks nowadays > > are based on). > > 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. > > Tim we are using the mars-nwe (netware 3 simularor) with the pipe filesystem it is profiding the great thing is there is a file in the netware share that is a script on the server witch will be exec with the infos written to it as parameter. the bad thing is it requires ipx on the server activated. also bad only the old 16bit client will work (drivers) with mars. wfg Mario signature.asc Description: This is a digitally signed message part.
Re: BIOS
I am pretty sure that freeDOS has a dhcp client. Google for freedos and you will find it. - Original Message - From: "Henning Fehrmann" <[EMAIL PROTECTED]> To: Sent: Thursday, August 09, 2007 2:37 AM Subject: BIOS Hello everybody, we are interested in flashing a BIOS image and in manipulating the NVRAM of the motherboard automatically. Unfortunately, using certain vendors, the access to the NVRAM is not straightforward. These vendors are offering DOS tools only, to write in the NVRAM, hence, we have to boot a DOS image and here starts the trouble. 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. This means, we need networking under DOS. In particular, we are looking for a DHCP client. Has somebody experiences with this? 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. Regards Henning Fehrmann
Re: BIOS
On Thu, Aug 09, 2007 at 06:11:54PM -0500, John Heim wrote: > I am pretty sure that freeDOS has a dhcp client. Google for freedos and you > will find it. > > > - Original Message - From: "Henning Fehrmann" <[EMAIL PROTECTED]> > To: > Sent: Thursday, August 09, 2007 2:37 AM > Subject: BIOS Hello, We worked a while on the problem of flashing a bios and writing into the nvram of the motherboard. Here is a recipe which is still under development. Maybe somebody needs it. Create a bootable dos image 1. Go to http://www.freedos.org/ and download an installation-cd image, burn it onto a cd 2. Install freedos on a box. We tried it on 1. a Single-Dual Core Opteron 2218 1. with a Supermicro H8SSL-i2 board 2. and WD 1600YS SATA hd's 2. a Single-Dual Core Xeon 3060 1. with a Supermicro PDSML-LN2 board 2. and WD 1600YS SATA hd's 3. We have not been able to install freedos on a box with a Fujitsu Siemens D2461-A2 board but you can readout and write the board's nvram in a running system 3. Create a dos partition which starts from the first sector using the dos fdisk tool and format it with fat16. Make this partition not to big, since it has to go with pxeboot over the net. We toke approximately 32M. 4. Install a basic dos environment with mbr writing tools (smbtmgrx) and other programs you consider to be useful. 5. Reboot the box and go into the dos environment, execute a mbr writing tool. 6. Reboot again using liveCD Linux system (Knoppix). 7. Copy the first 63+N blocks of the hd into a file dd if=/dev/sda of=hd.img bs=512 count=63. 8. Copy the the complete dos partition into another file dd if=/dev/sda1 of=dos.img bs=512. 9. Combine the files dd if=dos.img of=hd.img bs=512 seek=63 and copy hd.img onto the tftp server. Modify the Image The idea is to mount the image to put different tools on there. Unfortunately, the image we just created has an MBR, which mount complains about. To get around that, we cut off the first (in our case: 63) blocks. The dos partition starts on block 64. dd if=hd.img of=dos.img bs=512 skip=63. To find out at which block the partition starts, you can search for the ASCII-string "FRDOS4", which indicates the beginning of a dos partition. This is a dos partition which can be loopback mounted. Copy the needed files into the mounted path. After umount, you update the image of the hd partition using dd again, with the seek parameter indicating the blocks you keep: dd if=dos.img of=hd.img bs=512 seek=63. Fill the dos partition with the tools and drivers you need. For us, this was basically: * WATT-32 (TCP/IP stack for DOS) http://www.bgnett.no/~giva/ * card driverhttp://www.georgpotthast.de/sioux/packet.htm In our case it worked with broadcom ethernet cards * ssh2doshttp://sourceforge.net/projects/sshdos * and misc. tools like vim Booting the dos image Assuming you use pxelinux, you can put this in the appropriate config file for the boot start: default fai-generated label fai-generated kernel kernel/memdisk append initrd=path/to/hd.img * After that, you should be able to boot into the dos image and see all the tools you have put there. * Next, you need to load the appropriate network drivers. * Search for the bios flash and nvram reading and writing tools. * The ssh client works with a key, so you avoid the passwd prompt. ssh the FAI server and change the pxelinux.cfg files to initialize the FAI installation (fai-chboot). * reboot Put everything in the autoexec.bat and it works automatically. (Has not been tested yet) Regards Henning Fehrmann
Re: BIOS
On Wed, Aug 15, 2007 at 05:44:49PM +0200, Henning Fehrmann wrote: > > We worked a while on the problem of flashing a bios and writing into the > nvram of the motherboard. > Here is a recipe which is still under development. Maybe somebody needs it. Congratulations for getting thus far! > Create a bootable dos image > >1. Go to http://www.freedos.org/ and download an installation-cd image, > burn it onto a cd >2. Install freedos on a box. We tried it on > 1. a Single-Dual Core Opteron 2218 >1. with a Supermicro H8SSL-i2 board >2. and WD 1600YS SATA hd's > 2. a Single-Dual Core Xeon 3060 >1. with a Supermicro PDSML-LN2 board >2. and WD 1600YS SATA hd's > 3. We have not been able to install freedos on a box with a Fujitsu > Siemens D2461-A2 board but you can readout and write the board's nvram in a > running system >3. Create a dos partition which starts from the first sector using the dos > fdisk tool and format it with fat16. Make this partition not to big, since it > has to go with pxeboot over the net. We toke approximately 32M. >4. Install a basic dos environment with mbr writing tools (smbtmgrx) and > other programs you consider to be useful. >5. Reboot the box and go into the dos environment, execute a mbr writing > tool. >6. Reboot again using liveCD Linux system (Knoppix). >7. Copy the first 63+N blocks of the hd into a file dd if=/dev/sda > of=hd.img bs=512 count=63. >8. Copy the the complete dos partition into another file dd if=/dev/sda1 > of=dos.img bs=512. >9. Combine the files dd if=dos.img of=hd.img bs=512 seek=63 and copy > hd.img onto the tftp server. This IMHO could be done without touching a real disk's MBR using a file (untested). > Modify the Image > > The idea is to mount the image to put different tools on there. > Unfortunately, the image we just created has an MBR, which mount complains > about. To get around that, we cut off the first (in our case: 63) blocks. The > dos partition starts on block 64. dd if=hd.img of=dos.img bs=512 skip=63. To > find out at which block the partition starts, you can search for the > ASCII-string "FRDOS4", which indicates the beginning of a dos partition. This > is a dos partition which can be loopback mounted. Copy the needed files into > the mounted path. After umount, you update the image of the hd partition > using dd again, with the seek parameter indicating the blocks you keep: > dd if=dos.img of=hd.img bs=512 seek=63. IIRC loopback mount has an option to skip to an offset inside the image... man mount > Fill the dos partition with the tools and drivers you need. For us, this was > basically: > > * WATT-32 (TCP/IP stack for DOS) http://www.bgnett.no/~giva/ Is there a binary version I have missed when I last looked? > * card driverhttp://www.georgpotthast.de/sioux/packet.htm You might also use the UNDI driver that sits on top of the PXE in the card's firmware. > In our case it worked with broadcom ethernet cards > * ssh2doshttp://sourceforge.net/projects/sshdos > * and misc. tools like vim > > > Booting the dos image > > Assuming you use pxelinux, you can put this in the appropriate config file > for the boot start: > > default fai-generated > > label fai-generated > kernel kernel/memdisk > append initrd=path/to/hd.img > > * After that, you should be able to boot into the dos image and see all the > tools you have put there. > * Next, you need to load the appropriate network drivers. > * Search for the bios flash and nvram reading and writing tools. > * The ssh client works with a key, so you avoid the passwd prompt. > ssh the FAI server and change the pxelinux.cfg files to initialize the FAI > installation (fai-chboot). Of course that's a more elegant solution than having a fake TFTP request which would trigger an action on the server side. Why didn't you go for a simple rsh instead, which is already a prerequisite for FAI (writeback of install logs)? > * reboot > > Put everything in the autoexec.bat and it works automatically. (Has not been > tested yet) If you don't mind I'd like to have a look at your image. I'd suggest to have an interface to the possible tasks as clean as possible so that changes to the payload have to be done in only one place (our vendor for example uses a zip file that contains the payload, which is unpacked into a ramdisk, and it's setup.bat is started - this way the autoexec.bat stays unmodified if you replace the payload) - KISS :-) (My images are in CVS, faiconfig/files/boot/fai/floppy-images/) Cheers, Steffen
Re: BIOS
Hello, > > This IMHO could be done without touching a real disk's MBR using a file > (untested). Copying the MBR was basically the first method which worked. According to the docu of memdisk, if you want to use arbitrary image sizes, it has to be hd image with mbr and partition table. > > > IIRC loopback mount has an option to skip to an offset inside the image... > man mount > Works fine, thanx. mount -o loop,blocksize=512,offset=32256 hd.img /mnt/dos > > > > > * WATT-32 (TCP/IP stack for DOS) http://www.bgnett.no/~giva/ > > Is there a binary version I have missed when I last looked? > We just build every thing from scratch. I guess this is the standard tcp/ip stack used for freedos. > > > * card driverhttp://www.georgpotthast.de/sioux/packet.htm > > You might also use the UNDI driver that sits on top of the PXE in the card's > firmware. I will take a look. > Of course that's a more elegant solution than having a fake TFTP request > which would > trigger an action on the server side. Why didn't you go for a simple rsh > instead, which > is already a prerequisite for FAI (writeback of install logs)? > Unfortunately, the only rsh version I found was from drdos and not free. > > If you don't mind I'd like to have a look at your image. > I'd suggest to have > an interface to the possible tasks as clean as possible so that changes to > the payload have to be done in only one place (our vendor for example uses > a zip file that contains the payload, which is unpacked into a ramdisk, and > it's setup.bat is started - this way the autoexec.bat stays unmodified if > you replace the payload) - KISS :-) > (My images are in CVS, faiconfig/files/boot/fai/floppy-images/) Of course, but I will not attach it to this email, since it is compressed 13MB. If it is in good shape (without a private sshkey), I will put it on a server and make a deb package out of it. Is somebody of the FAI developer team interested? Regards Henning
Re: BIOS
Hi, On Thursday 09 August 2007 09:37, Henning Fehrmann wrote: > we are interested in flashing a BIOS image and in manipulating the NVRAM of > the motherboard automatically. Are you aware that you can flash many bioses from linux now? Read http://www.hermann-uwe.de/blog/flashing-a-bios-the-linux-way-tm-using-flashrom to learn more, it's packaged and in sid, but a backport to etch is trivial. regards, Holger pgpEabIzLOIRA.pgp Description: PGP signature
Re: BIOS
Hi Holger, Holger Levsen wrote: > > Are you aware that you can flash many bioses from linux now? Read > http://www.hermann-uwe.de/blog/flashing-a-bios-the-linux-way-tm-using-flashrom > > to learn more, it's packaged and in sid, but a backport to etch is trivial. We have seen Uwe's planet post about this and it works for many boards. Nice thing, however, there is the uncertainty that after flashing the BIOS from within Linux the settings (nvram/cmos/whatever you want to call it) might be screwed up. Most importantly, if the boot order during flashing is reset, we would be screwed. Since the next reboot would most certainly not have PXE as is first boot option. Especially, the SuperMicro boards store settings out of reach for /dev/nvram thus we would need the DOS image stuff anyways :( But thanks for the pointer. Carsten
[Fwd: Re: BIOS]
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]
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]
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
