Hi folks - I'm trying to boot a dd'd disk image of an IDE-based SCO system
inside VMware 5.5, Bochs IA-32 emulator, or an actual Athlon-based PC.

This is the entire image of a 170MB hard drive to include partition table,
etc. as captured by "dd if=/dev/hda of=disk.img" from a Knoppix boot CD...

In all three cases (VMware/Bochs/Athlon box), I get
"SCO UNIX System V/386 i80486" followed by a "boot:" prompt.

"hd(40)unix" or simply pressing enter causes the kernel to load, but the
system immediately restarts after the the kernel load is complete (ie:
after .text, .data, .bss output to the console).

If I type "dir" at the "boot:" prompt, I can see a filesystem on the disk
image, so I'd guess the image is valid - but I've heard that SCO's IDE
controller support back then was extremely limited.

VMware presents the disk image to the guest OS as a SCSI disk hanging off
a Buslogic controller, but I'm not sure how to migrate a virtual SCO
system from IDE to SCSI when I can't boot the image in the first place

(I have 3.2v4.0y N1/N2 disks, but it reboots immediately after the kernel
load and "Insert N2, press enter" part - same as the hard disk image).

I can't mount the filesystem in Linux, either - I get a
"VFS: unable to find oldfs superblock on device" with the sysv module.
(this is with both loop devices and an actual IDE device /dev/hda4).
Possibly an HTFS filesystem, unsupported in Linux?

It'd be great to get this disk image to boot, or even to be able to grab
the files out of it - any ideas out there?

Thanks in advance.

Robert Giles

Robert Giles wrote:

> Hi folks - I'm trying to boot a dd'd disk image of an IDE-based SCO system
> inside VMware 5.5, Bochs IA-32 emulator, or an actual Athlon-based PC.
>
> This is the entire image of a 170MB hard drive to include partition table,
> etc. as captured by "dd if=/dev/hda of=disk.img" from a Knoppix boot CD...
>
> In all three cases (VMware/Bochs/Athlon box), I get
> "SCO UNIX System V/386 i80486" followed by a "boot:" prompt.
>
> "hd(40)unix" or simply pressing enter causes the kernel to load, but the
> system immediately restarts after the the kernel load is complete (ie:
> after .text, .data, .bss output to the console).
>
> If I type "dir" at the "boot:" prompt, I can see a filesystem on the disk
> image, so I'd guess the image is valid - but I've heard that SCO's IDE
> controller support back then was extremely limited.
>
> VMware presents the disk image to the guest OS as a SCSI disk hanging off
> a Buslogic controller, but I'm not sure how to migrate a virtual SCO
> system from IDE to SCSI when I can't boot the image in the first place
>
> (I have 3.2v4.0y N1/N2 disks, but it reboots immediately after the kernel
> load and "Insert N2, press enter" part - same as the hard disk image).
>
> I can't mount the filesystem in Linux, either - I get a
> "VFS: unable to find oldfs superblock on device" with the sysv module.
> (this is with both loop devices and an actual IDE device /dev/hda4).
> Possibly an HTFS filesystem, unsupported in Linux?
>
> It'd be great to get this disk image to boot, or even to be able to grab
> the files out of it - any ideas out there?

I've booted OSR5, but have never tried 3.2v4.x, in VMware Workstation.
I can't think of any difference that would definitely doom the attempt,
but I can imagine there might be one...

But from what you describe, there's a pretty big problem to start with.
If the image is from an IDE drive, it isn't going to be happy suddenly
booting up on a SCSI disk. Fortunately, VMware will also emulate IDE
disks. So that should be your first move: reconfigure your VM to use
IDE. If you didn't see that option, create a new VM and look again.
Tell it you're installing "other/other" OS. When you get to the disk
setup, you may need to click on "advanced" to get to the IDE-vs-SCSI
options.

As a diagnostic, you can boot with:

Boot
: defbootstr prompt

The kernel will load, then (still in the boot program) you'll get a
prompt before the kernel starts running. If you don't make it to the
prompt, that tells us something. I think you _will_ get that far. At
that point, type "v" (return) and you should get a memory map. Post
that, trying to keep it accurate...

