----- Original Message -----
From: "Robert Giles" <spammed-***@mail.utexas.edu>
Newsgroups: comp.unix.sco.misc
To: <***@jpr.com>
Sent: Tuesday, January 31, 2006 11:31 AM
Subject: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs
Post by Robert GilesHi 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
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 -- ***@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
