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: