I have just made the much belated discovery that ever since the pi kernel (Fri Aug 8 19:02:50 UTC 2014), the doinst.sh in the kernel-generic package has been creating a symlink 'ln -sf vmlinuz-generic-<version> vmlinuz-generic'.

Doh - As a slackpkg, lilo and generic kernel user, after every kernel upgrade since I have still being telling slackpkg No to running lilo after a kernel update, then editing /etc/lilo.conf so that the 'image=' pointed to the new generic kernel image before running lilo manually.
Changing /etc/lilo.conf so that 'image=/boot/vmlinuz-generic' will save that editing step.
Combined with my custom slackpkg function http://www.linuxquestions.org/questi...ml#post4957315 my kernel upgrades suddenly got a whole lot simpler and less error prone.

Much appreciated!

Yep, small changes like this can make all the difference.

I'm still not keen on the fact that both the 'huge' and 'generic' packages will try and create the vmlinuz -> vmlinuz-$KERNNAME.$VERSION symlink, thus making order of installation significant and potentially overwriting it should the admin have pointed it at something else, but that issue can be worked around by simply never using it (assuming you're aware of the potential gotcha in the first place).

I still do it manually - never knew. Maybe I'll still do it manually so I never forget.

1 members found this post helpful.

I guess it is convention that vmlinuz exists in /boot. If the admin wanted to point to that (rather than a specific kernel package), and had both installed, then the thing to do would be to blacklist the other package. Otherwise, if someone was wanting vmlinuz-generic, and did a package update for both, and rerun lilo, they'd get vmlinuz-huge on the next boot. (through the vmlinuz pointer last update) Doesn't seem like a good idea Probably should remove the other package and just have one kernel.

I just have the kernel-huge, kernel-huge-smp, kernel-generic-smp and kernel-modules-smp blacklisted in /etc/slackpkg/blacklist on my 64bit setup so that I only get the kernel-generic packages during an upgrade conducted with slackpkg. Works for me.

This is a bizarre timing for your comment (and this whole thread), I discovered this very thing like two days ago.

I use the symlinked kernel method for Grub and it does save you the trouble of rerunning Grub when you update anything kernel-wise.

Yea, I do all my lilo stanzas manually and never rely on the symlink after the initial install.

It seems like everytime I relax my iron grip on such things and rely on the conveniences it comes back to bite and confuse me - mostly confuse!

1 members found this post helpful.

Are these kernel updates in the current tree? I haven't seen any new kernels in the patches for 14.1.

On 32-bit, does anyone else find it strange that "smp" appears in both the package name and the version? This shows up in the package name and in the files installed to /boot. Does putting "smp" in the version serve some kind of purpose I'm not aware of?

elyk,
Pretty sure the "smp" (for symmetric multiprocessing) is simply there as a label.
So that you know what's in the tin ;-)

Right, but why is it there twice?

kernel-generic-smp-3.10.17_smp-i686-3

/boot/System.map-generic-smp-3.10.17-smp
/boot/config-generic-smp-3.10.17-smp
/boot/vmlinuz-generic-smp-3.10.17-smp

My guess: if it was named kernel-generic-3.10.17_smp-i686-3, it would conflict with kernel-generic-3.10.17-i486-3, or is at least easier to manage (package managers, SlackBuilds etc.). I think the smp LOCALVERSION is there so that you know you're running a smp kernel when doing uname -a or so.

1 members found this post helpful.

edit: I'm rewriting this post as I kind of went tangential first time.

On 32bit there are essentially 4 kernels: generic, huge, generic-smp and huge-smp.

The generic and huge kernels share their modules, which means they must share a LOCALVERSION string. The LOCALVERSION for these is "" (i.e. blank)

The generic-smp and huge-smp also share their modules which means they must share a LOCALVERSION string. The LOCALVERSION string for these is "-smp"

Kernel image files are named following this:
vmlinuz-${KERNNAME}-${VERSION}${LOCALVERSION}
The modules in lib modules also use $LOCALVERSION
/lib/modules/${VERSION}${LOCALVERSION}

This is why it looks like you have redundant information in the naming, but its not. (Except on the package file version field, where _smp really is unnecessary, but that's just cosmetic).

Personally, I've always found the sharing of modules a little funky, but it seems to work for Pat (albeit resulting in the unusual naming we see). I use a different naming scheme for my locally built kernel packages:
kernel-3.18.y-3.18.7-x86_64-1_local
If I use LOCALVERSION it gets appended to the packagename (right after the .y)

Under my scheme you'd end up with:
kernel-3.18.y-generic-smp-3.18.7-x86_64-1_local: /boot/vmlinuz-3.18.7-generic-smp /lib/modules/3.18.7-generic-smp
kernel-3.18.y-generic-3.18.7-x86_64-1_local: /boot/vmlinuz-3.18.7-generic /lib/modules/3.18.7-generic
kernel-3.18.y-huge-smp-3.18.7-x86_64-1_local: /boot/vmlinuz-3.18.7-huge-smp /lib/modules/3.18.7-huge-smp
kernel-3.18.y-huge-3.18.7-x86_64-1_local: /boot/vmlinuz-3.18.7-huge /lib/modules/3.18.7-huge

which looks cleaner, but wouldn't be able to share the modules like Pat chooses to do (but then if it were me, I'd not bother with both a huge and generic kernel anyway, so it wouldn't be an issue for me).

(that post made more sense this time )

3 members found this post helpful.

So - if lilo is ran by Slackpkg after a kernel upgrade, one would still have to rebuild the initrd and run lilo again, right?

I'm still going to do it manually. That will save me from going all potty-mouthed while I'm booting from the dvd to save me from myself.

1 members found this post helpful.