We are into web caching and we have tried hardware raid. It is reliable
but it doesnt seem to be feasible option in terms of performance and cost
and software raid is a joke when it comes to realiability.

I know it sounds a bit too much, but this is how I was planning to do it.
Say the kernel starts complaining about a disk failure, the script will
activate the program that will change the BIOS to boot from a flash device
or cdrom and reboot. The admin there will replace the disk and switch the
box on. The flash or cdrom will boot up and copy the image from its
storage or from network and change the BIOS setting again and reboot :-)
... maybe even copy the backup and restore the system to as it was.

I just thought it would be pretty cool to do that ... trying to be as lazy
as possible ... making scripts do everything for me ... :)

I saw some functions bios_sigsearch() and some assembly code on the system
and thought it might be possible. I didnt understand it so I posted the
question here.

I have tried the option that Lewis suggested but if the BIOS cant boot
from the first SCSI device it just sits there. I guess the MBR is still
there or something. I even tried removing the disk, but then the order
gets screwed up and flash device doesnt show up in the boot sequence
unless to manually select it.

Anyway, thanks for all your comments.


Pranav A. Desai

On Thu, 24 Jul 2003, Mark wrote:

> ----- Original Message -----
> From: "Pranav A. Desai" <[EMAIL PROTECTED]>
> Sent: Thursday, July 24, 2003 11:27 PM
> Subject: Is it possible to read BIOS setting?
> > Hi!
> >
> > This is what I am trying to do ...
> > If the hard disk fails (or becomes un-bootable) I would change the BIOS
> > setting to boot from second disk or maybe from cdrom, repair or reimage
> > the hard disk and reboot the box.
> >
> > I would like to automate this process, so that I dont have to be
> > physically present at the box. In fact, a script or program can activate
> > this on an event like hard disk error etc. kind of self-healing. But the
> > main problem with this is the BIOS settings need to changed.
> >
> > Does this sound reasonable?
> No, actually. :) Though your kern.securelevel (2+) may even prevent writing
> to CMOS ports directly (not really sure), I am sure, though, that doing so
> is a bad idea. Even back in the days of yore, when we had XT's and all, it
> could be done, but not devoid of risk. Such as corrupting the CMOS checksum,
> causing the BIOS to weird out on boot-up. And on an XT, at least you more or
> less knew which port did what. But nowadays that is quite uncertain too;
> "proprietary" they call it now. :) And even if it could be done, you would
> have to know, exactly, how your particular BIOS (version) calculates its
> checksums, in order to change data. Tricky business.
> Besides, if your disk fails to boot, what would you then, at that point,
> expect the BIOS to do? Automatically reboot and try from the second disk?
> And you would start the script to work this, exactly how? :)
> Not to mention that, these days, we have a better way of dealing with the
> untimely demise of hard disks; RAID is your friend. ;) Then, if one of your
> disk fails, your data remains intact, and you let an SNMP agent report the
> mishap to you. Then you haste home to check on your baby. :)
> - Mark
> _______________________________________________
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to