Viewing BIOS info without rebooting..?

[Todd D'Amore]

Is there a way to do this ? We have a large # of servers in remote
locations that need to be checked for Y2K compliance. Unfortunately we
don't have a record of the BIOS ver # . I am wondering if anyone has
figured out a way to do this with perhaps a small program or something
along those lines. All servers are running SCO Open Server 5.xx

Any and all suggestions are greatly appreciated, thanks for your time...

Todd D'Amore
tda...@jfax.com
Network Administrator
Jfax.com
+1.310.966.1863

[Jean-Pierre Radley]

Todd D'Amore averred (on Thu, Feb 25, 1999 at 11:51:39AM -0800):

| Is there a way to do this ? We have a large # of servers in remote
| locations that need to be checked for Y2K compliance. Unfortunately we
| don't have a record of the BIOS ver # . I am wondering if anyone has
| figured out a way to do this with perhaps a small program or something
| along those lines. All servers are running SCO Open Server 5.xx

hw -v | grep BIOS

--
Jean-Pierre Radley <j...@jpr.com> XC/XT Custodian Sysop, CompuServe SCOForum

[Sean]

On Thu, 25 Feb 1999 11:51:39 -0800, Todd D'Amore <tda...@jfax.com>
wrote:

>Is there a way to do this ?

hw -v | grep -i bios
would be a place to start.
If you need other information, also look
at the output of hw, hwconfig -h,
cat /etc/messages (look at boot info),

tell us what all you need to look at.

For instance, many times you can tell the
make and model of hard disk with the above,
how much RAM is in it, sometimes the exact
CPU installed, and other things...

[Bill Vermillion]

In article <36d65f2f...@news.txdirect.net>,

I believe the original poster asked about this because he was
concerned about having the proper BIOS for Y2K.

However Y2K problems in HW can be much more subtle than
just the BIOS. Depending on the RTC (real time clock) chip,
you might think you are okay, but find you are not.

The only real way is to test it, and not just set the clock ahead
so you can watch it roll-over to Y2K. If it does that, then you
must reboot to see what the clock says. SURPRIZE!! Many BIOSes
will now show a date up to 19 years in the past. The BIOS rolled
over but the RTC failed.

Here's a 'could happen' scencario. You've check the system for
data roll-over and you think you are okay.

However you didn't not check the HW roll-over functions - I only
mentioned one above - and you are going along your merry way
in the year 2000 with no problems. You figure you are now home
free.

So now 2 or 3 months into 2000, sometime in March perhaps, the
system needs to be rebooted. You let it go through on the
autoboot so it takes the time from the RTC and not the keyboard.

Things are okay until someone notices the date. You reboot, set
the BIOS clock, and the system now comes up with the proper date.
However many files now have a Jan 1, 1980 date as that was when the
OS though they were updated. The machine has just gone through a
20 year time warp by resetting the clock.

Now let's further imagine that one of your critical files was
updated during the time the clock was thinking it was 1980, and
also that this file is primarily read only - except when some
posting operations are run.

You get to work the next day and your phone is overflowing with
complaints about the system not working.

You check it, and find you can't access that critical read only
file. You drop to the OS and it's not there. You grep for it,
where in sight.

What happened? Remember the cron script you built to check for
files that were older than 90 days. Since 20 years is longer than
90 days, the file was reaped by the cleanup process.

Here's another. You get constant data coming in from some source,
the net, uucp links, etc., which then needs to update data bases.
In some applications it may be checking on the dates in the data
and it will just get dumped into the bit-bucket of the computer.

The problem there is that this incoming data might not be
recoverable. Imagine something similar to a POS system, where
once the transmission is verified, the source system deletes the
data.

Having a compliant BIOS with a non-compliant RTC could be just the
recipe for a real headache next January. The only way to be sure
is to test it through all possible variants.

--
Bill Vermillion bv @ wjv.com

[Tony Earnshaw]

Todd D'Amore wrote:

> Is there a way to do this ? We have a large # of servers in remote
> locations that need to be checked for Y2K compliance. Unfortunately we
> don't have a record of the BIOS ver # . I am wondering if anyone has
> figured out a way to do this with perhaps a small program or something
> along those lines. All servers are running SCO Open Server 5.xx

I've read all JPR's, sean's and Bill's comments. Personally I don't
think you can check the BIOS without rebooting the machine. We've been
checking all our workstations (the servers will come later, there has to
be a server reconfiguration, anyway). As Bill says, checking the BIOS
version alone won't tell you that much, you really do have to do a
rollover test.

We've been using two small utilities (Internet downloadable) to check
the rtc and BIOS details. These utils insist that one does a cold boot
of the computer into MSDOS. We then run the rtc check by doing the
new-year rollover, and next all the leap years until 2009, then extract
the BIOS info with another util.

This method doesn't subject the Unix date system to any stress and
avoids possible accidents with application misconfigurations.

We've got very unexpected results, incidentally. Not all the machines
one would expect to have y2k-compliant BIOSs have them, and a number of
machines that one wouldn't expect to have them do. It's also revealed
that we've been conned in the past with respect to clone PC vendors and
the equipment they install in their cases.

Tony

--
************* THE NEW DIMENSION IN DISTRIBUTION ***********
ilion Faculty B.V.
Tony Earnshaw email: to...@ilion.nl
Randstad 21-57
1314 BH Almere-Stad tel: +31 (0) 36 548 50 10
The Netherlands fax: +31 (0) 36 534 05 34
***************** http://www.ilion.nl *********************

[Jean-Pierre Radley]

Tony Earnshaw averred (on Fri, Feb 26, 1999 at 05:20:11PM +0100):

|
| We've been using two small utilities (Internet downloadable) to check
| the rtc and BIOS details. These utils insist that one does a cold boot
| of the computer into MSDOS. We then run the rtc check by doing the
| new-year rollover, and next all the leap years until 2009, then extract
| the BIOS info with another util.

URLs for the above utilities, please?

[Tom Melvin]

In addition to the other comments, I have used the below script to
work ou the bios ID (covers abut 95% of the machines I deal with).
All I then need is to check out one machine and all others with
the same ID can be assumed to be the same. I hope that logic is
valid.

The version of /etc/hw on 5.0.5 does try to work out the BIOS ID
but is not always sucessfull - Mind you my script can only handle
BIOS locations it knows about so is no better :-) The 5.0.5 version
runs on the earlier 5.0.x and 3.2v4.2 releases.

