Slackware 12.2 - HIGHMEM64 support - 1st kernel build
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
While it may true that the kernel-huge was intended as an installation kernel, I have never run anything else. I prefer knowing that there is nothing that I could install on my system, that I won't have the appropriate drivers for.
Shingoshi
Plan on installing a Toshiba Laptop on your system in the future? I'd take a hard look at those at those kernel options.
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.
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.
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:
Quote:
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.
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.
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.
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
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
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.
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
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.