Sorry to see you've had so many problems getting slamd64 up and running, I confess I never had these issues even with RC versions of slamd64. Anyway not having problems does not help solve yours ...
So, first of all some generic information for you:
1. nVidia drivers compile a kernel module, which clearly must reside *per kernel*. This is something you can live without until such time as the rest of the system is stable ... which means no errors on installs.
2. In old versions of slamd64 I had problems with the installer on the cd / dvd; it would segfault pretty randomly installing packages and so on. It looks like you're using the installer on your actual install, however, so this may not be applicable. You can use pkgtool on the slackware cds (cd 1 for "rescue disk") to install packages for slamd64.
As pertaining to your current problems:
The fact that you are having problems, even on a fresh installation, and never the same problem twice is leading me to be concerned about the quality of your hardware. Specifically, your hard drive. Failure to boot a kernel should not leave the partitions in a state that requires them to be fsck'd. Download the Ultimate Boot CD and run the disk checks necessary for your harddrive (make sure you get the manufacturer correct), you may also wish to perform a low-level format to correct any sector problems you may have aquired.
http://www.ultimatebootcd.com/
I encourage you *not* to do anything with the rest of this post until you have ascertained your hardware is not faulty.
Files
System.map.gz: Part of your kernel, really. See here
http://www.dirac.org/linux/system.map/ for a complete discourse.
bzImage: Your kernel image file.
config.gz: A compressed version of the .config used to make the kernel.
The problems with installing multiple kernel from slackware packages
It's easy to install packages, but unless you know what symlinks to remove, you will get bitten when installing multiple kernels from packages.
As you've already found out, most of them symlink to /boot/vmlinuz from things like /boot/vmlinuz-generic-2.6.12 and so on. Ensuring you never use these symlinks in lilo is the best way of dealing with the problem.
You will find lilo doesn't like long filenames, so you may be best off symlinking your long kernel names like this:
ln -s /boot/vmlinuz-generic-2.6.12 /boot/vmlinuz-1
ln -s /boot/vmlinuz-smp-2.6.12 /boot/vmlinuz-2
Whatever your scheme, you would be wise to ensure System.map matches your kernel prefix, like so:
/boot/vmlinuz-generic-2.6.12
/boot/System.map-generic-2.6.12
/boot/vmlinuz-smp-2.6.12
/boot/System.map-smp-2.6.12
If you've symlinked the kernels above and are using them in lilo, you should symlink your System.map files as well, for example:
ln -s /boot/System.map-generic-2.6.12 /boot/System.map-1
In closing ...
Check your hardware. If that's faultless, try reading things like /var/log/messages and dmesg to make sure there's no problems there. My suspicion is that you had a bad install due to bad sectors, and now your kernel is struggling to fix these problems that have occured with your FS on the fly (by having lots more bad sectors, or by the ext3 module being corrupted on install), all the while you're trying to install new stuff on a shakey foundation.
The steps to return to your desired state are very, very simple from a new install.
1. Format the whole drive, use the Slackware disk or a live CD to be confident there are no problems with the slamd64 one.
2. Repartition & reformat, again use a different disk.
3. Install from slamd64 media - do not activate swap, do this manually later - install whichever kernel you booted from - have lilo install itself to the MBR (if this is the only install, otherwise I trust you know where to put it).
4. Install the modules & smp kernel from packages, then hack the symlinks in /boot if necessary, tweaking lilo appropriately to have both kernels appear.
None of this should trigger segfaults, and if it does, there is some other problem than poorly typed commands.
Hope this helps,
- Piete.
