APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Getting near to the end?

© December 2006 Anthony Lawrence


Well, the SCO lawsuit is getting closer to the end. According to the Groklaw article in the link, the judge threw out most of their claims. Too bad he didn't throw them all out, but..

Anyway, it's getting even less likely that SCO is going to do well here. For those who are still running SCO systems, time could be running out: the company may not be there when you need them to be. So what now?

Well, obviously if you can easily switch to Linux or BSD, it's time to start laying plans. That doesn't mean you have to jump ship now, and of course application licensing fees may mean you want to put the move off as long as possible. But you need to be planning now, and if possible putting up test systems to find out what sorts of problems you will encounter. Better to have everything ready to go long before you absolutely need to.

For those unfortunate people with ancient software that cannot be transferred and won't run under Linuxabi, well, you just have to bite the bullet or resign yourself to scrounging old hardware to keep around as spares.

And for all of you who are hanging on but know you need to move, I've instituted a new section here that attempts to gather together articles related to conversions. That should help you find related material more easily.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Getting near to the end?


Inexpensive and informative Apple related e-books:

Take Control of Automating Your Mac

Photos: A Take Control Crash Course

Take Control of Pages

Sierra: A Take Control Crash Course

Take Control of Numbers

More Articles by © Anthony Lawrence

Fri Dec 1 17:25:31 2006: 2673   TonyLawrence

By the way, another possibility for those needing to keep old systems limping along is to do it under virtualization..

Sat Dec 2 04:35:24 2006: 2679   drag

That sounds like a very usefull research project/article.

How hard would it and what problems would it cause to try to pull a image off of a SCO box and stick it into Linux under Qemu or Vmware?

If you start off with 'dd if=/dev/sda of=sco.image' and copied that into a modern Linux box, what would be the next step?

Sat Dec 2 13:05:56 2006: 2680   TonyLawrence

I would expect that to be difficult - I was thinking more in terms of a new install.

I don't know if qemu-img


has any support for SCO

Sat Dec 2 22:32:52 2006: 2681   drag

I don't know much about qemu-img. I think it probably just does what dd does, except in a convient command.

For my personal use I just dd to make blank disk images.
dd if=/dev/zero of=hda.img
Then I let it run for a while and hit ctrl-c when it looks like it's gotten big enough. Of course it's easy to set for paticular sizes and different things like that. Then with Qemu install from a iso image to a disk image is very simple. Or you can specify the harddrive or cdrom /dev/ file if you want and it will work the same.

Then of course everybody knows about using dd to make backups of drives and making iso images and such.

For instance I wanted to mess around with operating system running off of a flash drive. When I wanted to muck around with changing a lot of stuff or installing a lot of software then I used dd to copy the the flash drive into a 'hda.img' or whatnot and used that. Then when I was finished I dd'd it right back.

I didn't use it a whole lot and I didn't realy end up doing much with it (got sidetracked with moving), but I don't remember any problems with it.

Also I don't know how well SCO file system support is for Linux, but then if you want you can use the 'offset' option in mount to mount paticular partitions to directories. Something like:
mount -o loop,offset=43235 hda.image /mnt

That way you can then go in and adjust the settings for the hardware or whatnot.

The hardware qemu emulates is pretty vanilla stuff. 32bit x86 (although it has support for other things), Cirruss logic video card or standard vga adapter, sound blaster or Esonic ES1713. Then you have options for different serial terminal stuff.

For options there is the qemu-launcher GTK front end, and to speed things up there is a propriatory kernel model called Kqemu that bypasses some of the cpu emulation to the real cpu. This makes it decently fast, although it's still not as fast as Vmware. (the author is willing to make the kernel module open source if some company steps up and compinsates him financially, btw.)

The things I've ran it in are Windows XP, FreeDOS, and Linux, however Windows was a fresh install only.

Sat Dec 2 23:21:37 2006: 2682   TonyLawrence

There are supposedly drivers for SCO filesystems, but I've never actually seen one. There are articles here on that subject.

The basic issue is that SCO does NOT create filesystems on fdisk partitions as Linux (non Raid linux) does. Sco divides a partition into "divisions" and puts filesystems on those.

Sun Dec 3 05:03:15 2006: 2683   BigDumbDinosaur

The basic issue is that SCO does NOT create filesystems on fdisk partitions as Linux (non Raid linux) does. Sco divides a partition into "divisions" and puts filesystems on those.

Minor clarification: SCO uses only one partition per disk, unlike Linux which can (and usually does) configure multiple partitions.

As a point of trivia, there's no reason that any partition has to be configured at all. The only thing the BIOS does when it reaches the point where it wants to load an OS is read CHS 0:0:0, load that code into RAM and then cheerfully assume (based upon some very simple tests) that there's an OS bootstrap loader waiting to be run. It is the OS boot loader that cares about partitions, which means, of course, that the boot loader could not care, if the programmer so wished.

Frankly, I wish the Linux coders would get away from this business of using multiple partitions to configure multiple filesystems. The division method used by SCO, in my humble opinion, is a superior scheme, and more resistant to damage.

Sun Dec 3 11:27:23 2006: 2684   drag

Well just use Linux LVM if you don't want to use partitions. The only problem is if your using Grub bootloader then you have to have a seperate /boot partition.

Otherwise probably the main reason otherwise people use partitions still is just because that is what they are used to. Probably the same reason why people are still using the /dev/sda and /dev/hda stuff; you can name those anything you want nowadays if your running udev, but most people keep it devfs-style because it's what they are used to.

I don't know how you would go about mounting lvm stuff in a disk image though...

That's too bad about the filesystem driver issue though with SCO stuff. That would maybe make things harder for migrating away from it. I know that the BSD systems typically use the 'divide up a big partition to smaller volumes' and such and Linux can read those (not sure how to go about doing that though) but obviously that is not very helpfull with the SCO stuff.

Sun Dec 3 11:35:59 2006: 2685   TonyLawrence

(Minor clarification: SCO uses only one partition per disk, unlike Linux which can (and usually does) configure multiple partitions.

More clarification: although it is common for SCO systems to use one partition, they can use all four, with multiple file systems: up to 7 per partition; see (link)

As Drag noted, the SCO scheme is similar to Linux LVM:

in the sense of carving up partitions.


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

An adversary capable of implanting the right virus or accessing the right terminal can cause massive damage. (George Tenet, director of the U.S. Central Intelligence Agency)

Linux posts

Troubleshooting posts

This post tagged:


SCO Lawsuit





Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode