Re: what to do about "cannot dump to dumpdev hd(1/41): space for

b.hutchman@xxxxxxxxx wrote:
Bela will likely chime in here, but I don't think it is possible to install
SCO 5.0.5 with root anywhere but in part2. By default 0 is boot, 1 is swap,
and 2 is root. Unless this is SCO UNIX 3.2v4.2 (pre SCO 5.0.0) in which
case 0 is root and 1 is still swap.

That is good to know. I'll grep my /dev/part2 device and see if I can
smoke out anything that would point to root being there.

The IT guy at the printing place found a page in one of the manuals
with this breakdown which supports what you said:
0 boot EAFS
1 swap NON FS
2 root HTFS
3 eng HTFS
4 eng2 HTFS
5 eng3 HTFS
6 recover NON FS
7 d1057all Whole Disk

When I did the mkdev hd, I remember seeing divvy show eng3 and the
whole disk division and maybe boot but nothing else. This has been
the challenge is figuring out what the original divvy table looked
like so I can then either try repair those filesystems or restore them
from tape (no documentation on what the tapes are so it is like
working a puzzle).

Did divvy show the start and end blocks for the unnamed file systems?
(Please post the divvy table you see. Second request!) If not, you have
a big problem as trying to find the start of a division is not
a trivial matter.

In another post you said:

I'm not sure what he used ... I'll ask and find out. The brand new SCSI disk does the exact same thing the old one did. Divvy looks the same, the same 3 bad blocks were complained about when I added the disk with mkdev hd the first time, when I do fsck -ofull on /dev/part4 and /dev/part5 they both have the same warning about the filesystem being larger than the filesystem it is currently in etc. (which I exit out of and don't continue) so at this point it looks like a good copy of the original disk.

The warning that the file system is larger then the space allocated
should not be fatal. Fsck is warning you that you should take steps to
correct the problem. I've see that before when a client used Microlite Backup
Edge to move his system from an 9G disk to an 18G disk and answered "percentage"
when asked by the RE2 software how he wanted the partitions resized to fit the
new disk: "Size" keeps the fdisk partition and divvy file system the same size
as the original disk, "percentage" expands the fdisk partition and divvy file systems
as it can to utilize the additional disk space on the new disk.

Go ahead and run "fsck -n -ofull /dev/part3 > /tmp/logfsck 2>&1" That will not
alter the file system and log its results to /tmp/logfsck. Check to see what
fsck tells you about the file system.

Note that even if the file system is not "clean" you can mount it with -r (read only)
and create a current backup to tape. If fsck throws a lot of errors beyond:
"UNREF FILE I=inode-number OWNER=UID MODE=file-mode SIZE=file-size
MTIME=modification-time (RECONNECT)" you might not want to trust what you can read
from the read-only file system. If logfsck shows only minor problems, go ahead and
run fsck without the -n and let it fix what it can.

With all the information you have provided I'd suggest the following
sequence:

1) restore the suspected root backup tape to a file system (not the root)
on the IDE disk you are using to try to mount the problem disk. Use
dtype /dev/rStp0 to check the format of the tape (cpio, tar, etc.) Pray
that it is not tar as tar is inadequate for backing up the root file system
as it will not backup /dev nodes.

2) Figure out how old the root back up is. 1993-95? This century? You decide if
you can trust the backup to have all the information you need to replicate
the running system to a new disk.

3) Check the crontab on the restored root to see if you can identify any
scheduled backup that might have been set up. If you're lucky, they included
one of the supertar products to perform the backup. If it's a home brew
backup, check the script and see if it logs any information about the disk
layout in the backup log.

(No help to you but when I used to use my cpio script to backup systems
I always included the output of dfspace in the backup log:

Start CPIO tape write: Thu Oct 07 12:29:22 2002

/ : Disk space: 1538.45 MB of 3678.40 MB available (41.82%).
/app1 : Disk space: 2987.78 MB of 6718.58 MB available (44.47%).
/app2 : Disk space: 2455.14 MB of 6718.58 MB available (36.54%).
/stand : Disk space: 27.77 MB of 39.99 MB available (69.43%).

Total Disk Space: 7009.15 MB of 17155.58 MB available (40.86%).

Root Disk Division:
0: boot 8033 48991
1: swap 48992 345950
2: root 345951 4112636
7: hd0a 0 4120671

The dfspace information would at least tell you the sizes of the
various mounted file system so that you can experiment with creating
file systems of the same size to get the block size of the file systems.
I have since moved all my clients to Microlite Backup Edge which creates
RE2 ISO image with all that information recorded for you.)

4) Failing to find anything useful from /usr/spool/cron/crontabs/root, look around
and see if you can find any usable information to help you.