HTFS first appeared in OSR5.0.0, so that isn't the problem with mounting
under Linux. It probably doesn't have the right driver to _find_ the
filesystem in its division within a partition. You can overcome that by
using `dd` to chop out just the filesystem -- if you can figure out its
start block. There are many ways to do this, none of them easily
described in a few words...

Yet another route would be to install OSR5 (any version you can get to
fly) on an IDE drive within a VM. Then add the 170MB image as a second
IDE drive and use `mkdev hd` to attach it. Or, again you could use `dd`
to slice out just the filesystem, then put it onto any OSR5 system (real
or virtual) as a single large file, use `marry` to make it into a block
device, and mount that.

The basic problem you have to solve is finding the filesystem within the
division within the partition. All of the proposed solutions break down
to two basic routes to this goal: (1) chop it out manually, (2) use
software -- 3.2v4.0 itself or OSR5 -- that has built-in knowledge of the
SCO divisioning scheme.

>Bela<

----- Original Message -----
From: "Robert Giles" <spammed-rgilesspam@mail.utexas.edu>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Tuesday, January 31, 2006 11:31 AM
Subject: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs


> Hi folks - I'm trying to boot a dd'd disk image of an IDE-based SCO system
> inside VMware 5.5, Bochs IA-32 emulator, or an actual Athlon-based PC.
>
> This is the entire image of a 170MB hard drive to include partition table,
> etc. as captured by "dd if=/dev/hda of=disk.img" from a Knoppix boot CD...
>
> In all three cases (VMware/Bochs/Athlon box), I get
> "SCO UNIX System V/386 i80486" followed by a "boot:" prompt.
>
> "hd(40)unix" or simply pressing enter causes the kernel to load, but the
> system immediately restarts after the the kernel load is complete (ie:
> after .text, .data, .bss output to the console).
>
> If I type "dir" at the "boot:" prompt, I can see a filesystem on the disk
> image, so I'd guess the image is valid - but I've heard that SCO's IDE
> controller support back then was extremely limited.
>
> VMware presents the disk image to the guest OS as a SCSI disk hanging off
> a Buslogic controller, but I'm not sure how to migrate a virtual SCO
> system from IDE to SCSI when I can't boot the image in the first place
>
> (I have 3.2v4.0y N1/N2 disks, but it reboots immediately after the kernel
> load and "Insert N2, press enter" part - same as the hard disk image).
>
> I can't mount the filesystem in Linux, either - I get a
> "VFS: unable to find oldfs superblock on device" with the sysv module.
> (this is with both loop devices and an actual IDE device /dev/hda4).
> Possibly an HTFS filesystem, unsupported in Linux?
>
> It'd be great to get this disk image to boot, or even to be able to grab
> the files out of it - any ideas out there?
>
> Thanks in advance.
>
> Robert Giles

Unfortunately this is going to be more in the nature of a fuller description
of your problem than an answer to it.

You captured a full raw disk image.
What you really want is a filesystem image not a disk image.
The filesystems are 2 layers down from the full raw disk.
The raw disk is chopped into 1 to 4 fdisk partitions, probably just 1, but
it still means your filesystem doesn't start at the beginning of the image
file.
The partition is then chopped into from 1 to 7 divvy partitions, probably 4
or 5, swap, boot, root, possibly a "u", and some reserved space.
You almost certainly only care about the root and the u if it exists.

Might have been slightly better if you'd dd if=/dev/hda4 of=file.img
(sco's fdisk counts backwards from everyone elses so partition 1 in sco, is
partition 4 in dos/windows/linux/freebsd)

Within that partition your filesystems reside on one or two out of a
possible 7 divvy partitions.
Linux doesn't know how to read the divvy table at the beginning of the fdisk
partition.

If you could write that image back out to real disk and use those N1/N2
disks to boot on real hardware, you could probably capture the filesystem
images and then linux may be able to read those.
I never did get around to trying it with anything other than xenix
filesystems.

