Kernel bug was closed because providing logs is impossible, because kernel doesn't boot


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:

1 Like

just re-open it (i think the bot even says so in the commentary text it typically writes)

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 :slight_smile:
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.”

the second one is indeed completely invalid

Bottom line is - generic kernel from Ubuntu repository would have exactly same issue if it would boot, because CONFIG_HID_SENSOR_HUB=m in generic arm64 kernel too. You can check config in boot yourself:

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.

Oliver, is filled against valid kernel. What exactly is wrong with this bugreport? Yes, sdm850-based laptops is supposed to boot with generic arm64 kernel, as most of the necessary code was upstreamed by the time 5.4 was released. And, yes, generic 5.4 kernel from mainline PPA does boot on this laptop.

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?