On Fri, May 29, 2020 at 23:24:58 +0000,
Suvayu Ali <fatkasuvayu+linux@xxxxxxxxx> wrote:
Could you please share your workflow? I have been looking for some
guidance so that I can test upstream kernels when I encounter these
hardware issues. I don't need step by step instructions, I'm very
comfortable compiling software, I just need some way to manage the
self-compiled kernels alongside Fedora kernels without littering my
system with build artifacts, and play nice with SELinux :). I
typically limit any software I compile myself to /opt or $HOME;
unfortunately that doesn't quite work with kernels :-p
Usually once I decide that it is worth doing a bisect, I'll mention that
I'm working on doing a bisect in my Fedora bug report. Then I get
Linus' tree. Either doing a git pull if I have an existing one or a
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
if I don't. Sometimes if the checkout was in a bad state, git pull won't
update and it's easier to do a clone rather than figure out what is messed
up.
Next I copy over a Fedora kernel config file into the checkout. A sample
would look like the following if I was in the top directory of the checkout:
cp /boot/config-5.7.0-0.rc7.1.fc33.x86_64 .config
In theory the differencs in the Fedora kernel and Linus' could cause a
problem, but normally it won't.
Then I do a make clean all. Once you get close on the bisect you don't
really need to do a clean and it can speed things up a lot to skip it.
You will probably get asked about some configuration options, because of
differences between your checked out version and the Fedora kernel. Usually
just using the default works.
Then you need to switch to root.
When you install kernels, files are going to get added to /boot and a
directory is going to get added to /lib/modules . You are going to want to
clean those up (but make sure you don't clean up stuff for the running
kernel) before doing the next install to make sure you are running what
you think you are when you run the test.
Then you want to do:
make modules_install install
If all of the above works, you can reboot to test the new kernel. You
probably want to have a short delay set in grub to allow you to easily
pick which kernel you want to boot.
So if the the problem is still in the upstream kernel, then you'll want to
start the bisect.
In the checkout (which should be the broken latest Linus kernel) do
the following:
git bisect start
git bisect bad
Then you want to set the checkout to be some point in the tree that did not
have the problem you are testing for. The closer the the bug, the fewer
steps you will need to bisect the issue. You either need a git commit
hash or a version tag and do git reset --hard to checkout the next
kernel to test.
Then you build and test stuff as above.
If the test fails then you run git bisect bad. If it succeeds then you
run git bisect good. Generally once you have a good and a bad kernel, you
won't want to manually checkout a particular commit. The last git bisect
command will have checked out a version roughly half way between the
latest good version and the earliest bad version you have seen so far.
Sometimes there can be issues with test kernels and you may have to manually
checkout a different version to jump around them.
You keep doing this until you find the commit that triggered the issue.
Then you can do git bisect log to get the list of tested kernels and
save that, so you can restart part way through if needed.
Then use git bisect reset to clean up the bisect stuff.
Sometimes, you can confirm the problem commit by starting at the latest
Linus kernel and do a git revert of the problem commit. That won't always
work if there is other stuff dependent on that commit.
Then you can note the in the Fedora bug. At this point it also makes
sense to report the issue upstream. You'll want to look at the bug and
try to guess which subsystem is involved and post to the subsystem list
and copy the main kernel list. People will normally assume you're off list
when replying, so you don't need to subscribe to the list to follow the
discussion.
Upstream might ask you to test fixes.
Once upstream is fixed, you can wait for the next rawhide kernel build to
test the fix for Fedora. Usually you can run rawhide kernels on other
Fedora versions. This is useful for testing when you don't normally run
rawhide and if you don't want to wait for the fix to get back ported to
older kernel releases. It's possible one of the Fedora maintainers could
do a backport if warranted. If they do, you'd want to do early testing
of updates to make sure the bug is really fixed.
I think that covers most of it. It isn't really as bad as it looks
written out.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
