Control: reassign -1 bpfcc-tools Control: tag -1 - moreinfo On Mon, 2017-01-02 at 02:14 +0800, Liang Guo wrote: > Hi, > > > On Sun, Jan 1, 2017 at 10:19 PM, Ben Hutchings <ben@decadent.org.uk> wrote: > > Control: reassign -1 src:linux 4.8.11-1 > > Control: severity -1 normal > > Control: tag -1 moreinfo > > The signed and unsigned kernels have exactly the same code. The only > > way they can differe in behaviour is on a system with Secure Boot > > enabled, where the signed one could be bootable (and then disable > > unsigned modules etc.) while the unsigned one does not. > > > > Given that you've been able to boot unsigned kernels, I don't believe > > signing has anything to do with this problem. > > > > You're not comparing the same versions of the signed and unsigned > > kernels, so perhaps there was a regression between 4.7 and 4.8 that was > > corrected between 4.8.11 and 4.8.15. Unfortunately we're not able to > > provide a signed image for 4.8.15-1 as it failed to build on one > > architecture. This should be corrected in the next version. > > > > Please report whether the next update to linux-signed-4.8.0-2-amd64 > > fixes this. > > > > I think I find the problem, when the kernel header don't match the kernel image, > bpfcc will throw Invalid argument exception, following is my test log: They match closely enough for module building, so I think bpfcc's version check might not be correct. [...] > It looks not a kernel bug, but a kernel team's bug. If signed and > unsigned kernel use the same header files, they should have the exact > same version in Debian archive. We can't upload them at the same time, so that's not possible in general. Ben. -- Ben Hutchings All the simple programs have been written, and all the good names taken.
Attachment:
signature.asc
Description: This is a digitally signed message part