OSR5 on VMware Server Beta SCSI?
Chad G
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
Bela Lubkin
> 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/507/drivers/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
<Alt SysRq> and then <Enter> 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<
Kevin Fleming
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
Chad G
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.
Kevin Fleming
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
Bela Lubkin
> 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,
"<Installation>". 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 <Installation> 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<
Bela Lubkin
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:
<Installation> mv /dev/fd0 /dev/fd0.save
<Installation> 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:
<Installation> 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<
Kevin Fleming
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.
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
Bela Lubkin
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
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 "<Installation>" 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<
Kevin Fleming
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
Bela Lubkin
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:
<Installation> 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<
Bela Lubkin
> Kevin Fleming wrote (quotes are Kevin and me alternately):
>
> 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:
>
> <Installation> 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:
<Installation> cd /dev
<Installation> mv install install.save
<Installation> 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/507/drivers/blc_3.05.1/
This is a 1.44MB floppy image. I used it through an image file. I also
tried this:
<Installation> dd if=install.save of=/dev/null bs=1k
720+0 records in
720+0 records out
<Installation> 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/507/drivers/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/507/drivers/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:
<Installation> cd /dev
<Installation> mv install install.save
<Installation> mknod install b 2 60
Hit Alt-F1 and answer the question with '1' (/dev/fd0)
5. Proceed normally
>Bela<