Re: Anyone seen this before?

Pat Welch wrote:
Steve M. Fabac, Jr. wrote:
I have a client running SCO 5.0.5 Host on a Compaq Prosignia 740
system where I replaced the single hard disk on the cha controller
with an Adaptec 2110S RAID controller and a pair of disks (RAID1).

The system has been running fine since the installation of the 2110S
in August 2004.

Last week I talked the client into replacing his Cypher QIC tape
drive and home brewed cpio backup with a DVD writer and Microlite
BackupEdge 2.2.

I had some initial problem with getting Backup Edge to properly
recognize the DVD drive. But working with Microlite tech support,
we identified an SCO tech article TA105353 that addresses SCSI underrun
errors with the Compaq cha driver. Once the changes specified in
the article were applied to the SCSI ID assigned to the DVD (the
IDE dvd drive is connected with an AEC 7720U SCSI to IDE adapter),
Backup Edge was able to auto detect the drive and subsequently
backup and verify using DVD-RAM media.

Now the problem: When testing the RE2 disaster recovery CD boot
image, I noted that the RAID1 hard disks spin down between operations
when booting and performing operations from the RE2 media.

Example: Going to the shell prompt and executing "mount /dev/hd0root /mnt"
results in the disks spinning up, root is mounted, and then the
disks spin down.

Subsequently, issuing the command "umount /dev/hd0root" is slow to
execute as the disks spin up, hd0root is unmounted, and then the
disks spin down. When I exited RE2 (to reboot the machine), the RAID
controller message "flushing: 0 1 2.... etc." which normally appears
when haltsys or shutdown is executed from the live system, is delayed
as the controller waits for the disks to spin back up.

I have never seen this before with Backup Edge RE2 media.

When I sent an inquiry to Microlite tech support, the response was:

I dont think this is RecoverEDGE related to be honest. We have no code to control the hard drive outside of configuring, mounting, and writing to it.

It sounds like some type of BIOS setting. However, I will pass this over to our engineers to see if they have an opinion.

But since SCO 5.0.5 is obsolete product and Microlite does not list
it as supported with BE 2.2, I don't expect any further testing from
Microlite.

I am posting this to the NG in the hope that someone had seen this before
(disks spinning down) on the Adaptec 2110 controller when cdrom or emergency
boot floppy has been booted and can direct me to the appropriate setting
to change this behavior.


Hi, Steve.

FYI 5.0.5 IS listed as supported by 02.02.00 by Microlite.

That said - it very much looks like an overly aggressive power saving/management setting in the BIOS, either the main BIOS or the RAID BIOS - most likely the main BIOS.

Hi Pat.

Thanks for the response. I was back on-site at the client's today to
recreate and re-test new RE2 media and the same spin down was experienced.

I did check the Adaptec controller settings (Control-A), but found nothing
in the configuration screen for the controller, Raid, or hard disk
that indicated power management or spin-up/spin-down.


Look for things like a setting that asks if the OS supports power management - make that No, as it probably assumes Windows style power management.

I had not seen your post and so I did not check the system BIOS (press
F10 when prompted, examine EISA settings) as the Adaptec 2110S is not a
Compaq supplied RAID controller and I felt that it was unlikely that the
Compaq EISA BIOS would have hooks into the Adaptec PCI RAID card.


Turn off anything that touches on power management, examine closely any setting that touches on hard drives.

As a last try, remove 02.02.00 and install either a back rev 02.01.xx or the just released 02.03.00 on the low chance that some interaction with 02.02.00 is exacerbating the spin down.

The spin down while annoying is not my major concern. It is very noticeable
when navigating the RE2 menu and doing things like fsck as you can hear
the disks spin up/down and anyone who has used Microlite RE2 would notice
the strange operation. My results in verifying the test restore was disturbing.

I begin to suspect that something was not right after my first attempt to
verify the RE2 media by restoring a "single-directory" backup created using
edgemenu to the /tmp directory (hd0root mounted on /mnt; cd /mnt/tmp).

The test restore of /usr/bbx to /tmp/bbx appeared to work as expected
with the command: "edge xvbf 64 dvd0" executed in the /mnt/tmp directory.

I rebooted the system and created a script to find all the files
in /tmp/bbx and run sum -r on the restored files and the original files
in /usr/bbx with the output saved to /tmp/sum.out. To my surprise, I found
74 files that failed with different checksums:

14755 8 /tmp/bbx/license.txt This list just shows a few of the files
52403 8 /usr/bbx/license.txt failing the sum -r test
21957 75 /tmp/bbx/relnotes.txt
11038 75 /usr/bbx/relnotes.txt
41738 100 /tmp/bbx/errata.htm
35862 100 /usr/bbx/errata.htm
64743 8 /tmp/bbx/bwu/Bbw00002.htm
23384 8 /usr/bbx/bwu/Bbw00002.htm
64181 60 /tmp/bbx/convert/BXRCV
46796 60 /usr/bbx/convert/BXRCV
11901 18 /tmp/bbx/convert/LISTING.BB3
19397 18 /usr/bbx/convert/LISTING.BB3
23746 18 /tmp/bbx/convert/LISTING.RX1
32926 18 /usr/bbx/convert/LISTING.RX1

Worse even then that was the result of the subsequent nightly backup:

# cat changedfiles_master.log
..../etc/utmp, 0 blocks <!Excluded>
..../etc/wtmp, 0 blocks <!Excluded>
..../etc/Master_backup, 0 blocks <!Excluded>
..../usr/lib/edge/tmp/dvd0.hotplug, 0 blocks <!Date>
==> Archive date: Wed Nov 12 20:00:10 2008
==> Disk file date: Wed Nov 12 20:54:56 2008
..../usr/dpt/dptelog.NotAvailable, - blocks <!Date>
==> Archive date: Wed Nov 12 20:25:31 2008
==> Disk file date: Wed Nov 12 20:50:32 2008
..../tmp/raid.save, 0 blocks <!Date>
==> Archive date: Wed Nov 12 20:25:04 2008
==> Disk file date: Wed Nov 12 21:00:04 2008
..../tmp/bbx/std/_visual, - blocks <!Byte> 1
==> Bytes differ at byte 10240
..../tmp/bbx/std/_xref.utl, - blocks <!Byte> 2
==> Bytes differ at byte 0
..../tmp/bbx/ext/_edtkey2.fam, - blocks <!Byte> 3
==> Bytes differ at byte 10240
..../tmp/bbx/ext/_edtkey3.fam, - blocks <!Byte> 4
==> Bytes differ at byte 10240
..../tmp/bbx/ext/_edtkeya.fam, - blocks <!Byte> 5
==> Bytes differ at byte 10240
..../tmp/bbx/ext/_fieldrs.bbx, - blocks <!Byte> 6
==> Bytes differ at byte 10240
..../tmp/bbx/ext/_filetyp.bbx, - blocks <!Byte> 7

.......

..../tmp/bbx/ext/_outdevi.am, - blocks <!Byte> 27
==> Bytes differ at byte 0
..../tmp/bbx/ext/_parse.pub, 3 blocks <!Byte> 28
==> Bytes differ at byte 0
..../tmp/bbx/ext/eus.am, - blocks <!Byte> 29
==> Bytes differ at byte 0
..../var/opt/K/SCO/Unix/5.0.5Eb/etc/auth/system/pw_id_map, 1 blocks <!File Changed>
<!Date>
==> Archive date: Wed Nov 12 20:06:29 2008
==> Disk file date: Wed Nov 12 20:33:41 2008
==> Bytes differ at byte 8
..../var/adm/sa/sa12, - blocks <!File Changed> <!Date>
==> Archive date: Wed Nov 12 20:00:02 2008
==> Disk file date: Wed Nov 12 21:00:04 2008
==> Bytes differ at byte 172392

29 of the files in /tmp/bbx failed the verify pass of the full
system backup. Meaning that the files were backed by the
scheduled backup starting at 20:00 and when the verify
pass performed a bit-level verify of the files on the hard
disk vs the files read from the DVD-RAM backup media, they
were different (not changed re sa12)!!

# sum -r /tmp/bbx/license.txt /usr/bbx/license.txt

14755 8 /tmp/bbx/license.txt
52403 8 /usr/bbx/license.txt