....ok I just tried it. linux can NOT read HTFS, and to verify I did things
right, I verified that I CAN read XENIX by doing the same steps.
The linux in question is a very current suse 10.0 .
This is how I tested:

on sco:
create a htfs image and put some files in it
# dd if=/dev/zero of=htfs.img bs=1024 count=1024
# marry -a htfs.img
# mkfs /dev/marry/htfs.img
# mount /dev/marry/htfs.img /mnt
# cp base64.tar.bz2 bzip2.tar.Z rsync.tar.bz2 /mnt
# umount /mnt
# marry -d htfs.img

create a xenix image the same way
# dd if=/dev/zero of=xenix.img bs=1024 count=1024
# marry -a xenix.img
# mkfs -f XENIX /dev/marry/xenix.img 2048:512
# mount /dev/marry/xenix.img /mnt
# cp base64.tar.bz2 bzip2.tar.Z rsync.tar.bz2 /mnt
# umount /mnt
# marry -d xenix.img

on linux:
make sure sysv is loaded and /mnt is clear
slosh:~ # modprobe sysv
slosh:~ # ls /mnt
.. ..

try to mount the htfs image
slosh:~ # mount htfs.img /mnt -t sysv -o loop
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

slosh:~ #

try to mount the xenix image
slosh:~ # mount xenix.img /mnt -t sysv -o loop
slosh:~ # ls /mnt
.. .. base64.tar.bz2 bzip2.tar.Z rsync.tar.bz2
slosh:~ #


So, I don't have time to work out the exact commands for all this but the
outline of one possible procedure goes like this:
-Some of these commands will be infuriatingly unmeaningful like saying
"step3 calibrate the hubble telescope". Sorry

* Write the image to a real disk.
* install that disk and a 2nd disk in the slwest machine you can fin and
underclock that as far as possible
(or, find a 5.0.x N1/N2 or generic bot/root pair and don't worry about the
speed of the cpu)
* use either linux or the sco boot disk to make at least 2 primary fdisk
partitions on the 2nd disk and make each partition no larger than 512 megs.
* You can't use the vast amounts of unused space on the 1st disk for this
because your image file is the whole raw disk including the partition table,
which must remain intact.
* boot the sco disk and break out of the installer
* create device nodes for the two whole fdisk partitions on the 2nd disk
* create device nodes for the one or two divvy partitions on the first disk
that you care about
there are 7 divvy partitions, 2 or 3 unused, and 3 others, /stand or boot
and swap and reserved you don't care about, just root and u if it exists,
and any others of course if there are any but its' not likely.
* mount the one or two filesystems that matter from the 1st disk
* cpio /mnt and dump the output right to >/dev/hd11 (2nd disk, 1st
partition)
and if present, cpio /mnt2 out to >/dev/hd12
* cpio in /dev/hdb1 and /dev/hdb2 into a subdirectory on linux

If you had a tape drive you could use that instead of raw fdisk partitions
on a 2nd hard drive.

How exactly to create those device nodes is what I don't know off the top of
my head and don't have time to look it up and try it 50 times until it works
The osr5 man pages are available in html form on the sco web site and one of
them, hd maybe? has a table with some examles spelling out the formula for
device major and minor numbers and what they correspond to.

If the vmware or bochs would work that would probably be easier, but I think
several have tried and few if any had it work.
The above is really not all that hard apart from some trial & error while
booted up into the N1/N2 disks.

Alternatively, since xenix allows fs up to 512 megs, and your fs's all
together can't exceed even 170 megs, you could create one 512 meg partition
on the second disk, create a xenix fs on it from the N1 disk (if it even has
that part of mkfs which it might not), mount it, and write your cpio's out
to two files on the xenix fs, and linux can mount the xenix fs since you
didn't use divvy.
Don't just copy the source files directly from one fs to the other such as
with cpio -p. xenix is a less capable fs than htfs so files will get damaged
along the way. Examples: xenix has no such thing as a symlink, and xenix
filenames cannot exceed 14 characters. so make a tar or a cpio. And cpio
will save more of the metadata in case you need it to figure out how to
resurect some application. Like if it needed special files like fifos or
device nodes, they will still be there in the cpio for reference vs a tar.

Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!

