Slackware 12.2 - HIGHMEM64 support - 1st kernel build
 

Greetings,

I'm doing my first kernel build on a fresh install of Slackware 12.2, and all I want to do is add support for 8G of RAM. Could someone point me to a guide that is specific to 12.2? I've Googled tons of build articles, and I'm at:
/usr/src/linux# make menuconfig

I'm in menuconfig, and I see the submenu where I can enable HIGHMEM64.

However, my question is this, can I simply enable that, and will this kernel be the exact same kernel that got loaded on install? In other words, if I don't change anything else, are the current defaults [in menuconfig] the same as the currently installed kernel? I didn't do anything special on the install.

I'd also greatly appreciate a step-by-step of what to do after I close out of menuconfig. I'm not exactly certain where the new kernel should go, and how to switch over to the new one.

I'm a touch nervous because this is a production server. It's MY production server, but I've got a couple full-timers using it, so any stupid mistakes I make affect others now. I have been using slackware for around 8 years now (obviously not exclusively), and I still consider myself a total noob. I know just about enough to be dangerous, but want to change that. Any help would be welcomed.

Beyond that, I would like a guide to optimizing my kernel. I was digging through the submenus of menuconfig, and I found a ton of crazy options like 'enable HAM radio support'. Seriously? Do I need this in my kernel? I run a LAMP environment at a cheap office.

Thanks,

-Heady

/first post, please go easy.

Welcome to LQ!
I see you have done a fair bit of homework and it will definitely help out.
All you have to do is enable the highmem64 option, then save the configuration, and once back at the terminal type 'make && make modules_install' which will rebuild the kernel and rebuild all the modules and install them to the correct locations.

The next part is where I deviate from everyone else, after running those two commands i run 'make install' which makes sure everything gets update and your vmlinuz is updated as well as your lilo.conf to point to the new kernel image. A LOT of people will tell you to do it another way that involves copying a couple files and effectively accomplishes the same thing. (please see further suggestions in post beneath me for how to go about the other way)

As for streamlining your kernel. A lot of times (if you have an x server running you can use 'make xconfig' which looks a bit prettier than the menuconfig and lets you see more on one screen) if you read the help on each setting you should be able to figure out what you need and what you don't. my suggestion is though, if you don't know what it does, leave it.

Have fun!

P.S. I would recommend waiting for another person to post after me because I am not sure if recompiling a kernel without enabling your filesystem as <*> will require you to rebuild your initrd.gz

Thanks C_Sniper! (nice handle!)

Yes, I've been tempted to use xconfig, but I'm trying to baby-step into CLI, and I figured ncurses is a good intermediate step...right? :)

Thanks for the tips. I'll wait a couple of posts as you say, and then I will give it a go.

To get the same exact kernel that got loaded on install, you need copy the current kernel's configuration file.

The process should be something like:
Now you need to edit lilo:
Add something like:
Then run:

Also read this:
http://www.slackbook.org/html/book.h...KERNEL-COMPILE


Yeah, it will. But if he uses the stock slackware kernel's configuration file, support for his filesystem should already be built it.

It's best to build support for your filesystem into the kernel and not as a module

Well, I followed your steps piratesmack, and got a modprobe error on the following boot. I can't get it to fully boot now. any ideas?

In the meantime, how can reconfig lilo to boot the old kernel?

got it working on the old kernel again.

In the truest spirit of Linux, I read article after article, scoured forums, booted from a few different sources, then finally found the answer in the darned MAN file. ;-)

Boot off a slax stick with the Slack Install DVD inserted. CD into the Slack DVD directory /mnt/sr0/slackware/a (in my case)

ROOT=/mnt/sda1 upgradepkg --install-new --reinstall kernel-modules-2.6.27.7-i486-1.tgz

installs/upgrades the package to the root partition of another disk (in this case sda1).

Fixed me up and booted normally with the old kernel. I'm still not certain what happened, maybe I better do this over the weekend next time, eh?!?

That's weird, did you change anything else in menuconfig?
And what was the exact error you got?

Sorry I didn't tell you this before, but another option you should look at in menuconfig is "General Options>Local version - append to kernel release [-smp]"

Change it from "-smp" to whatever you want to call it. "-custom" for example. That will make it so your new kernel's modules go into a different folder, like "/lib/modules/2.6.27.7-custom" instead of "/lib/modules/2.6.27.7-smp"

That way you can keep both kernels in case something goes wrong

sorry, i just missed piratesmack's direction in the post above: "zcat /proc/config.gz > .config" My question is already answered


>hi,
>i was actually going to attempt the same thing,
>i have slackware 12.2 installed working fine with all of my drivers, my problem is that i can use only 3gb of ram.

>i just want to recompile the default kernel with pae enabled. I dont want to reinstall the drivers or any other modules if possible and i dont >want to have any difference with the default kernel except pae.

>So about my question:

