I'm fairly new to SCO ... and could really do with some help here.
I have a SCO box (OpenServer 5.0.5), which is randomly crashing. When
rebooting, fsck runs and reports a number of problems, mainly "File System
larger than Physical Disk - please backup and rebuild".
It seems that the cpio backups have been failing for the last x months (but
not reporting an error - they just 'hang' - probably due to FS corruption!).
So, I have a SCO box, with no backups (cpio hanging) - and a disk full of
major FS errors. The machine however is up and running (albeit crashing
every few hours). We really need to rescue as much data as possible.
How should I attack this? Is there any trick to fixing / recovering from
this sort of state?
I would try installing a second disk, creating identical sized partitions -
and manually moving data accross. However, I have no idea how to re-create
the boot blocks etc.
Any help would be *very* much appreciated.
Thanks,
Steve
Bristol, UK
>
>Hi All,
>
>I'm fairly new to SCO ... and could really do with some help here.
>
>I have a SCO box (OpenServer 5.0.5), which is randomly crashing. When
How is it crashing? Panic? If so, show the panic message. Is the
system running off of a UPS? If so, are the batteries dead, bringing
the system down ungracefully?
Any hints here would help.
>rebooting, fsck runs and reports a number of problems, mainly "File System
>larger than Physical Disk - please backup and rebuild".
(possibly) Known issue; See TA#105306 at support.sco.com
>
>It seems that the cpio backups have been failing for the last x months (but
>not reporting an error - they just 'hang' - probably due to FS corruption!).
Ouch!
>
>So, I have a SCO box, with no backups (cpio hanging) - and a disk full of
>major FS errors. The machine however is up and running (albeit crashing
>every few hours). We really need to rescue as much data as possible.
>
>How should I attack this? Is there any trick to fixing / recovering from
>this sort of state?
First thing I might try - 'might' being the operative word here - is
to download and install one of the Supertars
(http://aplawrence.com/Reviews/supertars.html) and attempt to create a
full backup. This may be a double-edged sword, as introducing
new/additional software on a system with FS corruption *may* compound
the problem. If at all possible backup your non-OS data to tape (via
tar or cpio), THEN install the Supertar. If the Supertar backup
verfies OK, then use *it* to restore your system.
>
>I would try installing a second disk, creating identical sized partitions -
>and manually moving data accross. However, I have no idea how to re-create
>the boot blocks etc.
Check /var/adm/syslog and /var/adm/messages for any hints as to what
is causing the corruption. If there is no indication of a hard disk
failure, then I might be inclined to low-level the existing disk and,
assuming no errors during the format, reload the system (either from
the Supertar backup or from scratch, depending on which I trusted
most).
>
>Any help would be *very* much appreciated.
>
>
>Thanks,
>
>
>Steve
>Bristol, UK
>
Scott McMillan
> I have a SCO box (OpenServer 5.0.5), which is randomly crashing. When
> rebooting, fsck runs and reports a number of problems, mainly "File System
> larger than Physical Disk - please backup and rebuild".
That message indicates a very serious problem, very likely the cause of
_all_ the system's problems.
As far as I know, there are only two ways to get a filesystem larger
than the device. One is to run `mkfs -y /dev/some-device 123456`,
giving too large a number. The "-y" overrides mkfs's normal caution
about the requested size not matching the size of the device. The other
way is to make an image backup of a filesystem, then restore it onto a
smaller device.
> It seems that the cpio backups have been failing for the last x months (but
> not reporting an error - they just 'hang' - probably due to FS corruption!).
>
> So, I have a SCO box, with no backups (cpio hanging) - and a disk full of
> major FS errors. The machine however is up and running (albeit crashing
> every few hours). We really need to rescue as much data as possible.
>
> How should I attack this? Is there any trick to fixing / recovering from
> this sort of state?
Boot from a crash recovery floppy set. Mount the hard disk filesystem
read-only. Attempt to back it up.
You say "cpio hanging". A cpio backup is typically done with a pipeline
where one part collects the filenames:
find . -print
and the other part backs them up:
| cpio -o -O /dev/rStp0
You can do these separately, to get a better idea of where it's hanging.
Suppose you had booted from a boot/root set; /mnt was mounted from the
hard disk; and /mnt2 was another hard disk you added to the machine as a
writable scratch area. You could do something like:
cd /mnt
(find . -print > /mnt2/file-list; echo DONE) &
cd /mnt2
ls -l file-list
[wait a while]
ls -l file-list
Eventually you'll see "DONE". Or maybe hard disk activity will stop and
/mnt2/file-list will stop growing. If the list completes, you can back
up from it, e.g.;
cd /mnt
cpio -ov -O /dev/rStp0 < /mnt2/file-list
If this hangs, you'll be able to tell because the tape will stop
spinning and the filenames will stop scrolling. At that point you'll
have a tape containing _some_ of the files you want to back up. You can
restore it on another system. Meanwhile, you reboot, edit
/mnt2/file-list to remove the files already backed up, and back up again
to another tape. Repeat until frustrated.
You may find that the tape contains less files than you saw printed on
the screen. The hang may cause the tape to stop writing before it
should. When cutting down the list, be sure to remove only files that
have already been successfully restored elsewhere (plus the file(s) that
cause the hangs).
> I would try installing a second disk, creating identical sized partitions -
> and manually moving data accross. However, I have no idea how to re-create
> the boot blocks etc.
This would also work -- in fact copying directly across will probably be
a lot easier than doing it with tapes. You can use any archiver; tar
and cpio come with the system, the various "supertar" products are
better.
The best approach here would probably be to put in a new drive (take out
the old), do a fresh install, then add the old drive as a secondary
drive, copy the data files over.
You're either going to learn a lot about the system very fast, or you'll
end up hiring a consultant...
>Bela<