#!/bin/sh
# Mark I Fri 7th Aug 1998
# This version 10:20:53 AM Tue 11 Aug 1998 BST
# Needs to be run as root as access to /dev/mem is required.
# Won't run on Xenix as dd craps out
# Use tr and cat -v to catch rubbish

PATH=/usr/bin:/bin

Start=112 # Bios start is 0xe0000 = 112 x 8k Blocks
# (Get from hw -r rom, or is it a 'standard' location?)

#dd if=/dev/mem bs=8k skip=112 count=16 2> /dev/null | hd >/tmp/bios.$$

# This section could be in an external file, just stuck here to
# keep things simple, just now.

for Loop in 1 2 3 4 5 6 7 8 9 10 11
do
case $Loop in
1) Location=122928; Match="Award" ; ML=5 ; Offset=126065 ; Length=36 ;;
2) Location=98560 ; Match="AMIBIOS" ; ML=7 ; Offset=98424 ; Length=50 ;;
3) Location=48508 ; Match="Intel" ; ML=5 ; Offset=48572 ; Length=12 ;;
4) Location=0 ; Match="XXXXXXX" ; ML=7 ; Offset=98424 ; Length=50 ;;
5) Location=32 ; Match="Phoenix" ; ML=7 ; Offset=98343 ; Length=40 ;;
6) Location=84199 ; Match="PhoenixBIOS";ML=11 ; Offset=82170 ; Length=40 ;;
7) Location=128000; Match="AMIBIOS" ; ML=7 ; Offset=128120 ; Length=50 ;;
8) Location=65536 ; Match="AMIBIOS" ; ML=7 ; Offset=68762 ; Length=30 ;;
9) Location=65568 ; Match="American"; ML=8 ; Offset=65656 ; Length=38 ;;
10) Location=89904 ; Match="Acer"; ML=8 ; Offset=89904 ; Length=30 ;;
11) Location=99081 ; Match="Acer"; ML=8 ; Offset=99081 ; Length=30 ;;
esac

