Booting SCO 3.2v4.0 hard disk image in VMware or Bochs - SCO

This is a discussion on Booting SCO 3.2v4.0 hard disk image in VMware or Bochs - SCO ; 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 ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs

  1. 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


  2. Re: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs

    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<


  3. Re: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs


    ----- Original Message -----
    From: "Robert Giles"
    Newsgroups: comp.unix.sco.misc
    To:
    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!


  4. Re: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs

    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


  5. Re: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs

    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

  6. Re: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs

    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= output>
    dd if=/dev/hdd4 of=u.fs bs=1024 skip=<8001+divvy offset> count= 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


  7. Re: Booting SCO 3.2v4.0 hard disk image in VMware or Bochs

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


    I think you can equivalently do:
    mount -t sysv -o loop,offset= 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


+ Reply to Thread