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:

<Installation> mv /dev/fd0 /dev/fd0.save
<Installation> 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:

<Installation> mv /dev/install /dev/install.save
<Installation> 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

.

Relevant Pages