# ML is set to the number of characters to scan, can be set to
# an exact length is you are SURE the string is in an exact location.

# 2 AMI at 18100 (bedmin, whought,wheat, bbdmh, wickham)
# 3 Intel Pro m/board - TomP ?
# 4 AMI at 18000 - Not needed caught by 2
# 5 testbox
# 6 Phoenix (Robert)
# 7 AMI at 1F400 (stanho, avgb, upmin, hcorn)
# 8 AMI, OEM'ed
# 9 Old 486
# 10 Acer ?

# Look for a 'signature' (Match) at Location into the BIOS,
# use strings / awk to catch it

mem=`expr $Start \* 8192 + ${Location}`
What=`dd if=/dev/mem bs=1 count=$ML iseek=$mem 2>/dev/null | /bin/strings - |
awk '
/Award/ { print "Award" ; exit }
/Intel/ { print "Award" ; exit }
/AMIBIOS/ { print "AMIBIOS" ; exit }
/PhoenixBIOS/ { print "PhoenixBIOS" ; exit }
/Phoenix/ { print "Phoenix" ; exit }
/American/ { print "American" ; exit }
/ACR/ { print "Acer" ; exit }
'`
# Ok above is not nice, but it works where the below fails.
#awk -v Want=$Match '{ print ; if ( $0 ~ Want ) { print Want ; exit } }'`

# If it has been found, output what is at Offset:Length
if [ "$What" = $Match ]
then
echo "${Loop}-${Match} \c" # Output Loop for stats purposes
mem=`expr $Start \* 8192 + ${Offset}`
dd if=/dev/mem bs=1 count=$Length iseek=$mem 2>/dev/null | tr | cat -v
echo
exit
fi
done
# Check for ACR

xx="99-Acer `/etc/hw -r bios -v 2>/dev/null | egrep ' ACR.*-.*-.*-' | tail -1`"
[ "$xx" = "99-Acer " ] && xx="Bios Unknown"
echo $xx

Todd D'Amore commented on:

> Is there a way to do this ? We have a large # of servers in remote
> locations that need to be checked for Y2K compliance. Unfortunately we
> don't have a record of the BIOS ver # . I am wondering if anyone has
> figured out a way to do this with perhaps a small program or something
> along those lines. All servers are running SCO Open Server 5.xx
>

> Any and all suggestions are greatly appreciated, thanks for your time...
>
> Todd D'Amore
> tda...@jfax.com
> Network Administrator
> Jfax.com
> +1.310.966.1863

========================================================================
Tom Melvin t...@bdsl.com Sysop CIS SCOforum 100144,1471
========================================================================

[Bill Vermillion]

In article <199902261...@jpradley.jpr.com>,

Jean-Pierre Radley <j...@jpr.com> wrote:
>Tony Earnshaw averred (on Fri, Feb 26, 1999 at 05:20:11PM +0100):
>|
>| We've been using two small utilities (Internet downloadable) to check
>| the rtc and BIOS details. These utils insist that one does a cold boot
>| of the computer into MSDOS. We then run the rtc check by doing the
>| new-year rollover, and next all the leap years until 2009, then extract
>| the BIOS info with another util.
>
>URLs for the above utilities, please?

I got mine from www.zdnet.com. First page has the Y2K links.

I just looked and there is a new program from about a week ago that
replaces the one I downloaded.

Bill

[Bill Vermillion]

In article <1999022621...@xanth.bdsl.demon.co.uk>,

