I tried using fedbisect to bisect between kernel versions 4.13.16-202 and 4.14.6-200 on Fedora 26 and I couldn't build even bisect step 0.
I could find two different kinds of errors:
ERROR: Patch kbuild-AFTER_LINK.patch listed in specfile but is missing
And if that did not fail for some reason, I usually got:
/home/boehme/Downloads/kernel-bisect/build/linux-bisect-0 + cp '/home/boehme/Downloads/kernel-bisect/build/config-*' . cp: cannot stat '/home/boehme/Downloads/kernel-bisect/build/config-*': No such file or directory
I think it might be related to a very similar error message, that got printed before it tried building the rpms:
build (f26-candidate, /rpms/kernel.git:9d76398e4ca02cb6e7161cebe4ce23d071374bbc) 9d76398e4ca02cb6e7161cebe4ce23d071374bbc cp: der Aufruf von stat für '/home/boehme/Downloads/kernel-bisect/pkg-git/config-*' ist nicht möglich: No such file or directory cp: der Aufruf von stat für '/home/boehme/Downloads/kernel-bisect/pkg-git/Makefile.config' ist nicht möglich: No such file or directory now calling building for kernel-4.13.16-201.fc26. This may take a while...
As missing config files seem to be the reason, I did a quick research in the git repository git://pkgs.fedoraproject.org/kernel and found a commit, that might be related to it:
git://pkgs.fedoraproject.org/kernel
commit 1b7eeb80190501aaf226e90e8f58f994cfc3efe0 Author: Laura Abbott <labbott@fedoraproject.org> Date: Thu Nov 10 10:16:25 2016 -0800 Change method of configuration generation The existing method of managing configuration files gets unweildy. Changing individual lines in text files gets difficult without manual organization. Switch to a method of configuration generation that's inspired from the method used inside Red Hat. Each configuration option gets its own file which are then combined to form the configuration files. This makes confirming what's actually enabled much easier.
Could it be that these config files now need to be generated by the fedbisect script itself?
This project is mostly abandoned at this point, mostly because of issues like you pointed out. It's too much work to keep this in sync and it's not that much more valuable vs. just bisecting on the main kernel tree.
Login to comment on this ticket.