Startup Script

I'm pretty sure rc.local is called by default. Check out /etc/rc5.d to see if you find an entry S99rc.local.

The actual script itself resides under /etc, and you should edit it from there.

Another option is to creat a symlink in ~/.kde/Autostart to execute it when logging on.

Or (but I am not sure, check it out), create the script under /etc/init.d and use ksysv to have it started at the runlevel you need.

Newbie or not Newbie, there's always a question

Hi joany, welcome to the gang!

Can you please clarify what you are wanting to accomplish? The snippet that you provided above looks like you are trying to start the vmware tools, but that is normally done in a guest OS running in vmware.

So my first question is: are you trying to configure a guest virtual machine? If so, what version of VMware are you running; VMware workstation, server, something else? Next question from that one: what is the OS you are trying to run in the guest vm? Final question from that: how are you trying to load the vmware tools? Because normally the installation of the tools is semi-automatic. You do need to go through the configuration step, but then you should just need to put some entries in the various "run-levels" on the guest vm.

Finally, the vmware-tools are normally started ONCE during boot up of the virtual machine, not during login of a particular person to the virtual machine.

I do not have my laptop running at the moment, but I have VMware workstation running on it, and have a WHOLE BUNCH of different OSes available. So am I anywhere close to the problem you're experiencing? Is this a VMware issue we're talking about, or are you wanting to set up some other initialization? Please clarify.

So please get back to me with more details and I'll be happy to provide some ideas to get you going

Jon

Jon -

Your guess was absolutely right! I've installed MEPIS as a guest OS running on VMware Player. After I installed vmware-toolbox on the MEPIS guest system, I noticed that it doesn't autostart as it is supposed to.

I may not have installed vmware toolbox properly, or there could be some underlying incompatibility with MEPIS (I don't think VMware "officially" supports MEPIS). Anyway, I created a desktop icon to manually start vmware-toolbox, but I would really rather have it run automatically on boot up in the background.

I'm not very experienced with Linux (which is why I'm trying out MEPIS on the virtual machine before I take the final plunge and do a permanent installation with GRUB.)

The post just prior to yours mentions using ~/.kde/Autostart. I located that folder in the virtual file system and placed a link to vmware-toolbox in it. Sure enough, vmware-toolbox automatically starts when I log in -- however, by using that method, vmware-toolbox doesn't run in the background as I would like it to.

It sounds like you're familiar with VMware, which is good. Any help you can give this helpless newbie will be greatly appreciated.

By the way, I've tested about a dozen different Linux distros on VMware, and I can definitely say that MEPIS is the easiest one to use and the Synaptic Package Manager provides an awesome amount of software! When I do a permanent installation, I'll be going with MEPIS. I just need a little more time to try it out and learn about it.

Cheers

Hey joany, welcome back!

You'll be happy to know I have my laptop running, so I can check some stuff for you

Also, I apologize, in advance, if I cover any ground that you have already covered and know. I'm just wanting to be complete. No offense meant.

First, VMware will run Mepis just fine. I have copies of 3.3, 3.4, and 6.0 in guest vms.

Now, to some specifics. When you initially create the guest vm, and set up the virtual hard drive and all of that, what I like to do is give the vm more RAM, just so that it will run a notch faster. So even if the vm will be comfortable (minimally) running in 128 MB RAM, during installation I bump it up to 256 MB. You have noticed that, after starting the guest vm, after loading all your other stuff, perhaps bringing everything up-to-date with apt-get or synaptic, that VMware informs you that you have not installed vmware-tools right? Gee, I think that's why you originally posted this

