So this is *really* hard to trigger, but it happened for the second
time (in a month?) today when I tried to boot into a newly built
kernel.
What happens is that somehow the build gets confused about the
certificates, and my modules refuse to load with something along the
line of "Request for unknown module key 'Magrathea: Glacier signing
key'" (which is obviously the built-in generated key).
When it happens, I can do a rebuild, and the build will say
X.509 certificate list changed
which is kind of odd, since the list should *always* be just that
single key for me (ie "./signing_key.509").
But even after the rebuild the end result *still* did not work. I
needed to do a "git clean" and rebuild to make it all come out right.
So presumably the modules themselves still had the old stale data, or
something like that. Despite the whole rebuild, and re-installing the
modules and kernel.
As mentioned, this is very rare. I build and boot quite a lot of
kernels particularly during the merge window, and it definitely
doesn't happen every time.
So it really smells like some odd race - I build my kernels with "make
-j16", so there's certainly room for a race or two with any rule that
doesn't have proper dependencies. I don't see it, though.
Anybody see anything fishy in this area?
(Side note: the HHGTTG references are cute, but I suspect we should
rename the key so that it just says something boring like "build-time
autogenerated kernel key" instead. Just so that the error messages are
a bit more readable to people who aren't kernel engineers)
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