Tom Melvin <tom> wrote:
>In addition to the other comments, I have used the below script to
>work ou the bios ID (covers abut 95% of the machines I deal with).
>All I then need is to check out one machine and all others with
>the same ID can be assumed to be the same. I hope that logic is

>valid. ^^^^^^^^^^^^^^^^^^^^^^^^^^

That logic is not valied from my viewpoint. I'm will to hear
arguments against it. That is not a true statement unless all
the machines are from the same manufacturer and the same run of
motheboards. Just because the BIOS is the same does not mean the
RTC's are the same. One of the Y2K sites has documented some very
strange anomolies. One had to do with timing issues where the
update was not complete to the RTC but the line that said the
clock had been set was up. It documents a vary narrow window -
about 200 microseconds, where the first action doesn't complete
fully in thd first stage.

They also found one system where the time could jump several days,
hours, weeks. But they indicated to really test for that you'd
have to run the test continually for a long period of time. This
condition is quite rare.

Run the roll-over checks and be sure. You BIOS can NOT TELL
how the RTC will react on power-off/power-on.

During testing I also had one roll-over succesfully while running,
but on reboot the clock was back to 1980.

I have a couple of machines that aren't completely Y2K, but if you
set the clock manually, it will take 2000. So I'll shut it down
New Years eve, and reset the CMOS on bootup after midnight.

[Jean-Pierre Radley]

Bill Vermillion averred (on Sat, Feb 27, 1999 at 01:37:05AM +0000):

| >URLs for the above utilities, please?
|
| I got mine from www.zdnet.com. First page has the Y2K links.

Too vague, Bill. What are the programs and where are they?

[Tom Melvin]

Bill Vermillion commented on:

> In article <1999022621...@xanth.bdsl.demon.co.uk>,
> Tom Melvin <tom> wrote:
> >In addition to the other comments, I have used the below script to
> >work ou the bios ID (covers abut 95% of the machines I deal with).
> >All I then need is to check out one machine and all others with
> >the same ID can be assumed to be the same. I hope that logic is
> >valid. ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> That logic is not valied from my viewpoint. I'm will to hear
> arguments against it. That is not a true statement unless all
> the machines are from the same manufacturer and the same run of
> motheboards. Just because the BIOS is the same does not mean the
> RTC's are the same. One of the Y2K sites has documented some very

I don't have a definite answer, I tested this theory on a few of machines
and it held true. Recently, engineers have been out and run the nstl
testing program and I must admit again the above theory has held true.

I have noticed that even if there is a slight revision of the board the
BIOS ID changes I don't know enough about the techinical issues between
the relationship of the BIOS ID to the motherboard. The theory can be
used to give a rough idea.

I agree 100% that the only sure way is to check it.

Mind you, I have one machine that failed every test you could run
on it, kicked OSR 5 into life, let it rollover, rebooted, cold
booted and all was fine - in/out of bios setup fine, it would only
give a problem if the Date/Time in the BIOS was changed.

So I think no matter how you test there are always going to be oddities
that wil crop up.

[Bill Vermillion]

In article <1999022623...@jpradley.jpr.com>,

Jean-Pierre Radley <j...@jpr.com> wrote:
>Bill Vermillion averred (on Sat, Feb 27, 1999 at 01:37:05AM +0000):
>| >URLs for the above utilities, please?

>| I got mine from www.zdnet.com. First page has the Y2K links.

>Too vague, Bill. What are the programs and where are they?

Sorry about that. But I got them a month or so ago and can only
tell you from memory. I looked in yesterday after your question
and saw that some had been changed and it's on the y2k page.

Well you finally convinced me to try 'mutt' again, now are you
going to make me give up 'lynx' :-)

[GTE_News]

Thanks to all who posted a response, your help is greatly appreciated. I'll
get this problem licked one way or another.

Thank you

Todd D'Amore
Todd D'Amore wrote in message <7b48rd$v4$1...@news-1.news.gte.net>...