On Fri, Jan 11, 2019 at 09:55:45AM +0100, dot...@gmail.com wrote:
I recently came across an inconsistency in sid that it seems difficult (to me)
to overcome.
A kernel package named linux-image-4.19.0-1-amd64-unsigned provides the running
kernel but, since few days ago, it creates conflicts with the metapackage
linux-image-amd64 (bercause it depends on linux-image-4.19.0-1-amd which, in
turn, conflicts with the installed kernel).
I can't trivially replace the "unsigned" (BTW, what does "unsigned" stand for,
anyway?) version with linux-image-4.19.0-1-amd because of the same version
number.
I'm not really worried because this will probably be solved when moving to the
next kernel release but the situation is a bit annoying.
Is there any solution?
How did you get the unsigned kernel installed in the first place? It's
not typically installed, and I don't see any dependencies that would pull
it in. If it weren't installed there'd be no problem. :) If you have
another kernel already installed, boot into that, then replace the
unsigned kernel with the corresponding kernel that lacks the -unsigned
suffix. If you don't have another kernel installed, try installing an
older one or (as you suggested) wait for the next one. In theory you
should be able to just remove the -unsigned and replace it without
having another kernel available, but it's better to have an alternative
in case something goes wrong.
-unsigned means that the kernel doesn't come with a signature that can
be used for secure boot. It's part of the build process for the signed
kernels, is a reproducible build, and may have other special-purpose
applications, but it is not generally needed.
