Thanks GazL
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/ ... However, that's for another day :) -- kjh |
55020, thanks a lot for config-4.9!
Since you provide kernel-headers-4.9, I'd like to ask: does it mean that you suggest to install it? I know the standard view that Quote:
On the other hand: Quote:
|
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.
|
Mainline kernel 4.10-rc6 has been released for testing,
https://www.kernel.org/ It is the biggest release candidate of the 4.10 series to date. http://news.softpedia.com/news/linus...r-512353.shtml |
v4.9.7 and v4.4.46 are out.
|
Thanks GazL.
4.4.46 includes another CVE fix. -- kjh Code:
commit 63db7c91a3c0ebe0e291feea53e4c63391db9465 |
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.
|
Kernels 4.4.47 and 4.9.8
|
Wow, that was quick. I didn't even notice those go through 'review'. Thanks for the heads-up.
|
|
Quote:
|
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.
:twocents: |
Quote:
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 |
Quote:
Quote:
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. |
huge vs. generic
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) Obviously, this is only a tiny test... Have a nice day Franz |
All times are GMT -5. The time now is 04:08 AM. |