Updating Kernel Using make-kpkg - Not Intuitive ?
[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
Reply to: