mimosa wrote:The practical question is that according to the Slackbook, I should back up the old files then copy the new kernel to /boot/vmlinuz, and the new system map to /boot/System.map. Those are symlinks so I presume the effect will be to overwrite the two corresponding files in /boot that I backed up. But what about /boot/config, another symlink to a file in /boot?
From my /boot:
- Code: Select all
lrwxrwxrwx 1 root root 37 Mai 27 2011 README.initrd -> /usr/doc/mkinitrd-1.4.6/README.initrd
lrwxrwxrwx 1 root root 24 Jun 17 2011 System.map -> System.map-huge-2.6.37.6
-rw-r--r-- 1 root root 3015272 Aug 4 2011 System.map-2.6.39.3-ice
-rw-r--r-- 1 root root 2706772 Apr 10 2011 System.map-huge-2.6.37.6
-rw-r--r-- 1 root root 512 Jul 14 2011 boot.0820
-rw-r--r-- 1 root root 312 Jan 22 18:35 boot_message.txt
lrwxrwxrwx 1 root root 20 Jun 17 2011 config -> config-huge-2.6.37.6
-rw-r--r-- 1 root root 117248 Aug 4 2011 config-2.6.39.3-ice
-rw-r--r-- 1 root root 112298 Apr 10 2011 config-huge-2.6.37.6
drwxr-xr-x 5 root root 12288 Feb 28 21:29 grub
-rw-r--r-- 1 root root 308278 Mär 27 2011 salix.bmp
lrwxrwxrwx 1 root root 21 Jun 17 2011 vmlinuz -> vmlinuz-huge-2.6.37.6
-rw-r--r-- 1 root root 5599280 Aug 4 2011 vmlinuz-2.6.39.3-ice
-rw-r--r-- 1 root root 5866144 Apr 10 2011 vmlinuz-huge-2.6.37.6
mimosa wrote:Then I just need to run lilo and reboot, I take it; and if it doesn't work I just put the backed up files back and run lilo again.
I recommend adding an entry for each kernel in your bootloader. That way you don't even need a rescue system or anything to recover. Actually with grub2 you can generate a configfile containing an entry for each kernel automatically. Usefull if switching, building and changing kernels a lot.
mimosa wrote:I did select one or two config options to do with virtualisation, but I don't really understand what they will do
Bad. In this case it shouldn't matter, but the kernel could become unbootable. No more, no less.
Regarding Virtualisation. There are two kinds of options. Those affecting virtualisation capabilities/performance when the kernel is used as host and those when the kernel is running as guest.
I think for all of the first modules are built by default. The latter is disabled, I think, - probably due to overhead - and offers only performance benefit when used as a guest.
mimosa wrote:Will compiling the kernel locally attune it to my unglamorous Intel Atom CPU and make everything run faster?
No, definitely not noticeably. Maybe some irrelevant µs. Only some options and patches like (BFS, BFQ, ...), may offer some noticable performance benefits. (Unless in very special use cases of course. When deploying embedded or other fixed hardware systems you might choose such tweaks too.)
I usually build kernels like this:
- Obtain the kernel-sources, e.g. by copying /usr/src/linux-<ver> to your home
- Patch and configure them as desired (Don't forget to add a local version)
- Build the kernel
- Put the files into /boot (I wrote a script for that purpose)
- Install kernel modules: make modules_install
- Update your bootloader, with grub2 it's as simple as update-grub or grub-mkconfig
The aforementioned script (to be called from the top directory of the kernel source):
- Code: Select all
#!/bin/bash
if [ "$(whoami)" != "root" ]; then
echo "Need root!"
exit
fi
linvercode="$(grep 'LINUX_VERSION_CODE' include/linux/version.h | sed -e 's/.* \([0-9]\+\)/\1/')"
a="$(($linvercode >> 16))"
b="$(($linvercode >> 8 & 255))"
c="$(($linvercode & 255))"
probedver="$a.$b.$c.$(cat .version)"
probedlocalver="$(grep "CONFIG_LOCALVERSION=" .config | sed -e 's/[^"]*"\([^"]*\)"/\1/')"
kernelver=${1:-${probedver}}${probedlocalver}
if [ "$DRY" == "true" ]; then
dry='echo'
fi
$dry cp -v arch/x86/boot/bzImage /boot/vmlinuz-$kernelver
$dry cp -v .config /boot/config-$kernelver
$dry cp -v System.map /boot/System.map-$kernelver