5) If you can dope out the original size of the root file system (I'd use
whatever divvy indicates for the start and end block for division 2),
create a new file system the same size on the IDE disk and then use:

"dd if=/dev/correct_file_system of=/tmp/sb bs=1k count=1"

to grab the superblock from the just created file system and then
write it to the /dev/part2 (damaged root file system):

"dd if=/tmp/sb of=/dev/part2 bs=1k" (Keep a copy of the original /dev/part2

superblock before you do this so if you get it wrong, you can go back and
try again.) Then run fsck on the /dev/part2 file system (use -n until you
see what fsck says).

NOTE: I have never done this on an HTFS file system. It may or may not work.



That's a whole different ball game. I was called to an AMF bowling center
where they had a very customized SCO Xenix system running the pin setters.
It was totally unlike any SCO I'd worked on.

Bought new from the manufacturer? or used? If new, then you should call the
manufacturer for technical support.

It is 1993/1994 Bell & Howell equipment that was acquired used ... the
original company no longer exists. The IT guy at the printing place
that bought it tried to work on it as well as a technician that
services these. They then posted to our local Linux Users group to
find Unix guru's and that is how I got involved. I've never been
faced with quite this kind of puzzle before with SCO (dealt with
similar things with Sun & Linux though). It appears it worked for a
while and would get to the login prompt but not now. There is a tape
of what I think is the root filesystem.

Does SCO not have a file like Linux's inittab that shows the devices and
where they are mounted? I look at the inittab of the IDE drive I have
that works and it doesn't help me in trying to figure out where to look
on the messed up SCSI drive to get a clue as to the original filesystem
layout. I thought I'd see entries for root, boot etc. but I don't.
The /etc/default/filesys is the mount table consulted on boot up to mount
file systems. All you will get from that is the /dev/name_of_part_X and
the mount point. There is no information on what disk or partition the
file system is located on. That's all encoded by the major/minor numbers
for the /dev/file_system_name entry. There is nothing there that will tell
you the correct size of the file system.



I don't remember if I mentioned this or not but I used to administer a
SCO box back in 2001 but it has been too long ago and I've forgotten
most of what I knew about SCO ... now it is Linux and Solaris I work on.
In another post you wrote: PANIC: srmountfn Error 22 mounting rootdev hd (1/42)
cannot dump 32671 pages to dumpdev hd (1/41): space for only 0 pages

This error is indicative of a corrupted super block on the root file system.
(Note that 1/42 *IS* part2 on your disk.)

See:http://unix.derkeiler.com/Newsgroups/comp.unix.sco.misc/2004-09/0273....

Or search Google Groups with fsdb srmountfn

In that post, I detail how to recover from srmountfn on a Xenix file system.
since I have not been successful in using the fsdb on HTFS file systems,
I can't say if the information is the same or not.
Outstanding! Thanks. I've found online SCO Companion books too so
I've started to hit those.
I wonder if any of the HTFS versioning stuff can be leveraged in
situations like this ... still reading.

I'm going to image the good SCSI to another disk (I'm sure I have one
around here somewhere) so I can start to try things as I don't want to
mess with that one (it's the baseline) and I don't trust the original
SCSI as it probably is failing which is what lead to all this.



--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
.

Relevant Pages

  • Re: CHKDSK Ran on restart now I cant view files!
    ... Here is copy of log in event viewer if it will help. ... The type of the file system is NTFS. ... Volume label is Pic Backup. ... Windows will now check the disk. ...
    (microsoft.public.windowsxp.general)
  • Re: What about Image backups of active file systems (TI on XP)
    ... How careful do I have to be about file system activity? ... overnight dowing disk-to-disk backup to a USB1 ext disk. ... If I'm right, Trueimage allows you to make a boot disk, it might allow you to image from it, but my thoughts were that it was a recovery disk. ...
    (microsoft.public.windowsxp.general)
  • Re: What about Image backups of active file systems (TI on XP)
    ... How careful do I have to be about file system activity? ... overnight dowing disk-to-disk backup to a USB1 ext disk. ... but my thoughts were that it was a recovery disk. ...
    (microsoft.public.windowsxp.general)
  • Re: WinSBS2k3 backup "System State" casue error / dump
    ... > Brightstor Arcserve Backup for Windows r11.1 b3060. ... - Run chkdsk /f to verify the integrity of your file system. ... - Run the diagnostic tool that your hard disk manufacturer makes ...
    (microsoft.public.windows.server.general)
  • Re: Rom-only file system
    ... Is there a problem somewhere that you've noticed (other than debug output)? ... > I have a VIA EPIA ME6000 system with ATA flash disk running CE5.0. ... > I have a problem when I switch from RAM and ROM file system to ROM only ... > FS: Populating root file system... ...
    (microsoft.public.windowsce.platbuilder)