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

Re: naming kernel images (potato)



>>>>> "BC" == Ben Collins <bcollins@debian.org> writes:
    BC>  On Sat, Jun 03, 2000 at 12:37:11PM -0700, Pann McCuaig wrote:
    >> Whenever I've built a kernel I've used the following syntax:
    >> 
    >> # make-kpkg --rev tux.1.0 kernel_image
    >> 
    >> where "tux" identifies the machine to me and "1.0" identifies
    >> which of my revisions of the kernel I'm dealing with.
    >> 
    >> I install the resulting kernel-image-...-.deb with dpkg -i.
    >> 
    >> I recently upgraded a box to potato, grabbed the source for
    >> kernel-2.2.15, and built and installed a kernel. No worries.
    >> 
    >> But,
    >> 
    >> # apt-get update ; apt-get -s upgrade
    >> 
    >> offered to upgrade kernel-image-2.2.15 for me.  :-(
    >> 
    >> I definitely don't want that to happen. It's never happened
    >> before under slink, hamm, bo, or rex that I recall.
    >> 
    >> Deep in the vague recesses of my memory I seem to recall an issue
    >> similar to this being discussed, with a suggestion for naming
    >> kernel images to avoid the problem.
    BC>  try...
    BC> 
    BC> # make-kpkg --rev 3:tux.1.0 kernel-image
    BC> 
    BC> The 3 is an epoch (not sure that kernel-package will let you use
    BC> them, but give it a try). The epoch will override other versions
    BC> of a lower epoch even if the rest of the version is higher.
    BC> 

The epochs do work. I had the same problem yesterday when I noticed that
apt wanted to upgrade my custom kernel. So I let the upgrade proceed,
and didn't reboot. I then recompiled my custom kernel using:

make-kpkg --revision=786:phoenix-custom-2.2.15-1.0 kernel_image

Since then, dpkg/apt haven't upgraded my kernel.

-- 
Salman Ahmed
ssahmed AT pathcom DOT com



Reply to: