FreeBSD 7RC2 and VMware tools

[John Nielsen]

On Wednesday 27 February 2008 11:14:26 am Dimitri Yioulos wrote:
> On Monday 18 February 2008 5:02 pm, Dimitri Yioulos wrote:
> > On Mon, 18 Feb 2008 15:58:26 -0500, John Nielsen wrote
> >
> > > On Monday 18 February 2008 01:47:14 pm Dimitri Yioulos wrote:
> > > > On Mon, 18 Feb 2008 13:29:28 -0500, John Nielsen wrote
> > > >
> > > > > On Monday 18 February 2008 12:31:37 pm Dimitri Yioulos wrote:
> > > > > > On Sun, 17 Feb 2008 22:44:17 -0500, John Nielsen wrote
> > > > > >
> > > > > > > On Sunday 17 February 2008 01:06:28 pm Dimitri Yioulos 
wrote:
> > > > > > > > I'm not sure whether to have posted this here or on a
> > > > > > > > VMware list; apologies if I'm in the wrong place.
> > > > > > > >
> > > > > > > > The other day, I did a fresh install of v. 7RC2 from the
> > > > > > > > minimal CD on a CentOS 5.1 box running VMware server
> > > > > > > > 1.0.4.  I had previously successfully installed v. 6.2,
> > > > > > > > and upgraded to 6.3 on the same box. All has gone well,
> > > > > > > > except for the installation of VMware Tools. Getting the
> > > > > > > > Tools tarball and extracting the requisite files was
> > > > > > > > trivial. However, when I try to run
> > > > > > > > Vmware-Config-Tools.pl, I get a message saying that the
> > > > > > > > program must be run on a virtual machine. Well, it is. 
> > > > > > > > Is there a needed FBSD package I'm missing (the Tools
> > > > > > > > install program doesn't complain about it).  A known
> > > > > > > > issue, or bug, maybe?  Or is VMware support not yet
> > > > > > > > enabled?  Help would be greatly appreciated.
> > > > > > >
> > > > > > > I just went through almost the same thing, installing
> > > > > > > FreeBSD 7 under VMware Workstation on Windows. The
> > > > > > > config-tools script has a hard-coded version check which
> > > > > > > looks for libc.so.6 under /lib only. Rather than mess with
> > > > > > > the script, I just hard-linked the library from
> > > > > > > /usr/local/lib/compat (where it was installed by the
> > > > > > > compat6x port). Seemed to work fine after that. You'll need
> > > > > > > to be careful not to erase it if you ever run "make
> > > > > > > delete-old-libs", though.
> > > > > >
> > > > > > Thanks for the response!
> > > > > >
> > > > > > A symlink won't do for the above?
> > > > >
> > > > > Try it and see! I think I decided on a hard link since the
> > > > > script uses something like "if [ -f /lib/libc.so.6 ]" so it's
> > > > > looking only for a regular file and not a symlink.
> > > >
> > > > Hmm, when I try to hard-link ("ln /usr/compat/linux/lib/libc.so.6
> > > > libc.so.6"), I get "ln: ./libc.so.6: Cross-device link".  But,
> > > > when I do a symlink, which takes, I get
> > > > "/usr/libexec/ld-elf.so.1: Shared object "ld-linux.so.2" not
> > > > found, required by "libc.so.6"" when i run
> > > > vmware-config-tools.pl.  So, I symlink ld-linux.so.2, and run
> > > > tools. Then, I get "/usr/libexec/ld-elf.so.1: Undefined symbol
> > > > "__stdoutp" referenced from COPY relocation in
> > > > /usr/local/sbin/vmware-checkvm". Arrgh.  Any other ideas?
> > >
> > > You have /usr on a different partition than / in your VM, so you
> > > can't do a hard link. I would just copy the file back to /lib and
> > > not worry about it. Linking in other random libraries will cause
> > > problems, as you've observed.
> > >
> > > JN
> >
> > If I copy libc.so.6 to /lib, then tools complains about
> > ld-linux.so.2.  If I copy ld-linux.so.2, it then complains about
> > "/usr/libexec/ld-elf.so.1: Undefined symbol "__stdoutp" referenced
> > from COPY relocation in /usr/local/sbin/vmware-checkvm".  This is
> > pretty much the same as if I symlink the two files.  Even though I'm
> > a "glass half-full" guy, this is beginning to look dire (but it's the
> > worst thing to happen to me, I'm sure I'll live).  Still, it would be
> > nice to get this working.
>
> I did this a few days ago:
>
> /lib/libc.so. existed.  I symlinked libc.so.6 to it.  I then proceeded
> to install VMware Tools without complaint.
>
> However, I'm not sure if there's a vmware FreeBSD NIC driver.  If there
> is, it's not being used (as per dmesg, the AMD PCnet-PCI driver appears
> to be used).  On a Linux vm (please, no stone throwing  :-)  ), to use
> the vmxnet driver, I'd stop the network service, load the vmxnet driver
> module, then restart the service.  Is there a similar procedure on
> FreeBSD?

FreeBSD 7 handles the NIC with the le(4) driver, which is built in to the 
GENERIC kernel by default. In order for the hardware to be available for 
the vmxnet driver to attach to, le needs to be disabled. I would do this 
by building a custom kernel that doesn't include it, but it may also be 
possible using device.hints.

Once you're able to boot without another driver attaching to the hardware, 
you should be able to load the vmxnet module and have it see the 
hardware. If it's available and will work with 7.0, that is..  I've been 
happy enough with re(4) that I haven't gone that route myself. Further, 
64-bit VM's use an e1000 NIC which is supported by the em driver.

JN