How did you initially install Mepis into the vm. From a physical DVD/CD or from an IMAGE (.iso)? If you use the image, then installation and running is much faster BTW. Well, assuming that everything got loaded properly, then you should have been able to boot up into your guest Mepis and log in as you not root. You should have the message about not having vmware tools installed (didn't I just say that a moment ago?). Did you install the linux-headers that match your (guest) system? You can find out which version to load by opening a konsole and entering "uname -r". On my system it comes up "2.6.15-26-386". Then, go into synaptic and search for "linux-headers" (I'm assuming you're using Linux 6.0). Install this.

I will assume that you already ran through the vmware-tools configuration and that it worked (kinda). But I want to ask, did you choose "Install VMware Tools" from the VM menu of the VMware window? Once you did that, you should have had a CD-ROM icon pop up on the guest's desktop. I usually go into that and COPY the contents of the .tar.gz file out to a temporary directory (/home/me/tmp) for using it. So I won't go into any more detail on that. I'll assume that all went right. If you have any problems with any of that, please feel free to post back and I'll give more info.

RIGHT, on to where the heck the startup links should be!

All of what I describe from now on is from within the guest machine. Start it, log in as you, and open a konsole. If the commands below begin with "$" then you can do them as a regular user. If they begin with "#" then that is the root prompt and you must do the commands as root.

First, make sure that vmware-tools exist:

$ whereis vmware-tools
vmware-tools: /etc/vmware-tools /usr/lib/vmware-tools

Next, see if you have the initialization script:

$ ls -lad /etc/init.d/*vmware*
-r-xr-xr-x 1 root root 20434 2006-11-21 15:07 /etc/init.d/vmware-tools

Now, here's what you should have to start things automatically by the system. Various entries for the different "run-levels". They are located in /etc/rc*d/, where "*" represents run levels 0-6.

$ ls -lad /etc/rc*d/*vmware*
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc0.d/K08vmware-tools -> /etc/init.d/vmware-tools
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc2.d/K08vmware-tools -> /etc/init.d/vmware-tools
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc2.d/S19vmware-tools -> /etc/init.d/vmware-tools
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc3.d/K08vmware-tools -> /etc/init.d/vmware-tools
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc3.d/S19vmware-tools -> /etc/init.d/vmware-tools
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc5.d/K08vmware-tools -> /etc/init.d/vmware-tools
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc5.d/S19vmware-tools -> /etc/init.d/vmware-tools
lrwxrwxrwx 1 root root 24 2006-11-21 15:07 /etc/rc6.d/K08vmware-tools -> /etc/init.d/vmware-tools

These are "symbolic links". Do you have the same thing on your system? Do you have ANY of them? You will most likely have the ones that start "K08vmware-tools", but you probably don't have the "S19vmware-tools". If not, here's how to create them. This must be done as root.

# ln -s /etc/init.d/vmware-tools /etc/rc2.d/S19vmware-tools
# ln -s /etc/init.d/vmware-tools /etc/rc3.d/S19vmware-tools
# ln -s /etc/init.d/vmware-tools /etc/rc5.d/S19vmware-tools

Please note: the command lines above are CaSe SenSitIve. Once you have put them in place, you should be able to reboot your system and have vmware-tools running.

You can check to see if they are currently running by entering the command:

$ ps -ef | grep vmware
root somenumber 1 0 some:time ? 00:00:00 /usr/sbin/vmware-guestd --background /var/run/vmware-guestd.pid

Whew! I think I have everything there! See how this matches with your system and get back to me

Jon

Jon -

Thanks a million! You really ARE familiar with VMware!

First, I'll try to answer some of your questions. I installed MEPIS on VMware Reader using a MEPIS installation CD-ROM that a friend burned for me. To do this, I modified a *.vmx "appliance" file that originally had been compiled for Ubuntu, which I downloaded from the VMware web site. (There were no MEPIS appliances on their site, so I "borrowed" the one for Ubuntu.) Using that "borrowed *.vbx file was probably my first mistake. I'm assuming you installed MEPIS the right way, using VMware Server.

I specified 128 MB for the memory because my computer only has 512 MB of total memory, and I need a lot of memory to run that "other" OS -- otherwise, the "other" OS has a tendency to crash. Nevertheless, the actual MEPIS installation went very well and it generally runs okay.

No, I did not receive a message at any time telling me that VMware Tools were not installed. I'm assuming that such a message only appears when running VMware Server; but since I intalled MEPIS with VMware Reader, I'm not surprised that I didn't get those messages.

The other mistake I made was not updating everything using Synaptic Package Manager BEFORE attempting to install VMware Tools, like you suggested.

To make matters worse, I installed VMware Tools the HARD way: I downloaded the .tar file from the VMware web site and unpacked and manually compiled the binary files following their instructions to the letter. I just didn't know of a better and easier way to install VMware Tools at the time. During the "make install" stage of the process, I got error messages about problems with the virtual MEPIS file system -- I think the VMware Tools installer was looking for some system folders that didn't exist but I honestly don't remember all of the details. I have a hunch this is why VMware Tools didn't install completely.

Anyway, believe it or not, I did manage to install VMware Tools from the binaries -- well, sort of. There is a file /usr/bin/vmware-toolbox that launches it, and while it's running the cursor can drag in and out of the virtual machine. The only thing is that it won't start automatically or run in the background, which prompted my first post.

It's been a long day, and I'm a little too worn out to go over the rest of your troubleshooting tests tonight. I'll do this tomorrow when I'm a little fresher. Because of all the mistakes I've made so far, I'm not very hopeful that my results will match yours. I'll post the results.

In the meantime, I actually did manage to write a little shell script that starts VMware Tools in a minimized (but not background) state automatically upon logging in as username. I know this is not a very elegant solution, but I'm pretty proud that I was able to do such a thing, given the fact that I'm a complete newbie with Linux. This has been a really exciting learning experience for a 59-year old grandmother!

Thanks so much for your help.

- joany

Hey joany, thanks for the update. Yes, there's lots to learn, and lots to share. Glad I could help you get through some of the problems.

Please share the script that you set up and the instructions on how you're running it. It might help someone else.

Congratulations on being a 59-year old grandmother who can learn Linux!
There are quite a few of us > 0.5-century folks on this forum. All willing to help

Let me know what you find out.

Jon

Jon -

Here are my results:

$ whereis vmware-tools
vmware-tools: /etc/vmware-tools /usr/lib/vmware-tools

$ ls -lad /etc/init.d/*vmware*
-r-xr-xr-x 1 root root 18023 2006010-17 13:29 /etc/init.d/vmware-tools

$ ls -lad /etc/rc*d/*vmware*
lrwxrwxrwx 1 root root 24 2006-10-20 16:40 /etc/rc5.d/S06vmware-tools -> /etc/init.d/vmware-tools

lrwxrwxrwx 1 root root 24 2006-10-20 16:40 /etc/rc6.d/K08vmware-tools -> /etc/init.d/vmware-tools

You can see that I had only two "symbolic links" compared to your eight, and no "S19vmware-tools."

I'll go on to your next step and create the missing S19 symbolic links in the root terminal, reboot and see what happens!

By the way, here's the little shell script I referred to in my last post:

#!/bin/bash
if [ -x /usr/bin/vmware-toolbox ]; then
/usr/bin/vmware-toolbox --iconify
fi

(The --iconify parameter runs VMware tools in a minimized state without a dialog box popping up.) I copied this shell script, which I named "tools," into /home/username/.kde/Autostart and changed the file mode using chmod, which allows it to execute in Autostart:

$ chmod +x tools

Again, Jon, thanks for your patience and encouragement. I hope I can provide help to others with Linux some day. I cut my teeth on Fortran in college many years ago in the mainframe era, then moved on to PL/I when I entered the corporate world. When PCs came out, I learned a little DOS and then VisualBasic. Linux has been quite a challenge, but I'm enjoying it a lot. I think most of my problems will be solved by "unlearning" old habits I picked up while using the "other" OS.

Cheers

Jon -

I used the root terminal command "ln -s" to create all of the missing "symbolic links." I now have a total of nine of them, all pointing to /etc/init.d/vmware-tools:

/etc/rc0.d/K08vmware-tools
/etc/rc2.d/K08vmware-tools
/etc/rc2.d/S19vmware-tools
/etc/rc3.d/K08vmware-tools
/etc/rc3.d/S19vmware-tools
/etc/rc5.d/K08vmware-tools
/etc/rc5.d/S06vmware-tools
/etc/rc5.d/S19vmware-tools
/etc/rc6.d/K08vmware-tools

Note the /etc/rc5.d/S06vmware-tools symbolic link is an "extra" one that wasn't shown on your system. Is this a problem? If so, how can I remove it?

Next, I removed the little shell script that launches VMware Tools from Autostart, shut down the computer and rebooted. Unfortunately, VMware Tools did not appear to be running after making these changes (the cursor was "stuck" inside the VM window and I couldn't copy/paste between guest and host). I checked to see if the process was running in the user terminal and got this result:

$ ps -ef | grep vmware
username 4096 4023 0 10:29 pts/1 00:00:00 grep vmware

I did the same check in the root terminal with a similar result:

# ps -ef | grep vmware
root 4511 4453 0 10:30 pts/2 00:00:00 grep vmware

Right now, I'm at a loss as to why VMware doesn't start automatically when the system boots, since the links on my system now seem to be aligned with yours.

By the way, I then started VMware Tools manually with the shell script, checked to see if it was running in the terminal, and got this result:

$ ps -ef | grep vmware
username 4631 1 0 10:31 ? 00:00:000 /usr/bin/vmware-toolbox --iconify

If you have any further ideas, pass them along. I feel a little embarrassed at this point, since I'm pretty sure I messed up the installation of VMware Tools by trying to compile and install the application from the binary files -- plus the fact, I probably should have gotten a hold of VMware Server in the first place, instead of trying to do a MEPIS installation on VMware Reader.

- joany

Hi Joany. Thanks for the update.

First, to get rid of the "extra" startup link, you simply need to perform

rm /etc/rc5.d/S06vmware-tools

as user root.

Hmm, your inability to get this thing to run via the "normal" route is troubling. What happens if you try the init script directly? What I mean is, stop the vmware tools (or don't start them via your script), and open a konsole, "su" to root. Then, issue the command:

/etc/init.d/vmware-tools start
   (wait for a few seconds)
ps -ef |grep vmware   # you should see the vmware-guestd stuff

I'm beginning to suspect that the vmware-tools, or /etc/init.d/vmware-tools is not working correctly. And the script you wrote invokes vmware-toolbox; a different set of tools!

Just yesterday, since you got me started, I did a fresh install of Mepis 6.0 into a clean virtual machine. So I had to go through all of the steps from the beginning. At this moment in time I do not have my laptop running, so I can't tell you what BUILD of VMware Workstation I'm running, but it is VERSION 5.5.3, that I downloaded just yesterday. What version and build of VMware Player are you running? You can find that info in the Help screen.

The reason I ask is because when I ran the install tool in the virtual machine I had all the symbolic links created automatically. I didn't have to make any of them, and the system "just worked" (after a reboot of the virtual machine). So I'm wondering if the version of your vmware-tools might be whacked

Jon

Jon -

Now things just got interesting. I stopped VWware Tools and attempted to restart it in the root terminal. This is what I got when I typed in /etc/init.d/vmware-tools start:

VMware Tools is installed, but it has not been
(correctly) configured for the running kernel.
To (re-)configure it, invoke the following command:
/usr/bin/vmware-config-tools.pl.

This confirms to me that the configuration of VMware Tools was messed up from the get-go. So I said, "What the heck," and gave it a go. So I typed in the command /usr/bin/vmware-config-tools.pl, and this is what I got as a response:

Making sure VMware Tools's services are stopped.

Stopping VMware Tools services in the virtual machine:
Guest operating system daemon:
done
cat: /proc/pci: No such file or directory
This program previously created the file
/etc/rc5.d/S06vmware-tools, and was
about to remove it. Somebody else apparently did it
already.

Trying to find a suitable vmhgfs module for your running
kernel.

None of VMware Tools's pre-built vmhgfs modules is
suitable for your running
kernel. Do you want this program to try to build the
vmhgfs module for your system (you need to have a C
compiler installed on your system)? [yes]

I answered "yes" to that question and then things REALLY got squirrely:

Using compiler "/usr/bin/gcc". Use environment variable
CC to override.

What is the location of the directory of C header files
that match your running
kernel? [/usr/src/linux/include]

I'm afraid to go any further at this point. I'm smart enough to know I'm way over my head when somebody asks for the location of the directory of C header files that match my running kernel! YIKES!

You observed the difference between "vmware-tools" and the
"vmware-toolbox." I think vmware-toolbox is, in fact, a "different" set of tools that may do the same thing as vmware-tools. Remember that I installed VMware Tools by compiling it from binary files (although not very successfully). This could be sort of like installing an after-market air conditioner on a car. It's "different" than a factory air conditioner, but they both essentially do the same thing.

Anyway, if you have any clue where my C header files may be, maybe we can fix this thing. At this point, I'm really in debt to you for all your time and trouble. I just hope you got something useful out of all this!

Yup, I was wondering if that might happen.

Let's back up a bit, because you may or may not have some of the other required files and applications in your guest machine. What you WILL NEED is gcc and the linux-headers that match your kernel. All of what I describe, from here on in, will apply to the guest machine, not the host. And it's best to log in as root, or open a konsole and "su" to root.

What's all that junk above mean?

First: Exactly which version of Mepis are you trying to load into a guest machine? If it's 6.0-1, then the kernel will be 2.6.15-26-386. You can confirm that by opening a konsole (in the guest machine) and entering "uname -r".

Next, did you do a full update of the packages in your guest machine? I know the system probably runs a bit slow, but you can go into synaptic, choose Reload, then Mark All Updates, and Apply. Using my system yesterday as a guide, there will be about 73 packages to update (are you on broadband or dial-up?)

Once your system has been brought up-to-date, reboot and double-check the kernel version. I can't remember if there was a kernel update in the mix above. But it NOW should be 2.6.15-26-386. If so, go back into synaptic. Search for "linux-headers" and you will find one called "linux-headers-2.6.15-26-386". Right-click and choose to install (and there will be one more package added; let it). Apply the change.

I believe that gcc, the Gnu C Compiler, is installed by default, so I don't think you need to worry about that.

Next, in your konsole, logged in as root, go to where you have your vmware configuration script and run it.

Here's the good part: You can press Enter through most of the prompts. If everything's been set up properly, your compiler, libraries, and kernel headers will all be in the right places.

The process will hum, whirr, and bumb for a bit as it tests your kernel and builds the script. It should come back with no errors. You should be greeted with a final screen that asks you to confirm your screen resolution (1024x768?). Make the appropriate choice.

If all went well, you should now be able to look for the original symbolic links to /etc/init.d/vmware-tools and they should ALL be there.

You WILL have to reboot to have this mess take effect.

Let me know how it goes. Meanwhile, I'm sharpening my chainsaw and preparing to sacrifice a few rubber chickes on your behalf. That usually works

Jon

Jon -

I'm impressed! Downloading the linux-headers with the Synaptic Package Manager did the trick. (All of my other installed stuff was already updated.) After downloading and installing those packages, I was able to reconfigure vmware-tools from the root terminal with a "successful install" at the end!

However, the final message at the end of the install said that I could now launch vmware-toolbox, which is what I had been doing all along. I was rather puzzled by this, so I rebooted (with the shell script disabled) to see what would happen.

After the boot up and sign on were complete, the behavior of the cursor was just as if VMware Tools weren't running. I decided to test to see if vmware was in fact running:

$ ps -ef | grep vmware
root 3003 1 0 15:32 ? 00:00:00 /usr/sbin/vmware-guestd --background /var/run/vware-guestd.pid

The above response indicated that vmware was running, but yet the cursor was stuck in the virtual machine window and copy/paste didn't function. In other words, vmware may have been running, but it wasn't DOING anything ... arrrrgh. Again, I manually launched vmware-toolbox, and things worked as they should. Maybe it's actually vmware-toolbox that does the real work, and there's some kind of call procedure from vmware-tools that isn't happening as it should.

Apparently, we're getting very close to the solution but aren't quite there yet.

Cheers

Yay, you're almost there!

I told you that I had reloaded 6.0 into a new virtual machine right? Well, this afternoon I tried to finish up on configuring a virtual machine running Fedora 6. That's when I found out something that you have been mentioning all along. In the Fedora 6 vm, I had to open and install vmware-tools from an RPM file. That's when I was slapped in the face with the fact that there are both vmware-tools and vmware-toolbox. The vmware-tools is to be run at system startup; whereas vmware-toolbox is run by the end-user!

Now as to your quandary. Did you restart the guest vm? If you do not restart it, then all of the vmware-tools goodness will not "take" 'cause it changes the /etc/X11/xorg.conf file, and a bunch of other things that I don't know about. Normally you should just be able to stop/start a process or ctrl+alt+backspace to restart X Window, but in this can ya gotta reboot the whole thing!

Let me know what happens. Meanwhile, I shall dig into one of my vm's and try to remember if there's any significant difference in "-tools" vs "-toolbox"

Jon

Jon -

Yes, I did restart the virtual machine. In fact, I even cold booted the host computer just to make sure (you never know!) But I got the same results as before. I'm glad to find out I'm not going insane and that you ran into a similar situation when you installed VMware Tools on Fedora 6.

I paid close attention to all of those messages while MEPIS was booting up in the VM. I noticed that around the 70% complete mark, there was a message that "vmware tools services" were started, so apparently vmware-tools does start fairly early in the boot up process.

I think the root cause of my problem is that I did an "after market" installation of VMware Tools. But now that I think of it, I also did an "after market" installation of VMware Tools on Freespire 1.0 using the same method. However, when Freespire starts, the tools just work right away, even before logging in -- and without having to start vmware-toolbox. One difference is that Freespire is set up by default to log in as root. Could the fact that MEPIS has user accounts have something to do with why vmware-toolbox needs to be started with an "after market" installation?

Joany, have you been following this link?
http://www.mepis.org/node/11913

M_pav has provided an excellent description of all of the prompts that come up for installing VMware Server. I know they're different, but perhaps there is something that was missed.

No, the fact that Mepis has user accounts would have no bearing on the problem. All of the /etc/init.d/stuff is run BEFORE any user activity occurs. And if you have a script in /home/you/.kde/Autostart, that will not be run until you log in using KDE as your desktop (if you were to use GNOME for instance, it would not run).

Usually the problem with VMware (either host installation or tools or anything else) has to do with the configuration not being generated correctly. This is usually caused by answering a question wrong, or not having the proper headers. If you loaded Mepis 6.0 into a guest machine, it will already have the gcc compiler and a bunch of other libraries installed; however it may not have the linux-headers installed. If you find and install this via synaptic, it will go in the right place on the system (Mepis 6.0 was also designed to be "friendly" with VMware), so you shouldn't have to "do" anything to tell the configuration to run correctly.

In your guest machine exactly what command are you trying to run to configure and install the vmware-tools? In other words, can you please provide me with the exact directory and command(s) that you are typing in? I do not have my laptop plugged in at the moment (it figures), so I'll get back with you later and show you where my installation scripts and other stuff are in my Mepis 6.0 guest computer.

Don't make me have to sacrifice more rubber chickens! I haven't cleaned up all the mess from the last time. There's rubber scraps all over the place!

Jon

Hi, Jon -

I'll go through the steps in more detail:

First, I used Synaptic to download and install the latest linux headers called "linux-headers-2.6.15-26-386". I just re-verified that the package is installed. However, there are also three other linux-header* packages installed. Could there be a conflict??

I also read something on a post about installing VMware-tools on Debian, and needed something called a gcc-4.0 package, which I also verified is installed. However, there is also a gcc-3.3 package installed.

Next, I started a root terminal and typed in:

# /usr/bin/vmware-config-tools.pl

The following lines are what came back.

Making sure VMware Tools's services are stopped.

Stopping VMware Tools services in the virtual machine:
Guest operating system daemon: done
cat: /proc/pci: No such file or directory
Trying to find a suitable vmhgfs module for your running kernel.

None of VMware Tools's pre-built vmhgfs modules is suitable for your running
kernel. Do you want this program to try to build the vmhgfs module for your
system (you need to have a C compiler installed on your system)? [yes]

At this point I hit and the next block of lines appeared:

Using compiler "/usr/bin/gcc". Use environment variable CC to override.

What is the location of the directory of C header files that match your running
kernel? [/lib/modules/2.6.15-26-386/build/include]

This looked right, considering that my linux-header has the same number, so I hit again. The next block of lines appeared:

Extracting the sources of the vmhgfs module.

Building the vmhgfs module.

Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-config0/vmhgfs-only'
make -C /lib/modules/2.6.15-26-386/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.15-26-386'
CC [M] /tmp/vmware-config0/vmhgfs-only/cpName.o
CC [M] /tmp/vmware-config0/vmhgfs-only/cpNameLinux.o
CC [M] /tmp/vmware-config0/vmhgfs-only/dev.o
CC [M] /tmp/vmware-config0/vmhgfs-only/driver.o
CC [M] /tmp/vmware-config0/vmhgfs-only/hgfsUtil.o
In file included from /tmp/vmware-config0/vmhgfs-only/hgfsUtil.c:13:
/tmp/vmware-config0/vmhgfs-only/vm_asm.h: In function 'Div643264':
/tmp/vmware-config0/vmhgfs-only/vm_asm.h:1139: error: memory input 4 is not directly addressable
make[2]: *** [/tmp/vmware-config0/vmhgfs-only/hgfsUtil.o] Error 1
make[1]: *** [_module_/tmp/vmware-config0/vmhgfs-only] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.15-26-386'
make: *** [vmhgfs.ko] Error 2
make: Leaving directory `/tmp/vmware-config0/vmhgfs-only'
Unable to build the vmhgfs module.

The filesystem driver (vmhgfs module) is used only for the shared folder
feature. The rest of the software provided by VMware Tools is designed to work
independently of this feature.
If you wish to have the shared folders feature, you can install the driver by
running vmware-config-tools.pl again after making sure that gcc, binutils, make
and the kernel sources for your running kernel are installed on your machine.
These packages are available on your distribution's installation CD.
[ Press Enter key to continue ]

Note there was a problem in building something called the vmhgfs module, but the good news was that the rest of the VMware Tools is independent of this feature, so I hit again, and the next block of lines appeared:

No X install found.

Starting VMware Tools services in the virtual machine:
Switching to guest configuration: done
cat: /proc/pci: No such file or directory
DMA setup: done
Guest operating system daemon: done

The configuration of VMware Tools 2.5.2 build-20605 for Linux for this running
kernel completed successfully.

You must restart your X session before any mouse or graphics changes take
effect.

You can now run VMware Tools by invoking the following command:
"/usr/bin/vmware-toolbox" during an XFree86 session.

Enjoy,

--the VMware team

Note that there were some problems; however, the good news was that the configuration for this kernel completed successfully and I was told to enjoy by the VMware team. I took that cheery message to mean things were generally OK.

Then I went ahead, rebooted, and arrrrrgh -- the same result.

Does anything above point to the problem at hand??

Hi Joany. Thanks for more "stuff".

No, you shouldn't have any conflict if you have more than one kernel header installed. But as long has you have the one that matches your kernel (which it appears to d) you will be fine.

Let's not worry about the vmhgfs problem at the moment

The message about not having X is interesting. Are you logging is as a "regular user" into KDE in the guest machine? I.e. is KDE up and running? You should be, and it should be. Then, you should be able to open a konsole, "su" to user root and run the various configuration scripts.

Oh, for gins and griggles I just finished loading Slackware 11.0 into a virtual machine and got vmware-tools to load. Now THAT was weird. So I know you can do it.

Also, for my understanding, can you please explain what you mean my "-- the same result"? What is happening or not happening that tells you that the tools (not toolbox) are not installed? Like, is the mouse movement painfully slow? That is the prime indicator to me that I haven't got things running right in the vm. Is this what you're experiencing? Are there other things?

Jon

I'm your worst nightmare: A Geek with an Attitude!

Proud Charter Member of
Da Mepis Posse

Jon, you must have the patience of Job!

I was also taken aback by the statement about X not running. But I can assure you that KDE was up and running and I was logged in as a regular user ("username"). Also, I was doing the reconfigure within a root terminal. (In MEPIS, there are two separate "sessions" within one terminal window. One session has a white background and is available to any user, such as "username." The other session has a tan background and it is reserved for root. You can also toggle between them, which is a very nice feature, I think.)

Anyway, by "the same result" I mean that the cursor won't move between guest and host...you have to use ALT-A and ALT-G to toggle the cursor back and forth. Also, you can't copy/paste between guest and host. In other words, although vmware-tools is "running," it isn't actually "doing" anything. However, no, I don't find the mouse to be painfully slow.

In contrast, as soon as I launch vmware-toolbox, I get the enhanced graphics as advertised...I can move the cursor anywhere I want on the computer screen and copy/paste between guest and host.

This is certainly as strange problem. The application is obviously "installed" and from all indications it's also "running." But it definitely isn't "working"!

Did I understand correctly that you're having or have had a similar problem with Fedora 6?

Well Joany, this is going to get real educational (for me!). I have just done a couple tests on my system to see if I can duplicate some of what you're seeing. The results are not what I was expecting!

Unfortunately, I shall have to leave you hanging for a bit because I will be leaving for an appointment shortly. But let it suffice, that I have found out quite a few things regarding vmware-tools and vmware-toolbox.

Don't worry, I shall try to post my findings this evening. Stay tuned; this will be fun!

Jon

I'm your worst nightmare: A Geek with an Attitude!

Proud Charter Member of
Da Mepis Posse