Re: Bisecting an older kernel
On Mon, Feb 12, 2024 at 7:49 AM Julian Sikorski wrote: > > Am 12.02.24 um 10:03 schrieb Michael J Gruber: > > Am So., 11. Feb. 2024 um 23:14 Uhr schrieb Julian Sikorski > > : > >> > >> Hello, > >> > >> I am trying to bisect an issue which appears to have regressed between > >> 5.18 final and 5.19-rc2. This is somewhat challenging as most of the > >> kernels are since gone from koji, and the ark os-build branch seems to > >> have been rebased after kernel 6.7 release, meaning that the required > >> commits to the redhat folder are not in sync with the commits to the > >> kernel itself. > > > > I'm not sure I'm following this completely - are you saying that (part > > of) the old kernel sources are not there (in git) any more because a > > branch got rebased? > > Well the commits are there in the os-build branch, but they got rebased > on top of 6.7. This means that they are no longer in sync with upstream > kernel commits from the 5.19-rc0 timeframe. > In the meantime I was able to learn that the correct order is still > present in the tags: > > $ git bisect good kernel-5.19.0-0.rc0.fdaf9a5840ac.1 > $ git bisect bad kernel-5.19.0-0.rc0.babf0bb978e3.3 > > I was able to recreate an "os-build-5.19" branch and am finally building > a kernel now. > > > > >> I tried cherry-picking them on top, but it does not apply > >> cleanly either: > >> > >> $ git clone -b os-build g...@gitlab.com:cki-project/kernel-ark.git > >> $ git bisect start > >> $ git bisect bad v5.19-rc2 > >> $ git bisect good v5.18 > >> $ git checkout 2518f226c60d8e04d18ba4295500a5b0b8ac7659 > >> $ git cherry-pick > >> 0dd3ee31125508cd67f7e7172247f05b7fd1753a..6d8a7e484dc667c1094fc90452dee6af30d509f6 > >> > >> Is there a way simpler than trying to fix the cherry-pick conflicts > >> every single time? > > > > `rerere` can be really helpful for something like this. > > > I will have a look if I get stuck again, thanks! > > > I guess you've checked already whether the problem you're trying to > > solve depends on the extra redhat commits. > > I don't think so, there are redhat kernels which both do and do not work. > We do rebase the os-build branch, but I would strongly recommend doing a bisect on Linus' tree (master in kernel-ark) just using the 5.19 config. Doing bisects as rpms are massively time consuming and not worth the effort. If it were a redhat specific patch, you would know that quickly because 5.19-rc2 from Linus' tree would be good instead of bad. In this case, we rarely carry to many patches in any area, you could literally eyeball it and see which patch that we carry is causing the issue. Justin -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bisecting an older kernel
Am 12.02.24 um 10:03 schrieb Michael J Gruber: Am So., 11. Feb. 2024 um 23:14 Uhr schrieb Julian Sikorski : Hello, I am trying to bisect an issue which appears to have regressed between 5.18 final and 5.19-rc2. This is somewhat challenging as most of the kernels are since gone from koji, and the ark os-build branch seems to have been rebased after kernel 6.7 release, meaning that the required commits to the redhat folder are not in sync with the commits to the kernel itself. I'm not sure I'm following this completely - are you saying that (part of) the old kernel sources are not there (in git) any more because a branch got rebased? Well the commits are there in the os-build branch, but they got rebased on top of 6.7. This means that they are no longer in sync with upstream kernel commits from the 5.19-rc0 timeframe. In the meantime I was able to learn that the correct order is still present in the tags: $ git bisect good kernel-5.19.0-0.rc0.fdaf9a5840ac.1 $ git bisect bad kernel-5.19.0-0.rc0.babf0bb978e3.3 I was able to recreate an "os-build-5.19" branch and am finally building a kernel now. I tried cherry-picking them on top, but it does not apply cleanly either: $ git clone -b os-build g...@gitlab.com:cki-project/kernel-ark.git $ git bisect start $ git bisect bad v5.19-rc2 $ git bisect good v5.18 $ git checkout 2518f226c60d8e04d18ba4295500a5b0b8ac7659 $ git cherry-pick 0dd3ee31125508cd67f7e7172247f05b7fd1753a..6d8a7e484dc667c1094fc90452dee6af30d509f6 Is there a way simpler than trying to fix the cherry-pick conflicts every single time? `rerere` can be really helpful for something like this. I will have a look if I get stuck again, thanks! I guess you've checked already whether the problem you're trying to solve depends on the extra redhat commits. I don't think so, there are redhat kernels which both do and do not work. Cheers, Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Bisecting an older kernel
Am So., 11. Feb. 2024 um 23:14 Uhr schrieb Julian Sikorski : > > Hello, > > I am trying to bisect an issue which appears to have regressed between > 5.18 final and 5.19-rc2. This is somewhat challenging as most of the > kernels are since gone from koji, and the ark os-build branch seems to > have been rebased after kernel 6.7 release, meaning that the required > commits to the redhat folder are not in sync with the commits to the > kernel itself. I'm not sure I'm following this completely - are you saying that (part of) the old kernel sources are not there (in git) any more because a branch got rebased? > I tried cherry-picking them on top, but it does not apply > cleanly either: > > $ git clone -b os-build g...@gitlab.com:cki-project/kernel-ark.git > $ git bisect start > $ git bisect bad v5.19-rc2 > $ git bisect good v5.18 > $ git checkout 2518f226c60d8e04d18ba4295500a5b0b8ac7659 > $ git cherry-pick > 0dd3ee31125508cd67f7e7172247f05b7fd1753a..6d8a7e484dc667c1094fc90452dee6af30d509f6 > > Is there a way simpler than trying to fix the cherry-pick conflicts > every single time? `rerere` can be really helpful for something like this. I guess you've checked already whether the problem you're trying to solve depends on the extra redhat commits. Cheers, Michael -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Bisecting an older kernel
Hello, I am trying to bisect an issue which appears to have regressed between 5.18 final and 5.19-rc2. This is somewhat challenging as most of the kernels are since gone from koji, and the ark os-build branch seems to have been rebased after kernel 6.7 release, meaning that the required commits to the redhat folder are not in sync with the commits to the kernel itself. I tried cherry-picking them on top, but it does not apply cleanly either: $ git clone -b os-build g...@gitlab.com:cki-project/kernel-ark.git $ git bisect start $ git bisect bad v5.19-rc2 $ git bisect good v5.18 $ git checkout 2518f226c60d8e04d18ba4295500a5b0b8ac7659 $ git cherry-pick 0dd3ee31125508cd67f7e7172247f05b7fd1753a..6d8a7e484dc667c1094fc90452dee6af30d509f6 Is there a way simpler than trying to fix the cherry-pick conflicts every single time? Best regards, Julian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
