This guide is meant to provide a basis for compiling the Linux kernel, whether the latest stable kernel from the Debian Stretch Repositories, or any kernel listed in the Linux Kernel Archives. https://www.kernel.org/
There are currently 12 sections:
Dependencies.
Compiling the Debian stable kernel source from the repository.
Compiling the Linux Kernel Source fro the Linux Kernel Archives.
Initial Configuration and Install.
After boot.
Dual booting.
Configuration.
Scaling Drivers and Governors.
IO Schedulers/enabling BFQ.
Patches
Ideas to get you started.
Links.
Why compile your own kernel?
Both the Linux Kernel Archives, and the Debian repositories (though a version or two behind), offer the latest Linux kernels, fully patched with the newest security measures. This includes support for the dreaded spectre and meltdown problems of late, as well as new and exciting features, and fixes for older drivers. So, if you:
Want the latest in Linux kernel security features, both new and revised.
Have hardware that is currently unsupported and would like to activate/install certain drivers.
Need to deactivate an item that is causing conflicts.
Want to remove as much cruft as possible for speed and size.
Want to learn about what controls both your computer and software at the kernel level.
Like to tinker and explore. You will not get bored.
Like having absolute control over your system.
NOTE* Compiling and installing a kernel will not, in itself, cause any issues or damage. If your new kernel if corrupted, it either will not boot, or will quickly show if there is a problem after boot.
If you do have a problem, simply boot into your previous kernel and remove the offending version using apt-get remove --purge linux-Image-<version> linux-headers-<version>.</version></version>
***Dependencies
In order to compile your new kernel, some development programs need to be downloaded and installed:
***Compiling the Debian stable kernel from the repositories
Is there any reason to use the Debian kernel source v.s. the Linux kernel source?
Maybe. This will depend on your needs. Debian kernel security patches come from the upstream Linux Kernel, and are applied on a regular basis in order to be fully up to date with the very latest security from the upstream source.
However, Debian may apply other patches that allow certain Debian packages to work better within the existing Debian framework.
Mostly this applies to "out of tree" modules/drivers that Debian is implementing for different architectures. What affect this has on the end user depends on several factors, including architecture, programs used, transition of Debian versions from testing to stable, etc . . For MOST daily use, the upstream source from the Linux Kernel Archives can certainly be used.
To get the Debian kernel source at the current maximum patch level, you will need to install the Debian kernel source package using apt.
NOTE* SCROLL down a bit to skip to the Linux Kernel Archives section.
First find out what the latest kernel source package is by using apt-cache:
apt-cache search linux-source
Here is the example output from the code above:
apt-cache search linux-source
linux-source-4.19 - Linux kernel source for version 4.19 with Debian patches
linux-source - Linux kernel source (meta-package)
linux-source-5.4 - Linux kernel source for version 5.4 with Debian patches
linux-source-5.5 - Linux kernel source for version 5.5 with Debian patches
linux-source-5.6 - Linux kernel source for version 5.6 with Debian patches
linux-source-5.7 - Linux kernel source for version 5.7 with Debian patches
Decide which version you would like to work with:
sudo apt install linux-source-4.19
The Debian kernel source will install to /usr/src. We do not want or need to work on it from /usr/src. Working on the kernel from your home directory makes for a safer environment.
Make a folder in your home directory where you will be working:
mkdir ~/kernels
Now move the downloaded source to your new kernel directory (Use the correct version number):
You shouldn't need to change permissions on the resultant file as it is being extracted in $HOME, but if so:
sudo chmod -R 755 ~/kernels/linux-source-4.19
You should then remove the source paths/tree in /usr/src after moving the file to ~/kernels. This will keep /usr/src from getting cluttered up with different sources.
Remove the cruft left behind when you moved the source to ~/kernels:
-- From this point, please scroll down to Initial Configuration and Install --
***Compiling the Linux kernel from the Linux Kernel Archives
Simply download any available image you would like to compile from the Linux Kernel Archives. The only caveat here may be to use the version closest to your current kernel. This will ensure that the resultant initial changes will be small: https://www.kernel.org/
Make a directory in /home to work from:
mkdir kernels
Change your working directory to ~/kernels:
cd kernels
Place your source tarball into ~/kernels and extract using:
tar xaf linux-source-4.19.140.tar.xz
***Initial Configuration and Install
Once extracted, change directories and/or open a terminal in the resultant folder. (linux-source-4.19.140)
We need to clean up any files that may have been altered prior to release and make sure the kernel source tree is completely clean:
make clean && make mrproper
Next we open the configuration file (.config) that will instruct the compiler on what to add or leave out depending on your choices. The first code we run will sync all the items between kernel releases, removing and adding items as necessary.
make oldconfig
Make oldconfig uses the existing kernel configuration on your system to determine the default settings applied during distribution install. Make oldconfig only needs to be done (and should be) at the change of the major kernel release number, i.e. from 4.15 to 4.16.
Accept all of the defaults by hitting enter repeatedly (just hold it down), or look through them if you want. It's quite a list. The defaults are meant to protect the user. Nothing should be automatically turned on unless it has been deemed necessary and safe. The number of changed items between releases is generally under 20 or so, but the initial list could be a few hundred items if there are large separations between versions.
When you get to the end, save the file. This takes place in the main terminal window, no other "settings" window appears until running "make menuconfig", or one of the other options.
NOTE* IF you now want to compile a kernel specifically for your hardware/setup, you can use "make localmodconfig" You MUST plug in any usb's, cards, printers, et,al if you want the drivers to be automatically picked up. This actually works really well, and will remove loads of junk you dont need.
After running "make oldconfig", and possibly "make localmodconfig" then open menuconfig, which will be the goto from now on, as it collects your current kernel settings each time:
make menuconfig
This window will present you with a full menu to change the huge number of options the kernel contains. I have made up a list of some of the most common changes later in this guide, but for now:
Under General setup —> find, Local version – append to kernel release
click on Local version – append to kernel release, and type in 1.
For each new compilation, change the number sequentially to keep things a bit more orderly.
Compiling at this point is advised, so you will know the first kernel will work without issue. Other changes should be made on a subsequent compile.
Next, compile the kernel image and headers. There are other files created as well that can be ignored if you want, but may be useful.
Make the kernel with:
make deb-pkg
Or, if you have a dual-core processor:
make -j3 deb-pkg
Compilation can take anywhere from ten minutes to two hours depending on hardware and kernel configuration. You don't need a fancy computer to compile, it's just a longer wait. The configuration file is stored in the Linux kernel folder as .config. Show hidden files in your file manager to see it.
NOTE* If your kernel fails to compile, and you have not yet tried "make localmodconfig", give it a go as it may solve your compile problem.
When the compile is finished, cd to ~/kernels and install the kernel image, and kernel headers using:
sudo dpkg -i linux-image.xyz linux-headers.xyz where xyz = version number..
In order to make things easier, you should use tab-completion in the terminal.
Dpkg will automatically update your initramfs and grub menu after installation.
Reboot into your new kernel!
***After Boot
To see what happens with the Linux kernel on boot, and possibly address errors, in a terminal:
To see your currently running kernel:
uname -r
To see boot speed:
systemd-analyze
To get a read out of the kernel boot process.
dmesg
Similar to dmesg, through systemd:
sudo journalctl -b
If you want to know what drivers you are currently using:
lspci -k
If you believe you may have a failed driver:
dmesg | grep failed
To find the size of your currently running kernel, uname -r to get the version, then use the version number to find out running kernel size. I'm using kernel version 4.17.01:
ls -lha /boot | grep 4.17.01
And here is the output:
-rw-r--r-- 1 root root 103K Jun 7 13:02 config-4.17.01
-rw-r--r-- 1 root root 6.4M Jun 7 16:51 initrd.img-4.17.01
-rw-r--r-- 1 root root 1.8M Jun 7 13:02 System.map-4.17.01
-rw-r--r-- 1 root root 3.6M Jun 7 13:02 vmlinuz-4.17.01
The main changes in the kernel size from recompiling will be the initrd.img, shown here at 6.4 mb.
To get a complete list of your computers hardware, from the menu, open accessories --> System Information. The program Hardinfo comes installed with BunsenLabs and is an excellent tool to retrieve information.
There are links at the bottom of the post that can provide good information on the items found in the kernel.
***Dual-booting
If you choose to dual-boot, and BunsenLabs is not your core distribution, you will need to boot into the distribution that installed grub to the mbr.
Then:
sudo update-grub
to have BunsenLabs show in the grub boot menu.
This also goes for those that are not currently dual booting, but would like to give it a go. Grub automatically adds and updates the boot menu for all partitions. This means you can avoid installing grub altogether in the second distribution. After install, boot into the distribution that installed grub to the mbr, and update-grub.
Another way to add another distribution to the Grub boot menu, is by placing the below into /etc/grub.d/40_custom. In this example, I am dual booting with antiX as my second distribution on sda5.
menuentry 'Antix' {
set root=(hd0,5)
linux /vmlinuz root=/dev/sda5 ro quiet
initrd /initrd.img
}
*NOTE - You can add any other kernel parameters after quiet if required. (example - scsi_mod.use_blk_mq=1 if using bfq in the other distro.)
Then:
update-grub
If you want, you can replace; root=/dev/sda5, with root=UUID=$12345uuid... where $12345uuid... IS the actual UUID of /dev/sda5. This method may be more reliable, as fewer errors can develop from improper partition naming.
Yet one more way, and my preferred method, is with chainloading. This snippet is also placed in /etc/grub.d/40_custom. What it does is place a final menu entry that open the grub screen of the other distro. In this example, I am booting "Patience" on sda5:
One of the first things to do, is set up a way to see the differences in the configuration (.config) files between builds. This is important for keeping track of changes through the different builds you will be making. Sometimes you may only want to change one or two items in the configuration file, and having a way to keep track of these changes is important.
The easiest way is with the "diffconfig" utility that is found in your kernel source folder in /scripts/diffconfig. Copy this executable to ~/bin, make a folder in /home to compare the .config files, and call diffconfig with:
diffconfig .config1 .config2
Once you have opened menuconfig to start your custom configuration, the directions on navigating the menus appear at the top.
In particular, one should note / and SHIFT+/
Pressing / will give you a search box useful for finding drivers and other configuration options, while SHIFT+/ while an item is highlighted, will give the description of the item, it's current state, and other dependencies and reverse dependencies necessary to function.
For example, here is the description obtained by pressing SHIFT + / while in:
General setup ---> uselib syscall.
Here is the description:
CONFIG_USELIB: │
│ │
│ This option enables the uselib syscall, a system call used in the │
│ dynamic linker from libc5 and earlier. glibc does not use this │
│ system call. If you intend to run programs built on libc5 or │
│ earlier, you may need to enable this syscall. Current systems │
│ running glibc can safely disable this. │
│ │
│ Symbol: USELIB [=n] │
│ Type : bool │
│ Prompt: uselib syscall │
│ Location: │
│ -> General setup │
│ Defined at init/Kconfig:284
As you can see, I have it disabled as it is no longer necessary in the kernel.
Pressing the space bar will change the selected items status and the arrow keys move you through the lists, and through the items listed at the bottom of the display.
A surprising number of different options are available to '"pre-configure" your kernel. Here they are:
config
Updates the current kernel configuration by using a line-oriented program.
menuconfig - Used for this guide, and my default goto.
Updates the current kernel configuration by using a text based menu program.
xconfig - Many prefer this over menuconfig.
Updates the current kernel configuration by using a QT-based graphical program.
gconfig
Updates the current kernel configuration by using a GTK+-based graphical program.
oldconfig
Updates the current kernel configuration by using the current .config file and prompting for any new options that have been added to the kernel.
silentoldconfig
Just like oldconfig, but prints nothing to the screen except when a question needs to be answered.
randconfig
Generates a new kernel configuration with random answers to all of the different options.
defconfig
Generates a new kernel configuration with the default answer being used for all options. The default values are taken from a file located in the arch/$ARCH/defconfig file, where $ARCH refers to the specific architecture for which the kernel is being built.
allmodconfig
Generates a new kernel configuration in which modules are enabled whenever possible.
allyesconfig
Generates a new kernel configuration with all options set to yes.
allnoconfig
Generates a new kernel configuration with all options set to no.
localmodconfig
Generates a new kernel configuration using only the computers values. This requires
every device you want to have function in the new kernel, connected to the computer
and engaged during the 'make localmodconfig' command.
This means having a disk in the drive, A usb in one of the ports,
printer plugged in and on, internet engaged, and any other devices you can think of.
This is not as hard as it sounds, and can be quite rewarding.
The kernel will be reduced in size considerably, and performing 'make menuconfig' afterwards
will show you all the changes.
Note that the allyesconfig, allmodconfig, allnoconfig, and randconfig targets also take advantage of the environment variable KCONFIG_ALLCONFIG. If that variable points to a file, that file will be used as a list of configuration values that you require to be set to a specific value. In other words, the file overrides the normal behavior of the make targets.
You will also want to find out the information about your processors. The following codes will show the info you need:
less /proc/cpuinfo
grep flags /proc/cpuinfo
dmidecode -t processor
For even better information, download a simple programs:
sudo apt install cpuid
Then try:
cpuid | less
For more information:http://archive.oreilly.com/pub/a/linux/excerpts/9780596100797/kernel-build-command-line-reference.html
***Scaling Drivers and Governors
To find out whether you are currently using the pstates driver or the acpi-cpufrq driver:
For all of the above info, plus current running frequencies:
cpufreq-info
The results of which will look something like:
cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 1.20 GHz - 2.10 GHz
available frequency steps: 2.10 GHz, 1.60 GHz, 1.20 GHz
available cpufreq governors: ondemand, performance, schedutil
current policy: frequency should be within 1.20 GHz and 2.10 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.75 GHz.
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 10.0 us.
hardware limits: 1.20 GHz - 2.10 GHz
available frequency steps: 2.10 GHz, 1.60 GHz, 1.20 GHz
available cpufreq governors: ondemand, performance, schedutil
current policy: frequency should be within 1.20 GHz and 2.10 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.28 GHz.
The pstates information below was taken from - The Linux kernel user’s and administrator’s guide on pstates. (link below).
The Linux kernel supports a scaling subsystem that consists of three layers. The core, scaling governors, and scaling drivers.
The majority of modern processors are capable of operating in a number of different clock frequency and voltage configurations, often referred to as Operating Performance Points or pstates.
Scaling drivers talk to the hardware. They provide scaling governors with information on the available pstates (or pstate ranges in some cases), and access hardware interfaces to change pstates as requested by the scaling governor used.
Governors are basically scaling algorithms for one of two scaling drivers; The Intel pstates driver, and the acpi-cpufreq driver.
With the pstate driver, there are only two available governors, Performance and Powersave.
The default pstate governor, depends on the .config option -- CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE , with the Performance governor being the default.
If you are using acpi-cpufreq as your scaling driver, all of the Governors are used as they traditionally have, before the pstates driver was introduced to the Linux Kernel.
There are currently 6 governors that come with the Linux kernel without patching.
Note, People have reported mixed results with pstates. If you are having issues, you may want to disable the pstates driver and use acpi-cpufreq instead. Also, try different scaling governors for your specific needs.
If you want to disable pstates and use acpi-cpufreq as your scaling driver, then add this at boot time.
intel_pstate=disable
When using the acpi-cpufreq scaling driver, the only two governors I personally would consider for desktop/laptop use, are Ondemand, and Schedutil. That being said, I am also not worried about my battery, and this could/should be considered when making a selection
The Schedutil governor will probably become the default goto in the future.
If you would like more local information from our forum about the Ondemand settings and how to use them:
Adjusting some of the settings in the ondemand governor, babble style!
The CFQ IO Scheduler comes default on most Linux distributions, and is a fine choice for those who do common tasks like email, web surfing, documents, etc . . If however, you also do video editing, kernel compiling, and other load intensive operations, you may want to consider the BFQ IO Scheduler, which no longer needs to be patched to the kernel since version 4.12.
Here is the method for activating and using the BFQ IO scheduler:
After enabling the BFQ scheduler under: Enable the block layer ---> in menuconfig, you can enable and try out the BFQ IO Scheduler with a simple command line change to the grub boot menu.
From the IO scheduler wiki here: https://en.wikipedia.org/wiki/I/O_scheduling
Input/output (I/O) scheduling is the method that computer operating systems use to decide in which order the block I/O operations will be submitted to storage volumes. I/O scheduling is sometimes called disk scheduling.
What this means in general is that IO schedulers choose what and when files are accessed/copied to disk.
I/O schedulers can have many purposes depending on the goals; common purposes include:
To minimize time wasted by hard disk seeks.
To prioritize a certain processes' I/O requests.
To give a share of the disk bandwidth to each running process.
To guarantee that certain requests will be issued before a particular deadline.
Your current IO scheduler is probably "cfq". Check with:
sudo cat /sys/block/sda/queue/scheduler
You should see:
noop deadline [cfq]
*Note (Your drive may be different than "sda" and should be adjusted accordingly.)
BFQ is based on CFQ code, but it implements a more accurate scheduling policy. BFQ distributes the throughput to I/O-bound processes as desired, even if it fluctuates, independently of the device parameters and with any workload.
Soft real-time applications enjoy up to 3-time lower latencies than under CFQ and do not suffer from almost any glitch even in presence of heavy background workloads.
BFQ achieves a high throughput on SSDs without losing low-latency guarantees. (for solid state).
BFQ achieves up to 30% higher aggregate disk throughput than CFQ with most of the workloads considered, or the same throughput with the others.
Basically, if you do a lot of file transfer from video editing, copying files, backup, etc . . . BFQ is a good scheduler to use.
Also BFQ is the default I/O scheduler in Manjaro, Mageia, OpenMandriva, Sabayon, Arch Linux ARM. Interesting tidbit that.
To Use the BFQ Scheduler after enabling it in the kernel configuration file:
Once you have booted into your system, to see a list of available schedulers, open a terminal and:
sudo cat /sys/block/sda/queue/scheduler
Your output should be:
[mq-deadline] kyber bfq none
This shows that BFQ is now available for use, though not enabled yet. Yor current kernel may allow for this change as well. Simply check with the above code to see if BFQ is available.
You can now change the scheduler to BFQ FOR THIS SESSION ONLY by using:
sudo echo bfq > /sys/block/sda/queue/scheduler
Run the cat command again and you should see:
mq-deadline kyber [bfq] none
If so, then you are now using BFQ for the current session. Try all of the schedulers listed if you like.
Now, after using BFQ for a bit and you want to make it permanent on boot, you will need to edit /etc/default/grub.
sudo nano /etc/default/grub
Then add scsi_mod.use_blk_mq=1 after "quiet" like so and save.
Patches are an easy way to get some of the cool features that others have developed for the Linux Kernel. They are easy to implement, and easy to use.
As an example, lets say I want to patch gcc to allow for the march=native option. This option tells the GCC compiler to find all of the information about your computer, rather than depend on an "arch" setting that could be wrong.
Here is the link to a patch written for not only march=native, but provides a better list under Processor type and features--> Processor Family, changing the number of possible types to well over 20. "Generic-x86-64" is the default.
In order to use a patch, download or copy the code to a text file. Download is in the link.
For this purpose, I am using the 4.17.4 stable kernel with the "enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v4.13+.patch"
Yeah, that's the name:) you can, however, change it to whatever you want. Since I'm using TAB completion, it doesn't bother me at all, and definitely describes the patch.
Place the patch into your kernel tree directory, open a terminal, and:
If it doesn't work, you will be informed why. Some will, some won't. This one does on 4.17.4, and I now have march=native checked by default.
"man patch" in a terminal will show all of the options.
Run "make oldconfig" to see a list of the changes, their default setting, and location.
Afterwards, run "make menuconfig" as you normally would.
There are different patches all over if you do a decent search. If you find a super duper cool patch, let us all know by posting in the thread.
***Ideas to get you started
I've made up a list of many of the changes I have made that serve well for laptops and desktops that don't require special debugging or hardware options. Running through some of these will give you a feel for how to use menuconfig, and what you can expect from compiling your own kernel.
Many items here are simply not necessary for a laptop computer that is being used for common tasks; web surfing, email, usb, bluetooth, etc . . ..
Changing schedulers, governors, timers, debugging, and other kernel parameters can greatly enhance the kernels speed, most noticeable on boot, opening programs, and file transfer.
The smaller the kernel size, the faster the reads.
Networking and drivers are machine dependent, while security, crypto, and the like are personal.
There are over 4,300 options in the config file.
Upon opening make menuconfig:
Under General Setup:
1. () Local version – append to kernel release – – – Add a 1 to this to get started;)
2. POSIX Message Queues – – – Disable unless using solaris.
3. uselib syscall – – – Disable – Glibc doesn’t use this.
4. Auditing support - - - Disable
5. Kernel .config support---Enable-Gives access to the kernel config file
6. Enable access to .config through /proc/config.gz---Enable-Nice feature to have. You will also need to go into "security options" and uncheck "Restrict unprivileged access to the kernel syslog"
7. Memory placement aware NUMA scheduler – – – Disable – soon deprecated.
8. Configure standard kernel features (expert). – – – Enable, then INSIDE:
Enable ELF core dumps – – – Disable
Enable PC-Speaker support – – – Disable – -unless you like beeps-
Load all symbols for debugging/ksymoops – – – Disable – debugging.
NOTE* You can also disable standard kernel features, then go to Kernel Hacking, and remove all debugging. One depends on the other.
9. Enable SLUB debugging support – – – Disable – debugging.
10 Choose SLAB allocator (SLAB (Unqueued Allocator)) ---> --- Change to SLUB
11. SLUB per cpu partial cache. – – – EITHER – performance (N) on mine.
12. Profiling support – – – Disable – used by oprofile.
—
—
Enable loadable module support —>
1. Forced module loading – – – Disable – Really shouldn’t need this.
2. Forced module unloading – – – Disable – Really shouldn’t need this.
3. Module versioning support – – – Disable – for using modules from other kernels/systems.
—
—
Enable the block layer —>
1. Zoned block device support – – – Disable – Unless you have a ZAC or ZBC Storage device.
2. Block layer debugging information in debugfs – – – Disable – Debugging.
3. For interfacing with Opal enabled SEDs – – – Disable – Unless you know what this is.
4. Under Partition Types —>
Advanced partition selection – – – Disable – Unless using hard disks from another system.
5. Enable any IO Schedulers you wish to use.
—
—
Processor type and features —>
1. Enable MPS table. – – – If 64 bit, Disable, if not, read.
2. Linux guest support – – – Disable – Unless running under Hypervisor
3. Processor family (Generic-x86-64) – – – Change to yours! – cat /proc/cpuinfo to find out.
4. Supported processor vendors – – – Enable – and remove unused vendors.
5. Old AMD GART IOMMU support – – – Disable – Unless AMD Athlon64, Opteron, turion, etc. Then maybe.
6. IBM Calgary IOMMU support – – – Disable – Unless using IBM.
7. Maximum number of CPUs – – – Change to 4 or 8 Each adds 8 kb (256 x 8 = 2048).
8. CPU core priorities scheduler support – – – Enable – If using Intel – New support in latest kernel possible.
9. Reroute for broken boot IRQs – – – Disable – unless affected – read.
10. Enable support for 16-bit segments – – – Disable – Unless running Wine.
11. Numa Memory Allocation and Scheduler Support – – – READ – I disabled on mine.
12. Contiguous Memory Allocator – – – READ – I disabled on mine.
13. x86 architectural random number generator – – – Disable – How many do you need?
14. Supervisor Mode Access Prevention – – – Disable – Read – Security feature in newer intel.
15. EFI runtime service support – – – Disable – unless you have EFI support.
16. Timer frequency – – – Change to 1000HZ.
17. kexec system call – – – Disable – If you need this, you will know what it is:)
18. Build a relocatable kernel – – – Disable.
—
—
Power management and ACPI options —>
1. Enable workqueue power-efficient mode by default. – – Disable – Read.
—
—
Bus options (PCI etc.) —> Your on your own, and good to go through once you get a feel for re-compiling.
—
—
Executable file formats / Emulations —> I would leave this as is.
—
—
Networking support —> There is a lot here. Here's three.
1. Amateur Radio support – – – Disable – unless using amateur radio.
2. CAN bus subsystem support – – – Disable – Medical equipment type stuff.
3. Bluetooth subsystem support – – – Disable – Unless using Bluetooth.
—
—
Device Drivers —> On your own, but there are a bunch that can probably go right off. Most (or all) staging drivers can go, along with chrome and android, and a lot more
—
—
Firmware Drivers —> On your own. Some are removable, but I'd leave these alone overall.
—
—
File systems —>
1. Reiserfs support – – – Disable – Unless you formatted with Reiser.
2. JFS filesystem support. – – – Disable – Unless formatted with.
3. XFS filesystem support. – – – Disable – Unless formatted with.
4. GFS2 file system support. – – – Disable – Unless using a cluster.
5. OCFS2 file system support. – – – Disable – Unless using.
6. Btrfs assert support – – – Disable – Just this. Keep the file system.
7. NILFS2 file system support. – – – Disable – unless used.
8. F2FS filesystem support. – – – Disable – Read.
9. Direct Access (DAX) support. – – – Disable – unless needed.
10. Quota support – – – Disable – unless setting user limits.
11. Kernel automounter version 4 support│ – – – Disable – Distributed network stuff.
12. Overlay filesystem support. – – – Disable – Unless you know what this is.
13. Caches —>
Gather statistical information on local caching – – Disable – Debugging.
Gather latency information on local caching – – – Disable – Debugging.
Filesystem caching on files – – – Disable – READ FIRST.
—
—
Kernel hacking —>
1. printk and dmesg options —>
Show timing information on printks – – – Disable – unneeded for common tasks.
2. Compile-time checks and compiler options —>
Enable unused/obsolete exported symbols – – – Disable – unused.
3. Magic SysRq key – – – Disable – READ I don’t need this.
4. Kernel debugging – – – Disable – Debugging.
5. Tracers – – – Disable – unneeded.
6. (go back 2) Stack backtrace support – – – Disable – unneeded.
7. Runtime Testing – – – Disable – self tests.
8. Early printk via the EFI framebuffer – – – Disable – Debugging.
9. TOM Punit debug driver – – – Disable – Debugging.
—
—
Security options —> On your own, But be aware that you can remove many of the different security measures that may not be necessary for your usage. I offer no advice here.
Cryptographic API —> On your own;)
Virtualization —> On your own. Are you running kvm or using virtio?
Library routines —> On your own, but I advise leaving these alone unless you want a mess on your hands:)
Some items may not be disabled unless other items are. Going back to uncheck something that appeared un-checkable at first is a good idea.
Remember You can disable "standard kernel features" under the general section, then go to Kernel Hacking, and remove all debugging. One depends on the other.
This guide is meant to provide a basis for compiling the Linux kernel, whether the latest stable kernel from the Debian Stretch Repositories, or any kernel listed in the Linux Kernel Archives. https://www.kernel.org/
There are currently 12 sections:
Why compile your own kernel?
Both the Linux Kernel Archives, and the Debian repositories (though a version or two behind), offer the latest Linux kernels, fully patched with the newest security measures. This includes support for the dreaded spectre and meltdown problems of late, as well as new and exciting features, and fixes for older drivers. So, if you:
NOTE* Compiling and installing a kernel will not, in itself, cause any issues or damage. If your new kernel if corrupted, it either will not boot, or will quickly show if there is a problem after boot.
If you do have a problem, simply boot into your previous kernel and remove the offending version using apt-get remove --purge linux-Image-<version> linux-headers-<version>.</version></version>
***Dependencies
In order to compile your new kernel, some development programs need to be downloaded and installed:
First update the repositories:
sudo apt updateDownload and install the programs with:
sudo apt install build-essential libncurses5-dev libssl-dev libelf-dev bison flex bc fakeroot***Compiling the Debian stable kernel from the repositories
Is there any reason to use the Debian kernel source v.s. the Linux kernel source?
Maybe. This will depend on your needs. Debian kernel security patches come from the upstream Linux Kernel, and are applied on a regular basis in order to be fully up to date with the very latest security from the upstream source.
However, Debian may apply other patches that allow certain Debian packages to work better within the existing Debian framework.
Mostly this applies to "out of tree" modules/drivers that Debian is implementing for different architectures. What affect this has on the end user depends on several factors, including architecture, programs used, transition of Debian versions from testing to stable, etc . . For MOST daily use, the upstream source from the Linux Kernel Archives can certainly be used.
To get the Debian kernel source at the current maximum patch level, you will need to install the Debian kernel source package using apt.
NOTE* SCROLL down a bit to skip to the Linux Kernel Archives section.
First find out what the latest kernel source package is by using apt-cache:
apt-cache search linux-sourceHere is the example output from the code above:
apt-cache search linux-sourcelinux-source-4.19 - Linux kernel source for version 4.19 with Debian patches
linux-source - Linux kernel source (meta-package)
linux-source-5.4 - Linux kernel source for version 5.4 with Debian patches
linux-source-5.5 - Linux kernel source for version 5.5 with Debian patches
linux-source-5.6 - Linux kernel source for version 5.6 with Debian patches
linux-source-5.7 - Linux kernel source for version 5.7 with Debian patches
Decide which version you would like to work with:
sudo apt install linux-source-4.19The Debian kernel source will install to /usr/src. We do not want or need to work on it from /usr/src. Working on the kernel from your home directory makes for a safer environment.
Make a folder in your home directory where you will be working:
mkdir ~/kernelsNow move the downloaded source to your new kernel directory (Use the correct version number):
sudo mv /usr/src/linux-source-4.19.tar.xz ~/kernelsChange your working directory to ~/kernels:
cd kernelsExtract the source file from the tarball:
tar xaf linux-source-4.19.tar.xzYou shouldn't need to change permissions on the resultant file as it is being extracted in $HOME, but if so:
sudo chmod -R 755 ~/kernels/linux-source-4.19You should then remove the source paths/tree in /usr/src after moving the file to ~/kernels. This will keep /usr/src from getting cluttered up with different sources.
Remove the cruft left behind when you moved the source to ~/kernels:
sudo apt purge linux-source-4.19For more information on the Debian kernel source:
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html
-- From this point, please scroll down to Initial Configuration and Install --
***Compiling the Linux kernel from the Linux Kernel Archives
Simply download any available image you would like to compile from the Linux Kernel Archives. The only caveat here may be to use the version closest to your current kernel. This will ensure that the resultant initial changes will be small: https://www.kernel.org/
Make a directory in /home to work from:
mkdir kernelsChange your working directory to ~/kernels:
cd kernelsPlace your source tarball into ~/kernels and extract using:
tar xaf linux-source-4.19.140.tar.xz***Initial Configuration and Install
Once extracted, change directories and/or open a terminal in the resultant folder. (linux-source-4.19.140)
We need to clean up any files that may have been altered prior to release and make sure the kernel source tree is completely clean:
make clean && make mrproperNext we open the configuration file (.config) that will instruct the compiler on what to add or leave out depending on your choices. The first code we run will sync all the items between kernel releases, removing and adding items as necessary.
make oldconfigMake oldconfig uses the existing kernel configuration on your system to determine the default settings applied during distribution install. Make oldconfig only needs to be done (and should be) at the change of the major kernel release number, i.e. from 4.15 to 4.16.
Accept all of the defaults by hitting enter repeatedly (just hold it down), or look through them if you want. It's quite a list. The defaults are meant to protect the user. Nothing should be automatically turned on unless it has been deemed necessary and safe. The number of changed items between releases is generally under 20 or so, but the initial list could be a few hundred items if there are large separations between versions.
When you get to the end, save the file. This takes place in the main terminal window, no other "settings" window appears until running "make menuconfig", or one of the other options.
NOTE* IF you now want to compile a kernel specifically for your hardware/setup, you can use "make localmodconfig" You MUST plug in any usb's, cards, printers, et,al if you want the drivers to be automatically picked up. This actually works really well, and will remove loads of junk you dont need.
After running "make oldconfig", and possibly "make localmodconfig" then open menuconfig, which will be the goto from now on, as it collects your current kernel settings each time:
make menuconfigThis window will present you with a full menu to change the huge number of options the kernel contains. I have made up a list of some of the most common changes later in this guide, but for now:
Under General setup —> find, Local version – append to kernel release
click on Local version – append to kernel release, and type in 1.
For each new compilation, change the number sequentially to keep things a bit more orderly.
Compiling at this point is advised, so you will know the first kernel will work without issue. Other changes should be made on a subsequent compile.
Next, compile the kernel image and headers. There are other files created as well that can be ignored if you want, but may be useful.
Make the kernel with:
make deb-pkgOr, if you have a dual-core processor:
make -j3 deb-pkgCompilation can take anywhere from ten minutes to two hours depending on hardware and kernel configuration. You don't need a fancy computer to compile, it's just a longer wait. The configuration file is stored in the Linux kernel folder as .config. Show hidden files in your file manager to see it.
NOTE* If your kernel fails to compile, and you have not yet tried "make localmodconfig", give it a go as it may solve your compile problem.
When the compile is finished, cd to ~/kernels and install the kernel image, and kernel headers using:
sudo dpkg -i linux-image.xyz linux-headers.xyz where xyz = version number..
In order to make things easier, you should use tab-completion in the terminal.
Dpkg will automatically update your initramfs and grub menu after installation.
Reboot into your new kernel!
***After Boot
To see what happens with the Linux kernel on boot, and possibly address errors, in a terminal:
To see your currently running kernel:
uname -rTo see boot speed:
systemd-analyzeTo get a read out of the kernel boot process.
dmesgSimilar to dmesg, through systemd:
sudo journalctl -bIf you want to know what drivers you are currently using:
lspci -kIf you believe you may have a failed driver:
dmesg | grep failedTo find the size of your currently running kernel, uname -r to get the version, then use the version number to find out running kernel size. I'm using kernel version 4.17.01:
ls -lha /boot | grep 4.17.01And here is the output:
-rw-r--r-- 1 root root 103K Jun 7 13:02 config-4.17.01-rw-r--r-- 1 root root 6.4M Jun 7 16:51 initrd.img-4.17.01
-rw-r--r-- 1 root root 1.8M Jun 7 13:02 System.map-4.17.01
-rw-r--r-- 1 root root 3.6M Jun 7 13:02 vmlinuz-4.17.01
The main changes in the kernel size from recompiling will be the initrd.img, shown here at 6.4 mb.
To get a complete list of your computers hardware, from the menu, open accessories --> System Information. The program Hardinfo comes installed with BunsenLabs and is an excellent tool to retrieve information.
There are links at the bottom of the post that can provide good information on the items found in the kernel.
***Dual-booting
If you choose to dual-boot, and BunsenLabs is not your core distribution, you will need to boot into the distribution that installed grub to the mbr.
Then:
sudo update-grubto have BunsenLabs show in the grub boot menu.
This also goes for those that are not currently dual booting, but would like to give it a go. Grub automatically adds and updates the boot menu for all partitions. This means you can avoid installing grub altogether in the second distribution. After install, boot into the distribution that installed grub to the mbr, and update-grub.
Another way to add another distribution to the Grub boot menu, is by placing the below into /etc/grub.d/40_custom. In this example, I am dual booting with antiX as my second distribution on sda5.
menuentry 'Antix' {set root=(hd0,5)
linux /vmlinuz root=/dev/sda5 ro quiet
initrd /initrd.img
}
*NOTE - You can add any other kernel parameters after quiet if required. (example - scsi_mod.use_blk_mq=1 if using bfq in the other distro.)
Then:
update-grubIf you want, you can replace; root=/dev/sda5, with root=UUID=$12345uuid... where $12345uuid... IS the actual UUID of /dev/sda5. This method may be more reliable, as fewer errors can develop from improper partition naming.
Yet one more way, and my preferred method, is with chainloading. This snippet is also placed in /etc/grub.d/40_custom. What it does is place a final menu entry that open the grub screen of the other distro. In this example, I am booting "Patience" on sda5:
menuentry 'Chainload patience (auf /dev/sda5)' {set root='hd0,msdos5'
configfile /boot/grub/grub.cfg
}
In a terminal:
ls -lha /dev/disk/by-uuidThis will show you the partitions by name, as well as the uuid of each partition on your computer.
This thread discusses best practices: https://forums.bunsenlabs.org/viewtopic.php?pid=72521#p72521
The Archwiki on Dual-booting: https://wiki.archlinux.org/index.php/GRUB#Dual-booting
***Configuration
One of the first things to do, is set up a way to see the differences in the configuration (.config) files between builds. This is important for keeping track of changes through the different builds you will be making. Sometimes you may only want to change one or two items in the configuration file, and having a way to keep track of these changes is important.
The easiest way is with the "diffconfig" utility that is found in your kernel source folder in /scripts/diffconfig. Copy this executable to ~/bin, make a folder in /home to compare the .config files, and call diffconfig with:
diffconfig .config1 .config2
Once you have opened menuconfig to start your custom configuration, the directions on navigating the menus appear at the top.
In particular, one should note / and SHIFT+/
Pressing / will give you a search box useful for finding drivers and other configuration options, while SHIFT+/ while an item is highlighted, will give the description of the item, it's current state, and other dependencies and reverse dependencies necessary to function.
For example, here is the description obtained by pressing SHIFT + / while in:
General setup ---> uselib syscall.
Here is the description:
CONFIG_USELIB: │
│ │
│ This option enables the uselib syscall, a system call used in the │
│ dynamic linker from libc5 and earlier. glibc does not use this │
│ system call. If you intend to run programs built on libc5 or │
│ earlier, you may need to enable this syscall. Current systems │
│ running glibc can safely disable this. │
│ │
│ Symbol: USELIB [=n] │
│ Type : bool │
│ Prompt: uselib syscall │
│ Location: │
│ -> General setup │
│ Defined at init/Kconfig:284
As you can see, I have it disabled as it is no longer necessary in the kernel.
Pressing the space bar will change the selected items status and the arrow keys move you through the lists, and through the items listed at the bottom of the display.
A surprising number of different options are available to '"pre-configure" your kernel. Here they are:
config
Updates the current kernel configuration by using a line-oriented program.
menuconfig - Used for this guide, and my default goto.
Updates the current kernel configuration by using a text based menu program.
xconfig - Many prefer this over menuconfig.
Updates the current kernel configuration by using a QT-based graphical program.
gconfig
Updates the current kernel configuration by using a GTK+-based graphical program.
oldconfig
Updates the current kernel configuration by using the current .config file and prompting for any new options that have been added to the kernel.
silentoldconfig
Just like oldconfig, but prints nothing to the screen except when a question needs to be answered.
randconfig
Generates a new kernel configuration with random answers to all of the different options.
defconfig
Generates a new kernel configuration with the default answer being used for all options. The default values are taken from a file located in the arch/$ARCH/defconfig file, where $ARCH refers to the specific architecture for which the kernel is being built.
allmodconfig
Generates a new kernel configuration in which modules are enabled whenever possible.
allyesconfig
Generates a new kernel configuration with all options set to yes.
allnoconfig
Generates a new kernel configuration with all options set to no.
localmodconfig
Generates a new kernel configuration using only the computers values. This requires
every device you want to have function in the new kernel, connected to the computer
and engaged during the 'make localmodconfig' command.
This means having a disk in the drive, A usb in one of the ports,
printer plugged in and on, internet engaged, and any other devices you can think of.
This is not as hard as it sounds, and can be quite rewarding.
The kernel will be reduced in size considerably, and performing 'make menuconfig' afterwards
will show you all the changes.
Note that the allyesconfig, allmodconfig, allnoconfig, and randconfig targets also take advantage of the environment variable KCONFIG_ALLCONFIG. If that variable points to a file, that file will be used as a list of configuration values that you require to be set to a specific value. In other words, the file overrides the normal behavior of the make targets.
You will also want to find out the information about your processors. The following codes will show the info you need:
less /proc/cpuinfogrep flags /proc/cpuinfodmidecode -t processorFor even better information, download a simple programs:
sudo apt install cpuidThen try:
cpuid | lessFor more information:http://archive.oreilly.com/pub/a/linux/excerpts/9780596100797/kernel-build-command-line-reference.html
***Scaling Drivers and Governors
To find out whether you are currently using the pstates driver or the acpi-cpufrq driver:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driverTo find out which governor is in use on your system:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorFor all of the above info, plus current running frequencies:
cpufreq-infoThe results of which will look something like:
cpufreq-infocpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us.
hardware limits: 1.20 GHz - 2.10 GHz
available frequency steps: 2.10 GHz, 1.60 GHz, 1.20 GHz
available cpufreq governors: ondemand, performance, schedutil
current policy: frequency should be within 1.20 GHz and 2.10 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.75 GHz.
analyzing CPU 1:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 10.0 us.
hardware limits: 1.20 GHz - 2.10 GHz
available frequency steps: 2.10 GHz, 1.60 GHz, 1.20 GHz
available cpufreq governors: ondemand, performance, schedutil
current policy: frequency should be within 1.20 GHz and 2.10 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 1.28 GHz.
The pstates information below was taken from - The Linux kernel user’s and administrator’s guide on pstates. (link below).
The Linux kernel supports a scaling subsystem that consists of three layers. The core, scaling governors, and scaling drivers.
The majority of modern processors are capable of operating in a number of different clock frequency and voltage configurations, often referred to as Operating Performance Points or pstates.
Scaling drivers talk to the hardware. They provide scaling governors with information on the available pstates (or pstate ranges in some cases), and access hardware interfaces to change pstates as requested by the scaling governor used.
Governors are basically scaling algorithms for one of two scaling drivers; The Intel pstates driver, and the acpi-cpufreq driver.
With the pstate driver, there are only two available governors, Performance and Powersave.
The default pstate governor, depends on the .config option -- CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE , with the Performance governor being the default.
If you are using acpi-cpufreq as your scaling driver, all of the Governors are used as they traditionally have, before the pstates driver was introduced to the Linux Kernel.
There are currently 6 governors that come with the Linux kernel without patching.
performance
powersave
conservative
on-demand
schedutil
userspace
Note, People have reported mixed results with pstates. If you are having issues, you may want to disable the pstates driver and use acpi-cpufreq instead. Also, try different scaling governors for your specific needs.
If you want to disable pstates and use acpi-cpufreq as your scaling driver, then add this at boot time.
intel_pstate=disableWhen using the acpi-cpufreq scaling driver, the only two governors I personally would consider for desktop/laptop use, are Ondemand, and Schedutil. That being said, I am also not worried about my battery, and this could/should be considered when making a selection
The Schedutil governor will probably become the default goto in the future.
If you would like more local information from our forum about the Ondemand settings and how to use them:
Adjusting some of the settings in the ondemand governor, babble style!
Main source for pstates information:
https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html#passive-mode
***IO Schedulers
Be aware, If you have a solid state drive, IO schedulers may not be necessary.
Please see this link for more information: https://forums.bunsenlabs.org/viewtopic.php?id=3402
The CFQ IO Scheduler comes default on most Linux distributions, and is a fine choice for those who do common tasks like email, web surfing, documents, etc . . If however, you also do video editing, kernel compiling, and other load intensive operations, you may want to consider the BFQ IO Scheduler, which no longer needs to be patched to the kernel since version 4.12.
Here is the method for activating and using the BFQ IO scheduler:
After enabling the BFQ scheduler under: Enable the block layer ---> in menuconfig, you can enable and try out the BFQ IO Scheduler with a simple command line change to the grub boot menu.
From Here: http://algo.ing.unimo.it/people/paolo/disk_sched/
"BFQ is a proportional-share storage-I/O scheduler that also supports hierarchical scheduling with a cgroups interface."
From the IO scheduler wiki here: https://en.wikipedia.org/wiki/I/O_scheduling
Input/output (I/O) scheduling is the method that computer operating systems use to decide in which order the block I/O operations will be submitted to storage volumes. I/O scheduling is sometimes called disk scheduling.
What this means in general is that IO schedulers choose what and when files are accessed/copied to disk.
I/O schedulers can have many purposes depending on the goals; common purposes include:
Your current IO scheduler is probably "cfq". Check with:
sudo cat /sys/block/sda/queue/schedulerYou should see:
noop deadline [cfq]*Note (Your drive may be different than "sda" and should be adjusted accordingly.)
BFQ is based on CFQ code, but it implements a more accurate scheduling policy. BFQ distributes the throughput to I/O-bound processes as desired, even if it fluctuates, independently of the device parameters and with any workload.
Soft real-time applications enjoy up to 3-time lower latencies than under CFQ and do not suffer from almost any glitch even in presence of heavy background workloads.
BFQ achieves a high throughput on SSDs without losing low-latency guarantees. (for solid state).
BFQ achieves up to 30% higher aggregate disk throughput than CFQ with most of the workloads considered, or the same throughput with the others.
Basically, if you do a lot of file transfer from video editing, copying files, backup, etc . . . BFQ is a good scheduler to use.
Also BFQ is the default I/O scheduler in Manjaro, Mageia, OpenMandriva, Sabayon, Arch Linux ARM. Interesting tidbit that.
To Use the BFQ Scheduler after enabling it in the kernel configuration file:
Once you have booted into your system, to see a list of available schedulers, open a terminal and:
sudo cat /sys/block/sda/queue/schedulerYour output should be:
[mq-deadline] kyber bfq noneThis shows that BFQ is now available for use, though not enabled yet. Yor current kernel may allow for this change as well. Simply check with the above code to see if BFQ is available.
You can now change the scheduler to BFQ FOR THIS SESSION ONLY by using:
sudo echo bfq > /sys/block/sda/queue/schedulerRun the cat command again and you should see:
mq-deadline kyber [bfq] noneIf so, then you are now using BFQ for the current session. Try all of the schedulers listed if you like.
Now, after using BFQ for a bit and you want to make it permanent on boot, you will need to edit /etc/default/grub.
sudo nano /etc/default/grubThen add scsi_mod.use_blk_mq=1 after "quiet" like so and save.
GRUB_DEFAULT=0GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=
lsb_release -i -s 2> /dev/null || echo DebianGRUB_CMDLINE_LINUX_DEFAULT=" vga=791 quiet scsi_mod.use_blk_mq=1 "
GRUB_CMDLINE_LINUX=""
Your grub file may be different than above.
Once you have the line the way you want, hit "F2" to open the "save file" prompt, type "y" and ENTER.
Update grub. If you don't, nothing changes.
sudo update-grubBe careful here, screwing up you grub file may, or may not allow you to boot if you get it wrong.
IF you do mess up, simply reboot, drop down one in the menu and type "e" again to bring up the prompt, and change it back to the original.
In order to have BFQ as the default scheduler upon boot, you will need to create a file in /etc/udev/rules.d indicating such.
To make the file 60-block.rules in /etc/udev/rules.d:
sudo nano /etc/udev/rules.d/60-scheduler.rules-
Add this line:
ACTION=="add|change", KERNEL=="sd[!0-9]|sr", ATTR{queue/scheduler}="bfq"Hit F2 and save.
upon REBOOT, check with:
sudo cat /sys/block/sda/queue/scheduler***Patches
Patches are an easy way to get some of the cool features that others have developed for the Linux Kernel. They are easy to implement, and easy to use.
As an example, lets say I want to patch gcc to allow for the march=native option. This option tells the GCC compiler to find all of the information about your computer, rather than depend on an "arch" setting that could be wrong.
Here is the link to a patch written for not only march=native, but provides a better list under Processor type and features--> Processor Family, changing the number of possible types to well over 20. "Generic-x86-64" is the default.
https://github.com/graysky2/kernel_gcc_patch
In order to use a patch, download or copy the code to a text file. Download is in the link.
For this purpose, I am using the 4.17.4 stable kernel with the "enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v4.13+.patch"
Yeah, that's the name:) you can, however, change it to whatever you want. Since I'm using TAB completion, it doesn't bother me at all, and definitely describes the patch.
Place the patch into your kernel tree directory, open a terminal, and:
patch -p1 < enable_additional_cpu_optimizations_for_gcc_v4.9+_kernel_v4.13+.patchIf it doesn't work, you will be informed why. Some will, some won't. This one does on 4.17.4, and I now have march=native checked by default.
"man patch" in a terminal will show all of the options.
Run "make oldconfig" to see a list of the changes, their default setting, and location.
Afterwards, run "make menuconfig" as you normally would.
There are different patches all over if you do a decent search. If you find a super duper cool patch, let us all know by posting in the thread.
***Ideas to get you started
I've made up a list of many of the changes I have made that serve well for laptops and desktops that don't require special debugging or hardware options. Running through some of these will give you a feel for how to use menuconfig, and what you can expect from compiling your own kernel.
Many items here are simply not necessary for a laptop computer that is being used for common tasks; web surfing, email, usb, bluetooth, etc . . ..
Changing schedulers, governors, timers, debugging, and other kernel parameters can greatly enhance the kernels speed, most noticeable on boot, opening programs, and file transfer.
The smaller the kernel size, the faster the reads.
Networking and drivers are machine dependent, while security, crypto, and the like are personal.
There are over 4,300 options in the config file.
Upon opening make menuconfig:
Under General Setup:
1. () Local version – append to kernel release – – – Add a 1 to this to get started;)
2. POSIX Message Queues – – – Disable unless using solaris.
3. uselib syscall – – – Disable – Glibc doesn’t use this.
4. Auditing support - - - Disable
5. Kernel .config support---Enable-Gives access to the kernel config file
6. Enable access to .config through /proc/config.gz---Enable-Nice feature to have. You will also need to go into "security options" and uncheck "Restrict unprivileged access to the kernel syslog"
7. Memory placement aware NUMA scheduler – – – Disable – soon deprecated.
8. Configure standard kernel features (expert). – – – Enable, then INSIDE:
Enable ELF core dumps – – – Disable
Enable PC-Speaker support – – – Disable – -unless you like beeps-
Load all symbols for debugging/ksymoops – – – Disable – debugging.
NOTE* You can also disable standard kernel features, then go to Kernel Hacking, and remove all debugging. One depends on the other.
9. Enable SLUB debugging support – – – Disable – debugging.
10 Choose SLAB allocator (SLAB (Unqueued Allocator)) ---> --- Change to SLUB
11. SLUB per cpu partial cache. – – – EITHER – performance (N) on mine.
12. Profiling support – – – Disable – used by oprofile.
—
—
Enable loadable module support —>
1. Forced module loading – – – Disable – Really shouldn’t need this.
2. Forced module unloading – – – Disable – Really shouldn’t need this.
3. Module versioning support – – – Disable – for using modules from other kernels/systems.
—
—
Enable the block layer —>
1. Zoned block device support – – – Disable – Unless you have a ZAC or ZBC Storage device.
2. Block layer debugging information in debugfs – – – Disable – Debugging.
3. For interfacing with Opal enabled SEDs – – – Disable – Unless you know what this is.
4. Under Partition Types —>
Advanced partition selection – – – Disable – Unless using hard disks from another system.
5. Enable any IO Schedulers you wish to use.
—
—
Processor type and features —>
1. Enable MPS table. – – – If 64 bit, Disable, if not, read.
2. Linux guest support – – – Disable – Unless running under Hypervisor
3. Processor family (Generic-x86-64) – – – Change to yours! – cat /proc/cpuinfo to find out.
4. Supported processor vendors – – – Enable – and remove unused vendors.
5. Old AMD GART IOMMU support – – – Disable – Unless AMD Athlon64, Opteron, turion, etc. Then maybe.
6. IBM Calgary IOMMU support – – – Disable – Unless using IBM.
7. Maximum number of CPUs – – – Change to 4 or 8 Each adds 8 kb (256 x 8 = 2048).
8. CPU core priorities scheduler support – – – Enable – If using Intel – New support in latest kernel possible.
9. Reroute for broken boot IRQs – – – Disable – unless affected – read.
10. Enable support for 16-bit segments – – – Disable – Unless running Wine.
11. Numa Memory Allocation and Scheduler Support – – – READ – I disabled on mine.
12. Contiguous Memory Allocator – – – READ – I disabled on mine.
13. x86 architectural random number generator – – – Disable – How many do you need?
14. Supervisor Mode Access Prevention – – – Disable – Read – Security feature in newer intel.
15. EFI runtime service support – – – Disable – unless you have EFI support.
16. Timer frequency – – – Change to 1000HZ.
17. kexec system call – – – Disable – If you need this, you will know what it is:)
18. Build a relocatable kernel – – – Disable.
—
—
Power management and ACPI options —>
1. Enable workqueue power-efficient mode by default. – – Disable – Read.
—
—
Bus options (PCI etc.) —> Your on your own, and good to go through once you get a feel for re-compiling.
—
—
Executable file formats / Emulations —> I would leave this as is.
—
—
Networking support —> There is a lot here. Here's three.
1. Amateur Radio support – – – Disable – unless using amateur radio.
2. CAN bus subsystem support – – – Disable – Medical equipment type stuff.
3. Bluetooth subsystem support – – – Disable – Unless using Bluetooth.
—
—
Device Drivers —> On your own, but there are a bunch that can probably go right off. Most (or all) staging drivers can go, along with chrome and android, and a lot more
—
—
Firmware Drivers —> On your own. Some are removable, but I'd leave these alone overall.
—
—
File systems —>
1. Reiserfs support – – – Disable – Unless you formatted with Reiser.
2. JFS filesystem support. – – – Disable – Unless formatted with.
3. XFS filesystem support. – – – Disable – Unless formatted with.
4. GFS2 file system support. – – – Disable – Unless using a cluster.
5. OCFS2 file system support. – – – Disable – Unless using.
6. Btrfs assert support – – – Disable – Just this. Keep the file system.
7. NILFS2 file system support. – – – Disable – unless used.
8. F2FS filesystem support. – – – Disable – Read.
9. Direct Access (DAX) support. – – – Disable – unless needed.
10. Quota support – – – Disable – unless setting user limits.
11. Kernel automounter version 4 support│ – – – Disable – Distributed network stuff.
12. Overlay filesystem support. – – – Disable – Unless you know what this is.
13. Caches —>
Gather statistical information on local caching – – Disable – Debugging.
Gather latency information on local caching – – – Disable – Debugging.
Filesystem caching on files – – – Disable – READ FIRST.
—
—
Kernel hacking —>
1. printk and dmesg options —>
Show timing information on printks – – – Disable – unneeded for common tasks.
2. Compile-time checks and compiler options —>
Enable unused/obsolete exported symbols – – – Disable – unused.
3. Magic SysRq key – – – Disable – READ I don’t need this.
4. Kernel debugging – – – Disable – Debugging.
5. Tracers – – – Disable – unneeded.
6. (go back 2) Stack backtrace support – – – Disable – unneeded.
7. Runtime Testing – – – Disable – self tests.
8. Early printk via the EFI framebuffer – – – Disable – Debugging.
9. TOM Punit debug driver – – – Disable – Debugging.
—
—
Security options —> On your own, But be aware that you can remove many of the different security measures that may not be necessary for your usage. I offer no advice here.
Cryptographic API —> On your own;)
Virtualization —> On your own. Are you running kvm or using virtio?
Library routines —> On your own, but I advise leaving these alone unless you want a mess on your hands:)
Some items may not be disabled unless other items are. Going back to uncheck something that appeared un-checkable at first is a good idea.
Remember You can disable "standard kernel features" under the general section, then go to Kernel Hacking, and remove all debugging. One depends on the other.
GOOD LUCK:)
***Links
The Linux Kernel Documentation (provides info on latest release as well):
https://www.kernel.org/doc/html/latest/index.html
This site explains the different active kernel releases, and the definition of distro kernels:
https://www.kernel.org/category/releases.html
The Arch Wiki on kernel development:
https://wiki.archlinux.org/index.php/Kernels/Traditional_compilation
A lot of the configuration items can be looked up here:
https://lwn.net/Kernel/Index/
Pstate and acpi-cpufreq information:
https://www.kernel.org/doc/html/v4.12/admin-guide/pm/intel_pstate.html#passive-mode
To find out what's going on with kernel development:
https://lwn.net/Kernel/
Last edited by sleekmason (Aug 12 2021 10:11:07)
Lilidog
Last edit: sleekmason 2022-02-15