Hi,

I'm normally using slackpkg to keep my machines upgraded (on Slackware stable). Now recently there have been two consecutive kernel upgrades, with all the kernel-* 3.2.29 packages replaced by kernel-* 3.2.45 packages.

On a "normal" machine I don't care if the old kernel-* packages are replaced by the updates. But I'm running a few virtual machines as "build boxes", and I'd like to keep the old and the new kernel installed, to be able to boot on both, in order to build kernel modules for machines still running the 3.2.29 kernel.

In other words, is there a way to make Slackware behave like a RHEL/CentOS machine, where 'yum upgrade' updates all packages except the kernel packages, where new packages are merely installed alongside older versions?

Cheers,

Niki

I'd try to blacklist kernels in /etc/slackpkg/blacklist but when an upgrade shows, install it (kernel+ modules) with installpkg or slackpkg install (neither upgradepkg nor slackpkg upgrade, of course). In addition you will just have to change the stanza in /etc/lilo.conf to give the full path of the old kernel instead of /boot/vmlinuz before running lilo manually. Then I think that you would just have to set the kernel against which you build the new modules as a build option.

OT: I need a proofreader for French translation of Slackware scripts' messages in slint. And I know that you would catch any typo, mistranslation or clumsiness

http://docs.slackware.com/howtos:sla...ystemupgrade?s[]=kernel&s[]=installpkg#considerations_about_the_kernel

Always use installpkg for kernel and kernel-modules. Blacklist them in /etc/slackpkg.conf .

Eric

One trick I use in order to help in not having any upgradepkg accidents with my home-grown kernel packages is to slightly modify the package name so that the version number is included in the package name field and not the version field, i.e.
kernel-3.9.6-custom-none-x86_64-1_local

Doing it this way means I can use "upgradepkg --install-new *" without fear of a new kernel clobbering the old one.

Yeah I can do that. Just send me all the files by mail, Didier.

info@microlinux.fr

Thanks, Eric. According to the documentation, I've been living dangerously until now. I've been using slackpkg upgrade-all to upgrade even the kernel, then hardcoded the kernel version in mkinitrd.conf and rebuilt the initrd before the first reboot.

I'll mark this thread as solved.

I have my kernel packages blacklisted in /etc/slackpkg/blacklist to keep them from being overwritten but there are two instances where I do allow slackpkg to upgrade them for me. Firstly if I have just performed a clean install the first thing I do is update the system anyway and since I haven't yet even switched to the generic kernel I go ahead and let slackpkg upgrade my kernel. It just makes for a more clean and tidy install for me. Secondly, if the upgrade is to the same kernel version like recently... 3.2.45(1) to 3.2.45(2) to 3.2.45(3) I will go ahead and allow slackpkg to upgrade it.

Now this is strange. On a machine running the stock 3.2.29 kernel from the installation disc, I downloaded the updated kernel sources from patches/linux3.2.45 and tried to install them manually using installpkg.

Here's what I get:

Any idea what's going on here?

Partial download perhaps? Check the md5sum and/or signature.

Edit: In fact you should always do that before you install a package you manually downloaded. Slackpkg would have done that but since you aren't using it in this case it is up to you.

1 members found this post helpful.

OK, found the culprit. Wrong md5sum. I re-downloaded the package from another mirror, and everyting worked fine.