I found myself in pretty strange circumstances - ubuntu-kernel-bot asked me to provide logs in bugreport where providing logs is impossible due to nature of the issue. And 60 days later it just close unresolved issue. What I should do next time when I have something like this? Here is links to reports for reference:
Oliver, please check second link - I tried this. Bot closed report nevertheless, as you can see, and no one came to disable bot (and old tag âbot-stop-naggingâ no longer works).
ah, sorry, i admittedly did not open the links
the second one is indeed completely invalid, the mainline builds are just for verifying fixes and not supported at all, so this one got properly closed âŚ
the first one is against a kernel that is for IoT boards using a snapdragon 410c SoC, even if you would manage to make it boot on a lenovo device with qualcomm 850 chip it would surely miss a lot of bits and pieces to run more than a very basic commandline system. you should probably try the linux-generic kernel for arm64 here âŚ
you should probably try the linux-generic kernel for arm64 here âŚ
Which is what I did as mentioned in issue description: âI found that both of generic and snapdragon kernels from focal repository (5.4.0-14-generic and 5.4.0-14-snapdragon was tested) does not boot on Lenovo Yoga C630 WOS.â
well, then make sure to file both bugs against valid kernels (linux-generic), bugs against mainline PPA kernels will always be auto-closed (i bet witout anyone even looking at them) and iâm not sure if arm laptops are supposed to work or not with the generic arm64 kernel but in any case both bugs should be filed against a supported package.
Why so? Isnât kernel build config issue have to be communicated with Canonical one way or another?
Also, please notice that I mentioned mainline PPA in second bugreport only because of first issue. You know, I can not fill bugreport about not working keyboard if kernel from Ubuntu repository doesnât even boot.
The only thing âwrongâ with the bug report is you didnât follow the instructions that the bot wrote in its comment:
If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to âConfirmedâ.
You are right, I missed âConfirmedâ part. After looking at bot comment for ten years again and again I didnât bother to read it one more time, which is why I missed this part.
Anyway, what to do with .config issue if kernel from repo does not boot, but will have same issue once âbootâ part will be resolved?