[mostly OT, but tangentially on-topic perhaps] I find the procedure for updating the kernel by compiling from Debian source less than intuitive ... even using make-kpkg ...
Every time a kernel security fix gets released, I download the Debian kernel source deb, unpack it, copy over my .config from the old source tree, run "make-kpkg kernel-image" to generate a binary kernel & modules deb, and then dpkg -i to install it. *That's* when things get confusing : =====================< cut >====================== glimmer:/usr/src# dpkg -i kernel-image-2.4.18_10.00.Custom_i386.deb (Reading database ... 68042 files and directories currently installed.) Preparing to replace kernel-image-2.4.18 10.00.Custom (using kernel-image-2.4.18_10.00.Custom_i386.deb) ... You are attempting to install a kernel image (version 2.4.18) However, the directory /lib/modules/2.4.18 still exists. If this directory belongs to a previous kernel-image-2.4.18 package, and if you have deselected some modules, or installed standalone modules packages, this could be bad. However, if this directory exists because you are also installing some stand alone modules right now, and they got unpacked before I did, then this is pretty benign. Unfortunately, I can't tell the difference. If /lib/modules/2.4.18 belongs to a old install of kenel-image-2.4.18, this is your last chance to abort the installation of this kernel image (nothing has been changed yet). If this directory is because of stand alone modules being installed right now, or if it does belong to an older kernel-image-2.4.18 package but you know what you are doing, and if you feel that this image should be installed despite this anomaly, Please answer n to the question. Otherwise, I suggest you move /lib/modules/2.4.18 out of the way, perhaps to /lib/modules/2.4.18.old or something, and then try re-installing this image. Do you want to stop now? [Y/n] =====================< cut >====================== What on earth is this trying to say to me ? I'm doing a _very_ normal and likely kind of kernel installation : there's been a kernel security bulletin, I've recompiled the kernel without changing a single aspect of the config (so there shouldn't be any differences in module disposition) - and yet make-kpkg/dpkg doesn't seem to cater for me at all. The set of modules is only really likely to change if I change some hardware in my PC - less likely than the publishing of a kernel security bulletin in my case [:-(] Instead of "If /lib/modules/2.4.18 belongs to a old install of kenel-image-2.4.18, this is your last chance to abort the installation of this kernel image" how about "If /lib/modules/2.4.18 belongs to a old install of kenel-image-2.4.18, you should stop this installation now, move the directory out of the way, and then rerun this command" or even: just do the moving-out-of-the-way for me, without bothering me - duh. I thought make-kpkg was supposed to be a convenience command. [I suspect that the make-kpkg --revision parameter may help here, but I confess I only barely comprehend the advice on revision numbers in /usr/share/doc/kernel-package/README.gz. When I have an urgent need to fix my kernel due to a serious security hole, the last thing I need is to have to spend 3 hours failing to understand the instructions.] It gets worse : =====================< cut >====================== Do you want to stop now? [Y/n]n Unpacking replacement kernel-image-2.4.18 ... Setting up kernel-image-2.4.18 (10.00.Custom) ... You are attempting to install a kernel version that is the same as the version you are currently running (version 2.4.18) .......... =====================< cut >====================== Yes ! *The* single most likely case, wouldn't you think ? =====================< cut >====================== ...... The modules list is quite likely to have been changed, ....... =====================< cut >====================== Er .. no, not _likely_ at all .... slightly possible though ... =====================< cut >====================== ...... and the modules dependency file /lib/modules/2.4.18/modules.dep needs to be re-built. It can not be built correctly right now, since the module list for the running kernel are likely to be different from the kernel installed. I am creating a new modules.dep file, but that may not be correct. It shall be regenerated correctly at next reboot. I repeat: you have to reboot in order for the modules file to be created correctly. Until you reboot, it may be impossible to load some modules. Reboot as soon as this install is finished (Do not reboot right now, since you may not be able to boot back up until installation is over, but boot immediately after). I can not stress that too much. You need to reboot soon. Please Hit return to continue. =====================< cut >====================== Good grief ! Just tell me that my system may behave unpredictably until the system has been rebooted ... It's a weird mixture of advice for the terminally stupid, and advice for the kernel super-guru : "Reboot as soon as this install is finished (Do not reboot right now, since you may not be able to boot back up until installation is over, but boot immediately after)" Indeed. I realise this post is mostly off-topic on debian-security, so if anyone can advise me of a better forum for my observation I'd be grateful. debian-user ? debian-dpkg ? Maybe a usability bug filed against make-kpkg ? Or maybe I'm missing some point, and the above comments belong in the trash. Comments/flames welcome. Cheers Nick Boyce Bristol, UK -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
