[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bigmem kernel



On Fri, 5 Mar 2010 09:54:00 -0500 (EST), Marc Auslander wrote:
> I am confused by this and the other explainations.
>
> To be clear - I am only concerned about the vmlinuz symlink.  I know
> package management works.
>
> When I installed bigmen, it swung vmlinuz to the newly installed
> kernel, just as every other kernel install/update I've done has.
>
> So what happens if the normal kernel package is updated.  I fear the
> update would swing vmlinuz to the latest version of the normal
> kernel.  If this is not going to happen, what rule would prevent it?

To be honest, I'm really not sure if a security update, new stable
point release, etc. upgrades a kernel what will happen to the
symlinks.  Since both the standard kernel and the bigmem kernel
are stock kernels, chances are that security updates will affect
both of them at once.  There are several alternatives you can choose
from.  One is to de-install the standard kernel with

   aptitude purge linux-image-<whatever>

Leaving only the bigmem kernel.
You should then manually examine the symlinks afterwards, make sure
that they are correct, and then, for good measure, run your boot
loader.  If there is only one kernel, it can't pick the wrong one.  :-)
Besides, it saves disk space.

Another choice is to manually inspect the symlinks every time
any kernel is updated to make sure that they are the way you want
them.  Another choice is to edit /etc/kernel-img.conf and set
"do_symlinks=no".  This will keep the maintenance scripts from
updating symlinks.  But of course, if you should intentionally
install a different kernel later, you will have to update the
symlinks by hand and re-run the boot loader.  If you have
installed a hook script in /etc/kernel/postinst.d or
/etc/kernel/postrm.d to maintain symlinks, these are not
affected by the setting in /etc/kernel-img.conf and will still
be run.


Reply to: