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.
Yes, after noting that /lib/modules/$(uname -r)/source and /lib/modules/$(uname -r)/build are symlinks to /usr/src/$(uname -r)/
I was wondering the same thing: i.e. whether I could reinstall VMWare and maybe somehow override /usr/include/linux/ with /usr/src/$(uname -r)/include/ ...
As far as I know, I've never encountered any issues with upgrading the kernel headers without recompiling glibc. I'd be interested to hear if anyone ever has, and under what circumstances.
There's also the option to create a .config based on your system. When you make -localmodconfig the running modules on your system are used as basis for the config. This way you get a streamlined kernel with only support for hardware you have. Before you do this you must make sure you've connected everything you'll need (like USB sticks/external drives with filesystems you use, your webcam, everything you use needs to be there or it won't be included. You even need a DVD/CD in your drive or it won't work.). This greatly reduces the compile time. Since you leave out everything you don't need.
commit 63db7c91a3c0ebe0e291feea53e4c63391db9465
Author: Kees Cook <keescook@chromium.org>
Date: Tue Jan 24 15:18:24 2017 -0800
fbdev: color map copying bounds checking
commit 2dc705a9930b4806250fbf5a76e55266e59389f2 upstream.
Copying color maps to userspace doesn't check the value of to->start,
which will cause kernel heap buffer OOB read due to signedness wraps.
CVE-2016-8405
Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Peter Pi (@heisecode) of Trend Micro
Cc: Min Chong <mchong@google.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
4.9.5 with LiveSlack 1.1.5 being used since 1/25/2017 without problems. Installed all pkgs including the headers and have not had any problems slackbuilding other packages. Don't know if that helps answer the question about installing the headers, but just a status report of using all dave's packages.
(Pat highly suggests running generic kernels over huge and only provides huge as a starting point.)
This intrigues me, because I've been using only the huge kernel with Slackware since 1996. It's worked okay so far, but am I incurring a risk? What is the reasoning for preferring generic?
Distribution: Slackware64-current with "True Multilib."
Posts: 8,415
Original Poster
Rep:
With older hardware the generic kernel, along with the initrd, provides, IMHO, a noticeable performance improvement. With more "modern," as in faster, processors you may not even notice the difference between running the huge kernel vs. the generic.
Last edited by cwizardone; 02-06-2017 at 05:18 AM.
This intrigues me, because I've been using only the huge kernel with Slackware since 1996. It's worked okay so far, but am I incurring a risk? What is the reasoning for preferring generic?
I'm not positive why he recommends that, but I imagine it is similar to what cwizardone mentioned... mainly a slight savings in resources/boot time.
But, Pat's official words can be found in the CHANGES_AND_HINTS.TXT file on your favorite mirror. He requests people to not report bugs unless they can reproduce it on a generic kernel.
Code:
Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock
generic kernels. You will need to create an initrd in order to boot
the generic kernels - see /boot/README.initrd for instructions.
The huge kernels are primarily intended as "installer" and "emergency"
kernels in case you forget to make an initrd. For most systems, you
should use the generic SMP kernel if it will run, even if your system is
not SMP-capable. Some newer hardware needs the local APIC enabled in the
SMP kernel, and theoretically there should not be a performance penalty
with using the SMP-capable kernel on a uniprocessor machine, as the SMP
kernel tests for this and makes necessary adjustments. Furthermore, the
kernel sources shipped with Slackware are configured for SMP usage, so you
won't have to modify those to build external modules (such as NVidia or
ATI proprietary drivers) if you use the SMP kernel.
This intrigues me, because I've been using only the huge kernel with Slackware since 1996. It's worked okay so far, but am I incurring a risk? What is the reasoning for preferring generic?
Quote:
Originally Posted by bassmadrigal
But, Pat's official words can be found in the CHANGES_AND_HINTS.TXT file on your favorite mirror. He requests people to not report bugs unless they can reproduce it on a generic kernel.
Code:
Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock
generic kernels.<snip>
I think that you are both right.
There is generally no issue running a huge kernel. In some cases though this can cause an issue. This could be the case if two kernel drivers claim the same device (this device being selected because it matches a glob that would be e.g. found in the output of "modinfo <module>|grep ^alias:" in case of a module) and the driver that takes over the device is not the "good" one.
If you use a generic kernel you can blacklist one of the drivers and see what happens. That is not possible if the drivers are built in, making difficult to analyze and solve the problem in that case.
So my understanding is : in most cases running a huge kernel is fine, but use a generic kernel if need be. "If need be" includes but is not limited to issues that could be linked to conflicting or "not the good one" kernel drivers, and configurations that need an initrd, like including encrypted partitions.
Last edited by Didier Spaier; 02-06-2017 at 02:03 PM.
Reason: s/handover/takes over/ Why may we not write in French #~à@!???
I did some testing here. For me, the huge kernel boots about 3 to 4 seconds (not significantly) faster than the generic kernel. Considering that, I decided not to get into the hassle of initrd construction after kernel upgrades
(>5 year old desktop, intel core 5, nvidia, off the shelf sata drive, slackware current)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.