Thanks PV! - My apologies for being slower than a snail on a Sunday stroll

allend · 03-09-2015, 06:43 AM

Quote:

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

Yes - unless you use the slackpkg custom function I linked in post #1.
That was the point of my initial post. Upgrading a system running the generic kernel can now be handled by slackpkg with prompts to update initrd and to run lilo without any additional manual steps.

fogpipe · 03-09-2015, 04:29 PM

Quote:

Originally Posted by mlangdn

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

I always do it manually too. I have been burned by kernel install scripts, never on slackware, but on other distros, and dont trust them.
If i see a kernel upgrade listed in slackpkg, i back up my lilo.conf, /lib/modules dir and kernel source dir before continuing and then usually immediately rebuild the kernell to my liking right after its first boot.

bassmadrigal · 03-09-2015, 04:41 PM

Quote:

Originally Posted by fogpipe

If i see a kernel upgrade listed in slackpkg, i back up my lilo.conf, /lib/modules dir and kernel source dir before continuing and then usually immediately rebuild the kernell to my liking right after its first boot.

Out of curiosity, wouldn't it be easier to just download the .config Pat provides for the newer kernel and then grab the source yourself and build it that way? Seems like it would remove the unnecessary step of installing a package containing a kernel you have no intention of using.

For me, kernels are pretty much the only thing that I'll build outside of Slackware's package management. Right now, I'm running 3.18.8 and I have several older kernels that I used after upgrading the stock 3.10.17.

fogpipe · 03-09-2015, 04:53 PM

Quote:

Originally Posted by bassmadrigal

Out of curiosity, wouldn't it be easier to just download the .config Pat provides for the newer kernel and then grab the source yourself and build it that way? Seems like it would remove the unnecessary step of installing a package containing a kernel you have no intention of using.

I like booting to its default config to get a good look and its easy enough to just install the new kernel and reboot to do that. I also like having the default kernel installed, with its default config, as a back up and baseline.
Maybe ill give your method some thought tho.
Also, i have put some time into the .config im currently using and the source downloads through slackpkg just as well as it would from kernel.org.

elyk · 03-09-2015, 08:52 PM

Quote:

Originally Posted by GazL

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

Ah, that's the part I'm missing. Thanks! I usually go with something like vmlinuz${LOCALVERSION}-${VERSION} for my naming scheme and was wondering why not just set LOCALVERSION to "-generic-smp".

Quote:

Originally Posted by GazL

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).

Well, it is still redundant on the /boot files since KERNNAME includes LOCALVERSION, right? Every time I go edit lilo.conf and type "smp" twice, I ask myself why I'm typing it twice

GazL · 03-10-2015, 04:36 AM

Quote:

Originally Posted by elyk

Ah, that's the part I'm missing. Thanks! I usually go with something like vmlinuz${LOCALVERSION}-${VERSION} for my naming scheme and was wondering why not just set LOCALVERSION to "-generic-smp".

I prefer vmlinuz-${VERSION}${LOCALVERSION} because that is how the modules directory gets named and it keeps it all consistent. My scheme results in packages looking like this:

Code:

PACKAGE NAME:     kernel-3.18.y-3.18.9-x86_64-1_local
COMPRESSED PACKAGE SIZE:     32M
UNCOMPRESSED PACKAGE SIZE:     136M
PACKAGE LOCATION: ./kernel-3.18.y-3.18.9-x86_64-1_local.txz
PACKAGE DESCRIPTION:
kernel-3.18.y: Kernel 3.18.9
kernel-3.18.y:
kernel-3.18.y: This is an all-in-one package that contains
kernel-3.18.y: a linux kernel, its modules and its build directory.
kernel-3.18.y:
kernel-3.18.y: Package includes:
kernel-3.18.y:   /boot/vmlinuz-3.18.9
kernel-3.18.y:   /boot/System.map-3.18.9
kernel-3.18.y:   /lib/modules/3.18.9/...
kernel-3.18.y:   /usr/obj/3.18.9/...
kernel-3.18.y:

LOCALVERSION if used would go on the end of the version on all 4 files/locations, and after the .y on the package name.
/usr/obj is non-standard and allows me to build and package a kernel with read-only sources by using an out of tree build directory.

Quote:

Originally Posted by elyk

Well, it is still redundant on the /boot files since KERNNAME includes LOCALVERSION, right? Every time I go edit lilo.conf and type "smp" twice, I ask myself why I'm typing it twice

Yes, on reflection you're quite right, that bit could go without causing a collision as LOCALVERSION will still differentiate them. Guess I wasn't thinking straight.