>i have installed kernel sources package, does the sources and configuration under /usr/src/linux reflect my actual kernel configuration? i mean >if i just change pae here, and make a build, would that be ok? or are the config files for my default kernel is residing elsewhere?

>thanks in advance

You should really run a 'make oldconfig' directly after you copy the .config file into place, just to be on the safe side.

I think that maybe because I'm already running a Slamd64 64-bit kernel (and HIGHMEM64 is already configured), I may not be having this option shown. So how do I build a 32-bit kernel with HIGHMEM64 while running a 64-bit kernel. Where exactly is the configuration for HIGHMEM64? I don't see it. If the 64-bit kernel already has HIGHMEM64, will the 32-bit build default to the same value?

Shingoshi

I've used Eric's guide to build a new kernel. This is a thorough, well-written how to on kernel compiling. I highly recommend it.

Building a Linux Kernel from source

Look at "Processor type and Features->High memory Support".

Edit: I just booted my Slamd64 to check this and I can't find it either - not sure what's going on there. Maybe a kernel version or something ?

I was looking for the location of the configuration option....
 

I was looking for the location of the configuration option....
But as I stated, and was later substantiated by the respondent (bgeddy) below you, the configuration doesn't show up when you're running a 64-bit kernel. A 64-bit kernel already has this enabled by default. So you're not going to see this configuration option, no matter how hard you look.

I'm going to try with another kernel source I have on my system, and remove the .config file. Hopefully, that will give me a new blank configuration without any ARCH previously set.

And by the way, I have built numerous kernels, including 64-bit. But you simply can't configure what doesn't show up!

Shingoshi

I used Alien Bob's guide, on a 32 bit compile, and the option read something like --enable ram up to 64 gb-- or something like that ...I used the ncurses menuconfig...it's in there somewhere, can't remember more than that, sorry.

HIGHMEM won't show up with a 64-bit kernel...
 

How many times do I have to write this?
HIGHMEM won't show up with a 64-bit kernel...
I just tried the configuration of my kernel using a clean .config. That produced the same result (because of uname). But then it occurred to me to use "linux32 remake menuconfig". Yes, you're reading correctly. I use remake instead of make. And that did the trick. Only by convincing the kernel (with linux32) that it was a different ARCH, would it finally allow me to build a 32-bit version. HIGHMEM64 showed up, and I set it as required. So all is good now. Well, I think it is. I haven't actually started the rest of the configuration and build yet.

Shingoshi

remake is a patched version of make which provides additional features for debugging. Look for it.
http://bashdb.sourceforge.net/remake/

I was not actually replying to your post, but, rather I was adding a general post to the thread about compiling a kernel for other users. I thought Eric's guide was a useful thing to mention.
I usually quote a post if I reply to it. I can understand your confusion with my reply. Sorry for the confusion. As a Gentoo user I know you are proficient with compiling a kernel. No disrespect was intended with my post.

Hitest,
Your apology is deeply appreciated. And may you keep firing on all cylinders (pun for "hitest" petrol).

Thank you!
Shingoshi

Hell, I can't even get Gentoo installed! (well, that was a few years ago...spooked me so bad I haven't been back) LOL

You are welcome, Shingoshi! :)

I will be the first to admit it...
 

Gentoo is NOT for the faint of heart. I've heard so many Slackware users complain about trying to use Gentoo, that it's almost pathetic. And many of them have been long time experienced Linux users. I'm one of those more adventurous types. If I see a mountain (figuratively speaking, mind you), I'm the first who wants to climb it. I've done so many of the things that users are NOT supposed to do, that it's become an obsession with me.

One of those things was to use slapt-get to directly upgrade from Slackware to Slamd64. Even Fred (the Slamd64 creator) thought I was insane. But it worked. I did have some problems, simply because of the many programs which I had compiled myself, and hadn't yet upgraded. But for package building, I use src2pkg, which is excellent. As with Tukaani's tukbuild previously, I've also done a lot of testing for src2pkg for 64-bit builds. And I'm still actively engaged in that.

In fact, it's because of my use of src2pkg on my 32-bit system using a 64-bit kernel, that I was aware of linux32. I had to build my own copy of it, since the one from Slamd64 is a 64-bit binary and was of no use to me. I have a very large config file for src2pkg.conf. And because I have to use linux32 for just about everything that I do, I knew it might work in this case as well.

