Plan on installing a Toshiba Laptop on your system in the future? I'd take a hard look at those at those kernel options.

The point is invalid by the simple fact that I've not been prevented from running kernel-huge, simply because I don't have a laptop. And more to the point, I often either clone or move disks from one system to another. And those systems often have different resources. Never will I be confronted with a situation where I will have to do anything to get the kernel-huge to run.

So find a better argument,
Shingoshi

With a "huge" kernel you will still require the kernel-modules package to have any networking capability. You may just as well switch to a "generic" kernel then. The smaller kernel will boot faster and udev will make sure all your (present and future) hardware will be recognized and configured properly.
There is no need at all for running the "huge" kernel after the installation of Slackware.

If you are afraid of creating an initrd, Slackware (-current) now has /usr/share/mkinitrd/mkinitrd_command_generator.sh which will tell you what command you should run for the creation of a proper initrd.

Eric

Since some of you haven't gotten the point:
Any time I clone or move disks from one system to another, I am essentially carrying out a new install. Since the components in the new system are never the same as the components the disks were originally in. If I built a stripped down kernel for the old system, chances are I wouldn't have the necessary modules ready for the new motherboard and it's components.

When I move disks from one system to another, I want that system fully functional the moment I boot it. Now I don't really care how much anyone else may want some particular advantage of compiling a stripped kernel. I will never run anything but the kernel-huge. That's just the way it's going to be.

Shingoshi

Whatever you're smoking seems to have affected your reading comprehension abilities. Nobody is suggesting that you should compile a "stripped kernel" at all. In fact, if you build an initrd for the generic kernel, nothing else about your situation changes - it blows your whole argument quite some ways out of the water. Everything that the huge kernel supports is also supported by the generic kernel -- the only thing you'd be putting in your initrd is support for your root filesystem, and that doesn't change when you pull the disk and slide it into a different machine.

Instead of trying to show everyone how much "premonition" and leetness you have, perhaps you should spend a little more time trying to actually understand what's being said to you.

No, you'll get a different kernel.
Here's my advice
1. make a backup of your current kernel and modules:
# cd /boot
# mkdir backup
# cp vmlinuz* System.map* config* backup

# cd /lib/modules
# mkdir backup
# cp -R linux-$(uname -r) backup

2. now copy your old config to the kernel source
(in which you had previously launched make menuconfig)
# zcat /proc/config.gz > .config
then
# make menuconfig
then enable the options you want

I have 4GB of RAM. Only a total of 3GB were shown when I
used the original kernel from slackware12.2.
I built a new kernel (2.6.29.2) and now the RAM is displayed correctly.
Here's some excerpts of my config

CONFIG_X86_32=y
...
# CONFIG_64BIT is not set
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_PHYS_ADDR_T_64BIT=y
...
# CONFIG_NOHIGMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y
...
CONFIG_X86_PAE=y

I usually go this way
1. backup
2. cd to the kernel source I want to build
# make menuconfig
# make bzImage modules
# version=<the version I'm building>
# cp System.map /boot/System.map-$version
# cp arch/x86/boot/bzImage /boot/vmlinuz-$version
# cp .config /boot/config-$version
# make modules_install
# cd /boot
# ln -sf System.map-$version System.map
# ln -sf vmlinuz-$version vmlinuz
# ln -sf config-$version config

Another thing. After my first installation of slackware
I get rid of the silly link rc.modules
(that points to rc.modules-someversion)
and rename rc.modules-someversion rc.modules
(it's in the /etc/rc.d folder)

If you have problems rebooting with your new kernel
you can boot with a live system (or your slackware cd)
and delete or move somewhere the 3files in /boot and
the modules directory that was installed, then
move back the files and folders from the backup
directories you created above to their original location

good luck

Part of the problem here is that I don't think any of you have tried your own advice while running a 64-bit kernel. I'm tired of repeating myself. So if you haven't read my previous comments, do so. The compilation failed the last time with errors I don't remember. But it may have been related to the running kernel. I'll have to check it again. I still haven't tried to recompile my kernel again. I may get to that today. Actually, no I won't. I'm getting a new cooling system for this computer, and will have to install it today. So I won't get to a new compilation until tomorrow.

Shingoshi

Shingoshi,

This is a *SLACKWARE* forum. It's expected that the people here are running Slackware. Slackware does not ship a 64bit version, and therefore it does not ship a 64bit kernel. Since it does not ship a 64bit kernel, it logically follows that NO, nobody is attempting to use a 64bit kernel with 32bit userland.

You're doing something that's completely unsupported. It's unsupported - not because it cannot work (for some values of "work") -- because it's impossible to support due to the sheer number of things that can go wrong.

You're certainly entitled to do it, but throwing this wackiness around during a "normal" discussion about kernel building and such is insane -- it just confuses new users. Because they're new users, they don't know enough to realize that what you're doing is completely unsupported (and borderline insane by some measures).

Ultimately, the problems you're seeing are (or at least *should* be) expected, but that's a discussion for another day/time, and I don't have time/energy/inclination to discuss it anyway.

Shingoshi,
If you want to try out a 64bit kernel without interfering
with your installed system, you can use RIP
(Recovery Is Possible), a linux live system that you can
use on a cdrom or a usb stick

http://www.tux.org/pub/people/kent-r...looplinux/rip/

When you boot on that system, you have the choice of booting
with a 32bit kernel or a 64bit kernel

Thank you for your positive input!

Shingoshi