Insufficient disk space or inodes SCO 5.0.7 2

[masinc1]

We had a system crash while running 5.0.5 on a PII. I restored the master Lone Tar backup in total to a 36GB SCSI drive (4x larger than previous drive) and then upgraded to SCO 5.0.7. Everything worked fine including an old ISA Arnet smartport card. We decided to upgrade to a P4. I put the CDRW and the SCSI Seagate tape drive from the PII into the P4. We got a new PCI Digi Acceleport XEM 16. The CD and the tape are working. When I try to install the Digi the system returns the following: insufficient disk space or inodes to install selected packages; details an error occured while calulating disk space usage for "misc:mpi:ClientControl 4.2.0" Can't determine which file system should contain "/etc/perms/mpi" Possibly corrupt mount table (mnttab).

When doing df -v the only listing is for /stand 30720 blocks, 64% used.

Checking divvy shows the boot sector with the first block 0 and the last 15359; swap is 15360 to 111615; the root file system is 111616 to 35824939; division 3-5 are not used; division 6 is recover, 35824940 to 35824949; divsion 7, whole disk is 0 to 35832950.

When I run fdisk and display the partition table, partition 1 has status active, type UNIX, starts at track 1 and ends at 1137554; total disk size is 1137810 tracks.

Unless I am miscalculating the systen is not recognizing the entire drive. Do I have one problem with the drive & another with the Digi board or are they both one problem?

 

[masinc1]

Realized I did miscalculate - used 512/block instead of 1024. Still would appreciate any feedback.

 

[motoslide]

This is you primary problem:

"When doing df -v the only listing is for /stand 30720 blocks, 64% used."

The /stand is the boot filesystem, which is small. What isn't showing is your "/" filesystem, which should be the remainder of that disk.

Next issue:

"We decided to upgrade to a P4"

How? Did you just move the 36GB SCSI disk into a new platform? Replace the M/B in your existing system? What was the previous SCSI controller, and what is the new SCSI controller?

My best advice would be to re-install 5.0.7 onto the new hardware as a fresh install, then re-install Lone-Tar, and restore everything into a different directory (like /old).
After that, you'd have to manually move things into place, but you'd end up with a cleaner system.

Or, go back to the beginning and get the Lone-tar folks (who are awesome) to help you with the first restore to 5.0.5. Either something didn't go well back at that step with the way it created the new filesystems, or things went bad moving to the P4.

You don't have a problem with the DigiBoard. It's just the first thing to point out the problem.

 

[piperent]

I think Motoslide has a point, but since everything seems to work correctly except the new Digi-board, I'd look at the following first. Then if that doesn't solve the problem, go with the re-install.

One thing I have run into when installing new Digi products is the Permissions and Ownership of the install package component is configured incorrectly. This then causes many erroneous errors to occur, one of which is the error you received. If you are loading from removeable media, I would recommend copying the 'install' file to /tmp/VOL.000.000, then change the permissions to something like 'rwxrw-rw-' (766) and make sure the ownership is by root. Then install using 'media-images'. I won't guarantee that this is the problem, but in speaking with tech support at Digi, they indicated this to be a VERY common occurrence. They apparently had a large quantity of driver media that was built with the incorrect permissions and ownership. I originally experienced it when I downloaded the most current driver for a Digi Portserver. That's when they told me they had the problem on several lines. You may want to contact them before taking the extreme measure of re-installing.

Hope this solves your problem.

 

[masinc1]

Thanks piperent for the information on Digi. The board is now working.

All programs seem to be working as they should. I am still confused/concerned about what the system returned with df -v.

To answer motoslide the new hard drive was moved from the PII to the P4. The old card was an Adaptec 2940 UW and the new is a 2940 UW as well. We were working with Lone Tar. That input was the reason we upgraded SCO on the new drive while still with the PII. All preliminary inquires from various sources indicated this was reasonable. You seem to disagree.

Since the system seems to be working, is the feeling to leave it alone or are we just experiencing a calm before another disaster?

 

[motoslide]

Good call, Piperent, on the Digi permissions solution. I've been working with SCO and Digi for a long time and had never seen that symptom. I'll throw you a star first for just being right, and secondly because I might run into that symptom myself at some point.

Masinc1: I've often favored a clean install vs. upgrade. Just a personal choice, I guess. We support one primary software package, and I've gotten pretty good at restoring the package, users, printers, etc. onto a fresh system. I can see the merit of going with an upgrade and hoping for the best on other situations.

There's a Tech Article on SCO's website which addresses your filesystem symptoms. I don't know if it will resolve your problem, but it would be worth checking into:

TA# 112821

 

[masinc1]

Thanks motoslide, I will check that article. I agree a clean install is preferable, but we have many remote stores connecting through a Sonic Wall VPN and didn't feel we had the time to reconfigure those. This is a choice I might see differently after all the hours spent on the restore and upgrade.

To both you and piperent, I could not have gotten this completed over the weekend without your help. Much thanks!!

 

[piperent]

Happy to hear that this solved your problem. I've been using Digi products on SCO for the last 15 years, and occasionally I'll run into something like this. Always unexpected, never at a convenient time, and usually when I'm trying to meet a dead-line (or a flight).

Congrats on fixing the problem.

J Piper