Thanks PV! - My apologies for being slower than a snail on a Sunday stroll
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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.
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.
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.