On 14/01/19 11:20 PM, Vincent Lefevre wrote: > On 2019-01-11 09:52:04 -0500, Michael Stone wrote: >> On Fri, Jan 11, 2019 at 09:55:45AM +0100, dotdeb@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. > > Until a few weeks ago, it could be installed due to a "Provides:". > See the following bug I had reported: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916927 > > This problem is now solved, i.e. the "Provides:" was dropped. > But perhaps this is what is causing the *temporary* issue the > user has above. That's how I got that kernel via backports - the unsigned version of 4.19 is the only one available in stretch-backports. What worries me more than it being unsigned is that it appears to be Tainted - is that normal for bpo kernels? I don't remember seeing it in the past. Richard
Attachment:
signature.asc
Description: OpenPGP digital signature