On 09/15/2017 12:12 PM, Zwindl wrote:
Thanks for your patient and advice, I'll keep that in mind.
I do want help, and I got 1 day to build the system, but I can't recall how to
compile it, The last time I compile kernel is 2013, so, maybe I'll ask you so
many stupid questions during the build time.
ZWindL
Building a new kernel is not difficult. In an average week, I make at least 10
new kernels. Many of them are done on slow machines that take many hours. At
least, your i5 CPU should do it in less that one hour.
Step 1: Download the kernel sources using
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
If your system complains that the git command is unknown, then you will need to
install it with your package manager (pacman?).
Step 2: "cd linux" and copy the latest /boot/config-..... to the linux source
directory as ".config". Edit .config, find the line that says
"# CONFIG_LOCALVERSION_AUTO is not set", and change the line to read
"CONFIG_LOCALVERSION_AUTO=y".
Step 3: Build and install the latest version using
make -j9
sudo make modules_install install
You will need to answer some configuration questions at the start of the first
make line. Answer with the default value, i.e. just use an ENTER. When the build
is complete, reboot. Grub should show an entry for something like
v4.13-12084-ged43e4d190d0. The numbers after the 4.13 will likely be different,
but the form will match. Check that the new kernel still has the fault. If not,
it has been fixed and we do not need to find it.
It the problem is still in the latest version of the kernel, then we start the
bisection with the following:
git bisect start
git bisect bad v4.13
git bisect good v4.12
At this point, git will report the number of revisions to test, the likely
number of tries, and the SHA hash for the new kernel. Record the first 7 digits
of the hash, and repeat the make commands above. After the build is complete,
reboot into the kernel with the hash in the version name and test. Then enter
the command "git bisect xxx", where xxx is good or bad depending on the test. A
new trial will be generated by bisecting the appropriate half of the commits.
Record its hash and redo the build. Repeat until git tells you the bad commit.
This process will generate a number of kernels that will take quite a bit of
disk space. If you run short, you can delete kernels that have already been
tested from /boot. You should also delete the corresponding modules from
/lib/modules.
Good luck,
Larry
