Cpio Restore didnt go to plan

Hello folks, one of the RAID drives in our SCO system crashed recently and being hot swap it was replaced.
Problem was that on boot it stops at:

Checking protected password and protected subsystem databases....

First I did

#authck -a

and checked

/etc/auth/system/ttys

as per instructions in a previous thread but no go.

So I did a CPIO restore at "/" in single user mode

cpio -icudvmlB -I /dev/rct0 u/\*

Problem was, it must have restored at the wrong spot as

/dev/root

is now 100% used.
The crontab points to a backup script which has the backup as

cd /
find . -depth -print | cpio -ocvB -O /dev/rct0

This is a SCO system from 15 years ago (I'm away from the system at the moment, cant tell you what version) that is ignored in the corner - until something goes wrong.

Question 1:
I tried doing a find search on the drive to locate the wrongly located files but to no avail, so where did they go?

Question 2:
What did I do wrong and what is the correct sequence/command to fix my problem?

Question 3:
Is "/" different in single user mode compared to multi user?

I was a SCO hardware engineer 20+ years ago, but that was a lifetime ago and I think I have forgotten more than I remember.

Cheers

This is just a suggestion, but the problem you might have is that the backup crosses filesystem boundaries. If you restore without the filesystems mounted in the correct position relative to your current directory when you issue the command, then files will be put back in the directory in the parent filesystem.

If you can now boot but find the root filesystem is full, then you may need to unmount each filesystem and have a look in the directory each is mounted on.

Does this help?

Robin

Hmm, I'll have a look when I get back next week.
Thanks, any problems I'll get back......

Answer: No, it isn't.

As rbatte1 says, most likely, in single user you didn't have the non-root filesystems mounted (you'd have to mount them manually in single user) so the cpio restore created directories as it restored the non-root filesystem files. Then, when running multi-user with all non-root filesystems mounted, these files get 'covered' by the mount points so you can't see them any more. You need to go back to single user and remove the directory trees that should not be on root.

Ok, I'm back.
I tried to

umount /dev/root

but I'm told the device is busy (error 16).
I could however

umount /dev/boot
  • yep, something works.

I managed to fix the first problem "Checking protected password and protected subsystem databases..." by booting with floppies and restoring with tape, of course the restore stopped due to lack of space but I deleted a couple of unnecessary text files that gained me 6% !! See Pic....

The system is up but I'm still with the problem of where did the original restore files go. I think I am still owed another 20% of disk realestate!!

As I quoted above the backup was created with find . blah blah
But I restored the backup at / with

cpio -icudvmlB -I /dev/rct0 u/\*

So, to find the unnecessary duplicates from the restore could I run a script to get the location?

I think I have turned into a nube...

I think you restored into the unmounted /u that is different from the mounted /u
To compare, do

df -v /u
ls -ila /u

and note it e.g. on paper or in a new file /inodes.u
Then boot to single-user mode and compare.
If different then you can delete the /u contents in single-user mode. To be safe (I dont know SCO well) exclude recently opened files like this

cd /u
find /u -type f -atime +1 -exec rm {} \;

Since this is SCO Unix the filesystem will be /usr and not /u.

Other than that follow MadeInGermany's advice.

You could use divvy to see the filesystem layout on your hard disk.

divvy /dev/hd0

for the proper name of the hard drive you might need to use in this command

l /dev/hd*

Unmount the /u file system and see if the lost stuff shows back up under the now visible /u directory. As mentioned above, when you mount a file system anything previously stored at the mount point directory goes away so far as the OS is concerned.

Data could be in /usr or /u. Some SCO creates that directory but it doesn't mean that the original setup used it. It is a matter of keystrokes to have it at /u. I set mine up at /user.