On Tue, 31 Jan 2006, Bela Lubkin wrote:
> But from what you describe, there's a pretty big problem to start with.
> If the image is from an IDE drive, it isn't going to be happy suddenly
> booting up on a SCSI disk. Fortunately, VMware will also emulate IDE
> disks. So that should be your first move: reconfigure your VM to use
> IDE. If you didn't see that option, create a new VM and look again.
> Tell it you're installing "other/other" OS. When you get to the disk
> setup, you may need to click on "advanced" to get to the IDE-vs-SCSI
> options.

First, thanks for the response! Extremely helpful information.

Ok - I went ahead and created a new .vmdk file with the appropriate
C/H/S, etc. and pointed to the raw disk image as an IDE device (IDE:0:0)...

> As a diagnostic, you can boot with:
>
> Boot
> : defbootstr prompt
>
> The kernel will load, then (still in the boot program) you'll get a
> prompt before the kernel starts running. If you don't make it to the
> prompt, that tells us something. I think you _will_ get that far. At
> that point, type "v" (return) and you should get a memory map. Post
> that, trying to keep it accurate...

Ok - here's a console screenshot of the memory dump:
https://webspace.utexas.edu/daihatsu...emory-dump.png

Pressing enter causes the virtual machine to reboot at that point.

> HTFS first appeared in OSR5.0.0, so that isn't the problem with mounting
> under Linux. It probably doesn't have the right driver to _find_ the
> filesystem in its division within a partition. You can overcome that by
> using `dd` to chop out just the filesystem -- if you can figure out its
> start block. There are many ways to do this, none of them easily
> described in a few words...

Ahhhhh... ok, well I'll go Google around for divvy, I had no idea there
were multiple filesystems within one partition!

That's good to know it cannot be HTFS...

> Yet another route would be to install OSR5 (any version you can get to
> fly) on an IDE drive within a VM. Then add the 170MB image as a second
> IDE drive and use `mkdev hd` to attach it. Or, again you could use `dd`
> to slice out just the filesystem, then put it onto any OSR5 system (real
> or virtual) as a single large file, use `marry` to make it into a block
> device, and mount that.