Gnashley (the creator of src2pkg: http://www.linuxquestions.org/user/gnashley-88281/) had been pestering me for some time just to go back and use a 32-bit kernel. And I finally (though reluctantly) conceded. Once I have my new kernel installed and running, hopefully all of my previous problems with not being able to run some 32-bit apps will be over. Although, the compulsive-obsessive in me will still feel like I've submitted to failure. :redface:

Shingoshi

I used Gentoo inside a chroot on Slamd64. I wanted to examine building Slackware packages with their automated build system. It really is the gold mine for obsessive builders like me.

I may still go ahead and recompile gcc to allow 64-bit builds. Because all I really want to do is create kernel modules, which I can't do with the default Slackware gcc. But that's another topic which you can find here on Linuxquestions.

Is there something NOT HUGE about HUGEMEM64 on an smp kernel?
 

Is there something NOT HUGE about HIGHMEM64 on an smp kernel?

I mean maybe someone can explain this to me. Why isn't HIGHMEM64 enabled by default on the kernel-huge-smp? The very name of the kernel is HUGE. So why isn't it built for systems that require the maximum amount of resources available? Why are we being forced to create a kernel with a major option not provided by default. Almost anyone who has a new processor and motherboard, will have the option of using memory in amounts larger than 4GBs. I mean, for crying out loud. Windows is hamstrung to 4GBs. Is the kernel-huge only supposed to be a clone of the Windows limitation?

With the new Intel i7 motherboards, no one is going to be content for long with the limitation of 4GBs. Those boards use a minimum of 6GBs, and a maximum of 72GBs (using 4GB modules). Even on an old socket-775 board, using the Intel ich10r northbridge chip, the maximum amount of available memory is 16GBs. So am I the only one who has thought about this?

Shingoshi

It's called HUGE because it's built with everything (Kitchen sink and all) included and is not a reference to the amount of addressable memory.

It's not a conspiracy... honest ;)

I made no mention or implication of conspiracy.
 

I was asking about the apparent lack of consistency (not conspiracy) here. If it's called HUGE for the sake of "everything in it", that level of completeness should also include (by implication) the amount of memory that can be used. And what may have been good in the past, isn't going to satisfy the concerns I've raised about our current (Intel i7 et. al.) state technology. It is simply no longer adequate to NOT provide compiled kernels with the maximum amount of memory available. Conspiracy or not!

Shingoshi
ps. The HIGHMEM option is likely going to have to be raised to match the new systems (with more than 64GBs) that can run 32-bit Linux.

Once again, do not confuse the name "huge" in this kernel with the addressable memory. It is huge because it contains as much drivers as possible to allow installation on a variety of hardware.

It's explained like this in CHANGES_AND_HINTS.TXT:

And the Slackware-HOWTO states:

It's somewhat unlikely that you will ever need more than 4GB of RAM to install Slackware.

Eric

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. It's just my preference. So, expecting users to recompile a kernel, designates Slackware as a do-it-yourself distribution.

Shingoshi

That's exactly what attracts me to Slackware: decisions are not made for me. With Slackware I am stimulated to make my own decisions - I am in control.

I prefer a hundred times a 'do-it-yourself' distribution over a 'we-do-everything-for-you' distribution. :)

Slackware doesn't "expect" or require users to compile their own kernel, but gives them all the tools & sources necessary to do it *if they choose to do so*.

Where do you see that expectation documented?

And?

I like to have both, Slackware for the "do-it-yourself", and Ubuntu for "I-could-do-it-myself, but you-can-do-it-for-me-because-I'm-a-lazy-****-at-times" :D

You really mean that I'm not allowed to whine!! ;-)
 

Ok guys! Admittedly, I'm whining! I've already installed and am running a 64-bit kernel. It really confuses the hell out of your system. But the thing that really gets me is that I can't build 64-bit kernel modules. The rest of the stuff (odd issues here and there) I've learned to deal with. So I finally decided to go back and try to build a 32-bit kernel with HIGHMEM64. But for some weird reason, I'm having difficulty trying to build a 32-bit kernel.

First of all, I had to use "linux32 make menuconfig" just to get the HIGHMEM option to show up. The 64-bit kernel was telling the build, "hey, we're building a 64-bit kernel, 32-bit options don't apply here. That alone was annoying until I figured out what was happening. I kept thinking I must be missing something here. I wasn't. It just doesn't show up!

I may have to resort to building a kernel on another box which is running a 32-bit kernel, and see if it succeeds there. It really shouldn't be a problem. But that's the annoying part. If I didn't have another box to build a HIGHMEM64 kernel, I'd likely not be able to do it. So if the stock kernel came built with HIGHMEM64, I would have never experienced any of this. I think sometimes there simply are things that you can't do. Or the difficulty discourages anyone from trying. I didn't write any of this because I hadn't tried. Believe, I tried, all sorts of options and routes to get this done. If all else fails, I'll try installing a 32-bit kernel on this box, and then build the new kernel. Because I really like having my full 8GBs of ram. It's really sweet for mounting /tmp on tmpfs, and building packages there. It's just FAST!!

Shingoshi

Precisely mate. Man, 10 minutes in Ubuntu and I'm bored to death...just, well.....lost for words.....lol

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

The counter argument is, you don't have one...
 

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

Let me repeat myself...
 

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.

rebuilding kernel with PAE support
 

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

I greatly appreciate a voice of sanity...
 

Thank you for your positive input!

Shingoshi