Corrupted file on OSR5.0.2

Corrupted file on OSR5.0.2

Post by Lucky Leavel » Wed, 04 Sep 1996 04:00:00



Bela, et al,
   Over the weekend, I installed OSR5.0.2 on a customer's system from
CD-ROM (actually reinstalled, as it was OSR5.0.0).  In the course of the
install, I received the following error:

        file /opt/K/SCO/nfs/2.0.0.Dp/etc/up/yppush
        has checksum 72563527  expected 885376000

Is this file needed?  If so, how can I get a good copy of it?

Further, Lone-Tar found another file which failed verification, usually
indicating a corrupt file on disk:

/opt/K/SCO-aga-p9100/5.2.1c/.softmgmt/var/usr/lib/grafinfo/diamond/viperpro.xgi

which, I'm guessing, has something to do with a DIamond video adapter.
Since we don't use one of those, may I just delete the file?

BTW, in the course of installing OSR5.0.2, I did a thorough, destructive
scan on this hard drive and found no bad blocks.

Thank you,
Lucky

Lucky Leavell                            Phone: (812) 945-6555
Relational Information Systems, Inc.       FAX: (812) 949-9233

New Albany, IN 47150-2013                       71534,2674 (CompuServe)
WWW Home Page:  http://www.iglou.com/ris   ftp://www.iglou.com/members/ris

 
 
 

Corrupted file on OSR5.0.2

Post by Bela Lubki » Fri, 06 Sep 1996 04:00:00



>    Over the weekend, I installed OSR5.0.2 on a customer's system from
> CD-ROM (actually reinstalled, as it was OSR5.0.0).  In the course of the
> install, I received the following error:

>    file /opt/K/SCO/nfs/2.0.0.Dp/etc/up/yppush
>    has checksum 72563527  expected 885376000

> Is this file needed?  If so, how can I get a good copy of it?

It's part of NIS (formerly Yellow Pages).  If you mount the CD, the same
file should exist at the same pathname (/mnt/opt/K/...).  Compare them.
If they match, the file on the CD must be corrupted, which I think is
very unlikely.  More likely you'll find that the copy on your hard disk
is corrupted.  That means it must have been mis-copied; which leads to
suspicion about the hardware.  A bad copy could be caused by SCSI bus
problems, bad memory with no parity checking, or that sort of thing.

Quote:> Further, Lone-Tar found another file which failed verification, usually
> indicating a corrupt file on disk:

> /opt/K/SCO-aga-p9100/5.2.1c/.softmgmt/var/usr/lib/grafinfo/diamond/viperpro.xgi

> which, I'm guessing, has something to do with a DIamond video adapter.
> Since we don't use one of those, may I just delete the file?

That's the grafinfo file for the Diamond Viper Pro.

What does Lone-Tar mean by failed verification?  It backed the file up,
then did a bit-for-bit compare and it didn't match?  That's further
evidence of a hardware problem causing file corruption.  You shouldn't
be so much concerned about these individual files, as concerned about
the evidence of ongoing corruption.  You need to figure that out and fix
it or the system will be unreliable.

Quote:>Bela<


 
 
 

Corrupted file on OSR5.0.2

Post by Lucky Leavel » Fri, 06 Sep 1996 04:00:00




> very unlikely.  More likely you'll find that the copy on your hard disk
> is corrupted.  That means it must have been mis-copied; which leads to
> suspicion about the hardware.  A bad copy could be caused by SCSI bus
> problems, bad memory with no parity checking, or that sort of thing.

I did a thorough, destructive scan on the HD, an eight month old Conner
1GB (1060S, I think) with AWRE and ARRE turned on.  No bad blocks were
found in the scan.  The MB is a new ASUS with ECC using parity memory
(430HX chipset with A2 stepping ... thanks for that tip).  I did bump the
transfer rate upt from 5MBs to 6.7.  (I tested it at 8 MBs OK and backed
off to 6.7)  Parity checking is enabled on the SCSI bus and every device
that supports it (all of them, I think).

I did do a Software Verify which found 34 discrepancies which does seem
excessive for a new install.  I allowed it to fix those it could.

 >

Quote:> What does Lone-Tar mean by failed verification?  It backed the file up,
> then did a bit-for-bit compare and it didn't match?  That's further
> evidence of a hardware problem causing file corruption.  You shouldn't
> be so much concerned about these individual files, as concerned about
> the evidence of ongoing corruption.  You need to figure that out and fix
> it or the system will be unreliable.

It means a byte compare failed.  If a file's size or date stamp changes,
it isn't verified but that is not considered a failure.

Should I have turned the AWRE/ARRE off before doing the disk scan? (I just
now thought of that in resplying to this message.)  The disk scan reported
no bad blocks.  Is there any way to check on how many blocks have been
remapped?  I understand a successful remapping is not reported as an
error.

How can I test the HD so I can request replacement under warranty?  

Thank you,
Lucky

Lucky Leavell                            Phone: (812) 945-6555
Relational Information Systems, Inc.       FAX: (812) 949-9233

New Albany, IN 47150-2013                       71534,2674 (CompuServe)
WWW Home Page:  http://www.iglou.com/ris   ftp://www.iglou.com/members/ris

 
 
 

Corrupted file on OSR5.0.2

Post by Jeff Hyma » Fri, 06 Sep 1996 04:00:00





> > very unlikely.  More likely you'll find that the copy on your hard disk
> > is corrupted.  That means it must have been mis-copied; which leads to
> > suspicion about the hardware.  A bad copy could be caused by SCSI bus
> > problems, bad memory with no parity checking, or that sort of thing.

> I did a thorough, destructive scan on the HD, an eight month old Conner
> 1GB (1060S, I think) with AWRE and ARRE turned on.  No bad blocks were
> found in the scan.  The MB is a new ASUS with ECC using parity memory
> (430HX chipset with A2 stepping ... thanks for that tip).  I did bump the
> transfer rate upt from 5MBs to 6.7.  (I tested it at 8 MBs OK and backed
> off to 6.7)  Parity checking is enabled on the SCSI bus and every device
> that supports it (all of them, I think).

> I did do a Software Verify which found 34 discrepancies which does seem
> excessive for a new install.  I allowed it to fix those it could.

> > What does Lone-Tar mean by failed verification?  It backed the file up,
> > then did a bit-for-bit compare and it didn't match?  That's further
> > evidence of a hardware problem causing file corruption.  You shouldn't
> > be so much concerned about these individual files, as concerned about
> > the evidence of ongoing corruption.  You need to figure that out and fix
> > it or the system will be unreliable.

> It means a byte compare failed.  If a file's size or date stamp changes,
> it isn't verified but that is not considered a failure.

> Should I have turned the AWRE/ARRE off before doing the disk scan? (I just
> now thought of that in resplying to this message.)  The disk scan reported
> no bad blocks.  Is there any way to check on how many blocks have been
> remapped?  I understand a successful remapping is not reported as an
> error.

> How can I test the HD so I can request replacement under warranty?  

Lucky, here's some helpful info.

###############################################################################
KEYWORDS: bit level verify verification error byte Byte
===============================================================================

QUESTION: My bit-level verification failed. Inside the log file
          '/log/changed.V' contains the following file error:

          ./u/tpdata/eft/TBHST.I85, 20341 blocks <!Byte>
          ==> Bytes differ at block 42938

          The file, TBHST.I85 is the one I had so much trouble with last week.
          How can this file change between backup and verify when no one else
          is logged on?

ANSWER:   1. Lets see if it's the file, or a spot on the tape where this file
             tends to write to on the tape:
             [ Make sure NO ONE is on the system except 'root' ]
             # cd /u/tpdata/eft
             # cp TBHST.I85 xxxxx
             # sum TBHST.I85 xxxxx
         >>> Do the numbers match?
             # rm xxxxx
             # cp TBHST.I85 /tmp/xxxxx  (I'm assuming /u is a partition)
             # sum TBHST.I85 /tmp/xxxxx
         >>> Do the numbers match?
             # rm /tmp/xxxxx
             # lone-tar Cvfb  /tmp/trash.tar 20 ./TBHST.I85
             # lone-tar TTvfb /tmp/trash.tar 20
         >>> Does Bit-Level Pass OK?
             # cd /tmp
             # lone-tar xvfb trash.tar 20
             # sum TBHST.I85 /u/tpdata/eft/TBHST.I85
         >>> Do the numbers match?
             # rm trash.tar

          If everything above passes, then this proves that there are no
          I/O problems with this file 'TBHST.I85' when being moved around
          the hard drive, or even another partition.

          Next step is to see if to file 'TBHST.I85' by itself, can be
          written to the tape OK. Here we go:

          2. [ Make sure NO ONE is on the system except 'root' ]
             a. Put a blank tape in the tape drive... _not_ write protected.
             b. Run these commands:
                # cd /
                # lone-tar Cvfb /dev/rct0 20 ./u/tpdata/eft/TBHST.I85
                                  ^^^^.... Specify your correct tape drive name.
                # lone-tar TTvfb /dev/rct0 20

            >>> Does it pass bit-level verification?
######## (c)1996 Lone Star Software Corp. #####################################

Hope this helps,
Jeff Hyman
                                .--.
__________________________  .-. |  |  __________________________________

 Cactus International, Inc. | |_|  | | | Sales:   (800) LONE-TAR
 13987 W. Annapolis Ct.  _  |___   |_| | Support: (301) 829-1622
 Mt. Airy, MD 21771    _| ~-    |   ___| Fax:     (301) 829-1623
 Jeffrey Hyman         \,  _}   |  |     FTP:     ftp.cactus.com
 CompuServe: 74710,2627  \(     |  |     WWW:     http://www.cactus.com
------------------------------- |  | -----------------------------------
                                |  |

 
 
 

1. HTFS problem on SCO OSR5.0.2

Hi all

        I have a SCO box with Open Server 5.0.2 and it crash showing the
following message on console

PANIC:HTFS:Free block 62851 epi freed on HTFS dev hd (1/42)
Trying to dump 12191 pages to dumpdev hd (1/41), 153 pages per '.'

Panic String: HTFS: Free block %d epi freed on %s dev %s (%u/%u)

        When tried run tcbck , integrity or any else that make hd access these
message appear :

HTFS: Allocated inode 1030 in HTFS dev hd (1/42) superblock

        I'm looking for any patch for that problem or other way of solution.
Any idea, please?

        TIA

        betsy


2. : using an Aztech CDA468-03ISE CD-ROM with Linux

3. SCO OSR5.0.2 - X11 License Manager problem

4. Which on Redhat or Caldera?

5. SCSI Bus Hangs (was OSR5.0.2 Install Hangs)

6. How to solve "ldtermrsrv: out of blocks" on Solaris 2.4??????

7. tar, HP DAT drive, OSR5.0.2 - help?

8. Linux INFO-SHEET (part 1/1)

9. Soundblaster and OSR5.0.2

10. Problem with SCO OSR5.0.2 / AFPS/ Windows 95

11. SCO OSR5.0.2: Unable to open License Manager in X

12. OSR5.0.2 swap problem

13. Lone-Tar Backup Errors ==> OSR5.0.2 Problems