This is probably the easiest route if I can't figure out where the
filesystem resides within that partition. Does SCO offer a Knoppix-style,
bootable rescue disc of some kind? (just wondering...
it could be hidden somewhere on ftp://ftp.sco.com/ or
ftp://stage.caldera.com/

Robert Giles

Robert Giles wrote:

>
>
> Ahhhhh... ok, well I'll go Google around for divvy, I had no idea there
> were multiple filesystems within one partition!

I dunno what else you might need to know about SCO to get this done, but
after you get it running, there are be other differences you need to be
aware of. See http://aplawrence.com/newtosco.html and perhaps
http://aplawrence.com/Linux/scolindiff.html

>
> This is probably the easiest route if I can't figure out where the
> filesystem resides within that partition. Does SCO offer a
> Knoppix-style, bootable rescue disc of some kind? (just wondering... it
> could be hidden somewhere on ftp://ftp.sco.com/ or
> ftp://stage.caldera.com/

There are boot diskette images (see
http://aplawrence.com/SCOFAQ/FAQ_sco...nloadboot.html ) but they
aren't rescue disks. With some effort, you can gain access to a very
raw command line (see
http://aplawrence.com/Unixart/lost_root_password.html for example) but
the procedure can be more than frustrating - these aren't Knoppix :-)

Microlite and Lone-tar make better EBD's
(http://aplawrence.com/Reviews/supertars.html) but you need an existing
system to create them.




--
Tony Lawrence
Unix/Linux/Mac OS X resources: http://aplawrence.com

Robert Giles wrote:
> Ahhhhh... ok, well I'll go Google around for divvy, I had no idea there
> were multiple filesystems within one partition!

Oddly enough, I was doing something very similar (extracting data
from a 3.2v4.2 system using Linux) last week. It took a lot of false
starts, but the eventual technique I used was:

- Run 'divvy' on the SCO machine, and note the output.
- Image its hard drive, and then restore the image into a virtual HD in
Virtual PC.
- Boot Linux in Virtual PC.
- Scan the imaged drive for a sector with the correct EAFS magic number
(0xfd187e21 at offset xxxxx3F8), and note how many sectors it is from
the start of the partition. That gives the offset to the first
filesystem, and the rest can be calculated from the divvy output.
- Use 'dd' with appropriate options to pull out the filesystems - eg:

dd if=/dev/hdd4 of=root.fs bs=1024 skip=8001 count=<count from divvy
output>
dd if=/dev/hdd4 of=u.fs bs=1024 skip=<8001+divvy offset> count=<divvy
count>

- Mount the resulting file using "-o loop,ro".

On the Linux side, I was using an ancient 2.0.30 install manually
patched with the sco_fs patches (which were designed for 2.1.30, so
applying them wasn't straightforward). My understanding is that the
mainline Linux kernel only supports AFS (magic 0xfd187e20), not EAFS.
The sco_fs patches are also supposed to add divvy support to the Linux
kernel, but in my case they didn't get the subpartitions right so I
ended up using 'dd' as described above.
One other thing - make sure the clock on the SCO system is set to
later than 1980. The machine I was imaging thought it was 1976 (no Y2K
patches had been applied) and Linux won't mount an EAFS system if its
check date is before 1980.

--
John Elliott

On Tue, 7 Feb 2006, johne@seasip.demon.co.uk wrote:
> - Run 'divvy' on the SCO machine, and note the output.

I didn't have access to the original machine this image came from, but I
did find a copy of hdinfo_sco.c, and compiled it with the appropriate
C/H/S values, but if I remember right, the data at the offsets didn't look
particularly interesting in a hex editor (lot of "aa05aa05aa05"???).

> - Scan the imaged drive for a sector with the correct EAFS magic number
> (0xfd187e21 at offset xxxxx3F8), and note how many sectors it is from
> the start of the partition. That gives the offset to the first
> filesystem, and the rest can be calculated from the divvy output.

Yeah, I located the various superblock magic numbers in the Linux sysv
module source, but couldn't actually find them anywhere in the disk image
with a hex editor (khexedit). Searched for the partial 0xfd187 and
0x781df for good measure... nothing (doesn't make sense, because I was
later able to mount the filesystem in OSR5 ???).

> dd if=/dev/hdd4 of=root.fs bs=1024 skip=8001 count=<count from divvy
> output>
> dd if=/dev/hdd4 of=u.fs bs=1024 skip=<8001+divvy offset> count=<divvy
> count>
>
> - Mount the resulting file using "-o loop,ro".

I think you can equivalently do:
mount -t sysv -o loop,offset=<numbytes> image.file mountpoint

(but that didn't work for me, because I couldn't find the superblock, and
the filesystem is EAFS as it turns out, bleh).

> On the Linux side, I was using an ancient 2.0.30 install manually
> patched with the sco_fs patches (which were designed for 2.1.30, so
> applying them wasn't straightforward). My understanding is that the
> mainline Linux kernel only supports AFS (magic 0xfd187e20), not EAFS.
> The sco_fs patches are also supposed to add divvy support to the Linux
> kernel, but in my case they didn't get the subpartitions right so I
> ended up using 'dd' as described above.

That explains a lot... in the end, I cheated and bought a 5.0.7 media kit
with an eval license. 'divvy' showed a single EAFS filesystem on the disk
image which I mounted and tar'd off to my 5.0.7 HTFS root.

I created a new, whole-disk EAFS filesystem which didn't mount in Linux...
but creating a new, whole-disk AFS filesystem worked just fine (this is
with a 2.6 Linux kernel).

The whole-disk sysv filesystem sharing thing is detailed on Tony's web
site here: http://aplawrence.com/SCOFAQ/FAQ_scotec1linuxfs.html

Well thanks again for the help folks, figured I'd post a follow-up for
future mushheads like myself to trip on, while searching groups.google
archives