SlackwareThis Forum is for the discussion of Slackware Linux.
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.
I need to re-compile the Slack-12 kernel (126.96.36.199-smp) with some different options (to do with getting standby / suspend / hibernate functionality working on my laptop).
My question is not so much to do with the kernel itself but the need to put copies of the relevant kernel .config and System.map files into the /boot directory. I have in the past followed the advice in http://shilo.is-a-geek.com/kernel14.html which suggests copying these files from the /usr/src/linux-xxxx directories where you build the kernel and remaking the symlinks so that System.map in /boot points to the new System.map-xxxx and .config points to the new .config-xxxx.
My question is : if you adopt this method and provide a new lilo start-up option for the new kernel, then the old kernel will not have the correct System.map and .config files referenced in /boot. Does that matter? What use is made of these files ?
duryodhan gives good advice -- I always compile my kernel in a special directory in my home directory (~/kernels, if you must know), and as a normal user. The ONLY steps you need to run as root are `make modules_install` and copying stuff to /boot. That way I know it's basically impossible to mess up my system when building a kernel.
It should also be noted that you may wish to compile a kernel newer than 188.8.131.52 if you are compiling a kernel anyway -- suspend/hibernate has REALLY improved since then. On a side note, I copy System.map to /boot and symlink it, but have forgotten in the past and my system has never had any ill effects. I only recently started copying my .config to /boot just in case I accidentally delete it in my ~/kernels directory, but it's really not necessary -- even if you do accidentally delete it, all that is required is running `zcat /proc/config.gz > /boot/config-kernelversion` and it will recreate it for you (assuming you've enabled /proc/config.gz support in the kernel -- it is enabled in the default Slackware kernels already).
As long as you are compiling a new kernel you might just think of upgrading as well. There were some acpi issues with 184.108.40.206 that were resolved with later kernels (at least on my machine). I'm using the generic 220.127.116.11 kernel now and couldn't be happier. Didn't even recompile it. Just downloaded and installed the kernel and kernel modules packages from -current, made an initrd, edited lilo.conf, and off I went. My standby, hibernate, etc. all work flawlessly now.
Just downloaded and installed the kernel and kernel modules packages from -current, made an initrd, edited lilo.conf, and off I went. My standby, hibernate, etc. all work flawlessly now.
Thanks (all) for the advice which seems to be to upgrade - already got the 2.6.24 sources and will build this. The only step that sounds unfamiliar in the above is "made an initrd" - any pointers as to how you do this? Looking forward to flawless standby & hibernations...
The only step that sounds unfamiliar in the above is "made an initrd" - any pointers as to how you do this?
Simple answer: You likely won't need to. I used the generic kernel as-is (no recompile), and by doing so I needed to create an initrd (initial ramdisk) to load modules the root filesystem requires. There is a readme in /boot that explains this. But since you are compiling your own kernel from source, you should not need to do this. I'm new to this though, so if someone has a better explanation than mine please correct me.
Creating an initrd (initial RAMdisk) is only necessary if the kernel modules for the filesystem used by your root (/) partition are not built in to the kernel and are built as modules. The / partitions must be able to be read in order to boot up your system, and so the correct filesystem module must be loaded into RAM. If you compile your own kernel, you should just include the filesystems in the kernel instead of as modules (ie[*] instead of [m]) and you won't need an initrd. However, if you use the generic kernel that ships with Slackware (or if you build your root filesystem as a module in your kernel) you will need to build an initrd. Instructions for how to do so are located in /boot/README.initrd, which is a symlink to usr/doc/mkinitrd-1.1.2/README.initrd. Alien Bob's script, as titopoquito mentioned, is a useful way to determine which command you should use to generate an initrd for your particular setup. It isn't proven to work 100% of the time (as far as I know it's new...but it's possible that I just haven't heard about it until recently), but I haven't heard of a case where it generates an incorrect command. It should be noted that, even if your other partitions use other filesystems different than your / partition, you can still include them as modules in your kernel and not built-in to save space (eg. if you use FAT32-formatted USB keys once in a while, but not all the time, the module will only be loaded when you use the USB key and it won't take up space in RAM when you're not using a USB key); it will automatically load the correct modules itself (provided that you have built autoloading of modules into your kernel). Only the root filesystem must be compiled into the kernel to avoid using an initrd.
Looks like duryodhan beat me to it by a mile. Oh well. [/edit]
Many thanks to all who helped with this query. Result : Kernel 18.104.22.168 built, initrd stuff done and suspend function working. Also understand a bit more about the boot process than I did. Just some funny stuff about how the KDE module (Klaptop) controls the power states, but no doubt not too hard to work it out. Thanks again.
Hey that's really cool that you got everything worked out. Thanks for reporting back to let us know how it went for you. I compiled my first kernel just a couple weeks after switching to Slackware and well... let's just say my results were mixed. LoL. Great learning experience though. Sounds like you did a better job than me! I think you'll like the new kernel. It may take some tweaking, but you'll find the acpi implementation in 22.214.171.124 to be much better than in previous kernels.