OSR5 on VMware Server Beta SCSI? - SCO

This is a discussion on OSR5 on VMware Server Beta SCSI? - SCO ; Has anyone had any luck with running OSR5.0.6-7 on the new VMware server Beta?? It seems to work fine with IDE drives, but attempting to load the BTLDs for the SCSI adapters always results in a "Bad magic number" error. ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: OSR5 on VMware Server Beta SCSI?

  1. OSR5 on VMware Server Beta SCSI?

    Has anyone had any luck with running OSR5.0.6-7 on the new VMware server
    Beta??

    It seems to work fine with IDE drives, but attempting to load the BTLDs
    for the SCSI adapters always results in a "Bad magic number" error. I've
    done quite a bit of research and experimentation trying to fix this, but
    I'm strking out so far, has anyone else tried this and found a solution??

    I have tried with both VMware SCSI adapters, LSI & BusLogic, with the same
    results.

    TIA

  2. Re: OSR5 on VMware Server Beta SCSI?

    Chad G wrote:

    > Has anyone had any luck with running OSR5.0.6-7 on the new VMware server
    > Beta??


    I used to work at SCO and now at VMware. I haven't personally tried
    this, but I have installed OSR507 on VMware WorkStation and VMware ESX
    Server. I've also been working with someone who is trying it on the
    VMware Server beta. The issues are very similar across the VMware
    emulation line.

    > It seems to work fine with IDE drives, but attempting to load the BTLDs
    > for the SCSI adapters always results in a "Bad magic number" error. I've
    > done quite a bit of research and experimentation trying to fix this, but
    > I'm strking out so far, has anyone else tried this and found a solution??


    It would really help if you said _when_ in the install you have this
    problem. Probably the best way would be to show the last few lines of
    console output (the error message and enough lines of context before it
    so we can see what was going on).

    But I think I know what you're running into. This is happening in the
    OSR5 boot program (before the kernel starts), while it's trying to link
    the BTLD into the kernel it's loading. The problem is simple. For some
    reason, boot is seeing the floppy (image) as the wrong density.

    I know of two workarounds. One is to actually write the BTLD to a
    floppy and attach your VM to the machine's physical floppy drive,
    instead of a floppy image. Every time I've tried that, it has correctly
    seen it as an 1.44MB 80 track 18 sector floppy.

    The other way is to explicitly state the density while loading the
    BTLD:

    Boot
    : defbootstr link=fd(61)blc
    : defbootstr link=fd(61)lsil

    fd(61) is "2nd floppy drive, 80 tracks, 18 sectors", equivalent to
    /dev/fd1135ds18 on an installed OSR5 system. (While booting from an
    OSR5 install CD, "floppy 0" is the boot floppy image on the CD.)

    > I have tried with both VMware SCSI adapters, LSI & BusLogic, with the same
    > results.


    Once you get past the current problem, you hit the next ones, which are
    that neither of the BTLDs shipped by SCO are actually compatible with
    the VMware emulation of the respective adapters.

    For "blc", SCO fixed the driver problem long ago but forgot to post it
    as a separate BTLD. They have just recently corrected that; the
    required driver can be found at:

    ftp://ftp.sco.com/pub/openserver5/50...rs/blc_3.05.1/

    For "lsil", it is possible to bring the driver up by using the OSR5
    kernel debugger during bootup, but this is involved -- and unnecessary.
    Just use "blc". I'm talking to an engineer at SCO about the possibility
    of revising "lsil" to be compatible with VMware, but as both emulations
    are equally capable and similar in performance, there isn't really much
    reason to do it.

    Two other workarounds you may find useful:

    1. mouse goes insane after a little while: add "kbm.wheel=no" to your
    bootstring. Not needed during ISL. Once installed, edit
    /etc/default/boot and add that to the end of DEFBOOTSTR. This
    disables the mouse wheel (which is a bit of a drag), but it's worth
    it to be able to use the mouse at all.

    2. X display comes up blank: run:

    /opt/K/SCO/Vidconf/*/usr/lib/vidconf/scripts/grafinit.sh -r

    You are likely to need to do this each time the VM is rebooted, so
    maybe add it to an rc script.

    If you started an X server and are staring at a blank screen, hit
    and then to exit the X server. Then flip to
    multiscreen 1 (Ctrl-Alt-F1) quickly before the server restarts. Run
    the `grafinit.sh -r` sequence. Remember that the very next X server
    you see might already have been started before you ran the
    correction, so it too may be bad; look to the next one after it.

    >Bela<


  3. Re: OSR5 on VMware Server Beta SCSI?


    Chad G wrote:
    > Has anyone had any luck with running OSR5.0.6-7 on the new VMware server
    > Beta??
    >
    > It seems to work fine with IDE drives, but attempting to load the BTLDs
    > for the SCSI adapters always results in a "Bad magic number" error. I've
    > done quite a bit of research and experimentation trying to fix this, but
    > I'm strking out so far, has anyone else tried this and found a solution??
    >
    > I have tried with both VMware SCSI adapters, LSI & BusLogic, with the same
    > results.
    >
    > TIA


    Hi Chad,
    I'm using 507 under VMWare Server Beta and it's working great. The
    install was pretty uneventful, too. I used the BusLogic adapter...here
    is a link for the blc BTLD floppy that I converted to VMWare's "flp"
    format.
    http://www.rcmb.ca/SCO-restore_files/blc.zip
    Point the floppy drive of the virtual machine to the file (unzipped)
    and you can link it in as normal.
    Kevin


  4. Re: OSR5 on VMware Server Beta SCSI?

    Thanks for the help and suggestions guys. Unfortunately, it looks
    like OSR5.0.6 is definitely not going to work with VMware Server, still
    pops up with the "Bad Magic Number" error when trying to load BTLDs at the
    CD "Boot:" prompt. 5.0.7 will load the BTLD for the BusLogic controller
    (thanks for the hints Bela, those are good things to know!), but it seems
    to be unable to integrate the BTLD into the kernel during the install, so
    once the install is finished and I reboot SCO can't find the hard disk
    anymore.
    I must be doing something wrong, so I'll keep trying with 5.0.7 and see
    if I can get it working. I've tried using both a physical floppy and the
    floppy image with the exact same results, on 2 different physical VMware
    servers, and also swapped out floppy drives just to make sure. Kevin, did
    you do anything special to trick 5.0.7 into installing with your floppy
    image?

    Thanks again for all your information, I really appreciate it.



  5. Re: OSR5 on VMware Server Beta SCSI?


    Chad G wrote:
    > Thanks for the help and suggestions guys. Unfortunately, it looks
    > like OSR5.0.6 is definitely not going to work with VMware Server, still
    > pops up with the "Bad Magic Number" error when trying to load BTLDs at the
    > CD "Boot:" prompt. 5.0.7 will load the BTLD for the BusLogic controller
    > (thanks for the hints Bela, those are good things to know!), but it seems
    > to be unable to integrate the BTLD into the kernel during the install, so
    > once the install is finished and I reboot SCO can't find the hard disk
    > anymore.
    > I must be doing something wrong, so I'll keep trying with 5.0.7 and see
    > if I can get it working. I've tried using both a physical floppy and the
    > floppy image with the exact same results, on 2 different physical VMware
    > servers, and also swapped out floppy drives just to make sure. Kevin, did
    > you do anything special to trick 5.0.7 into installing with your floppy
    > image?
    >
    > Thanks again for all your information, I really appreciate it.


    Now that you mention it there is another step. I'd forgotten about it
    till just now.
    -create VMWare machine using Buslogic SCSI
    -boot from install CD
    -at the boot prompt, type "dir fd(65)" to make sure the floppy address
    is correct.
    -at the boot: prompt, i used "defbootstr link=fd(65)blc
    Sdsk=blc(0,0,0,0)"
    -install as usual, but the installer will ask you to specify your
    floppy drive for the BTLD. choose (2) /dev/fd1. THIS ISN'T SUPPOSED
    TO WORK. It will error out, but choose "b" to about BTLD and continue
    install
    -after the install is finished, you have a little more work to do.
    when you get to the boot prompt, use "unix.install link=fd(64)blc
    Sdsk=blc(0,0,0,0) root=hd(42) swap=hd(41)". you're using fd(64) this
    time because it's the first floppy (last time the first floppy was the
    boot cd)
    -you can't use the regular unix kernel because it's fully linked and
    you won't have enough memory
    -now "mount /dev/fd0135ds18 /mnt" to mount your floppy image
    -"btldinstall /mnt" to add the driver
    -relink the kernel and reboot.


    Hope this helps.
    Kevin


  6. Re: OSR5 on VMware Server Beta SCSI?

    "Chad G" wrote:

    > Thanks for the help and suggestions guys. Unfortunately, it looks
    > like OSR5.0.6 is definitely not going to work with VMware Server, still
    > pops up with the "Bad Magic Number" error when trying to load BTLDs at the
    > CD "Boot:" prompt.


    That should be due to wrong floppy format detection. Did you explicitly
    use "link=fd(61)blc"? Did you try using a physical floppy instead of an
    image?

    But moving on to 507 is a good idea for other reasons, so no point in
    beating your head against 506.

    > 5.0.7 will load the BTLD for the BusLogic controller
    > (thanks for the hints Bela, those are good things to know!), but it seems
    > to be unable to integrate the BTLD into the kernel during the install, so
    > once the install is finished and I reboot SCO can't find the hard disk
    > anymore.


    "seems to be unable to integrate the BTLD" is a terrible transcription
    of an error message. Always show actual messages if you want help
    getting past them.

    I would guess this is again a problem with the format. Again I ask if
    you tried either "fd(61)blc" or physical floppy attachment.

    > I must be doing something wrong, so I'll keep trying with 5.0.7 and see
    > if I can get it working. I've tried using both a physical floppy and the
    > floppy image with the exact same results, on 2 different physical VMware
    > servers, and also swapped out floppy drives just to make sure. Kevin, did
    > you do anything special to trick 5.0.7 into installing with your floppy
    > image?


    Whoops, OK, you did try with the physical drive. I would really expect
    that to work.

    Troubleshooting:

    Get to the point where the problem occurs. I'm guessing the problem is
    something where it asks you for the BTLD floppy, goes out to access it,
    comes back and reports that it couldn't find that BTLD on that floppy?
    Show the actual messages. Also tell us if (when using the physical
    drive) it actually spun the floppy / lit up the access light.

    But anyway, get past that failure point. After the error message it
    asks you a question that amounts to: "try again? try a different drive?
    or give up on this BTLD?" Tell it to give up. Then I think it asks if
    you want to continue the install anyway, or give up on the whole
    install. Don't answer this question yet.

    Flip to multiscreen 3 (Alt-F3). There should be a shell prompt there,
    "". At that prompt, run:

    chroot /hdFS /bin/sh

    At this point your root directory is the hard disk root. Run:

    ls -l /etc

    just to get an idea of whether it worked. Output should scroll for a
    while, with lots of symlinks.

    mkdir /btld
    mount -r /dev/fd0135ds18 /btld
    ls -lR /btld

    Does the mount succeed? Does the `ls` produce plausible output? (Do
    the same on a working OSR5 system to see what to expect. You should at
    least see the directory path /blc/driver/blc/... with files like
    Driver.o, Space.c). Assuming that much works,

    btldinstall /btld

    It asks you questions, tell it you want to link in "blc". If it asks
    about relinking the kernel, say no.

    umount /btld
    exit # once, leaving the chroot
    ls -l /etc

    This output should be short, less than a screenful (I forget, there
    might not even be an /etc directory at that point -- an error message
    like "no such file" would be fine), showing that you're back out of the
    /hdFS chroot. This is important, if you don't exit the chroot then the
    install will fail later.

    Now you're done at the prompt. Flip back to tty01
    (Alt-F1). Continue the install normally.

    Eventually it relinks the kernel and will pick up the "blc" driver you
    manually added.

    If any step goes wrong, show us the last few commands and their output,
    hopefully including a couple of successful commands + the failed one.
    (But not the `ls -l` output unless it's very short, which would show
    that it was wrong...)

    >Bela<


  7. Re: OSR5 on VMware Server Beta SCSI?

    Kevin Fleming wrote:

    > Chad G wrote:
    > > Thanks for the help and suggestions guys. Unfortunately, it looks
    > > like OSR5.0.6 is definitely not going to work with VMware Server, still
    > > pops up with the "Bad Magic Number" error when trying to load BTLDs at the
    > > CD "Boot:" prompt. 5.0.7 will load the BTLD for the BusLogic controller
    > > (thanks for the hints Bela, those are good things to know!), but it seems
    > > to be unable to integrate the BTLD into the kernel during the install, so
    > > once the install is finished and I reboot SCO can't find the hard disk
    > > anymore.
    > > I must be doing something wrong, so I'll keep trying with 5.0.7 and see
    > > if I can get it working. I've tried using both a physical floppy and the
    > > floppy image with the exact same results, on 2 different physical VMware
    > > servers, and also swapped out floppy drives just to make sure. Kevin, did
    > > you do anything special to trick 5.0.7 into installing with your floppy
    > > image?
    > >
    > > Thanks again for all your information, I really appreciate it.

    >
    > Now that you mention it there is another step. I'd forgotten about it
    > till just now.
    > -create VMWare machine using Buslogic SCSI
    > -boot from install CD
    > -at the boot prompt, type "dir fd(65)" to make sure the floppy address
    > is correct.
    > -at the boot: prompt, i used "defbootstr link=fd(65)blc
    > Sdsk=blc(0,0,0,0)"
    > -install as usual, but the installer will ask you to specify your
    > floppy drive for the BTLD. choose (2) /dev/fd1. THIS ISN'T SUPPOSED
    > TO WORK. It will error out, but choose "b" to about BTLD and continue
    > install


    This _is_ supposed to work; why it fails is some mystery of the
    virtualization environment. You mean "this isn't expected to work" in
    the circumstances at hand.

    I wonder what would happen if, instead of "b) abort", you did some
    trickery. After it fails the first time, flip to tty03 (Alt-F3) and:

    mv /dev/fd0 /dev/fd0.save
    ln -s /dev/fd0135ds18 /dev/fd0

    then flip back to tty01, choose the "fd0" option. I think it will work.
    Once it has happily read the BTLD, flip back to tty03 and:

    mv -f /dev/fd0.save /dev/fd0

    In case you're wondering, during ISL, the boot program sees fd0 as the
    CD-ROM (specifically the El Torito boot floppy image on the CD). That
    means it sees the "real" floppy drive as fd1. The kernel does not
    support El Torito floppy emulation, so it sees the "real" floppy drive
    as fd0, even during ISL. Which is why we use fd0 for the kernel part of
    this, even though we use fd1 for the boot part.

    > -after the install is finished, you have a little more work to do.
    > when you get to the boot prompt, use "unix.install link=fd(64)blc
    > Sdsk=blc(0,0,0,0) root=hd(42) swap=hd(41)". you're using fd(64) this
    > time because it's the first floppy (last time the first floppy was the
    > boot cd)
    > -you can't use the regular unix kernel because it's fully linked and
    > you won't have enough memory
    > -now "mount /dev/fd0135ds18 /mnt" to mount your floppy image
    > -"btldinstall /mnt" to add the driver
    > -relink the kernel and reboot.


    This procedure should also work, and has less uncertainties, so it's
    probably better.

    I would use "fd(61)" and "fd(60)" throughout, not "fd(65)" and "fd(64)".
    60/61 are fd[01]135ds18, 64/65 are "autodetect" devices. The
    autodetection seems a little flaky with OSR5 under VMware, and even when
    it works, it can be several seconds slower than immediate access to the
    right format.

    If my suggestion about fooling with fd0's identity works, it would save
    a reboot cycle and a number of steps. Kevin, I don't suppose you'd like
    to test it and then re-issue the message I'm replying to, simplified that
    way?

    >Bela<


  8. Re: OSR5 on VMware Server Beta SCSI?


    Bela Lubkin wrote:
    > Kevin Fleming wrote:
    >
    > > Chad G wrote:
    > > > Thanks for the help and suggestions guys. Unfortunately, it looks
    > > > like OSR5.0.6 is definitely not going to work with VMware Server, still
    > > > pops up with the "Bad Magic Number" error when trying to load BTLDs at the
    > > > CD "Boot:" prompt. 5.0.7 will load the BTLD for the BusLogic controller
    > > > (thanks for the hints Bela, those are good things to know!), but it seems
    > > > to be unable to integrate the BTLD into the kernel during the install, so
    > > > once the install is finished and I reboot SCO can't find the hard disk
    > > > anymore.
    > > > I must be doing something wrong, so I'll keep trying with 5.0.7 and see
    > > > if I can get it working. I've tried using both a physical floppy and the
    > > > floppy image with the exact same results, on 2 different physical VMware
    > > > servers, and also swapped out floppy drives just to make sure. Kevin, did
    > > > you do anything special to trick 5.0.7 into installing with your floppy
    > > > image?
    > > >
    > > > Thanks again for all your information, I really appreciate it.

    > >
    > > Now that you mention it there is another step. I'd forgotten about it
    > > till just now.
    > > -create VMWare machine using Buslogic SCSI
    > > -boot from install CD
    > > -at the boot prompt, type "dir fd(65)" to make sure the floppy address
    > > is correct.
    > > -at the boot: prompt, i used "defbootstr link=fd(65)blc
    > > Sdsk=blc(0,0,0,0)"
    > > -install as usual, but the installer will ask you to specify your
    > > floppy drive for the BTLD. choose (2) /dev/fd1. THIS ISN'T SUPPOSED
    > > TO WORK. It will error out, but choose "b" to about BTLD and continue
    > > install

    >
    > This _is_ supposed to work; why it fails is some mystery of the
    > virtualization environment. You mean "this isn't expected to work" in
    > the circumstances at hand.


    Absolutely right.


    > I wonder what would happen if, instead of "b) abort", you did some
    > trickery. After it fails the first time, flip to tty03 (Alt-F3) and:
    >
    > mv /dev/fd0 /dev/fd0.save
    > ln -s /dev/fd0135ds18 /dev/fd0
    >


    I just tried it, but there is no /dev/fd0.
    In fact, there is no /dev/fdanything (ie. /dev/fd0135ds18, etc).
    The only thing close in /dev is /dev/floppyRamDisk.
    I'm happy to continue trying, though. I'm really quite fascinated by
    the whole virtual thing. Thanks for your previous tips about the mouse
    and video, too. Those cleared up some problems I'd been having for a
    while.

    Kevin


  9. Re: OSR5 on VMware Server Beta SCSI?

    Kevin Fleming wrote:

    > Bela Lubkin wrote:
    > > Kevin Fleming wrote:
    > >
    > > > Chad G wrote:
    > > > > Thanks for the help and suggestions guys. Unfortunately, it looks
    > > > > like OSR5.0.6 is definitely not going to work with VMware Server, still
    > > > > pops up with the "Bad Magic Number" error when trying to load BTLDs at the
    > > > > CD "Boot:" prompt. 5.0.7 will load the BTLD for the BusLogic controller
    > > > > (thanks for the hints Bela, those are good things to know!), but it seems
    > > > > to be unable to integrate the BTLD into the kernel during the install, so
    > > > > once the install is finished and I reboot SCO can't find the hard disk
    > > > > anymore.
    > > > > I must be doing something wrong, so I'll keep trying with 5.0.7 and see
    > > > > if I can get it working. I've tried using both a physical floppy and the
    > > > > floppy image with the exact same results, on 2 different physical VMware
    > > > > servers, and also swapped out floppy drives just to make sure. Kevin, did
    > > > > you do anything special to trick 5.0.7 into installing with your floppy
    > > > > image?
    > > > >
    > > > > Thanks again for all your information, I really appreciate it.
    > > >
    > > > Now that you mention it there is another step. I'd forgotten about it
    > > > till just now.
    > > > -create VMWare machine using Buslogic SCSI
    > > > -boot from install CD
    > > > -at the boot prompt, type "dir fd(65)" to make sure the floppy address
    > > > is correct.
    > > > -at the boot: prompt, i used "defbootstr link=fd(65)blc
    > > > Sdsk=blc(0,0,0,0)"
    > > > -install as usual, but the installer will ask you to specify your
    > > > floppy drive for the BTLD. choose (2) /dev/fd1. THIS ISN'T SUPPOSED
    > > > TO WORK. It will error out, but choose "b" to about BTLD and continue
    > > > install

    > >
    > > This _is_ supposed to work; why it fails is some mystery of the
    > > virtualization environment. You mean "this isn't expected to work" in
    > > the circumstances at hand.

    >
    > Absolutely right.
    >
    > > I wonder what would happen if, instead of "b) abort", you did some
    > > trickery. After it fails the first time, flip to tty03 (Alt-F3) and:
    > >
    > > mv /dev/fd0 /dev/fd0.save
    > > ln -s /dev/fd0135ds18 /dev/fd0

    >
    > I just tried it, but there is no /dev/fd0.
    > In fact, there is no /dev/fdanything (ie. /dev/fd0135ds18, etc).
    > The only thing close in /dev is /dev/floppyRamDisk.


    Hmmm, well, I just did a quick test and learned a couple of things.

    A big one is this: although /boot parses "link=fd(65)blc" correctly, the
    same string gets passed, as a unit, to the later ISL script that tries
    to load the BTLD into the link kit. It doesn't decompose it and its
    efforts are doomed to failure.

    That means that my advice to use "link=fd(xx)btld" is bogus. You have
    to use:

    Boot
    : defbootstr btld=fd(61) link=blc

    Having done that, ISL will at least have a chance to load the BTLD
    automatically.

    If it then fails at the ISL stage (you get the "a b c" menu), you can
    try the trickery I mentioned. But this doesn't use /dev/fd* device
    nodes, and as you noticed, /dev/fd* don't exist at that point. So you
    need to:

    mv /dev/install /dev/install.save
    mknod /dev/install b 2 61

    Then tell it to try again.

    I have to run right now so I can't test this, but I'm pretty sure it'll
    work. In fact I think there's a pretty good chance it'll work without
    ever having to look at the "" prompt.

    > I'm happy to continue trying, though. I'm really quite fascinated by
    > the whole virtual thing. Thanks for your previous tips about the mouse
    > and video, too. Those cleared up some problems I'd been having for a
    > while.


    With the HBA, mouse and video issues out of the way, are there any other
    outstanding problems with your use of OSR5 in a VMware virtual machine?

    I've installed OSR5 + SMP in an ESX 2.5.2 SMP VM, and there are issues
    there. It works, but performs poorly. By pure guess, it looks like
    some sort of slow interrupt delivery or something like that. SMP does
    work, though -- start up two CPU-intensive tasks at the same time and
    they complete in much less than twice the time.

    >Bela<


  10. Re: OSR5 on VMware Server Beta SCSI?


    Bela Lubkin wrote:
    > Kevin Fleming wrote:
    >
    > > Bela Lubkin wrote:
    > > > Kevin Fleming wrote:
    > > >
    > > > > Chad G wrote:
    > > > > > Thanks for the help and suggestions guys. Unfortunately, it looks
    > > > > > like OSR5.0.6 is definitely not going to work with VMware Server, still
    > > > > > pops up with the "Bad Magic Number" error when trying to load BTLDs at the
    > > > > > CD "Boot:" prompt. 5.0.7 will load the BTLD for the BusLogic controller
    > > > > > (thanks for the hints Bela, those are good things to know!), but it seems
    > > > > > to be unable to integrate the BTLD into the kernel during the install, so
    > > > > > once the install is finished and I reboot SCO can't find the hard disk
    > > > > > anymore.
    > > > > > I must be doing something wrong, so I'll keep trying with 5.0.7 and see
    > > > > > if I can get it working. I've tried using both a physical floppy and the
    > > > > > floppy image with the exact same results, on 2 different physical VMware
    > > > > > servers, and also swapped out floppy drives just to make sure. Kevin, did
    > > > > > you do anything special to trick 5.0.7 into installing with your floppy
    > > > > > image?
    > > > > >
    > > > > > Thanks again for all your information, I really appreciate it.
    > > > >
    > > > > Now that you mention it there is another step. I'd forgotten about it
    > > > > till just now.
    > > > > -create VMWare machine using Buslogic SCSI
    > > > > -boot from install CD
    > > > > -at the boot prompt, type "dir fd(65)" to make sure the floppy address
    > > > > is correct.
    > > > > -at the boot: prompt, i used "defbootstr link=fd(65)blc
    > > > > Sdsk=blc(0,0,0,0)"
    > > > > -install as usual, but the installer will ask you to specify your
    > > > > floppy drive for the BTLD. choose (2) /dev/fd1. THIS ISN'T SUPPOSED
    > > > > TO WORK. It will error out, but choose "b" to about BTLD and continue
    > > > > install
    > > >
    > > > This _is_ supposed to work; why it fails is some mystery of the
    > > > virtualization environment. You mean "this isn't expected to work" in
    > > > the circumstances at hand.

    > >
    > > Absolutely right.
    > >
    > > > I wonder what would happen if, instead of "b) abort", you did some
    > > > trickery. After it fails the first time, flip to tty03 (Alt-F3) and:
    > > >
    > > > mv /dev/fd0 /dev/fd0.save
    > > > ln -s /dev/fd0135ds18 /dev/fd0

    > >
    > > I just tried it, but there is no /dev/fd0.
    > > In fact, there is no /dev/fdanything (ie. /dev/fd0135ds18, etc).
    > > The only thing close in /dev is /dev/floppyRamDisk.

    >
    > Hmmm, well, I just did a quick test and learned a couple of things.
    >
    > A big one is this: although /boot parses "link=fd(65)blc" correctly, the
    > same string gets passed, as a unit, to the later ISL script that tries
    > to load the BTLD into the link kit. It doesn't decompose it and its
    > efforts are doomed to failure.
    >
    > That means that my advice to use "link=fd(xx)btld" is bogus. You have
    > to use:
    >
    > Boot
    > : defbootstr btld=fd(61) link=blc
    >
    > Having done that, ISL will at least have a chance to load the BTLD
    > automatically.
    >
    > If it then fails at the ISL stage (you get the "a b c" menu), you can
    > try the trickery I mentioned. But this doesn't use /dev/fd* device
    > nodes, and as you noticed, /dev/fd* don't exist at that point. So you
    > need to:
    >
    > mv /dev/install /dev/install.save
    > mknod /dev/install b 2 61


    Still no go.


    >
    > With the HBA, mouse and video issues out of the way, are there any other
    > outstanding problems with your use of OSR5 in a VMware virtual machine?


    The only thing I can think of offhand is a badly drfiting clock. I
    find that is very host-dependent, though. The clock is reasonably
    accurate running on my Pentium M 1.7GHz (just on its own, no ntp or
    anything), but horrible on my Athlon XP 3000 (2.2GHz). I've tried to
    set up ntpd on the guest to sync to the ntp server on the host (windows
    server 2003), and it works for about a day, but then starts drifting
    again.

    Also, running "sysconfig" in 507 crashes the machine and creates the
    error:
    ***VMware Server internal monitor error***
    vcpu-0:ASSERT vmcore/vmm/intr/apic.c:1653

    > I've installed OSR5 + SMP in an ESX 2.5.2 SMP VM, and there are issues
    > there. It works, but performs poorly. By pure guess, it looks like
    > some sort of slow interrupt delivery or something like that. SMP does
    > work, though -- start up two CPU-intensive tasks at the same time and
    > they complete in much less than twice the time.


    The shop I work at is going ahead with an ESX implementation. We
    should be getting the new hardware to run it on in the next month.
    They ordered IBM xSeries 366 w/ 2 x dual-core Xeon 3.0GHz. I think
    we're just going to assign one processor to the guest OSR507 machine
    (we don't have an SMP machine or license currently)...any known issues
    with one processor of a dual-processor machine?

    Kevin


  11. Re: OSR5 on VMware Server Beta SCSI?

    Kevin Fleming wrote (quotes are Kevin and me alternately):

    > > > > > -install as usual, but the installer will ask you to specify your
    > > > > > floppy drive for the BTLD. choose (2) /dev/fd1. THIS ISN'T SUPPOSED
    > > > > > TO WORK. It will error out, but choose "b" to about BTLD and continue
    > > > > > install
    > > > >
    > > > > This _is_ supposed to work; why it fails is some mystery of the
    > > > > virtualization environment. You mean "this isn't expected to work" in
    > > > > the circumstances at hand.
    > > >
    > > > Absolutely right.
    > > >
    > > > > I wonder what would happen if, instead of "b) abort", you did some
    > > > > trickery. After it fails the first time, flip to tty03 (Alt-F3) and:
    > > > >
    > > > > mv /dev/fd0 /dev/fd0.save
    > > > > ln -s /dev/fd0135ds18 /dev/fd0
    > > >
    > > > I just tried it, but there is no /dev/fd0.
    > > > In fact, there is no /dev/fdanything (ie. /dev/fd0135ds18, etc).
    > > > The only thing close in /dev is /dev/floppyRamDisk.

    > >
    > > Hmmm, well, I just did a quick test and learned a couple of things.
    > >
    > > A big one is this: although /boot parses "link=fd(65)blc" correctly, the
    > > same string gets passed, as a unit, to the later ISL script that tries
    > > to load the BTLD into the link kit. It doesn't decompose it and its
    > > efforts are doomed to failure.
    > >
    > > That means that my advice to use "link=fd(xx)btld" is bogus. You have
    > > to use:
    > >
    > > Boot
    > > : defbootstr btld=fd(61) link=blc
    > >
    > > Having done that, ISL will at least have a chance to load the BTLD
    > > automatically.
    > >
    > > If it then fails at the ISL stage (you get the "a b c" menu), you can
    > > try the trickery I mentioned. But this doesn't use /dev/fd* device
    > > nodes, and as you noticed, /dev/fd* don't exist at that point. So you
    > > need to:
    > >
    > > mv /dev/install /dev/install.save
    > > mknod /dev/install b 2 61

    >
    > Still no go.


    That's probably because I gave the wrong minor number: 2,61 is
    /dev/fd1135ds18, which (as I explained) is what you have to use when
    /boot is accessing the BTLD, but not the kernel. I should have said:

    mknod /dev/install b 2 60

    Any better?

    > > With the HBA, mouse and video issues out of the way, are there any other
    > > outstanding problems with your use of OSR5 in a VMware virtual machine?

    >
    > The only thing I can think of offhand is a badly drfiting clock. I
    > find that is very host-dependent, though. The clock is reasonably
    > accurate running on my Pentium M 1.7GHz (just on its own, no ntp or
    > anything), but horrible on my Athlon XP 3000 (2.2GHz). I've tried to
    > set up ntpd on the guest to sync to the ntp server on the host (windows
    > server 2003), and it works for about a day, but then starts drifting
    > again.


    Hmmm. You could try setting disable_tsc_clock=1 in
    /etc/conf/pack.d/clock/space.c (relink, reboot) -- that switches to the
    PIT as timer source. I would generally expect that to be worse, but in
    a VM, who knows. I do know that VMware virtual machines go to a lot of
    trouble to keep TSC and PIT both appearing to run at the right rates
    relative to the real wall clock, but this is complex stuff and there are
    many ways for it to go wrong. OSR506/7's high resolution clock support
    is also complex, the two could be interacting wrong.

    > Also, running "sysconfig" in 507 crashes the machine and creates the
    > error:
    > ***VMware Server internal monitor error***
    > vcpu-0:ASSERT vmcore/vmm/intr/apic.c:1653


    Running what? There's no `sysconfig` command in OSR5. I thought you
    might have meant `sysinfo`, but that seems to run fine for me.

    > > I've installed OSR5 + SMP in an ESX 2.5.2 SMP VM, and there are issues
    > > there. It works, but performs poorly. By pure guess, it looks like
    > > some sort of slow interrupt delivery or something like that. SMP does
    > > work, though -- start up two CPU-intensive tasks at the same time and
    > > they complete in much less than twice the time.

    >
    > The shop I work at is going ahead with an ESX implementation. We
    > should be getting the new hardware to run it on in the next month.
    > They ordered IBM xSeries 366 w/ 2 x dual-core Xeon 3.0GHz. I think
    > we're just going to assign one processor to the guest OSR507 machine
    > (we don't have an SMP machine or license currently)...any known issues
    > with one processor of a dual-processor machine?


    Not known to me. I would imagine that any clock issues could get
    incrementally worse, but I'm not sure that's a concern until you can
    figure out how to get a clean clock on a 1P VMware setup... My test
    setup at work is ESX on a 2P single-core HT Xeon box (4 logical CPUs,
    well below 3 CPUs worth of power). 1P OSR507 seems OK on it; of course
    I'm not running any sort of workload.

    >Bela<


  12. Re: OSR5 on VMware Server Beta SCSI?

    I wrote:

    > Kevin Fleming wrote (quotes are Kevin and me alternately):
    >
    > > > > > > -install as usual, but the installer will ask you to specify your
    > > > > > > floppy drive for the BTLD. choose (2) /dev/fd1. THIS ISN'T SUPPOSED
    > > > > > > TO WORK. It will error out, but choose "b" to about BTLD and continue
    > > > > > > install
    > > > > >
    > > > > > This _is_ supposed to work; why it fails is some mystery of the
    > > > > > virtualization environment. You mean "this isn't expected to work" in
    > > > > > the circumstances at hand.
    > > > >
    > > > > Absolutely right.
    > > > >
    > > > > > I wonder what would happen if, instead of "b) abort", you did some
    > > > > > trickery. After it fails the first time, flip to tty03 (Alt-F3) and:
    > > > > >
    > > > > > mv /dev/fd0 /dev/fd0.save
    > > > > > ln -s /dev/fd0135ds18 /dev/fd0
    > > > >
    > > > > I just tried it, but there is no /dev/fd0.
    > > > > In fact, there is no /dev/fdanything (ie. /dev/fd0135ds18, etc).
    > > > > The only thing close in /dev is /dev/floppyRamDisk.
    > > >
    > > > Hmmm, well, I just did a quick test and learned a couple of things.
    > > >
    > > > A big one is this: although /boot parses "link=fd(65)blc" correctly, the
    > > > same string gets passed, as a unit, to the later ISL script that tries
    > > > to load the BTLD into the link kit. It doesn't decompose it and its
    > > > efforts are doomed to failure.
    > > >
    > > > That means that my advice to use "link=fd(xx)btld" is bogus. You have
    > > > to use:
    > > >
    > > > Boot
    > > > : defbootstr btld=fd(61) link=blc
    > > >
    > > > Having done that, ISL will at least have a chance to load the BTLD
    > > > automatically.
    > > >
    > > > If it then fails at the ISL stage (you get the "a b c" menu), you can
    > > > try the trickery I mentioned. But this doesn't use /dev/fd* device
    > > > nodes, and as you noticed, /dev/fd* don't exist at that point. So you
    > > > need to:
    > > >
    > > > mv /dev/install /dev/install.save
    > > > mknod /dev/install b 2 61

    > >
    > > Still no go.

    >
    > That's probably because I gave the wrong minor number: 2,61 is
    > /dev/fd1135ds18, which (as I explained) is what you have to use when
    > /boot is accessing the BTLD, but not the kernel. I should have said:
    >
    > mknod /dev/install b 2 60
    >
    > Any better?


    I have now had time to try this myself. Here's what happens:

    Boot
    : defbootstr btld=fd(61) link=blc
    ...
    ... eventually:

    Preparing root filesystem ... Done.

    The BTLD packages will now be extracted.

    That volume does not contain the package: blc

    Please select the floppy device you are using:

    (1) /dev/fd0
    (2) /dev/fd1

    At this point I hit Alt-F3 and do this:

    cd /dev
    mv install install.save
    mknod install b 2 60

    Then I hit Alt-F1 and answer the question with '1', i.e. /dev/fd0
    (/dev/install).

    Install proceeds normally from that point.

    I used the "blc" BTLD from:

    ftp://ftp.sco.com/pub/openserver5/50...rs/blc_3.05.1/

    This is a 1.44MB floppy image. I used it through an image file. I also
    tried this:

    dd if=install.save of=/dev/null bs=1k
    720+0 records in
    720+0 records out
    dd if=install of=/dev/null bs=1k
    1440+0 records in
    1440+0 records out

    This makes it fairly clear what's wrong. "/dev/install" is a device
    node that tells the OSR5 floppy driver to autosense the floppy format.
    It's sensing the wrong format -- 720K, probably equal to /dev/fd0135ds9.

    >From past experience, I know this doesn't happen if I attach a machine's

    physical floppy drive to the VM. Then /dev/install correctly autosenses
    the 1.44MB floppy, and all is well. That means it's probably easier to
    just use a physical floppy -- assuming the machine has one.

    The simplest formula for getting past all this:

    1. Use ftp://ftp.sco.com/pub/openserver5/50...rs/blc_3.05.1/

    2. Write the BTLD to a 1.44MB physical floppy

    3. Attach the machine's physical floppy drive to the VM

    4. Boot the CD (or image) with "defbootstr btld=fd(61) link=blc"

    5. Proceed normally

    If no physical floppy drive:

    1. Use ftp://ftp.sco.com/pub/openserver5/50...rs/blc_3.05.1/

    2. Attach the floppy image to the VM's floppy drive

    3. Boot the CD (or image) with "defbootstr btld=fd(61) link=blc"

    4. When you see:

    That volume does not contain the package: blc

    Please select the floppy device you are using:

    (1) /dev/fd0
    (2) /dev/fd1

    Hit Alt-F3 and do this:

    cd /dev
    mv install install.save
    mknod install b 2 60

    Hit Alt-F1 and answer the question with '1' (/dev/fd0)

    5. Proceed normally

    >Bela<


+ Reply to Thread