The directory /opt/merge contains the files directly installed when you install the Win4Lin package. The directory /var/merge contains the files installed by the Win4Lin install script. If /opt/merge exists and /var/merge does not, then the install script failed to be run. The directory /var/merge/log contains the log files created by the installation process.
grep mki_install_hook /proc/ksyms
It should print back a line something like:
c010be50 mki_install_hook
If nothing prints back, then that is a big problem.
This means that the Linux kernel that is running is not "Win4Lin ready".
Perhaps you have kernel available that is "Win4Lin" ready, but it is not the one currently running. Refer to the installation notes about how to either install or build a "Win4Lin ready" kernel. If you are having trouble building the kernel please verify that you can build an unpatched kernel as supplied by your distribution.
If the kernel seems ok, then perhaps the Win4Lin package did not install properly or all the way. The log file "/var/merge/log/inst.log is produced when Win4Lin installs itself. If this file is missing then the RPM package did not properly install. (The rpm command is supposed to execute the script /opt/merge/postinst_rpm.sh after it copies in the files.) Near the end of the log file should be the line "Installation of Win4Lin is complete". Any errors or warning in the log are abnormal.
The log file "/var/merge/log/insmod.log" contains the output of the "insmod" commands that are used to load the modules. Take a look at it. Warnings about "kernel-module version mismatch" are fine and expected in many situations, but any other warning or error message probably indicates an error.
A common problem is when the kernel was created using "versioning" and you are not using the Win4Lin drivers that were created specially with that kernel versioning. (The "versioning" scheme used by several distributions seems somewhat broken in that modules built in the standard way cannot be used on these kernels.) If this is them problem then there will be many errors in the insmod.log file about unresolved names. There are a couple of solutions. One is to rebuild your kernel with versioning off. Another is to get Win4Lin modules created for that kernel's versioning. (if available). If you have this problem, contact your Linux distributor and complain that their system does not allow standard modules to be used.
Note: Win4Lin uses the script "/opt/merge/drivers/tools/loadem" to load the modules. When logged in as root, you can execute this script to make sure the modules get loaded. This also recreated the "insmod.log" log file. (This log file is recreated each time loadem is run.) If the problem is that the modules are failing to load, this log file should provide all the info needed to find out why.
Note: The loadem script also runs the mknode_linux.sh script (in the same directory). This creates the special device "node" files in the directory /var/merge/mrgdev. In this directory should be five node files and file subdirectories, and in the subdirectories are more nodes file (lots!) and more subdirectories.
If the Win4Lin drivers seem to be installed ok, then there is an easy test to verify Win4Lin basic functionality. The test involves executing a command to boot a DOS floppy in a Win4Lin virtual PC window. If the floppy boots, then Win4Lin has probably been installed correctly.
Make sure that your DISPLAY environment variable is set, just as it needs to be for any X client program. Put any bootable floppy in the drive and type this command at an xterm or other X windows terminal emulator:
/usr/bin/dosboot
A DOS window should pop up producing an "A>" prompt.
NOTE: The "ver" command will print out the DOS version, which you can use to verify that the boot floppy is the right match for the Windows installation CD (for those versions of Windows that require a boot floppy as part of loading Windows). Note: the DOS in "classic" Win95, Win95 OSR2, Win98 and Win Me are not the same DOS version. The DOS version has to match the Windows version.
Actually, all you need is any floppy, unbootable or not and try to boot from it with the dosboot command. If a DOS windows pops up and shows that it is trying to boot from that floppy, then that is sufficient to show that Win4Lin is basically working.
To close the DOS window produced by using the /usr/bin/dosboot test, it is necessary to use the windows's menu bar (Window->Exit) or a window manager function. (E.g. the window frame drop down menu "Close" selection.)
If the DISPLAY variable is not set Win4Lin will not run in an X window and there will be no menu bar selections available. In this case type <Esc> <Ctrl+k> (i.e. the escape key and then control-k.) This is the magic key sequence to kill a DOS session that is not running its own X window.
If you do not have a floppy drive then type this command:
/usr/bin/dosboot +aa:=/foo
The command specifies booting from a nonexistant "virtual floppy"
refered to as "/foo" which satisfies the test's requirements.
Now reinstall the Win4Lin package:
rpm -i win4lin.rpm
(or whatever the RPM filename is)
If after completely removing and reinstalling Win4Lin it is still not possible to pass the test and checks discussed on this page, you should gather all the log files and system information as described in Trouble Shooting Guide Table of Contents, so you will have all the necessary data ready for submitting a problem report.