# ls -l /tmp/bbx/license.txt /usr/bbx/license.txt

-rwxr-xr-x 1 1000 404 3641 Nov 6 1998 /usr/bbx/license.txt
-rwxr-xr-x 1 1000 404 3641 Nov 6 1998 /tmp/bbx/license.txt


# cat /tmp/bbx/license.txt | head -13

..../bin/edge
..../usr/lib/libsocket.so.1
..../bin/clear
..../bin/dparam
..../usr/bin/tput
..../etc/badtrk
..../etc/divvy
..../etc/fsck
..../etc/fdisk
..../etc/masterboot
..../etc/hdboot0
..../etc/hdboot1
/usr/lib/edge/recover2/MISCFILES


# cat /usr/bbx/license.txt | head -13

PLEASE READ THIS LICENSE CAREFULLY BEFORE INSTALLING THE SOFTWARE.
BY INSTALLING THE SOFTWARE, YOU ARE AGREEING TO BE BOUND BY THE TERMS
OF THIS LICENSE. IF YOU DO NOT AGREE TO THE TERMS OF THIS LICENSE,
YOU ARE NOT AUTHORIZED TO INSTALL THE SOFTWARE.

SOFTWARE LICENSE AGREEMENT
BASIS INTERNATIONAL LTD.
REDISTRIBUTION NOT PERMITTED

BASIS INTERNATIONAL LTD. ("LICENSOR") IS WILLING TO LICENSE THE SOFTWARE TO YOU
("LICENSEE") ONLY IF YOU ACCEPT ALL TERMS IN THIS LICENSE AGREEMENT.


With the system up and running in multiuser mode, I restored the same
DVD-RAM single-directory backup to /tmp/tmp/bbx and updated my checkfiles
script to compare /tmp/tmp/bbx to /usr/bbx and all 490 files matched.

I suspect that I had created a faulty RE2 recovery cd. (Be sure to mind
the BE warning to not rely on the RE2 media until you verify that
it works!)

Since I was unable to configure the Compaq Prosignia to boot
the DVD drive, I had to create RE2 media on CDR to use it to
boot from the original Compaq IDE cd drive.

I mistakenly selected "Boot Media on dvd0" from the
Backup Edge menu (marked as "4" below) to build the RE2 media
thinking that it would be correct. However, when I booted the
media in the cdrom0 drive, it failed the "testing access to CD"
phase and then reported that it could not load the misc files.

I thought that I could get around this by re-making the
single-directory backup from edgemenu and checking "make
backup bootable" option to write the cdrom.iso image that was
created for the step to create RE2 on the media in DVD drive.

The subsequent test of the RE2 CDR media passed the "testing access
to cd" and tickled the DVD-RAM disk in the DVD drive. It then
loaded the misc files from the cdrom.iso image on the DVD-RAM drive
and I performed the faulty restore of the /usr/bbx archive to /mnt/tmp/bbx.

Today, I rebuilt the RE2 ISO selecting the option (marked as 3 below)
"Image Only for cdrom0 Bootable Backups."

lqWhat Kind of Recovery Media/Image (F2 to Exit)?qk
1 x (Keep Current Settings) x
2 x 3.5" 1.44MB Floppy Diskette x
3 x Image Only for cdrom0 Bootable Backups x
4 x Boot Media on dvd0 x
5 x Image Only for dvd0 Bootable Backups x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

Since the customer's system is 5.0.5 host (no networking) I was
unable to copy the cdrom.iso off the system and looked for another way
to create the RE2 media.

I found cdrecord in /usr/lib/edge/bin and ran cdrecord -scanbus to identify
the ID for the DVD drive. I then created a "mkcd" script to write
the cdrom.iso image to CDR media in the DVD drive:

# cat /usr/lib/edge/bin/mkcd
#Cdrecord 2.00.3 (i386-pc-sco3.2v5.0.5) Copyright (C) 1995-2002 Jvrg Schilling
#Using libscg version 'schily-0.7'
#scsibus0:
# 0,0,0 0) *
# 0,1,0 1) *
# 0,2,0 2) *
# 0,3,0 3) *
# 0,4,0 4) *
# 0,5,0 5) 'MATSHITA' 'DVD-RAM SW-9576S' 'AY0J' Removable CD-ROM
# 0,6,0 6) *
# 0,7,0 7) *
#
/usr/lib/edge/bin/cdrecord -v -v fs=6m driveropts=burnfree speed=24 \
dev=0,5,0 /usr/lib/edge/recover2/images/cdrom.iso | tee /tmp/logcd 2>&1

I performed the "single directory" backup of /usr/bbx to DVD-RAM media today,
booted the new RE2 media, mounted /dev/hd0root on /mnt, cd to /mnt/tmp
and moved bbx to obbx to get it out of the way, then executed
edge xvbf 64 dvd0 to restore today's single directory backup of /usr/bbx.
(the one last week was done on the daily DVD rotation and had been
over written with the nightly backup so it was unavailable for today's
test.)

I noticed the same disk spin-up/spin-down as I performed the steps above
and again when unmounting /dev/hd0root and running a fsck -ofull from the
RE2 disk utility menu.

When I shut the RE2 system down and got the the "safe to power off, press
any key to reboot" message, I pressed enter to reboot the system without
powering off so as to avoid chancing any problems with the RAID controller.

I ran the same script to perform the sum -r on the files in /usr/bbx and
/tmp/bbx and they all matched except for RMRQMT_SORT.


sum -r /tmp/usr/bbx/config.new /usr/bbx/config.new >> /tmp/new_sum.out 2>&1
sum -r /tmp/usr/bbx/GETDAY /usr/bbx/GETDAY >> /tmp/new_sum.out 2>&1
sum -r /tmp/usr/bbx/RMRQMT_SORT /usr/bbx/RMRQMT_SORT >> /tmp/new_sum.out 2>&1
sum -r /tmp/usr/bbx/config.030101 /usr/bbx/config.030101 >> /tmp/new_sum.out 2>&1
sum -r /tmp/usr/bbx/config.050901 /usr/bbx/config.050901 >> /tmp/new_sum.out 2>


51507 5 /tmp/bbx/config.new
51507 5 /usr/bbx/config.new
30248 2 /tmp/bbx/GETDAY
30248 2 /usr/bbx/GETDAY
58230 73 /tmp/bbx/RMRQMT_SORT
53429 10 /usr/bbx/RMRQMT_SORT
29117 5 /tmp/bbx/config.030101
29117 5 /usr/bbx/config.030101
06941 5 /tmp/bbx/config.050901
06941 5 /usr/bbx/config.050901

#
# ls -l /tmp/bbx/RMRQMT_SORT /usr/bbx/RMRQMT_SORT
-rw-rw-rw- 1 katie group 512 Nov 18 14:47 /tmp/bbx/RMRQMT_SORT
-rw-rw-rw- 1 katie group 512 Nov 18 14:47 /usr/bbx/RMRQMT_SORT

# cmp -l /tmp/bbx/RMRQMT_SORT /usr/bbx/RMRQMT_SORT
#

Note that cmp -l did not list any differences.


# hd /tmp/bbx/RMRQMT_SORT > /tmp/hd.out.tmp
# hd /usr/bbx/RMRQMT_SORT > /tmp/hd.out.orig

# diff /tmp/hd.out.tmp /tmp/hd.out.orig
#

# sum -r /tmp/hd.out*
47490 1 /tmp/hd.out.orig
47490 1 /tmp/hd.out.tmp

# cat hd.out.tmp
0000 3c 3c 62 62 78 3e 3e 06 17 00 00 00 00 00 60 00 <<bbx>>.......`.
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
0070 04 02 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
0200
# cat /tmp/hd.out.orig
0000 3c 3c 62 62 78 3e 3e 06 17 00 00 00 00 00 60 00 <<bbx>>.......`.
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 ................
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
0070 04 02 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
*
0200
#

With the exception of the problem with sum -r on RMRQMT_SORT above,
I am confident that we now have a good RE2 image and that the disk spin
up/down when running from the booted RE2 media will not prevent getting
a good restore when (if) we have to use it to recover the system.


Good luck. Messing with old stuff is so much fun ... :|


Ain't it the truth!
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670

.