I'm Linux administrator who happens to 'administer' SCO Unix 5.0.7, which is virtual server on VMware - deployed from official ovf image.
My problem is that root filesystem is almost out of disk space, and we've decided to do it as we do on every other virtual servers and extend disk on vmware level, then extend it on OS level.
However, it seems not to be that easy as I first thought it would be. When used 'divvy' utility it doesn't seem to have any free blocks that could be allocated, so I thought that there might be something else that has to be done beforehand to let the system know that something changed in disk setup. I've also tried 'mkdev hd' and recreate kernel, but after that server was unbootable, perhaps because it erased everything that was there.
Could anyone here help me to achieve disk extension on that system?
You cannot increase the size of a HTFS partition without doing a backup and restore.
Do you have data files in the root file system, or do the log files just need to be truncated.
The easiest solution is to install Backupedge from microlite.com, do a full backup, create the recovery media, resize the partition, and boot from the recovery media and do a restore. Microlite provides a 60 day full function demo.
Thank you for suggestion. Does BackupEDGE provide a tool to resize partition?
Backup of data is not a problem at the moment, as snapshot on VMware is done, and I've already used it after tampering with partition table and disk itself.
For some strange reason RecoverEDGE only let me make a floppy, but since it's virtual machine it doesn't have floppy to be formatted. I've read through documentation and it should have more options including ISO that could be burned, but I didn't have that option.
Ultimately I've checked our other deoployed SCO that was virtualised and compared settings and it seems that disk extension is not that necessary and I will just go with easiest solution to add additional disks and create apropriate mountpoints.
Although this will allow you have more space for your current problem it is not going to clean out stuff on your root filesystem leading to the same space problem down the road in other places as log files and other stuff keeps building.
In the same circumstances on earlier systems, not virtualized, I used edge and a new temp filesystem to store stuff while the original was being cleaned off and a new filesystem and mount point was created. Edge does backup and restore to/from a filesystem location of your choice. For the burning there was the free iso creation tool and burning software from Nero, limited to CD but OK as the data was about 200mb.
You might also consider a tool I've used before from Storix It would let you run a backup and the rebuild your server laying out new partitions as you go. Probably better than just increasing everything everywhere. Try to keep the root filesystem and others like /usr & /var to only have what is critical to get the OS to boot, perhaps with backup/recovery software included. /tmp and /home should also be separate filesystems really, ideally on separate physical volumes (or LUNs if disk is VM or SAN provided)
I'm not sure if it is available for your OS though, but please do have a read. It is very likely and is an excellent tool, apparently written by some of those that wrote mksysb for AIX.
I will have to read entire documentation. I've installed BackupEDGE and left default settings and in RecoverEDGE the only option that appeared to me to have recovery image created was floppy drive, no ISO or anything other.
I need to have a second look at it, as I'm struggling with migration from physical to virtual server. Physical got tar of all directories and I tried to untar them on physical, but of course after reboot it crashed. Eventually I got to point where I excluded /etc /opt/{K,P} /var/opt/K directories and was able to relink kernel with only one error and succesfuly boot, but I'm not sure if services that were on physical were started fine (no erros during boot, but still).
The system will not run without /opt; it is the operating system. The files in /usr/bin and /bin, are only links to /opt/K....
-bash-3.2# cd /usr/bin
-bash-3.2# ls -li tar
32410 lrwxrwxrwx 1 root sys 35 Feb 15 2013 tar -> /opt/K/SCO/Unix/6.0.0Ni/usr/bin/tar
-bash-3.2#
The kernel is built from files in /etc/conf.
The system documentation is here if you did not install it. DocView: Access to SCO OpenServer Documentation
You did not say if your lack of disk space is a result of incremental file growth, or not allocating enough space to start with.
If the former, the following are places to look.
/usr/spool/mail, for unread system email (if empty, the location of mail boxes is stored in /usr/mmdf/mmdftailor.
/usr/adm/messages
/usr/adm/syslog
/usr/spool/lp/logs
/usr/tmp
Entire case started with project for p2v migration of old SCO machines. One of the machines had entire directory tar'ed and then we had to deploy virtual one. OVF eventually was deployed, but after comparison of disk setup of Physical with Virtual I though that root partition should be extended, as physical one had 2GB of space more. That's why the question in that thread. Eventually I'v noticed that Physical one has only 4GB of space used so Virtual machine is fine, I just needed another partition, and that was easy task.
Then, having virtual machine deployed i started restoring backed up tar files and restoring them on virtual as it is. I was prepared for some configs to be modified (/etc/fstab, etc.). But it turned out that partition table got messed up, so I tried and tried. Eventually I'v got to the point I described, I've noticed that actually all important things are in /opt/{K,P}, so I've first tar'ed those directories on virtual machine, restored physical machine tars, and overwritten what I previously tared on virtual one. And that allowed me to boot the machine without one error during boot procedure. But I don't know if that's proper way to migrate (for sure not) and if all services that supposed to start started (I a assume no errors means something).
Maybe you already know better procedure for doing such migration in diy way, without use of enterprise software. If teams that will test it tell me that I doeasn't work as it should I'll start reading documentation for Backup/RestoreEDGE and other software that was posted here.
Still thanks for all help, and If you have more suggestions I will be glad to read them.
If you used tar to backup the entire system, you would need to put it back the data on a system with appropriate filesystems already mounted, that way tar will write them to the correct slice of disk.
If you are planning to restore everything and the backup was made with tar -cvf device / then you can only restore to the exact path. You will also need to make sure you don't overwrite OS critical files or your machine may not boot or fail to work properly.
Can you elaborate more on how you did the copy?
Again, Storix would be an excellent tool here (if it supports your OS version) and it would allow you to take a backup of your physical server that you can use to create a virtual server and update the disk allocations at the same time. It will help you go P2P, P2V, V2V & V2P.
I have to confirm that I have no financial interest in it, I just think it's a very good product. There are others available, but this one seems to do far more in a far more useful way. To be honest it exceeds what HP-UX's Ignite and AIX's mysysb do by adding in the ability to adjust various things (storage, network etc.) when you start the recovery. Take the free trial, watch the videos and choose for yourself.
I was not doing that copy by myself, my colleague did, the result is each directory under root has own tar file - /dev was excluded. He said that he used option to preserve file attributes.
At first I've extracted it as it was - hoping that it will work, as on Linux it would, but when I used 'scoadmin' to reconfigure network it didn't let me relink/recompile kernel because it couldn't find some devices. Also partition table was changed, so it seems that it keeps partition table in some file... it was really strange for me.
Eventually, I found that SCO keeps system specific files in those K and P folders so I did like this:
tar /etc/ /usr/SCO/K,P on virtual server
untar backup files (all subfolders of /) from physical server on virtual
overwrite /etc /usr/SCO/K,P with tar file done in first step
Surprisingly after such operation relink of kernel was fine, and boot was fine also, I'm not sure if it works as on production if all services are fine.
The reason I did it that way, I thought that everything that was on physical one will be transferred but overwriting crucial directories with virtual machine default ones (those after installation) will solve the issue with drivers, partition setup, but still services in rc.d (transferred from physical) will be there and will be able to start and will have their configuration files.
So, It would be good to know if such procedure is reliable or if there are some directories that should be included in first step, so that files from new virtual machine are kept same as they were after the installation.
I would be inclined to do a fresh install in order to create the virtual system.
Install all the maintenance patches.
Install all the additional software.
Use 'ap' to transfer all the user accounts.
Use the following:
cd /usr/bin
ls -ltr |grep -v "@"
cd /bin
ls -ltr |grep -v "@"
This will list all the files in those two directories that are not part of the OS, and you can check the files that have dates significantly more recent that either the OS media date, or the original install date.
Copy the contents of /etc/rc?.d along with /usr/spool/cron/crontabs.
Assuming you are using SYSV printing and not CUPS, copy the contents of /usr/spool/lp/admins/lp/interfaces from the old system, after you have re-created all local printers on the new system.
Copy /etc/hosts, and /etc/resolv.conf from the old system.
If you use the same OS license on the new system, you will have to keep the systems on different tcp subnets, otherwise one of the systems will shut down.